Ubuntu

[Toshiba Portege Z935-P390] Fn key and suspend resume failure after first suspend

Reported by Rich Drewes on 2012-12-11
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned

Bug Description

After resuming from the first suspend after clean boot, the mute Fn key (Fn-esc) no longer works and neither do the screen brightness Fn keys nor the WIFI on/off Fn key nor the suspend to RAM Fn key (I usually suspend via the menu anyway). However, the volume up/down Fn keys continue to work. This is with 12.10 Quantal 64 bit installed on my new Toshiba Portege Z935-P390 via EFI boot.

***Then, if I attempt to suspend a second time the machine locks up during the suspend process, it appears. From the suspend logs it appears that the all scripted steps complete properly but things just hang in the final suspend step. The machine cannot be resumed from this, it must be rebooted.***

The same problems occur when I boot 32 bit 12.10 Quantal from a USB key. In order to test this I must disable the EFI setting in BIOS because only the 64 bit version of Quantal supports EFI boot.

However, if I boot 32 bit 12.04.1 from a USB key then I can suspend and resume multiple times.

A commit bisect revealed the offending commit is b74f05d61b73af584d0c39121980171389ecfaaa .

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: linux-image-3.5.0-19-generic 3.5.0-19.30
ProcVersionSignature: Ubuntu 3.5.0-19.30-generic 3.5.7
Uname: Linux 3.5.0-19-generic x86_64
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: drewes 1921 F.... pulseaudio
Date: Mon Dec 10 15:54:11 2012
EcryptfsInUse: Yes
InstallationDate: Installed on 2012-11-29 (11 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MachineType: TOSHIBA PORTEGE Z935
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-19-generic root=UUID=571cece6-83dd-42a5-ae09-efed2aabb209 ro quiet splash acpi_backlight=vendor usbcore.autosuspend=-1 vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.5.0-19-generic N/A
 linux-backports-modules-3.5.0-19-generic N/A
 linux-firmware 1.95
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
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 Z935
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:pnPORTEGEZ935:pvrPT234U-02P02E:rvnTOSHIBA:rnPORTEGEZ935:rvrVersionA0:cvnTOSHIBA:ct10:cvrVersion1.0:
dmi.product.name: PORTEGE Z935
dmi.product.version: PT234U-02P02E
dmi.sys.vendor: TOSHIBA

Rich Drewes (drewes) wrote :

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.7 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.7-raring/

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
Rich Drewes (drewes) wrote :

Thank you for your help.

I installed:

linux-headers-3.7.0-030700-generic_3.7.0-030700.201212102335_amd64.deb
linux-headers-3.7.0-030700_3.7.0-030700.201212102335_all.deb
linux-image-3.7.0-030700-generic_3.7.0-030700.201212102335_amd64.deb
linux-image-extra-3.7.0-030700-generic_3.7.0-030700.201212102335_amd64.deb

and it booted OK. All Fn keys worked on first boot as before. I suspended and resumed and got my desktop back but the only Fn keys that worked were volume up/down. The mute, brightness, and suspend Fn keys did NOT work, as with 3.5 kernel after first resume. I tried to suspend again. This went a little differently than with the 3.5 kernel: now the screen went dark just after initiating suspend, instead of staying backlit and empty as with 3.5 kernel. However, as before, the system could not be resumed with a press on the power button. Alt-SysReq-REISUB did nothing. I verified this behavior two more times. In each case I had to hold the power button down for 5 seconds to recover from the second suspend after clean boot. So the problems remain with the upstream 3.7 kernel.

Note that there is some discussion about the kernel boot option "acpi_backlight=vendor" fixing the Fn keys for brightness adjustment after resume:
http://www.linlap.com/toshiba_portege_z930
This does not work for me. The instruction was for a close relative of my Portege Z935-P390 but not my exact model.

BTW, if I blacklist the toshiba_acpi module, then the Fn key for mute works after the first suspend/resume (both 3.5 and upstream 3.7 kernels)! However, the brightness Fn keys still do not. And suspend still does not work after the first time. Removing the toshiba_acpi module and reinserting it between first and second suspend attempts does not fix suspend problem.

To clarify, 12.04.1 works great with repeated suspend resume cycles, and the Fn keys come back each time. I would gladly downgrade to 12.04.1 but 12.04.1 does not support EFI boot.

I am marking this kernel-bug-exists-upstream as directed.

Rich

tags: added: kernel-bug-exists-upstream

Rich Drewes, thank you for testing the requested mainline kernel. Could you please provide the information following https://wiki.ubuntu.com/DebuggingKernelSuspend ?

tags: added: needs-upstream-testing
removed: kernel-bug-exists-upstream
tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream-v3.7
removed: needs-upstream-testing
tags: added: regression-release
Rich Drewes (drewes) wrote :

Thanks for your help.

* I am running the mainline kernel 3.7.0-030700 (another one, 3.7-rc8-raring was suggested but that comment was apparently deleted, so I stayed with 3.7.0-030700.

* Model is Toshiba Portege Z935-P390

* BIOS is latest available from Toshiba website

* /sys/power/pm_trace is present, so kernel is properly configured for tracing problems

* cat /proc/acpi/wakeup output after initial clean boot (and also identical after resume from first suspend):

Device S-state Status Sysfs node
LANC S4 *enabled pci:0000:00:19.0
HDEF S3 *disabled pci:0000:00:1b.0
USBB S4 *disabled pci:0000:01:00.0
RP02 S4 *disabled
PXSX S4 *disabled
RP04 S4 *disabled
PXSX S4 *disabled
USBC S4 *disabled
EHC1 S4 *enabled pci:0000:00:1d.0
EHC2 S4 *enabled pci:0000:00:1a.0
XHC S4 *disabled
PWRB S4 *disabled
LID S4 *disabled

* I then did one normal suspend/resume cycle since the first one always goes OK.

* I did a second suspend attempt to suspend using the instructions for pm_trace on the page you referenced. This appeared to hang on suspend as expected. I had to hold power button down and reboot. The dmesg output is attached. The Magic number is present but the next line is "tty tty26: hash matches" which I don't think is helpful?

* I repeated this entire operation two more times (dmesg2.txt, dmesg3.txt in subsequent messages). In these cases the Magic number line was also present but the next line referenced rtc_cmos which I think is also not helpful?

Rich

Rich Drewes (drewes) wrote :

Here is the 2nd dmesg from the traced suspend attempt.

Rich Drewes (drewes) wrote :

Here is the 3rd dmesg from traced suspend attempt.

Rich Drewes (drewes) wrote :

Some more information that may be helpful:

* The 64 bit version of 12.04.1 does actually have some preliminary support for EFI, enough to boot from a USB stick. When I do boot this I can suspend and resume many times without trouble. Recall that the 32 bit version of 12.04.1 has no support for EFI (it appears) so I could not boot it at all with my BIOS set to EFI mode, which I must do to be able to dualboot Windows 8 on the other partition.

* Therefore the problem I am having with 12.10 only being able to suspend/resume once is very likely not related to 64 bit vs. 32 bit issues since now I know that 64 bit 12.04.1 booted in EFI mode from a USB key can suspend/resume many times just fine. Nor is the suspend/resume problem likely related to EFI vs CSM (old BIOS compatibility) issues, for the same reason. My understanding is that EFI replaces lots of old BIOS functionality, so it seemed to be a potentially likely source of suspend-resume issues, but that appears not to be the case.

* I would gladly just downgrade and install the the 64 bit version of 12.04.1 on the hard disk since it supports EFI and is able to suspend/resume multiple times, BUT even though it is able to boot EFI off the USB stick, it is sadly apparently not able to create a proper EFI boot on the hard disk (as 12.10 can). Sigh.

Rich

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Rich Drewes (drewes) wrote :

One more thing:

I tried again to install 12.04.1 in EFI mode, since 12.04.1 does does not have the suspend/resume problem that 12.10 does, and it created an unbootable system as before. But this time I was able to make the system bootable through the use of the amazing boot-repair tool (available at https://launchpad.net/~yannubuntu/+archive/boot-repair) which I was able to run from the USB stick boot.

Now I have a functional 12.04.1 system, installed to disk, booting with the BIOS in EFI mode so that I can also boot Windows 8 from the other partition when desired. Yay.

The problem of only being able to suspend and resume once remains with 12.10 and hopefully will be fixed, but I wanted to mention this workaround for others who might have a similar problem.

Rich

tags: added: needs-upstream-testing
removed: kernel-bug-exists-upstream key
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Pedro Alves (pmgalves) wrote :

still happens for me on 3.8-rc1-raring

Changed in linux (Ubuntu):
status: Incomplete → Confirmed

Pedro Alves, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Kernel team article:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports

the Ubuntu Bug Control team and Ubuntu Bug Squad team article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
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 may delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
summary: - Fn key and suspend resume failure after first suspend
+ [Toshiba Portege Z935-P390] Fn key and suspend resume failure after
+ first suspend
Rich Drewes (drewes) wrote :

Short answer:

I have tested and the problem of suspend-resume working only once still exists in 3.8-rc1-raring for me on my Toshiba Portege Z935-P390.

Long answer:

I attempted to test 3.8-rc1-raring on a persistent USB key installation of 12.10 since I now have 12.04.1 installed on my hard disk and didn't want to disturb it. (Side note: to try this test I had to overcome a bug with usb-creator-gtk not actually creating a persistent installation using caspar/copy-on-write, even though it created and mounted the filesystem, because it failed to supply the "persistent" kernel option to the boot loader, but that is another story.) Unfortunately, installing the 3.8-rc1-raring mainline kernel on this USB installation rendered my USB key 12.10 installation unbootable and also rendered the 12.04.1 installation on my hard disk unbootable. Sigh. This may be related to EFI. So I gave up on that approach and recovered my 12.04.1 installation using the fabulous boot-repair tool.

Once I was able to boot my 12.04.1 installation, I installed the 3.8-rc1-raring kernel there. This went OK and I was able to boot the new kernel fine with the 12.04.1 base system. Once booted, I was able to suspend-resume once fine, and then the system hung on the second suspend-resume attempt, just as before. So it appears this "more than one suspend-resume on Toshiba Portege Z935-P390 problem" exists in 3.8-rc1-raring. Also, the fact that the rest of the environment was really 12.04.1 instead of 12.10, with only the addition of the 3.8-rc1-raring to the base 12.04.1 installation, gives further confirmation that this is a kernel regression problem and not due to some other part of the system environment (which I think we all believed anyway).

Rich

Pedro Alves (pmgalves) wrote :

Rich, can you try kernel 3.3.8? Worked for me, as I was only able to reproduce this post 3.4

Pedro Alves, please see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088721/comments/14 .

Rich Drewes, thank you for testing the requested kernel. Could you please test http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc2-raring/ ?

tags: added: kernel-bug-exists-upstream-v3.8-rc1
removed: kernel-bug-exists-upstream-v3.7
Rich Drewes (drewes) wrote :

The problem also exists in 3.8-rc2-raring (when installed on my 12.04.1 system). First suspend-resume is successful, second attempt fails.

Rich

tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream-v3.8-rc2
removed: function kernel-bug-exists-upstream-v3.8-rc1 needs-upstream-testing

Rich Drewes, thank you for testing 3.8-rc2. Could you please test http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc3-raring/ ?

tags: added: needs-upstream-testing
removed: kernel-bug-exists-upstream
Rich Drewes (drewes) wrote :

Tested v3.8-rc3-raring (on my 12.04.1 installation). Problem still occurs, just as before.

kk (ja-schm) wrote :

I have this problem too on my notebook Toshiba Tecra R950 since I upgraded BIOS to version 6.40 released on 10 january 2013. Before BIOS upgrade suspend and Fn keys worked properly.

I tested v 3.8-rc3-raring too. Problem still occurs. It's same as #20

kk (ja-schm) wrote :

I tested kernel 3.3.8-030308-generic 64bit from http://kernel.ubuntu.com/~kernel-ppa/mainline and this kernel works fine (suspend, Fn keys) I think its same as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1094800

Rich Drewes, thank you for testing v3.8-rc3. Could you please test http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc4-raring/ ?

kk, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Kernel team article:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports

the Ubuntu Bug Control team and Ubuntu Bug Squad team article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
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 may delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Rich Drewes (drewes) wrote :

Tested 3.8-rc4-raring (again, within 12.04.1 base system). No fix, problem still exists as before.

tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream-v3.8-rc4
removed: kernel-bug-exists-upstream-v3.8-rc2 needs-upstream-testing
kk (ja-schm) on 2013-01-19
no longer affects: linux

Rich Drewes, thank you for testing the newest mainline kernel. The next step is to perform a Ubuntu kernel bisect from linux 3.2.0-23.36 to linux-image-3.5.0-19-generic, in order to identify the last good Ubuntu kernel version, followed consecutively in version by the first bad one.

Hence, could you please test 3.4.0-5.11 via https://launchpad.net/ubuntu/+source/linux/3.4.0-5.11/+build/3550106 ?

Once this test is complete, could you please continue to bisect following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Thank you for your understanding.

Helpful bug reporting tips:
https://help.ubuntu.com/community/ReportingBugs

Rich Drewes (drewes) wrote :

I am happy to do this bisection however I want to make sure we are not duplicating efforts with this bug report:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1094800

Do you think it is worthwhile doing another bisection or should we wait for their results?

Rich Drewes, regarding bug 1094800, both the specific commit causing the regression, and whether that commit is the same one that caused your regression is unknown. As well, you both have different hardware. Hence, waiting for the final bisect results from it would delay your issue being addressed.

if you can bisect the issue down to a specific commit, this would maximize the speed for your problem to be addressed.

Rich Drewes (drewes) wrote :

It looks like the people in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1094800 have just identified the specific patches that broke the suspend. From the text descriptions of those patches, which specifically address suspend to RAM issues, it seems to me highly likely that the problem area is identified.

Rich Drewes, it would be helpful if you could test reverting the commit noted in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1094800/comments/36 to see if this allows you to suspend again. If so, this would indicate it being highly likely the problem area is identified for your hardware. Could you please test this following https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel ?

Rich Drewes (drewes) wrote :

Some additional help would be good. Here is what I've done so far:

I followed the instructions on BuildYourOwnKernel and got the git repository for the Quetzal kernel (3.5.0-22-generic), built it, installed the .debs, booted into it, and verified the problem still occurs (as expected).

What I want to do now, I think, is undo the commit b74f05d61b73af584d0c39121980171389ecfaaa and recompile the kernel and test that.

Do I have to roll back all the commits made after that one? I'm a little unclear how to proceed. Can you assist? Thanks.

Rich Drewes, to test all commits prior to b74f05d61b73af584d0c39121980171389ecfaaa, one may execute at a terminal:
cd ~/Desktop && git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-stable && cd linux-stable && git checkout 9587190107d0c0cbaccbf7bf6b0245d29095a9ae && cp /boot/config-`uname -r` .config && yes '' | make oldconfig && make-kpkg clean && CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers && cd .. && sudo dpkg -i *.deb

then reboot into the new kernel and test. Please report the results.

Rich Drewes (drewes) wrote :

The kernel built using the commands in #31 does not show the problem. I am able to suspend and resume multiple times with it. That is kernel 3.3.0-rc5-custom+ however, so I'm not sure it is testing what we want.

Remember that I reverted to 12.04.1 and I had been testing 12.10 kernels on a 12.04.1 base system to test this problem. I think the command you provided to pull down the -stable kernel got the older Precise kernel series, based on my 12.04.1 base system, which does not have the suspend problem anyway (which is the reason I reverted to it!)

In my comment #30 I mentioned that I had forced the fetching of the Quetzal kernel and was able to build and test that but I wasn't sure how to revert the commits to the point we wanted. Isn't something like that what we will have to do to test this?

Rich Drewes, thank you for testing the commit reversion. Now, please delete all the .deb files that got generated on your Desktop, and perform the next test,which will include the suspected commit:
cd ~/Desktop/linux-stable && git checkout b74f05d61b73af584d0c39121980171389ecfaaa && cp /boot/config-`uname -r` .config && yes '' | make oldconfig && make-kpkg clean && CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers && cd .. && sudo dpkg -i *.deb

then reboot into the new kernel and test. Please report the results.

Rich Drewes (drewes) wrote :

The kernel built according to comment #33 does introduce a suspend/resume problem, but a different one: the suspend/resume does not succeed even once. The system appears to suspend but when "resumed" it actually just boots.

According to the commit log, this suspend failure was noted and an attempt was made to fix it in a commit that came shortly after. That later commit apparently fixed things from "suspend never works" to "suspend works once" (the subject of this bug report). But the origins of the suspend problem does seem to be right at the commit in the kernel in comment #33.

I'll mention in passing that the kernels built according to #33 and #31 both have another problem that is probably unrelated: on boot into Unity the screen is rotated about 150 pixels to the right (with wraparound). This problem goes away after suspend/resume with the #31 kernel. With the #33 kernel no suspend/resume is possible.

Rich Drewes, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel#KernelTeam.2BAC8-KernelTeamBugPolicies.Overview_on_Reporting_Bugs_Upstream ?

Thank you for your understanding.

Marking Triaged as newest mainline kernel tested, and regression commit bisected.

description: updated
tags: added: cherry-pick
Changed in linux (Ubuntu):
status: Incomplete → Triaged

The fix has not yet been ported from the ACPICA tree (which is OS independent) to mainline Linux. The pm git tree's next branch so far has 20130418 but we need 20130518. I'd assume it'll make it in for 3.11 though.

https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next

tags: added: bios-outdated-6.50
tags: added: needs-upstream-testing
removed: kernel-bug-exists-upstream
Rich Drewes (drewes) wrote :

Mainline kernel 3.11.0-031100rc3-generic fixes the suspend/resume problem for me. (Other late releases may also fix the problem.)

tags: added: kernel-fixed-upstream-v3.11-rc3
removed: kernel-bug-exists-upstream-v3.8-rc4 needs-upstream-testing

Rich Drewes, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, please just make a comment to this.

Changed in linux (Ubuntu):
status: Triaged → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers