Kernel Bug Tracker – Bug 10054
keyboard not working after hibernate/resume
Last modified: 2008-11-22 10:59:45 UTC
Latest working kernel version: none
Earliest failing kernel version: 2.6.24 (not accurate, because I didn't try with an earlier version)
Distribution: "vanilla" 2.6.25-rc2 kernel from kernel.org
Hardware Environment: Acer TravelMate 7520g, Turion64 X2 TL60, SATA harddisks, Synaptics touchpad. Please request any other information if necessary.
Software Environment: Debian Linux with packages from unstable.
Problem Description: After the system has been hibernated and resumed, the laptop's keyboard is not working, and I am getting this error message through the console:
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly.
An attached USB keyboard is working after the resume, only the "embedded" keyboard is affected. And I think I should mention that everything else (eg. the touchpad) is working fine after the resume (except the pc-speaker, but I think that that will go to another report).
Steps to reproduce:
# echo disk > /sys/power/state
Load the same kernel image with "resume=<swap>".
# atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly.
... and the laptop's keyboard is not working, I need to reboot with the attached USB keyboard.
I've managed to figure out, that I only get this atkbd.c: Spurious ... error message after a resume, if I have used the setfont command to setup a console font. If I don't do this (ie. I'm leaving the default font) the laptop keyboard is working after the resume.
Can you try an earlier kernel, please? 2.6.23.x for example?
I've tried with 188.8.131.52, and it works fine there.
I've done a `setfont terminus`, hibernate->resume, and the keyboard is working. Altough the font has been reset to the default (ie. after the resume, the default font was active instead of terminus).
Any progress with this? What should I do next?
[Sorry, I didn't receive any notification of your previous post.]
Well, the only thing I can suggest you is to use 'git bisect' to find the change between 2.6.23 and 2.6.24 that broke your setup.
Can't do unfortunatelly. While trying the 2.6.23 kernels, it just panics during boot, and the results are are too many broken images while I'm working my way up until 2.6.24. Guess I'm just have to live without S4 :)
Daniel, has anything changed in your keyboard behavior with the latest kernel?
No, unfortunately not. I'm now using 184.108.40.206, and everything is the same, still getting that "Spurious ACK..." message after resume from a hibernate.
Could you please do "echo 1 > /sys/module/i8042/parameters/debug", suspend, resume and send me dmesg, please?
Created attachment 16381 [details]
Created attachment 16382 [details]
I've attached the dmesg, and also the kern.log file (who knows :). Hope that those will help!
Please don't hesitate to let me know, if more information or testing is needed.
This is still an issue with the latest stable prepatch 2.6.26-rc9
In the dmesg you posted I see keyboard data coming from the controller after resume. Was it done with the terminus font loaded?
Correct! Before the resume the terminus font was loaded.
Tried with 2.6.26 final, the resume is not working yet. Am I providing to few information, or is this a problematic issue?
I am just baffled as to why loading a different font would make a difference to the keyboard controller... car to send the same debug information without terminus loaded?
Wow, unfortunatelly, now with the font loaded, it acts the same; still can't resume with keyboard working. I'm attaching the log, but I sense that this will be identical to the previous one.
(In reply to comment #18)
> Wow, unfortunatelly, now with the font loaded, it acts the same; still can't
> resume with keyboard working. I'm attaching the log, but I sense that this will
> be identical to the previous one.
Of course that is *without* the font loaded. sry
Created attachment 17023 [details]
new kern.log (2.6.26)
does the problem still exist in the latest kernel release?
With 220.127.116.11, the problem doesn't exist. Thanks for asking, I would have forgot to test this.