Hi, I've an iBook G4 and since 2.6.30-rc1 my machine doesn't suspend to RAM. When doing “echo mem > /sys/power/state”, the screen gets black but the fan is still running and the LED of caps lock still works. I can't resume the system. I can only do a reset. I've bisected the problem and found 2ed8d2b as the first bad bug. With 2ed8d2b~1 I can suspend the machine, but not with 2ed8d2b. commit 2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7 Author: Rafael J. Wysocki <rjw@sisk.pl> Date: Mon Mar 16 22:34:06 2009 +0100 PM: Rework handling of interrupts during suspend-resume % cat /proc/cpuinfo processor : 0 cpu : 7455, altivec supported clock : 606.000000MHz revision : 3.3 (pvr 8001 0303) bogomips : 36.73 timebase : 18432000 platform : PowerMac model : PowerBook6,3 machine : PowerBook6,3 motherboard : PowerBook6,3 MacRISC3 Power Macintosh detected as : 287 (iBook G4) pmac flags : 0000001b L2 cache : 256K unified pmac-generation : NewWorld Memory : 640 MB % lspci -v -s 0:10 0000:00:10.0 VGA compatible controller: ATI Technologies Inc M9+ 5C63 [Radeon Mobility 9200 (AGP)] (rev 01) (prog-if 00 [VGA controller]) Subsystem: ATI Technologies Inc Apple iBook G4 2004 Flags: bus master, 66MHz, medium devsel, latency 255, IRQ 48 Memory at 98000000 (32-bit, prefetchable) [size=128M] I/O ports at 0400 [size=256] Memory at 90000000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at f1000000 [size=128K] Capabilities: <access denied> Kernel driver in use: radeonfb Bye, Jörg.
It seems that the timer interrupt is not marked appropriately on your system. Can you please do the following: (1) Try to reproduce the problem in the 'core' test mode, ie. # echo core > /sys/power/pm_test # echo mem > /sys/power/state (2) If you're able to reproduce it with (1), comment out suspend_device_irqs() and resume_device_irqs() in drivers/base/power/main.c and repeat (1)
Timer interrupts don't need to be marked specifically. On PowerPC, they come via a completely different exception vector that isn't related to the PIC, ie, they don't have a matching irq_desc or anything like that, it's just a different code path alltogether, and so will remain enabled until local_irq_disable() has been called.
OK, but the test from comment #1 is still worth doing IMO.
Hi, the test from #1 did fail. After removing these lines, my screen becomes scrambled and the CD-ROM is clicking, on suspend. I had to reset the system to get it working.
Please undo the changes in drivers/base/power/main.c and try the 'devices' test: # echo devices > /sys/power/pm_test # echo mem > /sys/power/state
The device test (from #5) gives the same result as with the patch. After nearly two seconds, the screen gets a white spot which grows and the cd-rom device is clicking. But on a keypress nothing changes and the led of capslock can be turned on and off.
It seems one of the drivers gets stuck in its .suspend() or .suspend_late() callback. The question is which one. Hmm. Please do the following, if possible: * Build the kernel with CONFIG_PM_VERBOSE * Boot without X and with no_console_suspend in the kernel's command line. * Save the output of dmesg to a file * Run 'echo 8 > /proc/sys/kernel/printk' * Run the test from Comment #5 * Tell us what the last few messages printed to the console are * Attach the output of dmesg saved earlier
Created attachment 22654 [details] Output of dmesg before suspend
I attach the dmesg output, but I can't tell what are the last lines printed by the kernel. The screen becomes blank too fast. Do you have an idea, how I can slowdown the suspend? BTW: I can reproduce still this bug with 31-rc5.
The bug is still in 31-rc8. I've used the USB console and net console to gather the kernel output. With the USB console I can't suspend. You can see in the net.log-1 the repeating line: [ 134.699378] therm_adt746x 7-002e: legacy suspend [ 134.699549] usb 4-1: type suspend [ 134.713034] usb usb4: type suspend, may wakeup [ 134.713195] pl2303 ttyUSB0: pl2303_send - failed submitting write urb, error -113 [ 134.713208] pl2303 ttyUSB0: pl2303_send - failed submitting write urb, error -113 [ 134.713456] pl2303 ttyUSB0: pl2303_send - failed submitting write urb, error -113 In net.log-2 (usb console disabled), you can see the machine suspends and wakes up immediatly: [ 71.134865] i2c-powermac i2c-powermac.0: suspend [ 71.135704] gem 0002:20:0f.0: suspend [ 71.136513] eth0: suspending, WakeOnLan disabled [ 77.745789] i2c-powermac i2c-powermac.0: resume This might be the reason why my screen becomes scrambled and doesn't stay blank. I might not get initialized correctly. But you're the experts and you might see something else.
Created attachment 22913 [details] Output at the usb console
Created attachment 22914 [details] net.log-1: Ouput at the net console while usb console is active This suspend failed and didn't reached the point where the screen becomes blank. It looks like a bug in the usb module. The log also contains often these lines: rite urb, error -113 ttyUSB0: pl2303_send - failed submitting write urb, error -113 rite urb, error -113 <3>[ 135.139035] pl2303 ttyUSB0: pl2303_send - failed submitting write urb, error -113 and [ 135.221589] pl2303 ttyUSB0: pl2303_send - failed submittin<3>[ 135.301771] pl2303 ttyUSB0: pl2303_send - fail I don't know if something with the recording (nc -u -l 6666) was wrong or if the netconsole send this broken data. Maybe, due to the massive amount of messages the netconsole stumbled.
Created attachment 22915 [details] net.log-2: Output at the netconsole with disabled usb console
Hmm. I wonder if this is a duplicate of bug #13950, then?
I don't think so. I've disabled USB support (CONFIG_USB_SUPPORT=n) and my iBook still don't suspend.
Please test if this patch fixes the issue for you: http://patchwork.kernel.org/patch/49462/
It doesn't solve the problem completely. Now, the iBook goes fully asleep and the LED of caps lock turns off. But after pressing a key and waking up the machine, the CD makes the usual noice, but the screen stays blank. So, with this patch sleeping works, but not waking up.
With the new version 2.6.32-rc5 my iBook fells asleep and wakes up correctly.
Fixed by commit 11a50873ef2b3c1c3fe99a661c22c08f35d93553 .