Description Damien Cassou 2009-12-02 15:16:13 UTC
Often, when I resume the computer after suspend to ram, the mouse pointer moves quite slowly compared to the speed of my finger on the touchpad. Also, letters appear slowly on the screen after I typed on the keyboard. I'm on a Macbook 4.1. I propose 50€ to fix this bug: http://www.cofundos.org/project.php?id=178. More details and attachments can be found at https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/400413 This bug is a duplicate of bug #14717 because I didn't know where to fill it. Please close the wrong one. ProblemType: Bug Architecture: i386 DistroRelease: Ubuntu 9.04 HibernationDevice: RESUME=UUID=70d3c014-ae85-46f4-af1c-67e607655bb2 MachineType: Apple Inc. MacBook4,1 NonfreeKernelModules: wl Package: linux-image-2.6.28-13-generic 2.6.28-13.45 ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.28-13-generic root=UUID=95867fa9-6a8a-4be3-8097-d9e512d5441d ro quiet splash ProcEnviron: PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.28-13.45-generic SourcePackage: linux
Comment 1 Rafael J. Wysocki 2009-12-02 21:04:50 UTC
*** Bug 14717 has been marked as a duplicate of this bug. ***
Comment 2 Zhang Rui 2009-12-22 09:13:09 UTC
please try the latest kernel, say 2.6.32, to see if the problem still exists. If yes, please attach the output of "/proc/interrupts" and "grep . /sys/firmware/acpi/interrupts/*" both before and after the suspend/resume. and attach the dmesg output as well
Comment 3 Damien Cassou 2010-01-02 11:13:40 UTC
Created attachment 24403 [details] dmesg before the problem
Comment 4 Damien Cassou 2010-01-02 11:14:14 UTC
Created attachment 24404 [details] /proc/interrupts before the problem
Comment 5 Damien Cassou 2010-01-02 11:15:01 UTC
Created attachment 24405 [details] /sys/firmware/acpi/interrupts before the problem
Comment 6 Damien Cassou 2010-01-02 11:15:22 UTC
Created attachment 24406 [details] dmesg after the problem
Comment 7 Damien Cassou 2010-01-02 11:15:42 UTC
Created attachment 24407 [details] /proc/interrupts after the problem
Comment 8 Damien Cassou 2010-01-02 11:16:01 UTC
Created attachment 24408 [details] /sys/firmware/acpi/interrupts after the problem
Comment 9 Damien Cassou 2010-01-02 11:20:57 UTC
Please note that the before_* files have been created _after_ a reboot of my computer, and _after_ the problem appeared. If this is a problem, I can create new files.
Comment 10 Damien Cassou 2010-01-02 11:24:00 UTC
Other people report the same issue: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/327311
Comment 11 Damien Cassou 2010-01-02 11:27:05 UTC
The attachments have been made on a 2.6.32 kernel, so I change the "Kernel version" field of this report to 2.6.32.
Comment 12 Zhang Rui 2010-01-04 01:00:29 UTC
(In reply to comment #9) > Please note that the before_* files have been created _after_ a reboot of my > computer, and _after_ the problem appeared. If this is a problem, I can > create > new files. yes, please. I want to see if there is an interrupt storm happened, i.e. interrupts increases a lot after suspend/resume.
Comment 13 Damien Cassou 2010-01-06 11:47:27 UTC
Created attachment 24463 [details] dmesg before the problem
Comment 14 Damien Cassou 2010-01-06 11:50:12 UTC
Created attachment 24464 [details] /proc/interrupts before the problem
Comment 15 Damien Cassou 2010-01-06 11:57:38 UTC
Created attachment 24465 [details] /sys/firmware/acpi/interrupts before the problem
Comment 16 Damien Cassou 2010-01-06 11:59:58 UTC
Created attachment 24466 [details] dmesg after the problem
Comment 17 Damien Cassou 2010-01-06 12:00:51 UTC
Created attachment 24467 [details] /proc/interrupts after the problem
Comment 18 Damien Cassou 2010-01-06 12:02:02 UTC
Created attachment 24468 [details] /sys/firmware/acpi/interrupts after the problem
Comment 19 Damien Cassou 2010-01-06 12:02:58 UTC
Ok, (In reply to comment #12) > (In reply to comment #9) > > Please note that the before_* files have been created _after_ a reboot of > my > > computer, and _after_ the problem appeared. If this is a problem, I can > create > > new files. > > yes, please. > I want to see if there is an interrupt storm happened, i.e. interrupts > increases a lot after suspend/resume. ok, I've updated all the files, sorry for the delay.
Comment 20 throughnothing 2010-01-12 00:13:08 UTC
I have the same problem... It looks like the "IO-APIC-fasteoi ata_piix, ehci_hcd:usb1, uhci_hcd:usb7" interrupts on cpu0 shoot up from ~70k to ~248k. I'm going to see if I can gather some of these files from my compter before and after and see if I get the same results.
Comment 21 throughnothing 2010-01-12 13:24:06 UTC
Created attachment 24519 [details] Before Suspend with everything working properly /proc/interrupts,/sys/firmware/acpi/interrupts/*,dmesg before sleep and before slowness problems.
Comment 22 throughnothing 2010-01-12 13:25:48 UTC
Created attachment 24520 [details] After resume with slowness problems This is all of the same data but after a resume where the slowness with keyboard/mouse is occuring.
Comment 23 Zhang Rui 2010-01-18 02:42:33 UTC
so please boot with kernel parameter "irqpoll" and see if the problem still exist.
Comment 24 Damien Cassou 2010-01-20 11:26:06 UTC
I haven't been able to reproduce the resume problem with this kernel option, which is a good thing. However, my computer froze twice since then and it never did before (I'm not saying this is related).
Comment 25 throughnothing 2010-01-25 15:12:47 UTC
I have not been able to reproduce the bug since using the irqpoll option either. I have not had any crashes yet either. I assume that it would be better not having to use polling, though, so hopefully there's still something we can do to help fix the issue so that using polling is not necessary? Let me know if I can provide any other information or help to help track down the problem when not using irqpoll.
Comment 26 Zhang Rui 2010-01-27 07:16:12 UTC
this seems like an interrupt routing issue. please boot with boot option "nousb" and see if the problem still exists after S3 resume.
Comment 27 throughnothing 2010-01-27 16:17:49 UTC
I haven't tried the "nousb" option yet, but I will say that my computer crashed twice yesterday, which it has pretty much never done before. Both times were when the screensaver was on (though I have no idea if this is the cause). When I came back, everything was just completely frozen and required a hard reset. I will try to test the nousb option over the next few days. I assume you mean to try the "nousb" option *without* the "irqpoll" option?
Comment 28 Zhang Rui 2010-01-28 00:47:52 UTC
(In reply to comment #27) > I assume you mean to try the "nousb" option *without* the "irqpoll" option? yes, you're right. :)
Comment 29 throughnothing 2010-01-28 02:21:22 UTC
Hehe, well this isn't going to work. With "nousb" enabled, the keyboard does not work...and of course I can't plug an external one in....because that would be usb as well. Any other suggestions of stuff I can do to help debug the problem?
Comment 30 Zhang Rui 2010-01-28 02:57:28 UTC
how about using ps2 keyboard/mouse or login via network? Because I suspect it is usb interrupt that is routed incorrectly.
Comment 31 throughnothing 2010-01-28 04:11:33 UTC
This would be really tricky. This is a macbook laptop, essentially the only external ports are usb and firewire. I don't really have another computer here that I can log onto it from remotely, but I may be able to figure something out. Even still, it seems that it would be very hard to reproduce this bug, or to tell if I have reproduced it as I would need to suspend it for a period of time, and then when it comes back to life, the remote ssh login may not show the sluggishness of the physical keyboard/mouse anyway..... If there's actually something that this may show/help with I can try to figure out some way to try this, I just don't know how I will verify that it is reproduced, etc. (Sometimes I can sleep/resume fine without the bug occuring).
Comment 32 throughnothing 2010-01-28 04:12:28 UTC
Actually the real problem in my case also is that I use encrypted / and /home partitions, so the machine cant even boot fully without my keyboard...maybe Damien can try this out :(
Comment 33 Zhang Rui 2010-01-28 07:11:25 UTC
well, let's try something else. please attach the output of "lspci -vvxxx" both before and after S3.
Comment 34 Damien Cassou 2010-01-28 09:10:42 UTC
(In reply to comment #33) > well, let's try something else. > please attach the output of "lspci -vvxxx" both before and after S3. with or without nousb or irqpoll? After a working or a failing resume?
Comment 35 Zhang Rui 2010-01-28 09:24:24 UTC
without any boot options and when the system becomes slow.
Comment 36 Damien Cassou 2010-01-30 17:12:53 UTC
Created attachment 24805 [details] lspci before suspend
Comment 37 Damien Cassou 2010-01-30 17:14:01 UTC
Created attachment 24806 [details] lspci after resume
Comment 38 Damien Cassou 2010-01-30 17:14:54 UTC
Comment 39 Damien Cassou 2010-03-14 08:55:02 UTC
Could you please help me with this?
Comment 40 Sebastian Thürrschmidt 2010-05-17 07:51:44 UTC
I've been getting the same problem, also on a MacBook 4,1, ever since Ubuntu Hardy (kernel version 2.6.24), up to and including Ubuntu Lucid. Strange thing is that the sluggishness comes and goes in mysterious ways: sometimes it occurs on every suspend/resume for several days in a row, then again only rarely or not at all for days or even weeks. While I do not assume that it is somehow correlated to the phase of the moon, I haven't managed to establish any other potential factors with any degree of certainty yet. I'd be happy to be of any help in resolving this. I'm running my system fully encrypted, so I can't easily use the nousb option, rather like Damien. But I'd even be prepared to swap hard disks temporarily and do a non-encrypted Linux install to capture any useful output or log files.
Comment 41 Zhang Rui 2011-04-22 02:38:08 UTC
does the problem still exist in the latest upstream kernel, say 2.6.38? If yes, please attach the dmesg after the problem occurs. and please verify if the problem can be reproduced with boot option "nomodeset".
Comment 42 Zhang Rui 2012-01-18 01:53:59 UTC
Bug closed as there is no response from the bug reporter. Please re-open it if the problem still exists in the latest upstream kernel.