From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1 Description of problem: When S3 suspending, I get the following kernel panic: codec_semaphore: semaphore is not ready [0x1][0x700300] codec_write 1: semaphore is not ready for register 0x26 Back to C! Debug: sleeping function called from invalid context at mm/slab.c:2090 in_atomic():0, irqs_disabled():1 [<c015beb4>] kmem_cache_alloc+0x63/0x78 [<c02480b2>] acpi_pci_link_set+0x3f/0x17f [<c02484e9>] irqrouter_resume+0x14/0x28 [<c029155e>] sysdev_resume+0x3d/0xb5 [<c02957dd>] device_power_up+0x5/0xa [<c014a104>] suspend_enter+0x2a/0x32 [<c014a17e>] enter_state+0x49/0x54 [<c0245596>] acpi_system_write_sleep+0x5a/0x6c [<c024553c>] acpi_system_write_sleep+0x0/0x6c [<c017b878>] vfs_write+0x9e/0x110 [<c017b995>] sys_write+0x41/0x6a [<c0103a1d>] syscall_call+0x7/0xb Suspending was working perfectly under FC3 so something is new in FC4. Bug #136993 seems to be similiar but was posted last year for FC3T3 so I don't know if this is a duplicate or not. Version-Release number of selected component (if applicable): kernel-2.6.11-1.1226_FC4 How reproducible: Always Steps to Reproduce: 1. have an up to date FC4+devel laptop (mine is a Dell Inspiron 600m) 2. suspend it 3. resume it Actual Results: Kernel error in the logs. Everything seems to be working most of the time, although I do get resumes that just hang. Additional info:
*** Bug 134905 has been marked as a duplicate of this bug. ***
With the 2.6.12-1398 kernel, I no longer have this problem. I'd forgotton about this bug and I'm not sure how many releases back it worked without the error but 1398 definitely works.
This bug is still active. A couple other people have reported it with the 2.6.12-1398_FC4 kernel and a look through the source shows that it hasn't been fixed.
*** Bug 136993 has been marked as a duplicate of this bug. ***
*** Bug 167394 has been marked as a duplicate of this bug. ***
*** Bug 164708 has been marked as a duplicate of this bug. ***
Well, here is the one from 2.6.13-1.1532_FC4 on i686 and with somewhat different backtrace Debug: sleeping function called from invalid context at mm/slab.c:2129 in_atomic():0, irqs_disabled():1 [<c0176913>] kmem_cache_alloc+0x3c/0x4e [<c029951e>] acpi_pci_link_set+0x3f/0x17f [<c0299a86>] irqrouter_resume+0x1e/0x3c [<c02e7bcd>] sysdev_resume+0x3d/0xb5 [<c02ec501>] device_power_up+0x5/0xa [<c015eaf8>] suspend_enter+0x44/0x46 [<c015ea5a>] suspend_prepare+0x63/0xbd [<c015eb6e>] enter_state+0x49/0x54 [<c015ec69>] state_store+0x81/0x8f [<c015ebe8>] state_store+0x0/0x8f [<c020f24a>] subsys_attr_store+0x1e/0x22 [<c020f454>] flush_write_buffer+0x22/0x28 [<c020f4a8>] sysfs_write_file+0x4e/0x73 [<c020f45a>] sysfs_write_file+0x0/0x73 [<c01a1017>] vfs_write+0xa2/0x15a [<c01a117a>] sys_write+0x41/0x6a [<c0104465>] syscall_call+0x7/0xb
The same backtrace as mentioned by Michal in #7 happens on my Thinkpad X30 laptop as well -- I've "acpi_sleep=s3_bios" in kernel options, and when I resume from suspend I get that backtrace. Everything seems to continue to work, though.
Debug: sleeping function called from invalid context at mm/slab.c:2486 in_atomic():0, irqs_disabled():1 [<c0143cdc>] kmem_cache_alloc+0x40/0x56 [<c02067ae>] acpi_pci_link_set+0x3f/0x17f [<c0206d16>] irqrouter_resume+0x1e/0x3c [<c02398fa>] __sysdev_resume+0x11/0x6b [<c0239bb8>] sysdev_resume+0x34/0x52 [<c023db51>] device_power_up+0x5/0xa [<c0136458>] suspend_enter+0x44/0x46 [<c01363ba>] suspend_prepare+0x63/0xbd [<c01364ce>] enter_state+0x49/0x54 [<c01365c9>] state_store+0x81/0x8f [<c0136548>] state_store+0x0/0x8f [<c0193c6a>] subsys_attr_store+0x1e/0x22 [<c0193e77>] flush_write_buffer+0x22/0x28 [<c0193ece>] sysfs_write_file+0x51/0x76 [<c0193e7d>] sysfs_write_file+0x0/0x76 [<c0158c76>] vfs_write+0xa2/0x15a [<c0158dd9>] sys_write+0x41/0x6a [<c0102edd>] syscall_call+0x7/0xb just an update showing that this problem is still unresolved in FC4... This is 2.6.14-1636 from davej's test kernel repo...
Debug: sleeping function called from invalid context at mm/slab.c:2486 in_atomic():0, irqs_disabled():1 [<c0143e9c>] kmem_cache_alloc+0x40/0x56 [<c020696e>] acpi_pci_link_set+0x3f/0x17f [<c0206ed6>] irqrouter_resume+0x1e/0x3c [<c0239aba>] __sysdev_resume+0x11/0x6b [<c0239d78>] sysdev_resume+0x34/0x52 [<c023dd11>] device_power_up+0x5/0xa [<c0136618>] suspend_enter+0x44/0x46 [<c013657a>] suspend_prepare+0x63/0xbd [<c013668e>] enter_state+0x49/0x54 [<c0136789>] state_store+0x81/0x8f [<c0136708>] state_store+0x0/0x8f [<c0193e2a>] subsys_attr_store+0x1e/0x22 [<c0194037>] flush_write_buffer+0x22/0x28 [<c019408e>] sysfs_write_file+0x51/0x76 [<c019403d>] sysfs_write_file+0x0/0x76 [<c0158e36>] vfs_write+0xa2/0x15a [<c0158f99>] sys_write+0x41/0x6a [<c0102edd>] syscall_call+0x7/0xb addresses changed a little but otherwise all is the same... This is 2.6.14-1637_FC4
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
Please see comment #10
Marking as 'devel', as the same bug still appears there, and will get fixed there first, and propagate back to FC4 eventually.
*** Bug 154610 has been marked as a duplicate of this bug. ***
FWIW, still happens on kernel-2.6.15-1.1823_FC4 as well.
Still happening on: 2.6.15-1.1854_FC5
The same "sleeping function called from invalid context" happens with 2.6.14-1.1653_FC4 and 2.6.14-1.1656_FC4 but there is another nasty regress here. With 2.6.14-1.1653_FC4 I have to do 'modprobe -r button' on a laptop suspend or a box goes into an infinite loop of suspend/wake-up cycles. If I will do 'modprobe -r button' then I have to do 'modprobe button' on a wake-up or I will be not able anymore to suspend with a power button or by closing a lid. This can be automated in scripts used by "action" in /etc/acpi/even/*.conf files so this is bearable if hacky. 2.6.14-1.1656_FC4 does not require the above but something worse happens. Every time I tried then on the at most second wake-up, and sometimes on the first one, my laptop simply reboots instead of returning from a suspend. Not very useful. It is better just to shutdown cleanly. A wakeup after the first suspend usually works but that is about it. I do not need to mention that I do not have any useful log traces from such reboots. It appears that a laptop starts waking and then its screen blinks and you are seeing a boot-from-scratch sequence.
A regress described in comment #17 seems to be gone with 2.6.15-1.1830_FC4. Yay! But here is another sample of "sleeping function called from invalid context"; this time from 2.6.15-1.1830_FC4 (i686). It is more detailed in an acpi part. Debug: sleeping function called from invalid context at mm/slab.c:2499 in_atomic():0, irqs_disabled():1 [<c01462f3>] kmem_cache_alloc+0x40/0x4f [<c0202c85>] acpi_os_acquire_object+0xb/0x3c [<c02171b1>] acpi_ut_allocate_object_desc_dbg+0x13/0x49 [<c021704b>] acpi_ut_create_internal_object_dbg+0xf/0x5e [<c02136d4>] acpi_rs_set_srs_method_data+0x3d/0xb9 [<c021aa3d>] acpi_pci_link_set+0x102/0x17b [<c021aecb>] irqrouter_resume+0x1e/0x3c [<c024d921>] __sysdev_resume+0x11/0x6b [<c024dbde>] sysdev_resume+0x34/0x52 [<c0251cb7>] device_power_up+0x5/0xa [<c0138787>] suspend_enter+0x44/0x46 [<c01386e5>] suspend_prepare+0x63/0xc1 [<c0138813>] enter_state+0x5e/0x7c [<c013894c>] state_store+0x81/0x8f [<c01388cb>] state_store+0x0/0x8f [<c0196a0a>] subsys_attr_store+0x1e/0x22 [<c0196c12>] flush_write_buffer+0x22/0x28 [<c0196c64>] sysfs_write_file+0x4c/0x71 [<c0196c18>] sysfs_write_file+0x0/0x71 [<c015b2c9>] vfs_write+0xa2/0x15a [<c015b42c>] sys_write+0x41/0x6a [<c0102e75>] syscall_call+0x7/0xb
I have a Dell Latitude D610, and I notice the same thing: when suspending on the 2.6.14-1.1656_FC4 kernel, it says "sleeping function called from invalid context" and then hangs after suspend. However, there is an even stranger twist. When I patched this kernel with Software Suspend 2 (swsusp2) (note: this is for suspend-to-disk), and THEN tried suspend-to-RAM, it worked just fine (although the same debug message occurred). This seems incredibly strange to me, and I don't see how this patch could affect ACPI functionality at all. (Note: for anyone who wishes to try this, swsusp2-patched Fedora kernel RPM's are available at http://mhensler.de/swsusp/ ... the 2.6.14-1.1656 patched kernel worked for me.) Even stranger: when I got the swsusp2-patched 2.6.15-1.1825 kernel, suspend-to-RAM no longer works. The debug message is gone, but the system hangs after suspend. Very, very strange. (In reply to comment #17) > The same "sleeping function called from invalid context" happens with > 2.6.14-1.1653_FC4 and 2.6.14-1.1656_FC4 but there is another nasty regress > here. > > With 2.6.14-1.1653_FC4 I have to do 'modprobe -r button' on a laptop suspend > or a box goes into an infinite loop of suspend/wake-up cycles. If I will do > 'modprobe -r button' then I have to do 'modprobe button' on a wake-up or > I will be not able anymore to suspend with a power button or by closing a lid. > This can be automated in scripts used by "action" in /etc/acpi/even/*.conf > files so this is bearable if hacky. > > 2.6.14-1.1656_FC4 does not require the above but something worse happens. Every > time I tried then on the at most second wake-up, and sometimes on the first one, > my laptop simply reboots instead of returning from a suspend. Not very > useful. It is better just to shutdown cleanly. A wakeup after the first > suspend usually works but that is about it. > > I do not need to mention that I do not have any useful log traces from such > reboots. It appears that a laptop starts waking and then its screen blinks > and you are seeing a boot-from-scratch sequence. >
This seems to have gotten worse in kernel-2.6.16-1.2066_FC4: when resuming from suspend, the kernel gets a NULL pointer deref and doesn't recover: <4<1> Unable to handle NULL pointer dereference at virtual address 00000038 printing eip: (but eip printing is empty, at least on console.) So, I'm raising severity to 'high'...
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
Tested with kernel 2.6.18-1.2200.fc5 and here is the trace message: Stopping tasks: ==============================================================================================================================| pnp: Device 00:09 disabled. Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Back to C! BUG: sleeping function called from invalid context at kernel/rwsem.c:20 in_atomic():0, irqs_disabled():1 [<c0403f10>] dump_trace+0x69/0x1af [<c040406e>] show_trace_log_lvl+0x18/0x2c [<c04045e9>] show_trace+0xf/0x11 [<c0404673>] dump_stack+0x15/0x17 [<c042ef78>] down_read+0x12/0x1f [<c0427923>] blocking_notifier_call_chain+0xe/0x29 [<c05970df>] cpufreq_resume+0x118/0x13f [<c053f3d4>] __sysdev_resume+0x20/0x53 [<c053f515>] sysdev_resume+0x16/0x47 [<c05435a1>] device_power_up+0x5/0xa [<c0436861>] suspend_enter+0x3b/0x44 [<c0436997>] enter_state+0x12d/0x14f [<c0436a3e>] state_store+0x85/0x99 [<c04969ea>] subsys_attr_store+0x1e/0x22 [<c0496adc>] sysfs_write_file+0xa6/0xcc [<c0461292>] vfs_write+0xa8/0x159 [<c04617d8>] sys_write+0x41/0x67 [<c0402d9b>] syscall_call+0x7/0xb DWARF2 unwinder stuck at syscall_call+0x7/0xb Leftover inexact backtrace:
That's a different bug to the one filed here. (That one is tracked in bug 211590) The original bug tracked here should be fixed now.