Distribution: Fedora Core 3 Hardware Environment: AMD Sempron 3100+ (32-bit K8) desktop with 1.5GB RAM; also reproduced on a Toshiba Portege 3500 laptop with 512MB RAM during 2.6.11-rc, although I had no clue what was causing the bug at that point Software Environment: .config is similar to what ships in 2.6.10-2.6.11 "rawhide"/"fc-devel" kernels; this means ACPI is enabled Problem Description: swsusp normally works, but if I enable CONFIG_DEBUG_PAGEALLOC, it breaks -- after "PM: snapshotting memory", swsusp never gets to the "critical section" and it kind of bounces back from the suspend attempt, for lack of a better way for me to describe the effect. I first hit this when trying to hack a vendor kernel into supporting swsusp (guess which one ;) -- sometimes things worked and sometimes they didn't. I later reproduced it on mainline 2.6.11-rc1 or -rc2 -- I don't remember which -- but it seemed to go away for -rc4. Then I hit the problem again on 2.6.11-rc5 and 2.6.11 final. Unfortunately it took me several weeks (i.e. until today) to figure out that I was being sloppy with my .configs and it was actually changes in those that were to blame for my troubles. I just finished narrowing it down to CONFIG_DEBUG_PAGEALLOC. Steps to reproduce: 1. Using either a pristine mainline tarball (with vanilla patches if you want a -rc or -bk kernel), or a hacked Fedora Core 3/4 kernel SRPM, compile a kernel with swsusp support. (Compared to the standard Fedora Core .config, set CONFIG_SOFTWARE_SUSPEND=y and CONFIG_PM_STD_PARTITION="".) 2. Install this new kernel. 3. If needed, edit /etc/grub.conf to make the new kernel the default. Also make sure that the new kernel has a "resume=" parameter 4. Reboot into the new kernel. 5. Log in as root (or log in as a normal user and become root). 6. echo 4 > /proc/acpi/sleep
This patch addresses the DEBUG_PAGEALLOC/swsusp conflict by disabling DEBUG_PAGEALLOC if swsusp is also enabled: http://marc.theaimsgroup.com/?l=linux-kernel&m=111017249931972&w=2 There's a variant of this problem which affects some VIA CPU's, and that will require a second patch, but that's not exactly the issue I reported here.
Closing, since my patch is in Linus's BitKeeper tree now.