Bug 15612

Summary: Acer Timeline TravelMate 8571: suspend to RAM fails
Product: Power Management Reporter: Stefan Koch (stefan.koch10)
Component: Hibernation/SuspendAssignee: power-management_other
Status: CLOSED CODE_FIX    
Severity: normal CC: a.vanloon, dmitry.torokhov, florian, rjw, rui.zhang, zukunft
Priority: P1    
Hardware: All   
OS: Linux   
URL: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/405120
Kernel Version: 2.6.31-20 Subsystem:
Regression: No Bisected commit-id:
Bug Depends on:    
Bug Blocks: 7216    
Attachments: dmesg with BIOS V1.33
dmidecode with BIOS V1.02
Automatically reset i8042 on Acet TM 8571
Automatically reset controller on S2R

Description Stefan Koch 2010-03-22 21:35:18 UTC
With my Acer TravelMate 8571-352G25Mn suspend to RAM does not work, too. (suspend to HDD works)
Thats the TravelMate with the Core2Solo SU3500 CPU shipped with Linpus Linux (terminal only)

I'm using ubuntu 9.10 amd64 with 2.6.31-20-generic linux kernel.
The latest apt-get update; apt-get dist-upgrade was today.

-------------

If I launch a suspend, the laptop goes in suspend (the power led is blinking) if I press the power button the laptop makes a reboot/restart.

Steps for the last suspend:
apt-get update
apt-get dist-upgrade
REBOOT (normal)
REBOOT (normal)

Open gnome-terminal THEN
sudo su
sh -c "sync; echo 1 > /sys/power/pm_trace; pm-suspend"

NOW suspend ERROR!
open gnome-terminal
sudo su
dmesg > dmesg.txt

The dmesg.txt file is attached here...

I use ubuntu 9.10 amd64 with 2.6.31-20-generic linux kernel.
The latest apt-get update; apt-get dist-upgrade was today.

Thanks...

See here, too:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/405120
Comment 1 Stefan Koch 2010-03-22 21:41:47 UTC
Created attachment 25645 [details]
dmesg with BIOS V1.33
Comment 2 Stefan Koch 2010-03-22 22:30:32 UTC
with ubuntu 10.04 beta from USB it's the same problem
Comment 3 Stefan Koch 2010-03-22 22:35:15 UTC
kernel from 10.04 beta: 2.16.32-16-generic
Comment 4 Stefan Koch 2010-03-22 22:36:41 UTC
the 10.04 from usb is amd64, too.
Comment 5 Zhang Rui 2010-03-23 07:43:58 UTC
please try to build the latest vanilla kernel, say 2.6.33 and 2.6.34-rc, and see if the problem still exists.
Comment 6 Stefan Koch 2010-03-23 14:01:56 UTC
CHANGE the line (Press "e" in GRUB bootloader; after edit Ctrl+X): linux /boot/vmlinuz-2.6.31-20-generic root=UUID=... ro quiet splash
TO: linux /boot/vmlinuz-2.6.31-20-generic root=UUID=... ro quiet splash i8042.reset=1

=> suspend to RAM works now
Comment 7 Dmitry Torokhov 2010-03-23 22:14:08 UTC
Hmm, I'll take dmidecode then...
Comment 8 Stefan Koch 2010-04-06 07:47:49 UTC
I have had installed the linux-2.6.36 kernel (ubuntu mainline) from 2010-04-03 and this kernel needs the i8042.reset=1 line, too.
Without this the suspend to RAM fails...

ubuntu mainline: http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2010-04-03-karmic/

I have attached dmidecode, now with BIOS V1.02 (I have downgraded, because Fan noise with V1.33 and V1.24)
Comment 9 Stefan Koch 2010-04-06 07:49:33 UTC
Created attachment 25880 [details]
dmidecode with BIOS V1.02
Comment 10 Stefan Koch 2010-04-06 13:41:03 UTC
I have compiled the vanilla kernel 2.6.34-rc3 from http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.34-rc3.tar.bz2 on my PC and installed the created DEB-Files from there on my laptop...
PC: Athlon64 3000+
NB: Intel Core2Solo SU3500
On both are ubuntu 9.10 amd64 versions installed.

This kernel needs the i8042.reset=1 option, too.
Without -> suspend fails
With -> suspend works
Comment 11 Rafael J. Wysocki 2011-01-16 22:27:43 UTC
Is the problem still present in 2.6.37?
Comment 12 Alexander van Loon 2011-07-31 17:48:36 UTC
I'm using the 3.0 kernel here (3.0.0-7.9 being the exact version of the Ubuntu package) and I can confirm that the fix is still necessary for getting suspend to RAM working. It's unfortunate this bug report hasn't seen any activity for so long, I'm watching this closely and I'm ready to do any debugging or whatever is required by the developers to assist with getting this bug killed.
Comment 13 Dmitry Torokhov 2011-08-01 05:04:59 UTC
Created attachment 67292 [details]
Automatically reset i8042 on Acet TM 8571

Sorry for the delay, could you please try this patch? Thanks!
Comment 14 Alexander van Loon 2011-08-01 09:51:09 UTC
Thank you so much for your quick reply. However, because the title of this bugreport is a little bit misleading, the patch seems to have been made only for the TravelMate 8571. The URL given in the description links to a bug report on Launchpad which mentions that not only the TravelMate 8571 is affected, but also the Acer Aspire 3410T, the Acer Aspire 3810T/3810TG/3810TZ and the Acer Travelmate 8371/8371G/8471.

For completeness I should have mentioned in my previous comment that I'm using an Acer Travelmate 8371 flashed with the latest BIOS version, 1.28.

I executed dmidecode on my laptop and it said the product name was TravelMate 8371. This line is found in the patch:

DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 8571"),

So if I change '8571' in this line to '8371' it should work on my laptop as well, right? Now I'm going to find some documentation on compiling a kernel on Ubuntu and applying the patch, I haven't done that before.
Comment 15 Dmitry Torokhov 2011-08-01 16:46:55 UTC
(In reply to comment #14)
> So if I change '8571' in this line to '8371' it should work on my laptop as
> well, right?

Yes. Or you could try adding the 2nd block (similar to the one my patch is adding) for your model.
Comment 16 Dmitry Torokhov 2011-08-02 21:06:24 UTC
Created attachment 67382 [details]
Automatically reset controller on S2R

Hmm, maybe we should reset the controller before suspending, like we do on resume, for all models. Could you please tell me if this patch makes S2R work for you?
Comment 17 Alexander van Loon 2011-08-03 12:51:48 UTC
Will report back with my findings on both patches near the end of next week.
Comment 18 Alexander van Loon 2011-08-21 17:52:57 UTC
Today I finally found some spare time to test the patches. I changed all instances of '5871' in the first patch to '8371' and modified my /etc/default/grub back to default values so the workaround was gone. Then I compiled two kernels of version 3.0.0.8.9, one for each patch.

I verified that suspend would fail again without the workaround just to be sure. Then I tested both kernels and both successfully suspended to RAM. Both patches work, thank you so much Dmitry! I hope these fixes will make it to the next Ubuntu release.

Last question, in the patches code regarding 'i8042' is modified to fix it. According to Google [1] i8042 is a keyboard controller for PS/2 keyboards, why/how can it interfere with the correct functioning of suspend?

[1] http://gunnarwrobel.de/wiki/Linux-and-the-keyboard.html#sec3
Comment 19 Dmitry Torokhov 2011-08-25 07:13:21 UTC
(In reply to comment #18)
> Today I finally found some spare time to test the patches. I changed all
> instances of '5871' in the first patch to '8371' and modified my
> /etc/default/grub back to default values so the workaround was gone. Then I
> compiled two kernels of version 3.0.0.8.9, one for each patch.
> 
> I verified that suspend would fail again without the workaround just to be
> sure. Then I tested both kernels and both successfully suspended to RAM. Both
> patches work, thank you so much Dmitry! I hope these fixes will make it to
> the
> next Ubuntu release.

Thanks for testing. Before applying to mainline we need wider testing as the 2nd patch will activate i8042 rest on suspend on all boxes, not only Acer.

> 
> Last question, in the patches code regarding 'i8042' is modified to fix it.
> According to Google [1] i8042 is a keyboard controller for PS/2 keyboards,
> why/how can it interfere with the correct functioning of suspend?

In modern (well rather not ancient) boxes i8042 is no longer a separate chip but rather part embedded controller + firmware emulating i8042 behavior. Embedded controller is typically responsible for many things, one of which is power management and unfortunately firmwares are usually not very robust. If they find themselves in unexpected state they tend to get very confused and stop working properly.

Hope this helps.
Comment 20 Zhang Rui 2012-01-18 02:02:10 UTC
It's great that kernel bugzilla is back.

can you please verify if the problem still exists in the latest upstream
kernel?
Comment 21 Alexander van Loon 2012-01-21 14:19:25 UTC
I confirm that this bug persists in the latest stable upstream kernel, 3.2.1. Or do you want to me to verify if it is still present in the latest unstable upstream kernel, 3.3-rc1 at the moment?
Comment 22 Florian Mickler 2012-01-21 16:35:57 UTC
A patch referencing this bug report has been merged in Linux v3.3-rc1:

commit 1729ad1f4f9e167ade84ca8b5269695c42351160
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Sat Oct 29 12:37:06 2011 -0700

    Input: i8042 - also perform controller reset when suspending
Comment 23 Alexander van Loon 2012-01-21 20:05:27 UTC
Thanks for the notice Florian. I just tested again with 3.3-rc1 and can now confirm that suspending works like a charm. Thank you so much for getting the patch merged Dmitry.
Comment 24 turskaja 2012-04-28 11:38:18 UTC
Hi!
I am working with my Acer Aspire 3810TZ (with the latest BIOS version, 1.28) on Ubuntu 12.04 Precise Pangolin, kernel 3.2.0-23-generic. At my computer the bug still exists, although I added the i8042.reset=1 in /etc/default/grub.
Does anybody have some ideas how to fix it?
Thanks!
turskaja
Comment 25 Alexander van Loon 2012-04-28 17:01:42 UTC
Maybe you could use the kernel packages of kernel 3.3.3 for Precise Pangolin from the Ubuntu Kernel PPA [1] and test again? With kernel 3.3.0 and higher the workaround is not necessary.

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3.3-precise/
Comment 26 turskaja 2012-04-28 18:03:29 UTC
I didn’t want to upgrade the kernel, but today I did so. I had to restore the old /boot/vmlinuz-3.2.0-23-generic (I had changed it to i8042.reset=1...).
http://www.ubuntubuzz.com/2012/03/upgrade-to-kernel-33-in-ubuntu.html helped me to install kernel 3.3.3 and finally suspend works (with uswsusp)
Thank you!
Comment 27 turskaja 2012-05-15 10:19:56 UTC
Hi there, back again!
After I updated my system to kernel 3.3.3 suspend2ram finally worked but nothing else. So I had to reinstall my computer, I’m back at 3.2.0-24-generic.
Is there another possibility to make s2ram work? (On ubuntu 10.04 it worked, but I can’t remember how I got working it).

Thanks, t
Comment 28 turskaja 2012-05-22 19:51:39 UTC
I added the i8042.reset=1 to /boot/grub/grub.cfg and all works fine in kernel 3.2.0-24-generic.
I was wondering why it works the first time by changing the setparams using ctrl + e as stefan describes here → https://bugzilla.kernel.org/show_bug.cgi?id=15612#c6, but afterwords it won’t work. But I realized that I have to change /boot/grub/grub.cfg to fix it permanent.
Thank you!
Comment 29 Stefan Koch 2012-06-01 12:36:35 UTC
@turskaja
Change line
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
in /etc/default/grub to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.reset"

Works with ubuntu 12.04.
Comment 30 Stefan Koch 2012-06-01 12:39:44 UTC
I can confirm, with ubuntu 12.10 (quantal) daily-live, downloaded a few hours ago, standby (suspend to RAM) works now out of the box.

The kernel is: 3.4.0-3-generic
Architecture: amd64

I think this problem is solved.

See also to launchpad bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/405120
Comment 31 Stefan Koch 2012-06-01 12:41:14 UTC
Thanks for our help.
Comment 32 turskaja 2012-06-25 19:56:18 UTC
Hey there, back again!
after updating the kernel, the problem came back.

The new kernel is: 3.2.0-25-generic

It worked fine with the  i8042.reset=1 argument in /boot/grub/grub.cfg

after updating, the same problem came back, changing 
line
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
in /etc/default/grub to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.reset" (or reset=1) didn’t change anything.

Thanks for your help!

turskaja
Comment 33 Stefan Koch 2012-06-25 20:43:27 UTC
Hi,

open a terminal and run:

sudo grub-install /dev/sdX
sudo update-grub /dev/sdX

I think the first command is not needed.

You could also try:

http://cdimage.ubuntu.com/daily-live/current/

Download it and write the image with the "dd" command to an USB stick and boot from it. Then make a suspend to RAM. And verify if the laptop have a correct wake-up.

(This is because the problem should solved in the ubuntu daily kernel - that means no i8042.reset is needed anymore)

Best regards

Stefan Koch