Subject : Re: Suspend to disk broken in latest 2.6.28-rc3 Submitter : Jens Axboe <jens.axboe@oracle.com> Date : 2008-11-12 18:42 References : http://marc.info/?l=linux-kernel&m=122651551216820&w=4 Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org> This entry is being used for tracking a regression from 2.6.27. Please don't close it until the problem is fixed in the mainline.
I can reproduce this on Toshiba Portege R500. The behavior is the same as on the Jens' box: - suspend to RAM and resume succeeds 100% of the time from the console - resume fails 90% of the time from under X - resume from hibernation is also broken if hibernated from under X - suspend to RAM / resume works with 2.6.27.7 The box is all Intel, so suspend/resume ought to work on it. I suspect there's a problem with DRM.
Does this look similar: http://sourceforge.net/mailarchive/message.php?msg_name=492A3485.5030407%40gmail.com Do you run compiz:
Yeah, I wonder if this is a DUP of the irq install/uninstall problem. If so, VT switch would probably also hang.
No, VT switches don't hang on this box.
Created attachment 19007 [details] Patch fixing the issue on Toshiba Portege R500 This patch form Keith Packard fixes the issue on Toshiba Portege R500.
Patch : http://bugzilla.kernel.org/attachment.cgi?id=19007&action=view
Notify-Also : Maxim Levitsky <maximlevitsky@gmail.com>
There's also a fix for resume with 915-class and original G[M]965 queued in for-airlied at the moment.
There still is a problem on Toshiba R500 with the patch from comment #6 applied. Namely, I tested the patch with a kernel having CONFIG_DEBUG_PAGEALLOC=y and CONFIG_NR_CPUS=128. After I've switched the settings to CONFIG_DEBUG_PAGEALLOC=n and CONFIG_NR_CPUS=2, resume from suspend to RAM occasionally fails (it is reproducible with the wakealarm suspend stress test script I'm going to attach in the next comment). However, it only fails if s2ram (the binary) is used for suspending, if 'echo mem > /sys/power/state' is used, it works 100% of the time (so far, it hasn't failed for me). Now, the differences are that (1) with CONFIG_DEBUG_PAGEALLOC=n on x86_64 the kernel's direct memory mapping is set up using 2M pages instead of 4K pages (I have no idea what the impact of this may be) and (2) s2ram does an additional VT switch right prior to suspend and right after the resume, so presumably there still is a problem with VT switching somewhere.
Created attachment 19033 [details] Script for automated stress-testing of suspend/resume with the help of RTC wake alarm
Re: comment #9: VT switching still has weird behaviour indeed on fixed -rc6 (A110L), in that sometimes switching to tty1 from x.org will not be successful and X will reappear (after screen blinking!). Switching again then works [usually?]. Yup, just tried it again for good measure, and yes indeed, it failed again and needed a second keypress attempt to work.
I have just tried the latest Linus' tree that contains all of the recent DRM fixes and unfortunately it hasn't fix the resume issue which is still present. I suspect it is related to the VT switching.
For me, the problem turned out to be related to interrupts, bug #12121, the $subject problem appears to have been fixed. For this reason, I'll close this bug now and Andreas please see if bug #11947 matches your symptoms and open a new bug entry for your issue if it doesn't.