Hello, I have a system that is unable to suspend to ram, under most but not all conditions. Suspend to disk works flawlessly as well as "Power On Suspend " (ACPI S1) if ACPI suspend is set to "S1(POS)" in the BIOS To me, the matter seems complicated, I have done as many tests as I can and I find it extremely difficult to describe my findings in a short manner. The System in concern is a Gigabyte GA-D525TUD , with an Atom D525 Processor (1.8GHz, Dual Core, Hyperthreading, no IntelSpeedStep/CPU Frequency Scaling ) and 4GB DDR3 ram installed. The mainboard is in use scince about one week. Bios Versions F2 (as shipped) and F3 (just updated) behave identical, buggy. Main problem "the bug": (at a "vanilla" 24x80 virtual terminal, tty0) # echo mem > /sys/power/state (machine suspends, power is turned off except for standby power, all OK) [I press the power button to wake it up again] (Power comes up, Machine is halted, Kernel panic'd, keyboard LEDs caps lock + scroll lock blinking, the monitor shows the VGA Bios "Intel PineView ..." or a panic screen) This is reproducible with www.kernel.org Kernels 2.6.35.10, 2.6.36.2 and 2.6.37-rc6 , all compiled for x86_64 (amd64) Most testing was done in the initrd for this would not wreck my harddrive (fsck complaining because of unclean shutdown). Therefore there were no programs running and also I could unload all modules with "rmmod" in the initrd (absolutely needed drivers are all compiled-in). But the results for suspending were all the same: Kernel Panic. No matter wether modules (mostly RAID, HD controller, iScsi ) were loaded or not. The outcome is the same when testing in the "really booted" state, in runlevel 3 as well as in runlevel 1. I followed http://en.opensuse.org/SDB:Suspend_to_RAM and the documentation in <Kernel-Source>/Documentation/power to no avail. A useable screen becomes visible after resume when Kernel cmd line option "acpi_sleep=s3_bios" is given. This seems ok to me. Of course, I used <web-search-engine-of-choice-here> but found nothing that solved the issue. Because of the blinking keyboard LEDs I assume a kernel panic upon resume and that it is not a driver that makes the trouble, nor is it my screeen being blank because the video would not be resumed as it is often the failure. This is why I bug the mainling list with this problem. It is difficult to obtain reasonable debug output as the console didn't come back after the suspend at first (alleviated by adding the kernel command line option "no_console_suspend") and serial debug output via ttyS0 stays frozen after resume. Using an oscilloscope, I see signals on the RS232-Tx line, at about 500-520 uSec/bit (a little unter 2000 baud - no sensible baud rate), so there is a bug in the resume of a serial console (Kernel cmd line option "console=ttyS0,115200n8 console=tty0" ), too. This bug seems not much important to me. Should I file it nevertheless ? Where ? Sidenote: When the serial console fails, console output on the screen may be slowed to a crawl, too. There is one Picture with an exceptionally long resume time (263 seconds!) because of that _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
