New: Suspend to RAM horks keyboard autorepeat, system bell, trackpad

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: [email protected]
ReportedBy: [email protected]

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.

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: [email protected]
ReportedBy: [email protected]

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.

Quoted 4 lines

http://bugzilla.kernel.org/show_bug.cgi?id=9555

Summary: Suspend to RAM horks keyboard autorepeat, system bell,
trackpad

Quoted 12 lines

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.

Quoted 4 lines

http://bugzilla.kernel.org/show_bug.cgi?id=9555

Summary: Suspend to RAM horks keyboard autorepeat, system bell,
trackpad

Quoted 12 lines

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.