Bug 152117 - most recent kernel update - keyboard doesn't work after 'standby'
Summary: most recent kernel update - keyboard doesn't work after 'standby'
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Final
Hardware: Other Other
: P5 - None : Normal
Target Milestone: ---
Assignee: Pavel Machek
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-19 22:08 UTC by Jon Nelson
Modified: 2006-02-23 21:57 UTC (History)
2 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jon Nelson 2006-02-19 22:08:04 UTC 
I'm using an IMB Netfinity which is a PIII 900.  Until the most recent kernel update, I could use 'standby', which worked very well!  However, since the most recent kernel update (kernel-default-2.6.13-15.8), when returning from standby I have about a 10% chance of the keyboard working. The "Num Lock" light stays on (like before), but it's completely unresponsive to input - my USB mouse and everything else works great.  I can unplug and plug back in my keyboard (PS/2 not USB style, FYI) and then it works great.  This isn't a huge issue but it is an unfortunate change and I felt that you should be informed.
Comment 1 Lars Marowsky-Bree 2006-02-21 16:02:18 UTC 
suspend and resume issue, it appears. Pavel?
Comment 2 Vojtech Pavlik 2006-02-21 20:19:51 UTC 
Can you supply more data? Like the 'dmesg' before and after the standby (which I believe is suspend-to-ram, or S3, right?).
Comment 3 Pavel Machek 2006-02-21 23:12:01 UTC 
S1 ... that's special "suspend-to-RAM, hardware state preserved" thing. Mostly useless. Don't know what changed in recent kernel update, and it may be nice to find out, but we don't support S1.
Comment 4 Jon Nelson 2006-02-21 23:53:02 UTC 
How reasonable is it to make this a kernel bug with the kernel folks (is there a bugzilla or whatever or kernel issues?)
Comment 5 Pavel Machek 2006-02-23 15:58:07 UTC 
bugzilla.kernel.org, probably cc vojtech and dmitri. I think this is wontfix, unless vojtech wants to take it...
Comment 6 Vojtech Pavlik 2006-02-23 18:00:37 UTC 
I, too, suggest that you take it to the Linux Kernel bugzilla, as standby
is a feature not supported by Novell/SuSE, while I may be willing to solve
it when I put my input-driver kernel hacker hat on.
Comment 7 Jon Nelson 2006-02-23 20:05:31 UTC 
Just a couple of notes:

1. I had to use S1 because the other suspend-like mode did not work at all.
2. I've observed something interesting - *if* the keyboard works after coming back from suspend, the screensaver does not engage.  If the keyboard does not work, invariably the screensaver is engaged, requiring me to enter my password.  Weird!

I'll try to figure out the best way to work the linux kernel bug tracker.
Comment 8 Jon Nelson 2006-02-23 21:08:57 UTC 
Is it possible that this is a powersave[d] problem? While entering the bug for the kernel (will post bug number here), I began to wonder if somehow it was powersave, under the theory that the screenlock (or lack thereof) appears tied to the behavior of the keyboard.
Comment 10 Christian Boltz 2006-02-23 21:31:16 UTC 
To understand recursion, you have to understand recursion first ;-))

(In other words: you added the wrong URL - this one is pointing to this bugreport...)
Comment 11 Jon Nelson 2006-02-23 21:57:33 UTC 
Aargh!

I meant:

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