Bug 152117

Summary: most recent kernel update - keyboard doesn't work after 'standby'
Product: [openSUSE] SUSE LINUX 10.0 Reporter: Jon Nelson <jnelson-suse>
Component: KernelAssignee: Pavel Machek <pavel>
Status: RESOLVED WONTFIX QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: suse-beta, vojtech
Version: Final   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

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