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.
Steps to Reproduce:
1. go to suspend, e.g. by acpitool -s
2. press power button to resume
System is not brought back to operational state
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
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 >
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
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  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.
Created attachment 155640 [details]
Files obtained by running firmware debugger kit.
Created attachment 155641 [details]
Created attachment 155642 [details]
Created attachment 155643 [details]
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 188.8.131.52-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-184.108.40.206-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-220.127.116.11-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.
I am reviewing this as part of the kernel bug triage project:
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.