[Toshiba Protege Z930-12T PT235E-02Q04KEP] fails to resume after second suspend on kernel >=3.4

[Pedro Alves]

After resuming from first supend, brightness keys don't work, power key doesn't show logout menu, and if I try to suspend a second time I'm unable to recover from suspension (blank screen)

Seems similar to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088721

This is definetly seems a regression. I did a manual bisect on kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline and everytihng works ok up until kernel 3.3.8. Starting from 3.4 and up until 3.8-rc, I can see this bug.

I also have a toshiba portege z830 and this doesn't happen, so it's specific to Toshiba Portege z930(-12T)
---
ApportVersion: 2.6.1-0ubuntu9
Architecture: amd64
DistroRelease: Ubuntu 12.10
InstallationDate: Installed on 2011-12-18 (378 days ago)
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
MarkForUpload: True
Package: linux (not installed)
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
Tags: quantal
Uname: Linux 3.4.0-030400-generic x86_64
UnreportableReason: The running kernel is not an Ubuntu kernel
UpgradeStatus: Upgraded to quantal on 2012-12-23 (7 days ago)
UserGroups:
---
ApportVersion: 2.6.1-0ubuntu9
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: pedro 4284 F.... xfce4-volumed
                      pedro 4425 F.... xfce4-mixer-plu
                      pedro 6001 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
DistroRelease: Ubuntu 12.10
HibernationDevice: RESUME=UUID=7ed7eab4-062c-41fe-87ed-15e8c5d1f9c8
InstallationDate: Installed on 2011-12-18 (378 days ago)
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
MachineType: TOSHIBA PORTEGE Z930
MarkForUpload: True
Package: linux (not installed)
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-21-generic root=UUID=f56c9ffc-46c0-46ce-a425-1f45c00fc6d2 ro quiet splash acpi_backlight=vendor i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 resume=UUID=7ed7eab4-062c-41fe-87ed-15e8c5d1f9c8
ProcVersionSignature: Ubuntu 3.5.0-21.32-generic 3.5.7.1
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory /home/pedro not ours.
 No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.5.0-21-generic N/A
 linux-backports-modules-3.5.0-21-generic N/A
 linux-firmware 1.95
Tags: quantal
Uname: Linux 3.5.0-21-generic x86_64
UpgradeStatus: Upgraded to quantal on 2012-12-23 (7 days ago)
UserGroups:

dmi.bios.date: 10/01/2012
dmi.bios.vendor: TOSHIBA
dmi.bios.version: Version 6.40
dmi.board.asset.tag: 0000000000
dmi.board.name: PORTEGE Z930
dmi.board.vendor: TOSHIBA
dmi.board.version: Version A0
dmi.chassis.asset.tag: 0000000000
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: Version 1.0
dmi.modalias: dmi:bvnTOSHIBA:bvrVersion6.40:bd10/01/2012:svnTOSHIBA:pnPORTEGEZ930:pvrPT235E-02Q04KEP:rvnTOSHIBA:rnPORTEGEZ930:rvrVersionA0:cvnTOSHIBA:ct10:cvrVersion1.0:
dmi.product.name: PORTEGE Z930
dmi.product.version: PT235E-02Q04KEP
dmi.sys.vendor: TOSHIBA

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

apport information

[Pedro Alves (pmgalves)]

last apport-collect was done on official Linux arpeggio 3.5.0-21-generic, where problem also appears

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1094800/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Pedro Alves (pmgalves)]

Added package (linux)

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.8 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc1-raring/

[Pedro Alves (pmgalves)]

Hey Joseph - Indeed, still exists.

I did a "manual bisect" using the kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ and it started happening in v3.4-quantal . In v3.3.8-quantal/ still worked

[Joseph Salisbury (jsalisbury)]

Can you confirm the bug did not exist in v3.3 final? v3.4 is not a linear commit to v3.3.8 stable. This test will rule out that the bug was fixed in a v3.3 stable release.

Also, did you test any of the v3.4 release candidates? v3.4-rc1, v3.4-rc2, etc? If not, that should be done to confirm the bug wasn't introduced in one of the release candidates. The best way to test the release candidates is to pick on in the middle, such as v3.4-rc4. If it has the bug, then test v3.4-rc2. If v3.4-rc4 does not have the bug, then test v3.4-rc6.

Thanks again for testing!

[Pedro Alves (pmgalves)]

Hello Joseph.

I'm assuming 3.3 final is 3.3.8 - I do confirm the bug does not exist in 3.3.8 (and as far as my tests went, didn't happen in any previous kernels I tested). Let me know if you want more tests on 3.3 series.

The bug, as I reported it, happens in 3.4-rc2. In 3.4-rc1 the system is able to suspend, but reboots when trying to resume from suspension

[Pedro Alves (pmgalves)]

Forgot to tell - also tested in 3.8-rc2 and the bug is still present

[Joseph Salisbury (jsalisbury)]

Thanks for all the testing. So it appears the bug was introduced in v3.4-rc2.

I'll start a bisect between v3.4-rc1 and v3.4-rc2.

[Pedro Alves (pmgalves)]

Just a note:

"I'll start a bisect between v3.4-rc1 and v3.4-rc2."

There seem to be a bug in v3.4-rc1, since it didn't even resume from suspend. In summary:

3.x -> 3.3.8: All working!
3.4-rc1: rebooted automatically while resuming from suspension
3.4-rc2 -> 3.8-rc2: behavior described in this report

[Joseph Salisbury (jsalisbury)]

Thanks for the update. So you can't confirm if the bug exists in v3.4-rc1 or not because it reboots during resume. That might indicate that the bug for this report may not exists in rc1, since it's at least waking up.

Also, when I was referring to 3.3 final, I was referring to v3.3. That kernel can be downloaded from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-precise/

[Pedro Alves (pmgalves)]

This bug report is about failing to resume from *second* suspension, where I just get with a blank display.

In 3.4-rc1 reboots while trying to resume from *first* suspend.

My very naive interpretation is that something regarding suspension changed for 3.4-rc1, wasn't working properly and was changed for rc2. That fix, however, was incomplete in comparision to the 3.3 and previous codelines

[Joseph Salisbury (jsalisbury)]

I started a kernel bisect between v3.4-rc1 and v3.4-rc2. This will require testing about 7 - 10 kernels to identify the commit that introduced this regression.

The first test kernel is available and is built up to commit:
43f63c8711ce02226b7bbdafeba7b8031faf3fb4

The kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1094800

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

[Pedro Alves (pmgalves)]

Joseph - that one exibits the behavior described here - so I guess we'd mark it as git bisect bad

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
e1a7eb08ee097e97e928062a242b0de5b2599a11

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1094800

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

[Joseph Salisbury (jsalisbury)]

Actually hold of for a bit. The kernel is still building. I'll post a comment when it is published.

[Pedro Alves (pmgalves)]

Joseph, feels kind'a silly for me to have you building kernels for me to test, so I went ahead and did the bisect myself to save you that time.

Making a quick summary of this behavior

Kernel <= 3.3 : System is able to successfully resume multiple times. Everything works.

3.4-RC1 : System reboots while trying to resume from *first* suspend

3.4-RC2 -> 3.8 (current): System recovers from first suspend, never recovers from second suspend.

6742259866d03d5bc19815441ba928e8378343dc is the first commit that exhibits the behavior described on this bug. This is a result of a merge between 2 branches.

- dba69d1092e291e257fb5673a3ad0e4c87878ebc: part of the 3.3 series, everything works great;

- 20d9d9a0544436b1b8c94689c01d746d6bd5525c : follows v3.4-rc1. System reboots while trying to resume from *first* suspend

Is there any other info I can provide? I can also try to see where between 3.3 and 3.4-RC1 it started to reboot

[Joseph Salisbury (jsalisbury)]

I built the next test kernel, up to the following commit:
e1a7eb08ee097e97e928062a242b0de5b2599a11

The test kernel can be downloaded from:
http://people.canonical.com/~jsalisbury/lp1094800

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

[Pedro Alves (pmgalves)]

Hum, joseph, did you see my last comment? I can absolutely test this one, but is it still relevant? Won't we get to the same results I got?

[Pedro Alves (pmgalves)]

I did the bisect to when this started happening. So here the deal:

SYMPTOMS:

3.x -> 3.3.8: All working!

3.4-rc1: rebooted automatically while resuming from suspension

3.4-rc2 -> 3.8-rc2: behavior described in this report

* Change on 3.3 that caused the system to reboot while trying to resume from first suspension:

b74f05d61b73af584d0c39121980171389ecfaaa is the first bad commit
commit b74f05d61b73af584d0c39121980171389ecfaaa
Author: Marcelo Tosatti <email address hidden>
Date: Mon Feb 13 11:07:27 2012 -0200

    x86: kvmclock: abstract save/restore sched_clock_state

    Upon resume from hibernation, CPU 0's hvclock area contains the old
    values for system_time and tsc_timestamp. It is necessary for the
    hypervisor to update these values with uptodate ones before the CPU uses
    them.

    Abstract TSC's save/restore sched_clock_state functions and use
    restore_state to write to KVM_SYSTEM_TIME MSR, forcing an update.

    Also move restore_sched_clock_state before __restore_processor_state,
    since the later calls CONFIG_LOCK_STAT's lockstat_clock (also for TSC).
    Thanks to Igor Mammedov for tracking it down.

    Fixes suspend-to-disk with kvmclock.

    Reviewed-by: Thomas Gleixner <email address hidden>
    Signed-off-by: Marcelo Tosatti <email address hidden>
    Signed-off-by: Avi Kivity <email address hidden>

:040000 040000 bdfcaa091fd3788bbe86a68ea61f0e792dfd3406 121a7fe2c66294dd13423ce556a74125980b6531 M arch

* Change that fixed the reboot issue on resume from first suspension but still caused a full lock when resuming from *second* suspend:

6742259866d03d5bc19815441ba928e8378343dc . This merge has a parent ( dba69d1092e291e257fb5673a3ad0e4c87878ebc ) that specifically states that aims to fix an issue cased by "s2ram broke due to this KVM commit: b74f05d61b73 x86: kvmclock: abstract save/restore sched_clock_state"

I can try to analyze the difference between this 2 commits but I think this is now way beyond my knowledge. What's the next steps?

[Joseph Salisbury (jsalisbury)]

Sorry, I missed your comment in #33 before I posted #34. I'll take a look at the commits you mention in comment #36 and do some research.

[Brian Murray (brian-murray)]

I have removed the tag regression-update from this bug report as the tag should be used for a regression which happened when installing a package from the -updates repository. This tag is used by the Stable Release Updates team to watch for regressions in packages from -updates and inappropriate usage of this tag makes it harder to find this category of regression. Thanks for your understanding. To learn more about how we use tags you may want to review http://wiki.ubuntu.com/Bugs/Tags.

[Fahad (fahadayaz)]

I can confirm that by installing kernel 3.3.8 from

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3.8-quantal/

suspend works fine every time, as do the brightness Fn keys (they stop working after a single suspend in future kernel versions).

What can I do to help eliminate this regression?

[Joseph Salisbury (jsalisbury)]

The v3.8-rc7 kernel is now available. Can you test this latest mainline kernel and confirm whether the bug still exists or not?

Thanks in advance!

[Fahad (fahadayaz)]

Unfortunately, the problems still occur in this kernel. On closing the lid, the certain Fn keys stop working. Resuming and closing the lid doesn't suspend again. Instead, you have to click on suspend from the menu to try and get it. This causes a black screen but no suspend.

This causes the laptop to freeze and you need to hold the power button and switch off before the laptop will start working again.

[Gerd Xhonneux (gxhonneux)]

I can confirm the same reproducible bug under Mint 14 (kernel 3.5.0-27-generic #46-Ubuntu SMP Mon Mar 25 19:58:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux) using a Toshiba Portégé Z930 - 14L (PT235E) and BIOS Version 6.50 (11/26/2012).

[Nahum Rozen (nahum)]

I have the very same issue with kernel 3.9.

Toshiba engineers - please solve this!

[Michael Marineau (mike-marineau)]

Greetings, I also hit this issue on the recently released Toshiva Kirabook. I bisected the v3.3->v3.4 change (with the help of patching in the kvm clock fix as needed) and tracked it down to this commit:

commit 2feec47d4c5f80b05f1650f5a24865718978eea4
Author: Bob Moore <email address hidden>
Date: Tue Feb 14 15:00:53 2012 +0800

    ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl registers

    Adds sleep and wake support for systems with these registers.
    One new file, hwxfsleep.c

    Signed-off-by: Bob Moore <email address hidden>
    Signed-off-by: Len Brown <email address hidden>

Specifically, when the sleep status/control registeres are detected they are used instead of the traditional registers. The failure to resume a second time is triggered by this write in the new acpi_hw_extended_wake_prep function:

    status = acpi_get_sleep_type_data(ACPI_STATE_S0,
                      &acpi_gbl_sleep_type_a,
                      &acpi_gbl_sleep_type_b);
    if (ACPI_SUCCESS(status)) {
        sleep_type_value =
            ((acpi_gbl_sleep_type_a << ACPI_X_SLEEP_TYPE_POSITION) &
             ACPI_X_SLEEP_TYPE_MASK);

        (void)acpi_write((u64)(sleep_type_value | ACPI_X_SLEEP_ENABLE),
                 &acpi_gbl_FADT.sleep_control);
    }

Replacing that write with the corresponding code from acpi_hw_legacy_wake_prep while leaving the other acpi_hw_extended_* functions alone gets suspend/resume working consistantly. That isn't quite enough as events don't seem to get re-enabled so acpi buttons and such don't work after resume. Copying the enable power button code from acpi_hw_legacy_wake to acpi_hw_extended_wake at least gets the power button back but lid, brightness, etc remain dead.

At the moment I've hacked these changes into v3.10.0-rc2 along with another hack to fix a video regression and it seems to behave reasonabley well. I'm not sure what the apropriate fix is, maybe a blacklist of devices that provide the new registers but don't implement them properly? I'll also post this to the linux-acpi list to see if anyone there offers advice.

[Michael Marineau (mike-marineau)]

Here is a quick patch to add a module paramter to switch back to the legacy sleep functions, just add acpi.legacy_sleep=1 to the kernel options. Not a great solution but a reasonable hack for folks watching this bug until something better comes along.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "0001-Add-option-to-favor-legacy-sleep-code-over-ACPI-v5.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Michael Marineau (mike-marineau)]

Turns out this has already been fixed in ACPICA so expect it in a mainline kernel near you soon. The fix is to simply not use the sleep registers unless the related reduced hardware flag is set, even if the sleep registers exist.

https://github.com/acpica/acpica/commit/34f226fa2643f1d2e6527ea4edb24947cfe1fb6a

http://article.gmane.org/gmane.linux.acpi.devel/61011

[Alexander Pevzner (pzz)]

Looking to ACPICA patch, I have created a temporary hotfix in a form of a tiny kernel module. For me. it completely solves a problem. Please, enjoy:

https://code.google.com/p/toshiba-pmfix/

[Joseph Salisbury (jsalisbury)]

The v3.10-rc4 kernel is now available. Can folks affected by this bug test v3.10-rc4 and see if it still exhibits the issue:
 http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc4-saucy/

[Fahad (fahadayaz)]

Unfortunately, Kernel v3.10-rc4 does not resolve the issue for me.

[Leo Gaggl (leogaggl)]

On mainline kernel 3.8.0-23-generic #34-Ubuntu SMP x86_64 Ubuntu 13.04 - problem still exists.

Will use temporary kernel module patch from https://code.google.com/p/toshiba-pmfix/ - thanks to Alexander Pevzner https://launchpad.net/~pzz !

[penalvch (penalvch)]

Pedro Alves, could you please provide the full computer model (ex. Portege Z930-BT9300)?

[Pedro Alves (pmgalves)]

Z930-12T

Kernel 3.11.0-031100rc4-generic fixed this problem!

[penalvch (penalvch)]

Pedro Alves, as per http://www.toshiba.co.uk/innovation/download_bios.jsp?service=UK an update is available for your BIOS (6.70). If you update to this, does it change anything?

If not, could you please both specify what happened, and provide the output of the following terminal command:
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date

Thank you for your understanding.

[Pedro Alves (pmgalves)]

$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
Version 6.40
10/01/2012

But like I said, 3.11 fixes this (also see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088721)

Didn't have the chance to upgrade to 6.70 yet (no windows here, upgrading bios is always a PITA through freedos, etc)

[Ivan Tiukov (itiukov)]

# sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
Version 6.70
04/04/2013

# uname -a
Linux ivan-tiukov 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I have this bug too..

[penalvch (penalvch)]

Ivan Tiukov, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices
Ubuntu Community: https://wiki.ubuntu.com/ReportingBugs

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report would delay your problem being addressed as quickly as possible.

Thank you for your understanding.

[Joseph Salisbury (jsalisbury)]

The following commit is in mainline and has been cc'd to stable:

7cec704 - ACPICA: Do not use extended sleep registers unless HW-reduced bit is set

I see this commit has made it to Raring and Quantal with the following commits:
Raring: b54663a
Quantal: 3792cff

Can you see if this bug is not resolved, Pedro? If it is, please change the status to "Fix Released".

[Fahad (fahadayaz)]

For me, this fixes the "power key doesn't show logout menu... and if I try to suspend a second time I'm unable to recover from suspension (blank screen)" bit, but not the "After resuming from first supend, brightness keys don't work"

[penalvch (penalvch)]

Fahad, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report would delay your problem being addressed as quickly as possible.

No need exists to comment here at this time. After reading the above documentation in it's entirety, if you have further questions, you are welcome to redirect them to the appropriate mailing list or forum via http://www.ubuntu.com/support/community/mailinglists , or you may contact me directly.

Thank you for your understanding.

[Joseph Salisbury (jsalisbury)]

This bug was nominated against a series that is no longer supported, ie raring. The bug task representing the raring nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

This bug was nominated against a series that is no longer supported, ie quantal. The bug task representing the quantal nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.