resume from suspend doesn't work (powers off instead) for Acer Aspire 3810T

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it without more information.

Please include the following additional information, if you have not already done so (pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" after a fresh boot and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "sudo lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.

For your reference, the full description of procedures for kernel-related bug reports is available at https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies Thanks in advance!

Architecture: i386
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=6f9ae10f-02b2-4a96-a7d7-700e22184757
MachineType: Acer Acer Project
Package: linux (not installed)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-3-generic root=UUID=b6d9abe7-e298-4e5e-984c-336ff8330d98 ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-3.19-generic
RelatedPackageVersions: linux-backports-modules-2.6.31-3-generic N/A
Uname: Linux 2.6.31-3-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 05/27/2009
dmi.bios.vendor: Acer
dmi.bios.version: V1.04
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: Acer Project
dmi.board.vendor: Acer
dmi.board.version: PSMBOU-1234567
dmi.chassis.asset.tag: None
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: None
dmi.modalias: dmi:bvnAcer:bvrV1.04:bd05/27/2009:svnAcer:pnAcerProject:pvrV1.04:rvnAcer:rnAcerProject:rvrPSMBOU-1234567:cvnAcer:ct10:cvrNone:
dmi.product.name: Acer Project
dmi.product.version: V1.04
dmi.sys.vendor: Acer

Thanks, I ran
apport-collect -p linux 405120

>> Using the "resume-trace" procedure described here does not yield any matches. Unloading all non-essential modules in single user mode doesn't fix it (used /etc/acpi/sleep.sh to initiate suspend).

Sorry, I forgot to include the URL.
https://wiki.ubuntu.com/DebuggingKernelSuspend

I have the same hardware and the same problem.

* I tried booting with init=/bin/bash and was able to unload *all* modules from memory. It did not help.

* I tried:

$ echo core > /sys/power/pm_test
$ echo mem > /sys/power/state

And it went through. I think this suggests a problem with the BIOS itself.

* I tried the above with 2.6.30-02063004 from the kernel PPA. It did not work.

* I tried the above with 2.6.31-020631rc5 from the kernel PPA. It did not work.

All kernels I used are 64bit.

My BIOS version is 1.08.

It looks like there's enough to confirm this

I have done something similar -
http://ubuntuforums.org/showpost.php?p=7702831&postcount=172

with the same result (didn't go through).

Also tried BIOS version 1.10 (released July 27). Didn't help.

I also tried booting with:

acpi_osi= [Yes, it ends at the equal sign.]
acpi_osi="Linux"
acpi_osi="!Linux" [I think this is the default but for the sake of completeness.]

None of it worked.

I disassembled the dsdt and found pearls like these:

                    Method (_BQC, 0, NotSerialized)
                    {
                        If (IGDS)
                        {
                            Return (BRTL)
                        }
                        Else
                        {
                            If (LAnd (LEqual (SPSG, One), LEqual (DPMD, One))) {}
                            Else
                            {
                            }
                        }
                    }

Have you also tried whatever Windows uses? I thought Linux used to always send the same OSI as Windows, for compatibility reasons (some manufacturers "pessimized" for Linux?). I'm far from sure, though, just recalled reading something like that somewhere a long time ago.

(BTW, I am DSDT-illiterate)

Yes, I've also tried acpi_osi="Windows 2006". I figured it would not hurt to try. It did not help. As far as I can tell from reading the DSDT, the DSDT cares only about 3 possibilities:

1. OSI is set to Linux
2. OSI is set to anything else than Linux.
3. OSI is not set.

I think all three possibilities have been covered.

I also tried acpi_serialize and libata.noacpi=1. Neither helped.

I've noticed upon resume the LED for the wireless flashes but the LED for the hard disk does not flash. In Windows, I've noticed the hard disk LED flashing before the wireless. I don't know whether it is an indication of anything.

I've fiddled with the DSDT but that did not help either.

The reason I called the snippet of DSDT a "pearl" is that the else branch of the "If (IGDS)" test is a noop. As coded, it is logically equivalent to this:

                    Method (_BQC, 0, NotSerialized)
                    {
                        If (IGDS)
                        {
                            Return (BRTL)
                        }
                    }

And either version generate a warning when compiled because if IGDS is false, then there is no return value. Basically this method is not coded according to spec. (Huge guess: IGDS is true if the laptop has integrated graphics and false if not. Since Acer has not yet released the models which have discrete graphics they have not yet coded the part of the DSDT which should execute if IGDS is false.)

I'm attaching the decompiled DSDT if someone wants to look at it. This is the one in BIOS 1.08.

Thanks for the hard work!

1 user reported success with suspending with a 4810t and an updated BIOS. If the DSDT is the problem, would it help if we get his DSDT and diff it with ours?
http://ubuntuforums.org/showpost.php?p=7703101&postcount=173

I just dumped my DSDT from BIOS 1.10, and there's a 354 lines diff between that and your dump. I have attached my dump.

I tried compiling it and got loads of different warnings.

Ok... latest test. I recompiled the kernel and made modular much of the ACPI functionality. Here's the relevant section of the config file:

CONFIG_ACPI=y
CONFIG_ACPI_AC=m
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_CONTAINER=m
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_CUSTOM_DSDT_FILE=""
CONFIG_ACPI_CUSTOM_DSDT_INITRD=y
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_FAN=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PCI_SLOT=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_SBS=m
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_WMI=m

Then:

1. I blacklisted modules which are not unloadable if loaded at all (processor is not unloadable if loaded at boot, I had to blacklist thermal too because it depends on processor and will force a load even if processor is blacklisted).

2. And I booted with init=/bin/bash and unloaded as much as I could: in the end all the ACPI modules were unloaded.

So I was left with the acpi functionality which is included in the kernel but all acpi modules removed (no WMI, no fan, no thermal, no processor, etc.).

It still did not fix the problem.

As far as I can tell the machine behaved exactly in the same way as with the stock kernel. I was concerned about thermal in particular: I know that there have been bugs on other machines where the temperature sensors would send out bogus data under certain conditions and would cause Linux to forcibly power down of the machine. Well, there goes that hypothesis...

@Matthew: Thanks for the dump. I'll check into it when I decide that I should spend more time on the DSDT. I'm also DSDT-illiterate so *for now* I'm holding off on doing anything more with it. Whatever I'm able to understand about it is inferred from general computer engineering knowledge and from reading bits of the ACPI specs.

I think my next step will be to boot with ACPI debug turned on (as you can see above I compiled in the necessary functionality for that: now I just need to add the right boot parameters) and look for anything amiss.

I've booted with debug turned on and did not see anything special. I've got a dump of dmesg with acpi.debug_layer=0xffff acpi.debug_level=0xfffff. I won't attach it unless someone specifically requests it. It is huge.

On the other hand, here is something which I had not paid attention to before (this appears in the dmesg even without acpi debugging turned on):

[ 31.206919] ata2.00: ACPI cmd 00/00:00:00:00:00:b0 rejected by device (Stat=0
x51 Err=0x04)
[ 31.207895] ata2.00: ACPI cmd ef/10:01:00:00:00:b0 rejected by device (Stat=0
x51 Err=0x04)
[ 31.208136] ata2.00: ACPI cmd ef/10:02:00:00:00:b0 rejected by device (Stat=0
x51 Err=0x04)
[ 31.208212] ata2.00: ACPI cmd ef/10:03:00:00:00:b0 filtered out
[ 31.208444] ata2.00: ACPI cmd ef/10:04:00:00:00:b0 rejected by device (Stat=0
x51 Err=0x04)
[ 31.208684] ata2.00: ACPI cmd ef/10:05:00:00:00:b0 rejected by device (Stat=0
x51 Err=0x04)

This is the kernel executing the drive's GTF. You can see the 4th command is filtered out by the kernel (i.e. it is not sent to the drive). I turned filtering off and found that the filtered command was the only command which the drive accepted. But even with filtering off, I was not able to resume.

I eventually removed the hard drive and booted from a USB stick but still was not able to resume.

I also tried acpi_power=s3_beep and did not hear any beep. (But I'm having a nagging doubt that there may not be a real *legacy* pc-speaker-style hardware on the laptop. I can't get the darn thing to beep when I'm booted in single user mode.)

I was thinking of trying uswsusp to work around the suspend problem on my 3810t. But I don't want to reinvent the wheel. Has anyone else tried this utility? There seems to be a pretty good set of instructions here: http://en.opensuse.org/S2ram

The problem seems to be at a lower level than that, but feel free to try.

I downloaded s2ram, inspected its code and decided it would probably not be helpful to try.

I could be wrong about this.

By all means, do try it.

Other things I've tried since my last report:

1. I've compiled 2.6.30.4 from kernel.org. This was mainly an effort to try to see if Ubuntu-specific patches would have introduced a bug.

2. I've tried 2.6.31-999.200908060936 from here:

http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2009-08-06/

3. I've also messed with /proc/acpi/wakeup to enable everything in there.

4. I've used ethtool to enable wake-on-lan on eth0. (Just in case the kernel was expecting the network card in a certain state upon wake up. I've also tried waking with a WOL packet... just in case there'd be some success.)

Nothing helped.

Same thing with alpha4/2.6.31-6 (rc6).

I noticed that the wifi light flashes briefly on resume if I had the wifi on before suspend.

Have you also tried removing the wifi card?

Yeah, I also tried rc6.

I've not tried removing the wifi card.

One thing I did was to modify the kernel code to force a speaker beep upon resuming from sleep. This did not work. I noticed the code which is triggered by s3_beep is run AFTER the kernel first perform some consistency checks. So if the consistency checks fail, the kernel does not run the code to make the speaker beep. I added code to perform the beeps BEFORE these checks but I still heard no beep.

I see two possibilities: 1) there is just no functional legacy PC speaker hardware on the board or 2) the kernel never regains control after the hardware resumes operations.

Hello,

I'm considering buying this laptop as well. So I would be interested to know if this can be solve or not.

What about putting information in syslog instead of beep ?

1 user reported the same issue with a 3410T, with an Atheros wifi card, so the wireless card is probably not the culprit.

I've changed the title of the bug to include the Aspire 3410T machine as well. As this machine shares its BIOS code with the 3810T, it is very likely to be the exact same problem. I would like to add that I'm ready and waiting to perform any tests required by the developers in tracing and fixing this bug. It would be great to get a fix in place for the Karmic release.

Darrell

See bug #423320 for the automatically-gathered crash report info, Aspire 3410T under Kernel 2.6.31-9, Karmic, Bios updated to version 1.10. By the way, the 3810T/3410T bios update from the Acer website sets the model name to "Acer Project" replacing the original "Aspire 3410T" or "Aspire 3810T".

A quick note to confirm that the bug is still present under Kernel 2.6.31-10

I think we may have to wait for Acer to release a new BIOS. Afterall, on the 4810t, it was reportedly solved by a BIOS update.

Has anyone contacted Acer yet?

For now, I'm using hibernate, which works fine. I have the SSD version, so resume is very fast (~10 seconds), and I can throw it into my backpack once it starts hibernating (may not be a good idea to do that on a harddrive). Suspend would be more convenient, though, especially for the harddrive version.

I've submitted a problem report on the Acer UK website. I'm sure the official response will be that they do not support Linux (true of course), Suspend does work under Vista.

That is true, but if we can at least get the support people to forward this problem to the engineers (even if it's a no-promise thing), it's possible that they will consider fixing it in the next BIOS update, since it will presumably be easy for them to do (they already fixed it, intentionally or not, for the 4810t).

By the way, has anyone tried TuxOnIce?

There doesn't seem to be a pre-built package for karmic.

In my request to Acer, I told them that the same problem with the 4810T has been reported to have been solved after a BIOS update, so hopefully I have pointed them in the right direction. Still, I think that experience tells us that when there is an incompatibility between Linux and a hardware manufacturer's implementation of any given feature, it is Linux which has to be "fixed", even if it is the manufacturer's implementation which is broken and/or not following standards. Here's hoping, though.

I got the same problem with an "Acer TravelMate 8471" and Ubuntu 9.04 32Bit.

Suspend seems to work, on resume it seems to start up, but powers off after a few seconds. With WindXP suspend works.

Everything else works fine.

* Intel Core™2 Duo SU9400 2x 1,4 GHz
* System-BIOS V1.03

BIOS 1.14 released for 3810t. Suspend still doesn't work.

3410T, Bios 1.14, Kernel 2.6.31-11-generic (64 bit) - suspend still does not work

After running
sudo sh -c "sync; echo 1 > /sys/power/pm_trace; pm-suspend"
i found strange record in dmesg output:

[ 0.657032] registered taskstats version 1
[ 0.657638] Magic number: 0:523:740
[ 0.657642] hash matches /build/buildd/linux-2.6.32/drivers/base/power/main.c:471

Sorry to be slightly out of sequence but I wanted to communicate that GRUB_CMDLINE_LINUX="i8042.reset=1" is is also a fix for a similar issue in the (I believe Acer manufactured) Packard Bell Easynote Butterfly S running the Insyde Bios v. 1.07. Thanks!

This same problem with Ubuntu 10.04 LiveCD

Also same problem with maverick.
Whats the point in reporting bugs if they`re not fixed in new ubuntu versions even if there`s a solution?

I can confirm that this problem is no longer affecting my Acer Timeline 3410T as of the Maverick update. If there is any kind of information dump I can provide regarding my system, I'd be happy to provide it.

3410T here as well, but I had to implement the fix under Maverick. Did you
upgrade from Lucid with the fix applied? May be it carried through.

On 11 October 2010 21:48, Chris Wilson <email address hidden> wrote:

> I can confirm that this problem is no longer affecting my Acer Timeline
> 3410T as of the Maverick update. If there is any kind of information
> dump I can provide regarding my system, I'd be happy to provide it.
>
> --
> resume from suspend doesn't work (powers off instead) for various Acer
> Timeline laptops
> https://bugs.launchpad.net/bugs/405120
> You received this bug notification because you are a direct subscriber
> of the bug.
>

For me, suspend correctly resume after secon suspend after updating to maverick. (3810tg)

I guess i was to quick with my conclusion.
Suspend still powers off my acer 8371. I did fresh install of maverick.

regards
robert

Robert, have you tried to update BIOS version?
What version do you have?

It seems I was too quick to conclude the problem solved. It did work in
the Maverick Development Release after applying the update (although it
didn't work immediately, it took one of the updates to get it to kick
in), but I recently reinstalled my system with Maverick, applied the
fix, and the problem was back.

Have you run "sudo update-grub"?

I have the TravelMate 8571, and suspend works fine with maverick.

For those who have not followed the discussion at the upstream bug report on the kernel's bugtracker, they have patches there which need testing. I confirmed these patches fix suspending, but they need testing from more persons before they can be implemented in the kernel. So anyone who is affected, can you please give the patches mentioned in the upstream bugreport a try and report you experience there?

Alex, link and instructions? :)

On the top of this bugreport you can see a link [1] to the kernel bugtracker. There you can download the patches. I had never patched and built my own kernel before, so I had to figure that out by myself with the help of Google. I can't seem to find the exact instructions I used, but these [2] are a good start, as is this [3] for applying patches. I wish I could upload the patched kernel I compiled so others could immediately use that without having to repeat the process of building the kernel themselves, but the kernel .deb files I got were huge (40 MB or something, which is probably what happens when you don't customise/fine tune the build process) and I already deleted them.

[1] http://bugzilla.kernel.org/show_bug.cgi?id=15612
[2] https://help.ubuntu.com/community/Kernel/Compile
[3] http://en.wikipedia.org/wiki/Patch_(Unix)

Matthew Lai, thank you for reporting this and helping make Ubuntu better. Karmic reached EOL on April 30, 2011.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release with only the Acer Aspire 3810T? If so, can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in a supported release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

If you have an issue for another laptop model, please file a new bug by executing the following at the Terminal and feel free to subscribe me to it:
ubuntu-bug linux

Thanks in advance.

I'm sorry I can't assist, I no longer have this laptop.

I still have this laptop
the problem still exists.

With kubuntu 11.10 (3.0.0-17-generic) this solution helps
"CHANGE the line: linux /boot/vmlinuz-[VERSION]-generic root=UUID=... ro quiet splash
TO: linux /boot/vmlinuz-[VERSION]-generic root=UUID=... ro quiet splash i8042.reset=1

=> suspend to RAM works now"

With ubuntu 12.04 beta2 with kernel 3.2.0-20-generic the problem still exists WITHOUT changing the lines above.

When this error will solved - that changing the line is no more required?

According to kernel bug report (https://bugzilla.kernel.org/show_bug.cgi?id=15612) this problem should solved in kernel 3.3 but ubuntu 12.04 uses 3.2.

@penalvch: Why did you change the status back to Incomplete?

How can this bug be incomplete when it has been fixed upstream (see kernel bug report https://bugzilla.kernel.org/show_bug.cgi?id=15612)? According to that bug report, the bug is fixed in kernel 3.3, but ubuntu 12.04 uses 3.2. When ubuntu upgrades the kernel, this bug will (finally) be solved for ubuntu users.

JW, this report is Incomplete for many reasons:
+ None of the items requested in https://bugs.launchpad.net/linux/+bug/405120/comments/141 were provided by Matthew Lai.
+ https://bugzilla.kernel.org/show_bug.cgi?id=15612 is about Acer Timeline TravelMate 8571 while this report is about a Acer Aspire 3810T. Hence, that bug is irrelevant unless it has been tested to fix the problem reported here in a Acer Aspire 3810T.
+ Bob Bib inappropriately marked this Confirmed without the above being satisfied, nor providing a comment why it should be Confirmed.

> + https://bugzilla.kernel.org/show_bug.cgi?id=15612 is about Acer Timeline TravelMate 8571 while this report is about a Acer Aspire 3810T. Hence, that bug is irrelevant unless it has been tested to fix the problem reported here in a Acer Aspire 3810T.

That report ends with "turskaja" confirming that kernel 3.3 from the PPA for Precise Pangolin works on his Acer Aspire 3810TZ (with the latest BIOS version, 1.28) (see last three comments).

Also, in the comments Alexander van Loon mentions the patch works for the Acer Travelmate 8371 (while the bug report is for 8571).

If you want, I can also install kernel v3.3 from the PPA to verify whether things work correctly now on my 3810T.

Am 29.04.2012 21:24, schrieb JW:
>> + https://bugzilla.kernel.org/show_bug.cgi?id=15612 is about Acer
> Timeline TravelMate 8571 while this report is about a Acer Aspire 3810T.
> Hence, that bug is irrelevant unless it has been tested to fix the
> problem reported here in a Acer Aspire 3810T.
>
> That report ends with "turskaja" confirming that kernel 3.3 from the PPA
> for Precise Pangolin works on his Acer Aspire 3810TZ (with the latest
> BIOS version, 1.28) (see last three comments).
>
> Also, in the comments Alexander van Loon mentions the patch works for
> the Acer Travelmate 8371 (while the bug report is for 8571).
>
> If you want, I can also install kernel v3.3 from the PPA to verify
> whether things work correctly now on my 3810T.
>

I can confirm vanilla linux 3.3 works on my 3810TG.

FWIW, the fix is confirmed to work on many (all?) timeline models by
many people on the <email address hidden> list.

Best regards.

I just tested it, and can confirm suspend-to-ram works in linux 3.3:

linux-image-3.2.0-24-generic-pae (3.2.0-24.37)
WITHOUT i8042.reset=1:
does NOT work

linux-image-3.2.0-24-generic-pae (3.2.0-24.37)
WITH i8042.reset=1:
works

linux-image-3.3.3-030303-generic-pae (3.3.3-030303.201204240708) [1]
WITHOUT i8042.reset=1:
works

linux-image-3.3.3-030303-generic-pae (3.3.3-030303.201204240708)
WITH i8042.reset=1:
works

I am using an Acer 3810T, with bios v1.27.

[1] Using deb downloaded here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3.3-precise/

JW, please execute the following via the Terminal and feel free to subscribe me to it:
ubuntu-bug linux

Thanks!

I can confirm, with ubuntu 12.10 (quantal) daily-live, downloaded a few hours ago, standby (suspend to RAM) works out of the box.
The kernel is: 3.4.0-3-generic
Architecture: amd64

I think this problem is solved.

I have added this information to my kernel bug report http://bugzilla.kernel.org/show_bug.cgi?id=15612

There the problem is marked as solved, too.

Thanks for our help.

Stefan Koch, please do not toggle this report. If you are having a problem in Ubuntu, please file a new report by executing the following via the Terminal and feel free to subscribe me to it:
ubuntu-bug linux

Thanks!

Hi Christopher,

my aim was not to say that I have a problem with the bug.
I have no problem with the bug.
With my kubuntu 12.04 installation I use the i8042-reset so it works.

Furthermore I would say that the problem is solved for future.
In the daily version from ubuntu 12.10 the bug doesn't appear anymore.
This is because the bug is fixed in linux kernel - see in my kernel bug report - there the bug is tagged as solved.

Why this bug is still incomplete?
Incomplete because it is there a mind to backport the fix to ubuntu 12.04 and older versions?

Thanks.

BTW, I've filed a fresh report as a bug #1009773 (as penalvch asked).

I've done some research for duplicate bug #1009773.

The results are very predictable.
The bug is already fixed in Linux kernel packaged for Ubuntu Quantal (version 3.4.0 at that time).
---
Why is it already fixed there?

The patch fixing this issue has been merged in Linux v3.3-rc1: http://bugzilla.kernel.org/show_bug.cgi?id=15612#c22
("Input: i8042 - also perform controller reset when suspending").
---
The possible explanation of the bug and the fix is following.
A MCU firmware emulated i8042 controller is a rather buggy thing sometimes going into unstable state: https://bugzilla.kernel.org/show_bug.cgi?id=15612#c19

To make it work correctly because of going into wrong states, it needs to be reset.

In our Acer models, it seems to work correctly most of times without reset (it only seems to glitch on suspend); therefore, enabling "i8042.reset" kernel option is an excessive one.

A patch named "Automatically reset controller on S2R" (merged in Linux v3.3-rc1: "Input: i8042 - also perform controller reset when suspending") forces this (emulated) i8042 controller to be reset on suspend by default, regardless of the system type (before that, by default, i8042 was forcibly reset by only on resume).

Well, with Linux >= 3.3, suspend should began to work out of the box on a greater number of machines.

Arch Linux has 'linux' package version '3.4.4-2':
http://www.archlinux.org/packages/core/i686/linux/
http://www.archlinux.org/packages/core/x86_64/linux/
therefore, it should be fixed, as for now.

Bob Bib, please do not toggle this report, nor mark your bug a duplicate of this one. For more on this please see https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported .

If you have more information to add, please do so on the report you created. Thanks!

Christopher M. Penalver (penalvch),
> please do not toggle this report, nor mark your bug a duplicate of this one.
would it be better to mark this bug as a duplicate of mine? :)

> If you have more information to add, please do so on the report you created.
well, copied that info there.

> For more on this please see https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported

"For sound, X drivers, and kernel bugs: please open a new bug instead of commenting on a similar bug: chances are that your hardware does not match the existing bug's hardware, so the bug will not be addressed. As well, unless asked of you by a developer or experienced triager, please do not mark your bug a duplicate of another reporter's bug."

Well, the chances are that's the same thing.

This bug was originally reported for the same laptop model, "Acer Timeline 3810t (and friends)" [see the original bug description].

BTW, do you think that there are any chances to get any more info about this bug?

It was reported 3 years ago for archived unsupported old Ubuntu version by a person with no recent activity;
it was sent to upstream bug tracker, where some patch (affecting the i8042 behavior regardless of the machine configuration) was conceived and merged into Linux v3.3-rc1.

-- The updated version of kernel have been proven to fix the problem by a number of affected users (including me).
-- Updated kernel is a part of Quantal now.
-- If someone experiences this problem in Quantal, he (or she) can always file a new bug report.
-- There are a lot of other Linux bugs around to fix them.
What's the reason to keep the status as "Incomplete"?
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

Good news: the i8042 reset fix
(commit 1729ad1f4f9e167ade84ca8b5269695c42351160)
has been cherry-picked into Linux 3.2.35:
http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.35

If I'm correct, Linux > 3.2.35 is now in precise-updates:
https://launchpad.net/ubuntu/+source/linux
Thus, it seems that a "Precise" task with a "Fix Released" status
can be finally added to the current :)
----
https://lists.ubuntu.com/archives/kernel-team/2013-January/024884.html
https://lists.ubuntu.com/archives/kernel-team/2012-November/022955.html
https://lists.ubuntu.com/archives/kernel-team/2012-November/022914.html

* to the current bug

I am aware of the cause of the bug in all...
When the computer enters suspend mode (at least in my case) the hard disk stops spinning and when I attempt resuming, I get a kernel panic.
The solution is for the kernel to always try to spin at least the hard disk drive where the root file system sits...
This doesn't affect computers having a solid-state drive [SSD] as their root disk.
I will first attempt checking whether this was solved in Precise (I had it in Lucid)

In Precise this is solved (I risked).

Paul Olaru,

the current bug has nothing to do with yours:
it relates to the buggy emulated keyboard controller, not HDDs,
and there were no kernel panics, just power-offs (or reboots, as someone reported).

next time, please read the bug description carefully before replying :)