Kernel Bug Tracker – Bug 15612
Acer Timeline TravelMate 8571: suspend to RAM fails
Last modified: 2012-06-25 20:43:27 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:
Open gnome-terminal THEN
sh -c "sync; echo 1 > /sys/power/pm_trace; pm-suspend"
NOW suspend ERROR!
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.
See here, too:
Created attachment 25645 [details]
dmesg with BIOS V1.33
with ubuntu 10.04 beta from USB it's the same problem
kernel from 10.04 beta: 2.16.32-16-generic
the 10.04 from usb is amd64, too.
please try to build the latest vanilla kernel, say 2.6.33 and 2.6.34-rc, and see if the problem still exists.
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
Hmm, I'll take dmidecode then...
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)
Created attachment 25880 [details]
dmidecode with BIOS V1.02
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
Is the problem still present in 2.6.37?
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.
Created attachment 67292 [details]
Automatically reset i8042 on Acet TM 8571
Sorry for the delay, could you please try this patch? Thanks!
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.
(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.
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?
Will report back with my findings on both patches near the end of next week.
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 188.8.131.52.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  i8042 is a keyboard controller for PS/2 keyboards, why/how can it interfere with the correct functioning of suspend?
(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 184.108.40.206.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  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.
It's great that kernel bugzilla is back.
can you please verify if the problem still exists in the latest upstream
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?
A patch referencing this bug report has been merged in Linux v3.3-rc1:
Author: Dmitry Torokhov <firstname.lastname@example.org>
Date: Sat Oct 29 12:37:06 2011 -0700
Input: i8042 - also perform controller reset when suspending
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.
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?
Maybe you could use the kernel packages of kernel 3.3.3 for Precise Pangolin from the Ubuntu Kernel PPA  and test again? With kernel 3.3.0 and higher the workaround is not necessary.
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)
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).
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.
in /etc/default/grub to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.reset"
Works with ubuntu 12.04.
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
I think this problem is solved.
See also to launchpad bug:
Thanks for our help.
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
in /etc/default/grub to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.reset" (or reset=1) didn’t change anything.
Thanks for your help!
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:
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)