Bug 14197

What happens if you do:

# echo core > /sys/power/pm_test
# echo disk > /sys/power/state

?

# echo core > /sys/power/pm_test

Nothing interesting happened; no system logs, no output.


# echo disk > /sys/power/state

* screen blanks, no text or cursor visible
* slight click from speakers
* disk light goes on for 10 seconds then off
* system is hung at this point; can't Alt-F1, etc.

System logs for the second test:

Sep 20 18:11:40 mars root: test 2 start
Sep 20 18:11:47 mars kernel: PM: Marking nosave pages: 000000000009f000 - 0000000000100000
Sep 20 18:11:47 mars kernel: PM: Basic memory bitmaps created
Sep 20 18:13:26 mars kernel: imklog 3.22.1, log source = /proc/kmsg started.

Hi, Neil
    From the problem description it seems that there exist two issues on your box.
    a. the system doesn't power off after hibernation. Will you please confirm whether the your box can be power off correctly using the command of "poweroff or shutdown?
    b. no resume. Will you please please add the boot option of "resume=xxx" and see whether it can be resumed? xxx means the swap partition.
   
Thanks.

Actually, I think there's a third problem, namely that "no_console_suspend" doesn't work, so I can't see any console output during hibernate.  Perhaps it is panicing, and I can't see the message???

Anyways:
a. Both "poweroff" and "shutdown -P now" do power the system off correctly.

b. adding "resume" didn't help:
Sep 20 21:46:20 mars kernel: PM: Marking nosave pages: 000000000009f000 - 0000000000100000
Sep 20 21:46:20 mars kernel: PM: Basic memory bitmaps created
Sep 20 21:55:44 mars kernel: imklog 3.22.1, log source = /proc/kmsg started.
Sep 20 21:55:44 mars kernel: Initializing cgroup subsys cpuset
Sep 20 21:55:44 mars kernel: Initializing cgroup subsys cpu
Sep 20 21:55:44 mars kernel: Linux version 2.6.30.5-43.fc11.x86_64 (mockbuild@xenbuilder4.fedora.phx.redhat.com) (gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) ) #1 SMP Thu Aug 27 21:39:52 EDT 2009
Sep 20 21:55:44 mars kernel: Command line: ro root=UUID=dd5fda5d-e1fc-4fb4-b02c-59cdbb14534c quiet no_console_suspend resume=/dev/sda5
[... stuff ...]
Sep 20 21:55:44 mars kernel: PM: Resume from disk failed.

I followed some more instructions in:
http://www.mjmwired.net/kernel/Documentation/power/basic-pm-debugging.txt

and did:
    echo devices >/sys/power/pm_test; echo platform >/sys/power/disk; echo freezer >/sys/power/state
which worked, then:
    echo devices >/sys/power/pm_test; echo platform >/sys/power/disk; echo devices >/sys/power/state
which hung as before.

Anything else that you want me to test?  This used to work in the Fedora Core 6 days!

(In reply to comment #5)
> I followed some more instructions in:
> http://www.mjmwired.net/kernel/Documentation/power/basic-pm-debugging.txt
> 
> and did:
>     echo devices >/sys/power/pm_test; echo platform >/sys/power/disk; echo
> freezer >/sys/power/state
> which worked,

# echo freezer > /sys/power/state

doesn't do anything.

> then:
>     echo devices >/sys/power/pm_test; echo platform >/sys/power/disk; echo
> devices >/sys/power/state

# echo devices > /sys/power/state

doesn't do anything as well.  I _guess_ you did "echo disk > /sys/power/state" as the last thing in both cases.

If that's the case, it seems one of device drivers hangs your system on suspend.

Can you please boot with init=/bin/bash and repeat the tests (you'll need to mount /sys and /proc manually for them to work)?

Ah, sorry, I was typing those commands into Bugzilla from memory, as my command-line history was lost from the crash.  You're right, I actually did:

    echo freezer > /sys/power/pm_test ; echo platform > /sys/power/disk ; echo disk > /sys/power/state
(which worked), and
    echo devices > /sys/power/pm_test ; echo platform > /sys/power/disk ; echo disk > /sys/power/state
which didn't.

=====

Okay, booting with init=/bin/bash, I found that /sys and /proc were already mounted (although nothing else was, of course).
The same behaviour was observed; with the "devices" level in pm_test, the screen blanked (no cursor), the disk light went on for 20 seconds (rather long, considering that there shouldn't be much state to save!), and then the system hung without powering down or rebooting.

"lsmod" output while booted with init=/bin/bash:

Module                  Size  Used by
ata_generic             6004  0 
pata_acpi               5520  0 
pata_atiixp             6272  2 
radeon                542888  1 
drm                   228580  1 radeon
i2c_algo_bit            6612  1 radeon
i2c_core               33504  3 radeon,drm,i2c_algo_bit

Can you try, in the init=/bin/bash "mode", to do

# echo shutdown > /sys/power/disk
# echo devices > /sys/power/pm_test
# echo disk > /sys/power/state

Does it survive the test in that case?

* screen blanks (despite "no_console_suspend")
* heavy disk activity for ~20 seconds
* disk activity stops, does not power-down
* system is hung; power cycled it
* "PM: Resume from disk failed." on reboot

(currently running 2.6.30.8-64.fc11.x86_64)

Can you try that with 2.6.32-rc3, please?

Okay, that was fun!  I haven't built a kernel since the 0.98 days...

You didn't say whether I should use the default .config, or the Fedora one, so I used the default (i.e. ran "make menuconfig" and immediately saved & exited, without changing any settings).

Booting that kernel with init=/bin/bash produced the exact same failure, i.e. blank screen during hibernate, no power-down, and failures on restore:

Oct  8 21:54:07 mars kernel: Linux version 2.6.32-rc3 (root@mars.rvacrosscanada.com) (gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) ) #2 SMP Thu Oct 8 19:13:43 PDT 2009
Oct  8 21:54:07 mars kernel: Command line: ro root=UUID=dd5fda5d-e1fc-4fb4-b02c-59cdbb14534c quiet no_console_suspend
...
Oct  8 21:54:07 mars kernel: PM: Resume from disk failed.

It also failed to start X, with these errors:

Oct  8 21:54:07 mars kernel: [drm:rs400_gart_adjust_size] *ERROR* Forcing to 32M GART size (because of ASIC bug ?)
Oct  8 21:54:07 mars kernel: Failed to wait MC idle while programming pipes. Bad things might happen.
Oct  8 21:55:29 mars kernel: [drm:radeon_cp_getparam_kms] *ERROR* invalid ioctl with kms radeon_cp_getparam_kms

perhaps that's because I'm not using the Fedora .config settings??  Anyways, with rc3 the same hibernate/resume failure occurs.

Will you please attach the kernel config used for 2.6.32-rc3?
How about if you compile the ata driver as built-in module?
thanks.

Created attachment 23367 [details]
".config" file for 2.6.32-rc3

It looks like the default configuration already makes the ATA driver built-in:
CONFIG_ATA=y

Is this the one that you meant?

Hi, Neil
   Will you please try the latest stable kernel and see whether the issue still exists?(for example: 2.6.35)

Thanks.

Yes, it's still broken in 2.6.34.7-56.fc13.x86_64.

Suspend: goes to text screen; 3 seconds disk activity; switches off
Resume: blank screen, 40 seconds disk activity, system frozen (blank screen, control-alt-delete doesn't work)

Hibernate: goes to text screen; 40 seconds disk activity; does not switch off
Resume: boots kernel, does fsck, boots normally (not a resume)

dmesg shows:
PM: Resume from disk failed.

Will you please add the boot option of "resume=xxx initcall_debug" and attach the output of dmesg when it can't be resumed from disk?(XXX means the swap area that is used to save the data related with hiberation).

Thanks.
    Yakui

Created attachment 32142 [details]
Output from "dmesg" command

Related issue: when I reboot to try to resume, GRUB's main menu doesn't appear, but it boots Linux immediately.  Do you know how/why this is happening, and how I can avoid it?

Useful bits from dmesg (complete log is attached):

PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000d0000
PM: Registered nosave memory: 00000000000d0000 - 0000000000100000
PM: Checking image partition /dev/sda5
PM: Resume from disk failed.
PM: Starting manual resume from disk
PM: Resume from partition 8:5
PM: Checking hibernation image.
PM: Error -22 checking image file
PM: Resume from disk failed.

It's great that kernel bugzilla is back.

can you please verify if the problem still exists in the latest upstream
kernel?

bug closed as there is no response from the bug reporter.