Bug 9555 - Suspend to RAM horks keyboard autorepeat, system bell, trackpad
Suspend to RAM horks keyboard autorepeat, system bell, trackpad
Status: CLOSED CODE_FIX
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend
All Linux
: P1 normal
Assigned To: power-management_other
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2007-12-12 18:18 UTC by Akkana Peck
Modified: 2008-09-23 07:29 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.23.8
Tree: Mainline
Regression: Yes


Attachments
.config for 2.6.23.8 (37.98 KB, text/plain)
2007-12-12 18:20 UTC, Akkana Peck
Details
working .config for 2.6.23.1 (37.98 KB, application/octet-stream)
2007-12-12 18:21 UTC, Akkana Peck
Details

Description Akkana Peck 2007-12-12 18:18:03 UTC
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.
Comment 1 Akkana Peck 2007-12-12 18:20:32 UTC
Created attachment 14004 [details]
.config for 2.6.23.8
Comment 2 Akkana Peck 2007-12-12 18:21:55 UTC
Created attachment 14005 [details]
working .config for 2.6.23.1
Comment 3 Anonymous Emailer 2007-12-12 18:34:07 UTC
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.

Comment 4 Anonymous Emailer 2007-12-12 21:22:54 UTC
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.

Comment 5 Anonymous Emailer 2007-12-12 21:39:09 UTC
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.

Comment 6 Anonymous Emailer 2007-12-12 22:46:05 UTC
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.

Comment 7 Greg Kroah-Hartman 2007-12-12 23:20:09 UTC
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


Note You need to log in before you can comment on or make changes to this bug.