Red Hat Bugzilla – Bug 186952
suspend on g4/ppc tibook gives kernel badness
Last modified: 2008-01-19 23:40:54 EST
Description of problem: Running "pm-suspend" does not work and dumps "Badness in wait_for_ready at drivers/ide/ide-iops.c:516". Details below. Version-Release number of selected component (if applicable): How reproducible: Every time. Steps to Reproduce: 1. Run pm-suspend 2. Look at kernel messages. 3. Actual results: It blanks the screen, but after a few microseconds, returns with the kernel messages displaying this: PM: Entering mem sleep pmac_pm_enter(3) PM: Finishing wakeup. radeonfb (0000:00:10.0): resuming from state: 2... radeonfb (0000:00:10.0): switching to D0 state... agpgart: Putting AGP V2 device at 0000:00:0b.0 into 1x mode agpgart: Putting AGP V2 device at 0000:00:10.0 into 1x mode PM: Writing back config space on device 0001:10:1a.0 at offset 1. (Was 2100003, writing 2100007) eth0: resuming PHY ID: 1410c62, addr: 0 eth1: Airport waking up eth1: New link status: Connected (0001) hda: Enabling Ultra DMA 4 Badness in wait_for_ready at drivers/ide/ide-iops.c:516 Call Trace: [C0393C40] [C0007A50] show_stack+0x54/0x184 (unreliable) [C0393C60] [C000E564] program_check_exception+0x19c/0x520 [C0393CB0] [C000FC24] ret_from_except_full+0x0/0x4c --- Exception: 700 at wait_for_ready+0x94/0xec LR = wait_for_ready+0x3c/0xec [C0393D70] [C005A18C] disable_irq_nosync+0x7c/0x90 (unreliable) [C0393D90] [C01DF410] pmac_ide_do_setfeature+0x108/0x320 [C0393DB0] [C01DF930] pmac_ide_dma_check+0x308/0x490 [C0393DE0] [C01D3740] ide_do_request+0x618/0x8cc [C0393E50] [C01D3D84] ide_intr+0x204/0x240 [C0393E80] [C0059E28] handle_IRQ_event+0x54/0xa8 [C0393EA0] [C0059F80] __do_IRQ+0x104/0x188 [C0393EC0] [C00057E8] do_IRQ+0x4c/0x7c [C0393EE0] [C000FC70] ret_from_except+0x0/0x14 --- Exception: 501 at default_idle+0x3c/0x44 LR = default_idle+0x34/0x44 [C0393FA0] [C00247C0] cpu_idle+0x3c/0x5c (unreliable) [C0393FB0] [C0003E70] rest_init+0x28/0x38 [C0393FC0] [C0394720] start_kernel+0x19c/0x1b0 [C0393FF0] [000037A0] 0x37a0 hdc: Enabling MultiWord DMA 2 Restarting tasks... done pmac_pm_finish(3) Expected results: It should suspend. Additional info:
At dwmw2's request, I have installed the apmud package, and run pmud. This package appears to be in the extras, but I'm including the info here just in case it's useful. (BTW, if this is the only way of getting suspend on the PowerBooks, we should include "apmud" in the core distribution and enable it on PowerBook installs.) With apmud, the laptop goes to sleep, but when it wakes up, the screen turns on but is blank. The machine becomes unpingable, but capslock works. I am trying this from text mode (runlevel 3), as switching back to X doesn't work even without suspend (see #187083). I've tried this both with calling "apm" directly, and with closing the lid. I have seen it work once or twice, but very rarely. When I *have* seen it work, upon return, I see the kernel badness I describe above. Perhaps 187083 and this issue are related ??
What if you run 'snooze' or 'snooze -f'? What if you unload various driver modules before suspending?
Neither work. Or both work rarely (snooze or snooze -f). I disabled as many services in /etc/rc.d/init.d/ as was possible, then I removed as many modules as possible. Still, calling snooze -f, would not work (actually it worked the first time, upon returning displayed the kernel badness described, and the second time it died as usual). So no difference. Here are a list of the remaining modules once I purged everything: Module Size Used by sunrpc 188488 1 ipv6 307364 8 dm_mod 67616 3 ext3 156808 2 jbd 78068 1 ext3 I also tried going into single user mode. No difference.
FWI, this issue is not related to 187083.
Looks like the IDE layer is now calling the DMA restore code at interrupt time, which is a bit dodgy for the powermac... I'm surprised it doesn't cause a problem for me. Then, disable_irq_nosync() should be fine to call at interrupt time too anyway... not sure what the bug on is about at this point
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.
(this is a mass-close to kernel bugs in NEEDINFO state) As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. If you believe that this bug was closed in error, please feel free to reopen this bug.