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
*** Bug 14717 has been marked as a duplicate of this bug. ***
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
Created attachment 24403 [details] dmesg before the problem
Created attachment 24404 [details] /proc/interrupts before the problem
Created attachment 24405 [details] /sys/firmware/acpi/interrupts before the problem
Created attachment 24406 [details] dmesg after the problem
Created attachment 24407 [details] /proc/interrupts after the problem
Created attachment 24408 [details] /sys/firmware/acpi/interrupts after the problem
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.
Other people report the same issue: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/327311
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.
(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.
Created attachment 24463 [details] dmesg before the problem
Created attachment 24464 [details] /proc/interrupts before the problem
Created attachment 24465 [details] /sys/firmware/acpi/interrupts before the problem
Created attachment 24466 [details] dmesg after the problem
Created attachment 24467 [details] /proc/interrupts after the problem
Created attachment 24468 [details] /sys/firmware/acpi/interrupts after the problem
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.
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.
Created attachment 24519 [details] Before Suspend with everything working properly /proc/interrupts,/sys/firmware/acpi/interrupts/*,dmesg before sleep and before slowness problems.
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.
so please boot with kernel parameter "irqpoll" and see if the problem still exist.
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).
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.
this seems like an interrupt routing issue. please boot with boot option "nousb" and see if the problem still exists after S3 resume.
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?
(In reply to comment #27) > I assume you mean to try the "nousb" option *without* the "irqpoll" option? yes, you're right. :)
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?
how about using ps2 keyboard/mouse or login via network? Because I suspect it is usb interrupt that is routed incorrectly.
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).
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 :(
well, let's try something else. please attach the output of "lspci -vvxxx" both before and after S3.
(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?
without any boot options and when the system becomes slow.
Created attachment 24805 [details] lspci before suspend
Created attachment 24806 [details] lspci after resume
Ok, done.
Could you please help me with this?
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.
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".
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.