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
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
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: 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.
Meeting started by jforbes at 19:00:20 UTC
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).
People present (lines said)
Generated by MeetBot 0.1.4.
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.
>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
@@ -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
@@ -72,6 +72,7 @@ int imx_drm_crtc_id(struct imx_drm_crtc *crtc)
static void imx_drm_driver_lastclose(struct drm_device *drm)
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,
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.
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?
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
If you have questions/comments please let me know.
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.
Daniel pointed me to this patch the other day and asked to get it into
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
@@ -18,6 +18,8 @@
@@ -369,7 +371,11 @@ static int evdev_release(struct inode *inode, struct file *file)
+ if (is_vmalloc_addr(client))
@@ -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;
- client = kzalloc(sizeof(struct evdev_client) +
- bufsize * sizeof(struct input_event),
+ client = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
+ if (!client)
+ client = vzalloc(size);
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: