Description of problem: I am using Toshiba Satellite A100-847 laptop, x86_64 arch. I'm not sure if this is really a kernel bug. The thing is that system goes to suspend-to-ram properly, but after it is resumed, I can hear the fan and the disk, but the screen is blank and I have to hold down the power button for a few seconds to shut it down. I am filing yet another bug report because it used to work before. I started to hit the problem since 2895 kernel, but now I have tried to roll back as far as 2798, but it does not help :(. So it looks like something else is causing the problem. How reproducible: always Steps to Reproduce: 1. go to suspend, e.g. by acpitool -s 2. press power button to resume Actual results: System is not brought back to operational state Expected results: System is back alive and kicking
Well, I can try to obtain some meaningful output using netconsole. I understand that this report is quite useless without some specific info. Do you have any suggestions.
Bummer. Nothing is output to netconsole. It looks like the network connection gets down before the freeze. Is there anything else I could do? These freezes are pretty annoying...
OK, it is not the kernel bug, as I have rolled back to the one that used to work, and it no longer does. Any ideas which other package may cause such issue?
After reading Richard Hughes' quirks info, and opensuse's s2ram page, I got a bit too optimistic. I just checked that not even Caps Lock works after resume, so the problem seems quite serious.
It is getting worse: even the minimal mode does not work. I mean adding init=/bin/bash to grub boot parameters, and then running echo mem > /sys/power/state.
I just tried s3_mode and s3_bios via echo 1/2/3 > /proc/sys/kernel/acpi_video_flags. Does not help.
It's getting worse. I downloaded 2.6.21-1.3201 rawhide kernel srpm, patched it to enable PM_TRACE under x86_64, rebuilt, installed and followed the procedure described here: http://people.freedesktop.org/~hughsient/quirk/quirk-advanced.html Unfortunately, time does not get changed and cat dmesg.txt | grep "hash matches" yields nothing. I am afraid that a certain kernel bug might be related. I wonder how it happened this laptop used to suspend at all. Maybe one of the BIOS updates screwed something up?
None of the grub options mentioned at [1] work. Neither does s3bios nor s3mode. pm_trace does not save anything into RTC. All the tests were done using init=/bin/bash and resulted with a solid freeze with non-responding capslock. [1] http://people.freedesktop.org/~hughsient/quirk/quirk-advanced.html
Created attachment 155640 [details] Test results Files obtained by running firmware debugger kit.
Created attachment 155641 [details] dtst.aml
Created attachment 155642 [details] dsdt.dat
Created attachment 155643 [details] dsdt.dsl
Not sure if you are following the upstream bug, so I'll post it here as well. I made an interesting discovery, namely found that the failed resume sequence™ (pm-suspend, resume that fails, holding down the power button to shut down and eventually a reboot) shifts the RTC 1 hour forward if invoked in minimal boot (init=/bin/bash), but leaves it intact when used with fully-booted system. I am running 2.6.22.1-27.fc7 now.
OK, update. Resume goes further with kernel-2.6.23-0.124.rc3.git2.fc8.x86_64 and stays the same with kernel-2.6.23-0.133.rc3.git6.fc8.x86_64. System resumes and is responsive, it is just the LCD that stays off. I have tried every single quirk, but no luck so far. Now I need to try combinations of them, as well as nvidia binary blob, which currently does not build against rawhide kernel. Cheers and big thanks to whoever made this go further. Just for record, kernel-2.6.22.1-41.fc7.x86_64 still gives complete lockup.
OK, with nvidia blob installed system resumes with no quirks at all, like it used to do at the very beginning. Any ETA on 2.6.23 making its way into Fedora 7? Or otherwise, would backporting the fix be possible? Thanks once again.
Problem persists in kernel-2.6.22.4-65.fc7.x86_64. Do you think it is worht filing a separate bug report about the lcd not coming back to life without the help of the blob?
Still OK with 2.6.23-0.148.rc4.fc8. So far, so good.
Hello Julian, I am reviewing this as part of the kernel bug triage project: http://fedoraproject.org/wiki/KernelBugTriage Thanks for filing the bug. If the problem is with an nvidia binary accelerated graphics driver it is difficult to debug for reasons you are probably aware. 2.6.23 will arrive in F7 with a couple of weeks as it currently stands at rc6. I am therefore closing as this as it appears resolved for you however please re-open should 2.6.23 not work for you. You may wish to try the following if the problem re-occurs: If the capslock light doesn't toggle, the system is completely dead. Try again, but this time before suspending, activate the pm_trace functionality with echo 1 > /sys/power/pm_trace. This reprograms the real time clock to contain a few bytes of information which we can use to diagnose which driver failed to resume. After the hang, reboot, boot up again, and save the output of dmesg. Another trick that sometimes works to force video to come back up is to enable the BIOS password. This makes the system resume in a VGA text mode that the kernel recovers from a lot easier. Not a real solution, but it can help to diagnose other problems. You may also wish to test with the open source nv driver. Regards Chris