Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 229464 - System ceased to resume from suspend on Toshiba Satellite A100-847
Summary: System ceased to resume from suspend on Toshiba Satellite A100-847
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-21 11:20 UTC by Julian Sikorski
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-09-13 14:13:25 UTC

Attachments (Terms of Use)
Test results (deleted)
2007-05-29 21:27 UTC, Julian Sikorski
no flags Details
dtst.aml (deleted)
2007-05-29 21:28 UTC, Julian Sikorski
no flags Details
dsdt.dat (deleted)
2007-05-29 21:29 UTC, Julian Sikorski
no flags Details
dsdt.dsl (deleted)
2007-05-29 21:29 UTC, Julian Sikorski
no flags Details

System ID Priority Status Summary Last Updated
Linux Kernel 7988 None None None Never

Description Julian Sikorski 2007-02-21 11:20:20 UTC
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:

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 17:15:16 UTC
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

Comment 2 Julian Sikorski 2007-03-10 22:52:31 UTC
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 20:48:19 UTC
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 20:14:33 UTC
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 21:53:46 UTC
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 >

Comment 6 Julian Sikorski 2007-05-24 22:55:17 UTC
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 16:18:19 UTC
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:
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 19:33:03 UTC
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.


Comment 9 Julian Sikorski 2007-05-29 21:27:27 UTC
Created attachment 155640 [details]
Test results

Files obtained by running firmware debugger kit.

Comment 10 Julian Sikorski 2007-05-29 21:28:35 UTC
Created attachment 155641 [details]

Comment 11 Julian Sikorski 2007-05-29 21:29:13 UTC
Created attachment 155642 [details]

Comment 12 Julian Sikorski 2007-05-29 21:29:35 UTC
Created attachment 155643 [details]

Comment 13 Julian Sikorski 2007-07-22 19:07:29 UTC
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 now.

Comment 14 Julian Sikorski 2007-08-24 19:52:02 UTC
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- still gives complete lockup.

Comment 15 Julian Sikorski 2007-08-24 20:18:52 UTC
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 16:03:29 UTC
Problem persists in kernel-
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 15:06:18 UTC
Still OK with 2.6.23-0.148.rc4.fc8. So far, so good.

Comment 18 Christopher Brown 2007-09-13 14:13:25 UTC
Hello Julian,

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.


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