Bug 229464 - System ceased to resume from suspend on Toshiba Satellite A100-847
System ceased to resume from suspend on Toshiba Satellite A100-847
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-21 06:20 EST by Julian Sikorski
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-13 10:13:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test results (11.05 KB, text/plain)
2007-05-29 17:27 EDT, Julian Sikorski
no flags Details
dtst.aml (30.39 KB, application/octet-stream)
2007-05-29 17:28 EDT, Julian Sikorski
no flags Details
dsdt.dat (30.40 KB, application/octet-stream)
2007-05-29 17:29 EDT, Julian Sikorski
no flags Details
dsdt.dsl (303.61 KB, text/plain)
2007-05-29 17:29 EDT, Julian Sikorski
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 7988 None None None Never

  None (edit)
Description Julian Sikorski 2007-02-21 06:20:20 EST
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
Comment 1 Julian Sikorski 2007-03-10 12:15:16 EST
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.
Comment 2 Julian Sikorski 2007-03-10 17:52:31 EST
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...
Comment 3 Julian Sikorski 2007-03-13 16:48:19 EDT
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?
Comment 4 Julian Sikorski 2007-05-24 16:14:33 EDT
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.
Comment 5 Julian Sikorski 2007-05-24 17:53:46 EDT
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.
Comment 6 Julian Sikorski 2007-05-24 18:55:17 EDT
I just tried s3_mode and s3_bios via echo 1/2/3 >
/proc/sys/kernel/acpi_video_flags. Does not help.
Comment 7 Julian Sikorski 2007-05-25 12:18:19 EDT
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?
Comment 8 Julian Sikorski 2007-05-29 15:33:03 EDT
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 
Comment 9 Julian Sikorski 2007-05-29 17:27:27 EDT
Created attachment 155640 [details]
Test results

Files obtained by running firmware debugger kit.
Comment 10 Julian Sikorski 2007-05-29 17:28:35 EDT
Created attachment 155641 [details]
dtst.aml
Comment 11 Julian Sikorski 2007-05-29 17:29:13 EDT
Created attachment 155642 [details]
dsdt.dat
Comment 12 Julian Sikorski 2007-05-29 17:29:35 EDT
Created attachment 155643 [details]
dsdt.dsl
Comment 13 Julian Sikorski 2007-07-22 15:07:29 EDT
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.
Comment 14 Julian Sikorski 2007-08-24 15:52:02 EDT
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.
Comment 15 Julian Sikorski 2007-08-24 16:18:52 EDT
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.
Comment 16 Julian Sikorski 2007-08-25 12:03:29 EDT
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?
Comment 17 Julian Sikorski 2007-08-29 11:06:18 EDT
Still OK with 2.6.23-0.148.rc4.fc8. So far, so good.
Comment 18 Christopher Brown 2007-09-13 10:13:25 EDT
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

Note You need to log in before you can comment on or make changes to this bug.