control key "stuck" after resume on Dell 1420n

Bug #213988 reported by J. Bruce Fields
8
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Medium
Amit Kucheria
Hardy
Fix Released
Undecided
Unassigned

Bug Description

SRU Justification:

Impact: This bug causes keyboard to spew garbage on resume and might cause it to go into an unknown state as reported by the bug reporter

Fix: This patch that is upstream since 2.6.26 (and is contained in Intrepid and Jaunty)

---

With the latest hardy, after a resume from ram the keyboard sometimes behaves as though the control key was always on; e.g., pressing just the "d" key on its own will close an xterm that has focus (as if ctl-d were pressed).

This is intermittent--it doesn't happen after every resume. (I think it may happen on those resume after which the control key is the first key I press, but I haven't been able to confirm this yet.)

When it happens, I can clear the problem by switching to a text console and then back to X with alt-ctl-F1, alt-ctl-F7.

Revision history for this message
J. Bruce Fields (bfields-fieldses) wrote :

There are also times when I get no response to keyboard or mouse input at all after a resume. I don't know if that's the same bug or not. In that situation, pressing the power key does still bring up the suspend/hibernate/etc. menu (though it's no use without other keys or the mouse working), and closing the lid usually puts the laptop back in suspend (which is my workaround for now, as usually the second resume will be succesful).

Revision history for this message
J. Bruce Fields (bfields-fieldses) wrote :

Starting xev and placing my mouse in it before suspend, then watching what happens on keypresses after resume, what I see is that after some resumes, if the first key I press is the left control key, I see that reported as *two* KeyPress events, the first for Control_R, the second for Control_L. Thereafter it reports key events as if the control key were held down (regardless of whether it is). If I press and release the right control key, the keypress is ignored, but the release is reported. Therefore pressing the right control key is a workaround that clears the problem.

Revision history for this message
Joe Caputo (jcaputo1) wrote :

Similar problem...

Ubuntu Hardy, 2.6.24-21 (2.6.24.21.23)
Dell Inspiron E1505 laptop

Occasionally on resume from suspend to RAM, my keyboard gets stuck in repeat. The repeated key doesn't seem to be related to any keys I press; for instance, I could press '5' and get a repeating 'm'. A second suspend/resume cycle doesn't seem to clear the problem up.

I'll try some of the suggestions in this thread and report back (especially regarding L-Ctrl/R-Ctrl, since usually the first thing I do after a resume is a VT switch using LCtrl, to force the X.org Synaptics driver to reassert itself); also, if I can dig up a USB keyboard, I'll see if plugging that in after resume allows me to collect some more information.

Revision history for this message
J. Bruce Fields (bfields-fieldses) wrote :

I found the attached commit in upstream, applied it to 2.6.24-19.41. Six suspend/resume cycles haven't shown the problem yet. I'll continue testing.

(By the way, the kernel my machine was actually running most recently was 2.6.24-21, not 2.6.24-19, but an apt-get source of linux-image-2.6.24-21-generic gets me a linux-2.6.24/ with a debian/changelog whose most recent entry is for 2.6.24-19.41. I'm a little confused as to how to get the latest source....)

Revision history for this message
Joe Caputo (jcaputo1) wrote :

I'd be interested to see how things work with this patch applied to 2.6.24-21, as I don't recall this problem with earlier kernels. Will post results if I get a chance to try it.

Revision history for this message
J. Bruce Fields (bfields-fieldses) wrote :

I've also now tested with the above attached patch applied to 2.6.24-21, and it appears to fix the problem (I've been unable to reproduce the problem after 8 more suspend-resume cycles).

Could someone apply this? It's a simple patch, and already in upstream 2.6.26 (so I'll mark this bug confirmed).

Joe Caputo: your symptoms are different from mine, but it wouldn't be surprising if they had the same root cause; it would be worth trying the same patch and reporting whether your problem is fixed.

(Turns out my problem getting the 2.6.24-21 source was just that my /etc/apt/sources.list had "deb" but not "deb-src" lines for hardy-proposed and hardy-updates.)

Revision history for this message
J. Bruce Fields (bfields-fieldses) wrote :

patch is available in upstream (2.6.26).

Changed in linux:
status: New → Confirmed
Revision history for this message
J. Bruce Fields (bfields-fieldses) wrote :

"There are also times when I get no response to keyboard or mouse input at all after a resume."

That bug appears to be different, though, as it isn't fixed by this patch. (After another 4-5 resumes, I *have* hit that bug again with the patch applied, but still haven't seen the control-key problem.)

Revision history for this message
Joe Caputo (jcaputo1) wrote :

> "There are also times when I get no response to keyboard or mouse input at all after a resume."
>
> That bug appears to be different, though, as it isn't fixed by this patch. (After another 4-5 resumes, I *have* hit that bug again with the patch
> applied, but still haven't seen the control-key problem.)

I sometimes get that, too, but I don't recall if I've ever hit it in Hardy. I agree, though... it's probably an unrelated issue.

Amit Kucheria (amitk)
Changed in linux (Ubuntu):
assignee: nobody → Amit Kucheria (amitk)
status: Confirmed → In Progress
Amit Kucheria (amitk)
Changed in linux (Ubuntu):
status: In Progress → Fix Committed
Stefan Bader (smb)
description: updated
Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Martin Pitt (pitti) wrote :

Please set the development release task appropriately for SRUs, closing karmic one. Otherwise they will stay around indefinitively.

Adding missing hardy task as well.

Changed in linux (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

Accepted linux into hardy-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in linux (Ubuntu Hardy):
status: New → Fix Committed
tags: added: verification-needed
Steve Beattie (sbeattie)
tags: added: hw-specific
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.24-24.56

---------------
linux (2.6.24-24.56) hardy-proposed; urgency=low

  [Stefan Bader]

  * Rebuild of 2.6.24-24.54 with 2.6.24-24.55 security release applied

linux (2.6.24-24.54) hardy-proposed; urgency=low

  [Andy Whitcroft]

  * SAUCE: do not make sysdev links for processors which are not booted
    - LP: #295091

  [Brad Figg]

  * SAUCE: Add information to recognize Toshiba Satellite Pro M10 Alps Touchpad
    - LP: #330885
  * SAUCE: Add signatures to airprime driver to support newer Novatel devices
    - LP: #365291

  [Stefan Bader]

  * SAUCE: vgacon: Return the upper half of 512 character fonts
    - LP: #355057

  [Upstream Kernel Changes]

  * SUNRPC: Fix autobind on cloned rpc clients
    - LP: #341783, #212485
  * Input: atkbd - mark keyboard as disabled when suspending/unloading
    - LP: #213988
  * x86: mtrr: don't modify RdDram/WrDram bits of fixed MTRRs
    - LP: #292619
  * sis190: add identifier for Atheros AR8021 PHY
    - LP: #247889
  * bluetooth hid: enable quirk handling for Apple Wireless Keyboards in
    2.6.24
    - LP: #227501
  * nfsd: move callback rpc_client creation into separate thread
    - LP: #253004
  * nfsd4: probe callback channel only once
    - LP: #253004

 -- Stefan Bader <email address hidden> Sat, 20 Jun 2009 00:14:36 +0200

Changed in linux (Ubuntu Hardy):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.