Bug 9555
Summary: | Suspend to RAM horks keyboard autorepeat, system bell, trackpad | ||
---|---|---|---|
Product: | Power Management | Reporter: | Akkana Peck (akkzilla) |
Component: | Hibernation/Suspend | Assignee: | power-management_other |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | bunk |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.23.8 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 7216 | ||
Attachments: |
.config for 2.6.23.8
working .config for 2.6.23.1 |
Description
Akkana Peck
2007-12-12 18:18:03 UTC
Created attachment 14004 [details]
.config for 2.6.23.8
Created attachment 14005 [details]
working .config for 2.6.23.1
Reply-To: akpm@linux-foundation.org (switching to email - please respond via emailed reply-to-all, not via the bugzilla web interface) On Wed, 12 Dec 2007 18:18:05 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9555 > > Summary: Suspend to RAM horks keyboard autorepeat, system bell, > trackpad > Product: Power Management > Version: 2.5 > KernelVersion: 2.6.23.8 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Hibernation/Suspend > AssignedTo: power-management_other@kernel-bugs.osdl.org > ReportedBy: akkzilla@shallowsky.com > > > Most recent kernel where this bug did not occur: 2.6.23.1 > Distribution: Ubuntu feisty > Hardware Environment: Sony Vaio SR71 > Software Environment: > Problem Description: > > With 2.6.23.8, when I suspend to RAM (using /usr/sbin/hibernate -F > /etc/hibernate/ram.conf) from within X, when I resume I see the following odd > behavior: > > 1. The system bell is now half a second long. > 2. Keyboard autorepeat has a very long delay -- like 7 seconds before the > first > repeated character shows up. > 3. If I configure X to use the (Alps) trackpad via the synaptics driver, > after > resuming, clicks from the trackpad don't work at all -- not only are taps > ignored (which is how I've configured xorg.conf) but the physical buttons > don't > generate click events either. If I configure X to use the trackpad just as a > PS/2 mouse, though, it still works normally after resuming. > > 2.6.23.1 with the same .config (I took the .config from 23.8, copied it into > the 23.1 directory, and ran make oldconfig) does NOT exhibit any of these > problems -- it resumes from suspend normally and everything still works. > > Steps to reproduce: > Boot 2.6.23.8. Log in, start X, suspend, resume. Hold down the return key and > observe no autorepeat (at least for a long time). echo ^G and hear the long > bell. xorg.conf to test the trackpad part available upon request. > > I will attach my .configs from 23.1 and 23.8. I've tried with and without > evdev, and with and without tickless, so neither of those is to blame. I > wanted > to try turning off the synaptic driver, but it seems to be a mandatory part > of > the PS/2 mouse driver now. I'm happy to try other configuration options. > > It's possible this is related to bug 7977, but that one is from 2.6.21 and is > supposedly fixed now, and nobody there mentioned the keyboard or bell > aspects. > A regression in the -stable series. IT'd be interesting to see if this has gone into 2.6.24-rc5 too. Reply-To: akkana@shallowsky.com > A regression in the -stable series. > > IT'd be interesting to see if this has gone into 2.6.24-rc5 too. I should have thought to check whether there was a pre-release available. I'm happy to say that 2.6.24-rc5 seems *not* to have this problem. I haven't tried it yet with the synaptics driver enabled, but the keyboard and bell work normally after suspend/resume. Reply-To: akkana@shallowsky.com Works fine (at least for one test -- I'll keep pounding on it) even with the Synaptics driver enabled. w00t! My apologies for wasting your time by not checking for a newer build to test -- thanks very much for the quick response, and I promise to check for an -rc before reporting next time. This bug can be closed unless anyone's curious what happened in 23.8. Reply-To: akkana@shallowsky.com [Replying again with all CCs] Andrew Morton writes: > > http://bugzilla.kernel.org/show_bug.cgi?id=9555 > > > > Summary: Suspend to RAM horks keyboard autorepeat, system bell, > > trackpad [ ... ] > > With 2.6.23.8, when I suspend to RAM (using /usr/sbin/hibernate -F > > /etc/hibernate/ram.conf) from within X, when I resume I see the > > following odd behavior: > > > > 1. The system bell is now half a second long. > > 2. Keyboard autorepeat has a very long delay -- like 7 seconds before the > first > > repeated character shows up. > > 3. If I configure X to use the (Alps) trackpad via the synaptics driver, > after > > resuming, clicks from the trackpad don't work at all -- not only are taps > > ignored (which is how I've configured xorg.conf) but the physical buttons > don't > > generate click events either. If I configure X to use the trackpad just as > a > > PS/2 mouse, though, it still works normally after resuming. [ ... ] > > A regression in the -stable series. > > IT'd be interesting to see if this has gone into 2.6.24-rc5 too. The problem seems fixed in 2.6.24-rc5 (and I'd like to apologize for wasting everyone's time by not checking for a new version first). So the bug appeared in the patches that took 2.6.23.1 to 2.6.23.8, and was fixed by something between .23.8 and .24-rc5. I'm fine with closing the bug since it's working fine in .24-rc5, but if anyone is curious what the problem was, I'm happy to help with tracking it down. It's very easily reproducible on this machine. On Wed, Dec 12, 2007 at 10:45:32PM -0800, Akkana Peck wrote:
> The problem seems fixed in 2.6.24-rc5 (and I'd like to apologize for
> wasting everyone's time by not checking for a new version first).
> So the bug appeared in the patches that took 2.6.23.1 to 2.6.23.8, and
> was fixed by something between .23.8 and .24-rc5.
>
> I'm fine with closing the bug since it's working fine in .24-rc5,
> but if anyone is curious what the problem was, I'm happy to help
> with tracking it down. It's very easily reproducible on this machine.
Yes, it would be nice to find out the 2.6.23 patch that caused this, so
we can revert it as people are still using the 2.6.23 tree :)
Can you do a bisection with the releases between 2.6.23.1 and 2.6.23.8
and see which release and then which patch caused this to happen?
thanks,
greg k-h
|