Created attachment 20668 [details]
dmesg 2.6.29 without fastboot after resume
If I enable fastboot my machine doesn't resume from S3, but hangs and then reboots. I'm not sure if it's too early to file bugs for fastboot?
I'll attach a few logs. If you need anything, please let me know.
I'm running the Ubuntu precompiled kernel from here: http://kernel.ubuntu.com/%7Ekernel-ppa/mainline/
Created attachment 20669 [details]
dmesg 2.6.29 with fastboot
The fastboot dmesg is cut off at the end I think. Must've been the crash. I'll post a full one if you wish.
Created attachment 20670 [details]
Created attachment 20683 [details]
patch: probe ata ports synchronously
please apply this debug patch on top of 2.6.29 and see if the problem still happens.
(In reply to comment #1)
> Created an attachment (id=20669) [details]
> dmesg 2.6.29 with fastboot
> The fastboot dmesg is cut off at the end I think. Must've been the crash.
> post a full one if you wish.
it would be great if you can attach the full dmesg.
please set CONFIG_PM_DEBUG, and run
echo devices > /sys/power/pm_test;
echo mem > /sys/power/state;
can the system come back after a few seconds?
if yes, please attach the dmesg after this test.
The system does not come back at all. Without the patch it turns it self off and on again twice. Then it's running the BIOS again.
With the patch the system resumes but just hangs. That can be traced:
[ 11.607544] Magic number: 0:77:396
[ 11.607597] hash matches drivers/base/power/main.c:390
[ 11.607741] rtc_cmos 00:09: setting system clock to 2024-03-02 20:22:30 UTC (1709410950)
I will attach the full dmesgs.
Created attachment 20702 [details]
dmesg 2.6.29 with fastboot, patch applied
dmesg 2.6.29 with fastboot, patch applied: Here it starts fine. It resumes and just hangs without even initializing the display.
Created attachment 20703 [details]
dmesg 2.6.29, patch applied, includes the trace data
Created attachment 20704 [details]
dmesg 2.6.29 fastboot, patch not applied, no trace found.
Will you please do the test as required in comment #4 and attach the output of dmesg_after?
>echo devices > /sys/power/pm_test;
> echo mem > /sys/power/state; dmesg >dmesg_after;
so this also happens in the test in comment #4?
yes. You are right Zhang Rui. I *did* the test exactly as in #4,
just one time with the patch and once without it.
I already described my results above.
As you may read from them, the system did not return
from suspend to ram in either, so there is no dmesg_after, only the magic nr. I could retrieve with the patch, see #5. I guess the word "traced" may be misleading. It doesn't mean that the system came back from suspend.
Oh and just to be very clear: It's not just the display that's not initialized. The system hangs completely. I can't reset it in any other way(SysRq can't reboot the computer either) but by pressing the power button a few seconds until it turns off. I did these tests out of the single user mode.
Created attachment 20750 [details]
patch: probe scsi disk synchronously
please apply this patch on top of the previous one,
the problem goes away this time, right?
Created attachment 20757 [details]
resume diag script
I have used this script for the resume tests.
Created attachment 20758 [details]
dmesg 2.6.29 fastboot, both patches applied, resumes fine
Yes, with both patches applied the resume works fine. For some reason there is a
WARNING: at kernel/power/main.c:176 suspend_test_finish+0x80/0x90()
in the kernel I use to test resuming. It's not in the kernel I originally discovered the problem in, though. All logs here except #20668 are from my test kernel.
Created attachment 20784 [details]
patch: probe scsi disk after ata port probe is done
please revert the previous two debug patches, apply this patch and see if it helps.
from the dmesg, we can see that
when fastboot is used
1. ahci driver probes port 0
2. sd driver probes the disk in port 0
3. ahci driver probes port 1 and 2
when fastboot is not used,
1. ahci driver probes port 0, 1, 2
2. sd driver probes the disk in port 0
I don't know if this sequence change causes this problem.
but the patch in comment #16 should fix this.
as the scsi/ata device is broken in this bug, cc Tejun.
The patch from #16 does not work at all for me. The behavior on resume is the same as vanilla, absolutely no change. As vanilla, I can't even get a "magic number".
How about boot option 'libata.noacpi'?
With which kernel? Unpatched, or one of the patches?
unpatched kernel please.
Does not help. Maybe forgot a parameter?
126:[ 0.000000] Kernel command line: root=UUID=4349ad91-9018-4e72-817b-46624e9a6c27 ro quiet splash fastboot libata.noacpi single
127:[ 0.000000] Booting kernel: `' invalid for parameter `libata.noacpi'
sorry, it should be libata.noacpi=1
please attach the lspci -vvxxx output both w/ and w/o "fastboot" parameter
#23: No, doesn't help at all. Behavior is the same as without the parameter.
Created attachment 20879 [details]
lspci normal boot
Created attachment 20881 [details]
lspci fastboot -vvxxx
Created attachment 20882 [details]
lspci diff -C10 normal fastboot
Created attachment 20883 [details]
lspci normal boot from init=/bin/bash
At first the lspci normal boot was done from the runnning system, not from init=/bin/bash. So that's fixed now. Now the diff is much smaller and I hope more usable. The fastboot diff is also from init=/bin/bash.
Please remove the NEEDINFO tag as it's incorrect.
Created attachment 20974 [details]
fix shipping in 2.6.30-rc1-git7
patch from Linus shipping in 2.6.30-rc1-git7
that should fix this bug.
2.6.30-rc1 did not fix the problem, rather it appeared without the fastboot parameter as well. But 2.6.30-rc2 is fixed with or without fastboot parameter.
Power-Off_Retract_Count is up
to 23 from all the testing... hope this one won't break like my last one a month ago.