On boot BUG: sleeping function called from invalid context at kernel/mutex.c:413 in_atomic(): 1, irqs_disabled(): 1, pid: 718, name: Xorg INFO: lockdep is turned off. irq event stamp: 621296 hardirqs last enabled at (621295): [<ffffffff81722296>] _raw_spin_unlock_irqrestore+0x36/0x70 hardirqs last disabled at (621296): [<ffffffff8172215f>] _raw_spin_lock_irq+0x1f/0x90 softirqs last enabled at (621218): [<ffffffff81070ff3>] __do_softirq+0x193/0x400 softirqs last disabled at (621201): [<ffffffff81071425>] irq_exit+0xb5/0xc0 CPU: 1 PID: 718 Comm: Xorg Not tainted 3.10.0-0.rc0.git10.1.fc20.x86_64 #1 Hardware name: Gigabyte Technology Co., Ltd. EP45-DS5/EP45-DS5, BIOS F12 09/30/2008 ffffffff81a19574 ffff88010934dc70 ffffffff8171a781 ffff88010934dc98 ffffffff810a2639 0000000000000000 ffff880123420000 ffff8801091fa6e0 ffff88010934dd20 ffffffff8171ebbb ffff8800b60fdd97 ffff88010934dd10 Call Trace: [<ffffffff8171a781>] dump_stack+0x19/0x1b [<ffffffff810a2639>] __might_sleep+0x179/0x230 [<ffffffff8171ebbb>] mutex_lock_nested+0x3b/0x400 [<ffffffff8136001c>] ? vsnprintf+0x20c/0x670 [<ffffffff815930c7>] hid_debug_event+0x37/0x100 [<ffffffff815932ec>] hid_dump_input+0x5c/0x90 [<ffffffff815943a1>] hid_set_field+0x41/0x110 [<ffffffff815a2383>] usb_hidinput_input_event+0x93/0x110 [<ffffffff81538d6e>] input_handle_event+0x8e/0x530 [<ffffffff81539430>] input_inject_event+0x1b0/0x250 [<ffffffff815392c3>] ? input_inject_event+0x43/0x250 [<ffffffff8153d70f>] evdev_write+0xef/0x150 [<ffffffff811dc422>] vfs_write+0xa2/0x170 [<ffffffff811dca0c>] SyS_write+0x4c/0xa0 [<ffffffff8172bf99>] system_call_fastpath+0x16/0x1b
The upstream discussion: http://www.spinics.net/lists/linux-input/msg25668.html the HID maintainer is aware of the problem now and a fix should come soon.
Are you able to pick, build and test patch? 1deb9d3 HID: debug: fix RCU preemption issue
*** Bug 961516 has been marked as a duplicate of this bug. ***
This should be fixed with commit 1deb9d341d475ff84262e927d6c0e36fecb9942e which is in 3.10-rc1.
$ git describe 1deb9d341d475ff84262e927d6c0e36fecb9942e v3.9-3620-g1deb9d3 which is in 3.10.0-0.rc0.git10.1.fc20.x86_64 and still happens.
(In reply to comment #5) > $ git describe 1deb9d341d475ff84262e927d6c0e36fecb9942e > v3.9-3620-g1deb9d3 That means it was in Jiri's tree at that point. But the date on the patch is May 6 2013, which means it's impossible it was in a kernel built on May 1. It wasn't merged into Linus' tree (and therefore rawhide) until commit f755407dd19072b7d20719bc5454caed9ab41cc1, which was on May 10. The best way to see if a non-merge commit is in rawhide is to use --contains. [jwboyer@zod linux]$ git describe --contains 1deb9d341d475ff84262e927d6c0e36fecb9942e v3.10-rc1~13^2