Latest working kernel version: 188.8.131.52
Earliest failing kernel version: 2.6.27-rc
Distribution: ubuntu 8.04
Hardware Environment: toshiba satellite U305-S5077 (lspci and boot dmesg will be attached right away)
Software Environment: doing native (by menu) suspend/resume
sometime resume from ram fails, giving a completely dead machine. Nothing works, not even SysRq-B. Nothing is left in the logs. It happens maybe every 7-9 correct resume events. It never happened in 2.6.26 (then it had problems with video not resuming, but this was another kind of problem). Problem is hardly bisectable...
The main difference could be the fact that now I have ath5k.ko driver instead of ndiswrapper for the wireless, but I have no proof whatsoever that the wireless could be the culprit. I can try to run with ndiswrapper instead a couple of day, but I'm not sure this is the correct strategy.
Created attachment 17996 [details]
lspci -vnn && lsusb -v
Created attachment 17997 [details]
Created attachment 17998 [details]
Have you tried to unload the ath5k module before suspend and reload it after the resume?
I am trying just that now. Survived 5 cycles, but that means (still) nothing.
Will you please add the boot option of "acpi_sleep=s3_beep" and see whether the beep voice can be heard when the system is resumed?
Of course please attach the output of acpidump.
If the beep voice can be heard, please always add the boot option of "acpi_sleep=s3_beep" and see whether the beep voice can be heard when failing in resume.
Ok, I will add it when I do the next reboot (compiling rc7 now).
Will attach acpidumd output now.
Going around 10 cycles, now with ath5k loaded, and I can't trigger it anymore.
Created attachment 18077 [details]
By the way, I do not know if it is a *real* regression. It did never happen if I haven't ath5k loaded, and this is a new driver, so...
Your call, anyway.
Booted 2.6.27-rc7 with
[ 0.000000] Kernel command line: root=UUID=995a9794-b3d4-4066-b9f8-36b84d4525ff ro nosplash log_buf_len=2M acpi_sleep=s3_beep
but there is no beep on good resume (I do not know if this should be like that...).
Will update if I'll have another lock.
(In reply to comment #10)
> By the way, I do not know if it is a *real* regression. It did never happen
> I haven't ath5k loaded, and this is a new driver, so...
if it's true, this is rather a ath5k driver bug than the generic suspend/resume bug.
will you please make sure that
problem can only be reproduced when ath5k driver is loaded?
It's quite difficult to be sure. I am running now with ath5k loaded.
The problem is that is seems independent from the number of times I do suspend/resume (doing a lot on a row doesn't trigger it), it appears randomly after a time is passed after boot.
Juat to keep this uptodate: I was unable to trigger it again.
A guy (Adrian Knoth) suggested me in private mail that he sees a similar thing on his HP nx6325 if he unplugged the AC adapter when suspended, and resume on battery; I tried this too but no locks happened.
So, it's almost a week that I am running the same -rc7 without any problem. I suppose that the acpi_sleep=s3_beep could not made a difference, true?
(In reply to comment #14)
> Juat to keep this uptodate: I was unable to trigger it again.
> So, it's almost a week that I am running the same -rc7 without any problem. I
> suppose that the acpi_sleep=s3_beep could not made a difference, true?
Do you think the bug can be closed, then?
Well, I suppose it can be closed as UNREPRODUCIBLE; if it happens again, I will reopen it or open another one.
Spoke too soon, happened again this morning. Completely dead, no acpi beep, no sysrq keys. I *do* had ath5k loaded.
Can you please apply the patch from http://marc.info/?l=linux-kernel&m=122307130419753&w=4 and see if the problem is reproducible with that? Please also attach a dmesg with a successful suspend/resume cycle with this patch applied.
Ok, I will. In this moment I can´t do it because I do not have the laptop with me till tomorrow evening, but I will asap. Do the patch apply to linus´ current kernel?
(In reply to comment #19)
> Do the patch apply to linus´ current kernel?
Yes, it should apply.
patch applied on v2.6.27-rc8-84-gfec6ed1. Will append the dmesg in a minute.
Created attachment 18174 [details]
dmesg: boot and a following successful suspend/resume cycle
Well, it looks like your BIOS doesn't enable ACPI on resume and that may lead to problems described in your report. You need the patch anyway, so please keep it applied.
Still, if it doesn't fix your resume problems, we'll have more debugging to do.
Till now, all ok. Did 4 cycles without problems.
How many cycles did it take to reproduce the problem before?
Uff. It happened after one week of use, maybe 4-5 cycles per day. But it seems that happens randomly, sometime it triggered two times in a row, sometime it worked ok for days... I am trying to stress it a bit today, suspending and resuming a lot of times. Till now no problem.
OK, do I understand correctly that the patch does help?
Yes, I think it helps. Although I cannot be sure given the randomness of the bug, it's more than a week now of correct behaviour. Surely the patch does not harm anything, and it seems it helps.
I think you can close it, if it happens again with the patch, I will reopen it.
Still ok after 9 days. Yes, I think the patch definitely helps. Please push it for -stable, if you want you can add a
Tested-by: Romano Giannetti <email@example.com>
The patch is on its way to the mainline and it will go into -stable after it's been merged.
thanks for testing, Romano.
marking as RESOLVED, since fix is in the queue
Fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768
shipped in linux-2.6.28-rc1
Author: Matthew Garrett <firstname.lastname@example.org>
Date: Wed Aug 6 19:12:04 2008 +0100
ACPI: Clear WAK_STS on resume