kernel November 2013

kernel@lists.fedoraproject.org

27 participants
25 discussions

Patch reason tracking
by Josh Boyer 20 Nov '13

20 Nov '13

Hi All, Every month I'm trying to publish a Fedora Kernel patch report that lists all of our patches and why we are carrying them. Thankfully, the past couple of times I've done this it's been pretty clear that for the most part we're just carrying fixes queued up to head to Linus soon. However, it also means I have to track down the status of that patch every month. I've been trying to keep PatchList.txt up to date, but that isn't scaling very well as it's easy for people to forget to add patches to it or remove them when we drop the patch. To help this tracking, I'd like to push the status information into each patch itself. What I propose is basically to fields at the top of each patch: Bugzilla: Upstream-status: The first is fairly self-evident. It just list the Red Hat Bugzilla number associated with the patch. If there isn't one, just put N/A. Upstream-status is fairly free-form at the moment, but the intention is to briefly capture when the patch is going to hit Linus' tree, or some other subsystem tree. This can be done fairly simply e.g.: Upstream-status: 3.13 Upstream-status: queued in net-next for 3.14 Upstream-status: <link to lkml or other mailing list thread> Upstream-status: Fedora Mustard Eventually I plan on writing a tool to scrape this information together for the report, but I wanted to get some feedback on the two fields for now. Do they seem pretty straight-forward? Do you have questions or other ideas/suggestions? If nobody screams much, I'll likely update all the patches in F20 and rawhide this week (I've already done some of them.) If we eventually get to some kind of patchwork style tracker, this shouldn't interfere at all and might actually help reviewers. Thanks. josh

2 2

Fedora Kernel Meeting Minutes 11-15-13
by Justin Forbes 15 Nov '13

15 Nov '13

Meeting started by jforbes at 19:00:20 UTC Full logs: http://meetbot.fedoraproject.org/fedora-meeting/2013-11-15/fedora-meeting.2… Meeting summary Who's here? (jforbes, 19:00:33) releases (jforbes, 19:01:36) Users wishing to run 3.12 on stable releases should use the rawhide-nodebug repository until Fedora 20 ships (jforbes, 19:04:43) http://jforbes.livejournal.com/14128.html (jforbes, 19:04:54) rawhide (jforbes, 19:05:37) Trinity (jforbes, 19:07:50) Test/QA (jforbes, 19:10:25) open floor (jforbes, 19:18:33) Meeting ended at 19:25:13 UTC (full logs). Action items (none) People present (lines said) jforbes (36) davej (27) nirik (4) zodbot (2) Generated by MeetBot 0.1.4.

1 0

[PATCH 3.13] Fix imx-drm build
by Josh Boyer 12 Nov '13

12 Nov '13

Bugzilla: N/A Upstream-status: https://lkml.org/lkml/2013/11/12/413 (hopefully 3.13) I turned off imx-drm yesterday because it doesn't link with the config options we have set. This fixes it. josh >From ce4a59012b5f2a9b521cad4610f055a792841951 Mon Sep 17 00:00:00 2001 From: Josh Boyer <jwboyer(a)fedoraproject.org> Date: Tue, 12 Nov 2013 11:03:57 -0500 Subject: [PATCH] staging: imx-drm: Fix modular build of DRM_IMX_IPUV3 commit b8d181e408af (staging: drm/imx: add drm plane support) added a file to the make target for DRM_IMX_IPUV3 but didn't adjust the objs required to actually build that as a module. Kbuild got confused and this lead to link errors like: ERROR: "ipu_plane_disable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined! ERROR: "ipu_plane_enable" [drivers/staging/imx-drm/ipuv3-crtc.ko] undefined! Additionally, it added a call to imx_drm_crtc_id which also fails with a link error as above. To fix this, we adjust the make target with the proper objs, which will change the name of the resulting .ko. We also add an EXPORT_SYMBOL_GPL for imx_drm_crtc_id. Signed-off-by: Josh Boyer <jwboyer(a)fedoraproject.org> --- drivers/staging/imx-drm/Makefile | 4 +++- drivers/staging/imx-drm/imx-drm-core.c | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile index 2c3a9e1..8742432 100644 --- a/drivers/staging/imx-drm/Makefile +++ b/drivers/staging/imx-drm/Makefile @@ -8,4 +8,6 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/ -obj-$(CONFIG_DRM_IMX_IPUV3) += ipuv3-crtc.o ipuv3-plane.o + +imx-ipuv3-crtc-objs := ipuv3-crtc.o ipuv3-plane.o +obj-$(CONFIG_DRM_IMX_IPUV3) += imx-ipuv3-crtc.o diff --git a/drivers/staging/imx-drm/imx-drm-core.c b/drivers/staging/imx-drm/imx-drm-core.c index 4483d47..2b366d8 100644 --- a/drivers/staging/imx-drm/imx-drm-core.c +++ b/drivers/staging/imx-drm/imx-drm-core.c @@ -72,6 +72,7 @@ int imx_drm_crtc_id(struct imx_drm_crtc *crtc) { return crtc->pipe; } +EXPORT_SYMBOL_GPL(imx_drm_crtc_id); static void imx_drm_driver_lastclose(struct drm_device *drm) { -- 1.8.3.1

1 0

qxl patch
by David Airlie 10 Nov '13

10 Nov '13

Hey guys, Since I think we are trying to calm down the random gpu hacker commits to fedora kernel, I said I'd let you guys do all the hard work, http://cgit.freedesktop.org/~airlied/linux/commit/?h=qxl-fedora-queue&id=db… I'd like to get that patch into as many fedora's as possible, it seems to apply okay on 3.11 and 3.12 for me, They are all backports from drm-next that I wasn't game to stable yet but I think we'd like in Fedora as they avoid some issues, they are also mostly in <redacted> enterprise. Dave.

2 5

VT-d and x2apic: broken resume after suspend to ram
by Peter Senna 10 Nov '13

10 Nov '13

Hi, I'm trying to fix a bug that is affecting me for more than two years now. It is happening in a Toshiba R830-10P notebook. I've filled a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=787299 And recently asked for help on the LKML: https://lkml.org/lkml/2013/11/1/186 The issue is that trying to resume after suspending to ram freezes the computer. The resume starts well, but then it hangs. I found that this may be related to VT-d / x2apic. If I disable VT-d on the BIOS, suspend / resume works fine. If I enable VT-d and pass nox2apic as boot parameter to Kernel suspend and resume works fine. Any ideas on how to debug this issue without a serial port? Thanks! -- Peter

1 0

3.13 kernel rebase
by Josh Boyer 10 Nov '13

10 Nov '13

Hi All, I'll be starting the 3.13 rebase on Monday in rawhide. As previously discussed, we'll keep rawhide-nodebug on 3.12 in the stabilization branch and use that as the base for rolling 3.12 back to F20 and older releases. If you have questions/comments please let me know. josh

2 1

Workstation product kernel requirements
by Josh Boyer 09 Nov '13

09 Nov '13

Hi All, My apologies for sending this out so late compared to the other product queries. I will simply claim that I hope the current Fedora kernel is already meeting desktop/workstation needs and my delay was partially because of that ;). At any rate, the kernel team would like to know what you see as the requirements for the Workstation product. Thus far the discussions with the other product groups has mostly centered around packaging changes. I would imagine Workstation doesn't particularly suffer from anything in the current packaging, and could likely share a common packaging scheme with Server for the most part. However, if that isn't the case please let us know what you'd like to see from a packaging standpoint, keeping in mind we want a single main kernel package across all 3 products as much as possible. On IRC, Matthias mentioned some issues around interactivity and I/O. If there are other things like that, please speak to those as well. Thanks for your time. josh

7 16

[PATCH 3.11 3.12] Avoid high-order allocations in evdev
by Josh Boyer 08 Nov '13

08 Nov '13

Daniel pointed me to this patch the other day and asked to get it into Fedora. josh Bugzilla: N/A Upstream-status: Queued for 3.13 >From 92eb77d0ffbaa71b501a0a8dabf09a351bf4267f Mon Sep 17 00:00:00 2001 From: Daniel Stone <daniel(a)fooishbar.org> Date: Thu, 31 Oct 2013 07:25:34 +0000 Subject: Input: evdev - fall back to vmalloc for client event buffer evdev always tries to allocate the event buffer for clients using kzalloc rather than vmalloc, presumably to avoid mapping overhead where possible. However, drivers like bcm5974, which claims support for reporting 16 fingers simultaneously, can have an extraordinarily large buffer. The resultant contiguous order-4 allocation attempt fails due to fragmentation, and the device is thus unusable until reboot. Try kzalloc if we can to avoid the mapping overhead, but if that fails, fall back to vzalloc. Signed-off-by: Daniel Stone <daniels(a)collabora.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> --- diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c index b6ded17..a06e125 100644 --- a/drivers/input/evdev.c +++ b/drivers/input/evdev.c @@ -18,6 +18,8 @@ #include <linux/poll.h> #include <linux/sched.h> #include <linux/slab.h> +#include <linux/vmalloc.h> +#include <linux/mm.h> #include <linux/module.h> #include <linux/init.h> #include <linux/input/mt.h> @@ -369,7 +371,11 @@ static int evdev_release(struct inode *inode, struct file *file) mutex_unlock(&evdev->mutex); evdev_detach_client(evdev, client); - kfree(client); + + if (is_vmalloc_addr(client)) + vfree(client); + else + kfree(client); evdev_close_device(evdev); @@ -389,12 +395,14 @@ static int evdev_open(struct inode *inode, struct file *file) { struct evdev *evdev = container_of(inode->i_cdev, struct evdev, cdev); unsigned int bufsize = evdev_compute_buffer_size(evdev->handle.dev); + unsigned int size = sizeof(struct evdev_client) + + bufsize * sizeof(struct input_event); struct evdev_client *client; int error; - client = kzalloc(sizeof(struct evdev_client) + - bufsize * sizeof(struct input_event), - GFP_KERNEL); + client = kzalloc(size, GFP_KERNEL | __GFP_NOWARN); + if (!client) + client = vzalloc(size); if (!client) return -ENOMEM; -- cgit v0.9.2

1 0

Will F20 release with a 3.12 kernel now that it has slipped?
by Bruno Wolff III 07 Nov '13

07 Nov '13

Has F20 slipped enough that now it is practical to release with a 3.12 kernel?

3 3

Rawhide nodebug and the 3.12 kernel
by Justin Forbes 07 Nov '13

07 Nov '13

We have a slight issue with the 3.12 kernel timing in that it is too late to push it into Fedora 20, but too far away from the Fedora 20 release to just ignore the 3.13 development cycle until we can push 3.12. As a result, we will be tracking 3.12 and stable updates for it in the rawhide-nodebug repository. This gives us a chance to keep it built and tested on all primary architectures, and make sure we are in good shape to push 3.12 out as an update as soon as possible. Once 3.12 can be pushed to releases, the rawhide-nodebug repository will return to doing non debug builds of rawhide, tracking Linus' tree upstream. I will let everyone know that is happening through the same channels with a couple of days notice. More information on the rawhide-nodebug repository can be found at: http://fedoraproject.org/wiki/RawhideKernelNodebug Thanks, Justin

6 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel November 2013