Additional info: BUG: sleeping function called from invalid context at kernel/mutex.c:413 in_atomic(): 1, irqs_disabled(): 1, pid: 369, name: X INFO: lockdep is turned off. irq event stamp: 581003882 hardirqs last enabled at (581003881): [<ffffffff81726b06>] _raw_spin_unlock_irqrestore+0x36/0x70 hardirqs last disabled at (581003882): [<ffffffff8172732b>] _raw_spin_lock_irqsave+0x2b/0xa0 softirqs last enabled at (581003722): [<ffffffff8160efc1>] netlink_poll+0x141/0x1e0 softirqs last disabled at (581003720): [<ffffffff81726848>] _raw_spin_lock_bh+0x18/0x80 CPU: 1 PID: 369 Comm: X Not tainted 3.10.0-0.rc0.git15.1.fc20.x86_64 #1 Hardware name: /DG33FB , BIOS DPP3510J.86A.0572.2009.0715.2346 07/15/2009 ffffffff81a1bd8c ffff880185899c60 ffffffff8171f091 ffff880185899c88 ffffffff810a3239 0000000000000000 ffff88019f034000 ffff880185984dc0 ffff880185899d10 ffffffff8172342b ffff880173e3bb1f ffff880185899d00 Call Trace: [<ffffffff8171f091>] dump_stack+0x19/0x1b [<ffffffff810a3239>] __might_sleep+0x179/0x230 [<ffffffff8172342b>] mutex_lock_nested+0x3b/0x400 [<ffffffff81361a6c>] ? vsnprintf+0x20c/0x670 [<ffffffff815958f7>] hid_debug_event+0x37/0x100 [<ffffffff81595b1c>] hid_dump_input+0x5c/0x90 [<ffffffff81596bd1>] hid_set_field+0x41/0x110 [<ffffffff815a4bb3>] usb_hidinput_input_event+0x93/0x110 [<ffffffff8153b92e>] input_handle_event+0x8e/0x530 [<ffffffff8153bff0>] input_inject_event+0x1b0/0x250 [<ffffffff8153be83>] ? input_inject_event+0x43/0x250 [<ffffffff815402df>] evdev_write+0xef/0x150 [<ffffffff811dd410>] vfs_write+0xc0/0x1f0 [<ffffffff811fc479>] ? fget_light+0xf9/0x510 [<ffffffff811dddcc>] SyS_write+0x4c/0xa0 [<ffffffff817307d9>] system_call_fastpath+0x16/0x1b
Created attachment 743853 [details] File: dmesg
Are you still seeing this with later 3.10 kernels?
Slight delay in getting back as since then have upgraded the system config ... now has a new 2 TB hdd and Fedora 19. uname -a Linux localhost.localdomain 3.11.0-0.rc1.git1.2.fc20.x86_64 fdisk -l Disk /dev/sda: 2000.4 GB, 2000398934016 bytes, 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk label type: dos Disk identifier: 0x0006ed08 Device Boot Start End Blocks Id System /dev/sda1 * 2048 1435647 716800 83 Linux /dev/sda2 1435648 165275647 81920000 83 Linux /dev/sda3 165275648 329115647 81920000 83 Linux /dev/sda4 329117696 3907029167 1788955736 83 Linux e4defrag version 2.0 e4defrag -v /dev/sda1 runs fine (/boot) e4defrag -v /dev/sda2 runs fine (/home) e4defrag -v /dev/sda4 runs fine (/data) e4defrag -v /dev/sda3 crashes and the system hangs this is the (/) partition have to hard reset the system. ==== dmesg snip ======= [ 0.867021] ata1: SATA max UDMA/133 abar m2048@0xe02a5000 port 0xe02a5100 irq 46 [ 0.867025] ata2: SATA max UDMA/133 abar m2048@0xe02a5000 port 0xe02a5180 irq 46 [ 0.867027] ata3: SATA max UDMA/133 abar m2048@0xe02a5000 port 0xe02a5200 irq 46 [ 0.867029] ata4: SATA max UDMA/133 abar m2048@0xe02a5000 port 0xe02a5280 irq 46 [ 0.867032] ata5: SATA max UDMA/133 abar m2048@0xe02a5000 port 0xe02a5300 irq 46 [ 0.867034] ata6: SATA max UDMA/133 abar m2048@0xe02a5000 port 0xe02a5380 irq 46 [ 1.173039] ata4: SATA link down (SStatus 0 SControl 300) [ 1.174035] ata3: SATA link down (SStatus 0 SControl 300) [ 1.174055] ata1: SATA link down (SStatus 0 SControl 300) [ 1.176041] ata5: SATA link down (SStatus 0 SControl 300) [ 1.177039] ata6: SATA link down (SStatus 0 SControl 300) [ 1.327043] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 1.327613] ata2.00: ATA-9: WDC WD20EZRX-00DC0B0, 80.00A80, max UDMA/133 [ 1.327616] ata2.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA [ 1.328198] ata2.00: configured for UDMA/133 ==== dmesg snip =======
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
*********** MASS BUG UPDATE ************** This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested.