Failure to resume after suspend: Toshiba Portege 4010

[Tom Eastman]

Binary package hint: acpi-support

I've been messing around with Edgy on my Toshiba Portege 4010 for about a month now and still haven't been successful in getting Suspend-to-RAM reliably working.

I've tried flipping most of the settings in /etc/default/acpi-support, but haven't had much success.

At the moment most of those settings are back at defaults. The laptop suspends seemingly cleanly, but on resume, is stuck at a blank console screen with the yellow letters 'Linu' in the top left corner of the screen.

Searching around Google for this symptom, the suggested fix is to put "acpi_sleep=s3_mode" in the kernel command line, but for me this doesn't seem to work.

Interestingly, suspend-to-disk works just fine, and *after* resuming from suspend to disk, suspend-to-RAM also seems to work more often, but will still fail about half of the time.

Later today I'll attach 'lspci' and 'dmesg' output, and whatever else people think might be useful information. I'm also more than happy to provide remote root-level access to the laptop if that will help someone poke around and diagnose the problem.

What further information can I provide that will help?

Cheers,

       Tom

[Peter Whittaker (pwwnow)]

Tom, useful further information includes the outputs of the following:

uname -a

sudo lspci -vv

sudo lspci -vvn

sudo demidecode

Please be sure to run with sudo, these require root privileges to get the goods. (And be sure to attach, please!)

Also, if the machine fails to resume, I presume you need to reboot? If so, following an unsuccessful resume and boot, could you please attach /var/log/kern.log.0 - it will cover everything up to the reboot....

Thanks!

[slon (generesnik)]

I have same laptop with same problem. Since it crashes every time I switched to suspend to disk and don't have kernel logs.
Suspend to RAM worked fine in Dapper. Furthermore I tried Dapper with kernel from Edgy and it crashes on suspend to ram all the time as well.
I hope it helps

Linux toshi 2.6.17-10-generic #2 SMP Tue Dec 5 22:28:26 UTC 2006 i686 GNU/Linux
lspci -vv
00:00.0 Host bridge: ALi Corporation M1644/M1644T Northbridge+Trident (rev 01)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
        Latency: 0
        Region 0: Memory at f0000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [b0] AGP version 2.0
                Status: RQ=28 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
        Capabilities: [a4] Power Management version 1
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: ALi Corporation PCI to AGP Controller (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Memory behind bridge: f7f00000-fdffffff
        Prefetchable memory behind bridge: 28000000-280fffff
        Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR+
        BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-

00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
        Subsystem: Toshiba America Info Systems Unknown device 0004
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (20000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at f7eff000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:04.0 IDE interface: ALi Corporation M5229 IDE (rev c3) (prog-if f0)
        Subsystem: Toshiba America Info Systems Unknown device 0004
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (500ns min, 1000ns max)
        Interrupt: pin A routed to IRQ 255
        Region 4: I/O ports at eff0 [size=16]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,...

[Tom Eastman (tveastman)]

Here's the info :-)

Note that the kernel I'm using came out of the Feisty repository a month or so back -- I was hoping a more recent one would help.

I also spent some time trying to get a kern.log from a *working* resume, doing the hibernate--first trick I mentioned before, but it's not working for me today. If I manage to get it to work I'll post that kern.log as well.

Thanks!

[Tom Eastman (tveastman)]

And here's the kern.log, it includes the bootup, the suspend attempt, and the subsequent reboot.

The suspend itself was attempted 18:38

[Tom Eastman (tveastman)]

Oops, didn't attach the file correctly, next try:

[Peter Whittaker (pwwnow)]

Marking as confirmed and directing to kernel based on attached logs.

Tom, any chance you can try a more recent Feisty kernel? (I'm at 2.6.20-5, FWIW.) Thanks!

[Tom Eastman (tveastman)]

Hey, I tried the new kernel, but it's still unsteady.

After playing around, resuming now correctly restores the video state (I get back to either the console or X), but most of the time the computer has locked up.

After bootup, I can go: 'echo mem > /sys/power/state' to make it immediately suspend, and *successfulle* resume. But if I try to do it a second time. It locks up on resume.

Attached is a kern.log from a bootup, suspend, and *successful* resume. Any new hints?

[Tim Gardner (timg-tpi)]

Please read and try the suggestions contained in :

https://wiki.ubuntu.com/KernelSuspendDebugging

[Tom Eastman (tveastman)]

Hi Tim,

Since my last update to this bug I've started again with a fresh install of Feisty. I did a complete update before running this experiment so I ought to have the latest of everything.

Following the advice in KernelSuspendDebugging, I attempted to suspend/resume three times. Each time, I got a different message in 'dmesg'.

First attempt:

    [ 10.487581] Magic number: 11:940:953
    [ 10.487622] hash matches device ttya8
    [ 10.487768] hash matches device ptyza

Second attempt:

    [ 10.257222] Magic number: 11:119:46
    [ 10.257233] hash matches device ttyef

Third attempt:

    [ 9.658558] Magic number: 11:222:147
    [ 9.658700] hash matches device ttyp1

However, I'm not sure if this is working properly, as, even when I'm not connected to the network, when I start up again the laptop still seems to know the correct time. Shouldn't pm_trace be doing something to mess up the clock? If my clock is still correct does that mean that it's not working right?

[Tim Gardner (timg-tpi)]

The fact that you are getting 'Magic number' in the dmesg output indicates that pm_trace was set successfully. Now I just have to figure out what the pseudo-TTY driver is doing.

Please confirm the Feisty kernel release version, e.g., 'uname -r'.

[Tom Eastman (tveastman)]

$ uname -a

Linux portege 2.6.20-8-generic #2 SMP Tue Feb 13 05:18:42 UTC 2007 i686 GNU/Linux

[Tom Eastman (tveastman)]

Do let me know if there's any other information I can provide that will help.

You're also welcome to a shell account on the laptop itself, if that can help.

[slon (generesnik)]

So, is this bug ever going to be fixed? Mandriva has no problems with this issue. Maybe you should check out how they do it and take notes?

[Launchpad Janitor (janitor)]

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Tom Eastman (tveastman)]

I no longer own the laptop in question, but I will be able to test the latest version of Ubuntu on it next time I have access to it (around Christmas time).

[Peter Whittaker (pwwnow)]

<bump> Adding artificial activity so that the bug does not expire before Tom gets a chance to test with Intrepid later this year.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Leann Ogasawara (leannogasawara)]

Anyone been able to test Intrepid yet? Does the issue still exist? If so, it would be great if you could give the latest Jaunty Alpha release a test - http://cdimage.ubuntu.com/releases/jaunty/ . Please let us know your results. Thanks.

[Peter Whittaker (pwwnow)]

I'm closing this (marking as invalid) due to inactivity and lack of a test machine. Tom, if you do get a chance to this on the laptop in question (comments 16 and 17) and get the same results, please do reopen this with appropriate debug information. Otherwise, it's the dustbin of irreproducible results for this report.