Op 15-10-09 23:59, Dmitry Torokhov schreef: > > Hm, this is wierd... In the dmesg you sent me in the previous mail I see: > > input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input4 > > So it looks like sometimes it is in raw and sometimes it is in > translated mode. The i8042.reset might be affecting it. Also, are you > using BIOS password at resume by any chance? > > I guess we'll have to wait till you get back to the box and then I want > fresh debug dmesgs (after poweroff) of older (with bind/unbind) and latest > kernels, going through boot, 1st (make sure to type qwerty) and 2nd > resume (qwerty again). Make sure you don't have any other i8042 or atkbd > switches besides i8042.debug. Hello, Back with some results :-) Attached is a (bzip-compressed) log [1] of a 2.6.30 kernel started with i8042.debug (nothing else important). The log contains 4 suspend-resumes (look for "Back to C"): * from the console, using "echo mem > /sys/power/state", keyboard fine * from the console, using "pm-suspend" (aka "all the nasty stuff done by the distro"), keyboard fine * from X, using "echo mem > /sys/power/state", keyboard gone * a unbind-bind cycle, keyboard back * from X, using "echo mem > /sys/power/state", keyboard fine What I realised during this experiment, is that the keyboard goes away after the first suspend-resume _in X_. Each time, I typed on the keyboard "qwerty" (and almost nothing else). Do you see what goes wrong in resuming the keyboard? I can provide a similar log for a 2.6.32-rc3 kernel, if you are interested? BTW, once the keyboard is gone, a rmmod-modprobe cycle of psmouse doesn't recover it, it has to be a rmmod-modprobe cycle of atkbd. See you, Eric [1] Also available uncompressed at http://pieleric.free.fr/unorder/i8042-2.6.30-unbind-bind.dmesg
Attachment:
i8042-2.6.30-unbind-bind.dmesg.bz2
Description: application/bzip
