Bug 115352

Summary: Blinking keyboard LEDs after kernel panic considered harmful
Product: [openSUSE] SUSE LINUX 10.0 Reporter: Ulrich Windl <Ulrich.Windl>
Component: KernelAssignee: Vojtech Pavlik <vojtech>
Status: RESOLVED WONTFIX QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: dmueller, suse-beta
Version: Beta 3   
Target Milestone: ---   
Hardware: i686   
OS: All   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Screen shot with repeated kernel messages after panic

Description Ulrich Windl 2005-09-06 06:38:09 UTC 
Before someone added the patch to blink the keyboard LEDs after a kernel panic,
I was able to scroll back the current terminal (text console). With that
modified panic routine this was no longer possible.
Recently it's even worse: After a kernel panic repeated messages are generated
that will scroll the actual panic message off the screen quickly. The messages are:
<4>atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might by
trying access hardware directly.

See also bug #115350.
Comment 1 Ulrich Windl 2005-09-06 06:39:11 UTC 
Created attachment 48878 [details]
Screen shot with repeated kernel messages after panic
Comment 2 Andreas Kleen 2005-09-06 09:21:07 UTC 
Easy fix is to just diable that useless printk. atkbd/i8042 in general 
is far too noisy for its own good.
Comment 3 Vojtech Pavlik 2005-09-06 09:50:00 UTC 
The printk is far from useless - it helps debugging cases where something
messes with the hardware without the knowledge of the driver.

The LED blinking code is quite problematic:

    * it doesn't disable the keyboard IRQ, causing responses
      from the commands it sends to be delivered to the original
      driver (which then complains)

    * doesn't read the data port, and probably relies on the
      IRQ code to empty the incoming buffer.

    * definitely relies on the original driver to still handle
      keypresses, while causing a stream of command responses
      to mix in.

This can never work. There are a few possible ways to fix it:

     * Disable the keyboard interrupt in the blink routine and
       read the data port. This will work even when IRQs are
       dead and won't depend on anything else. Scrollback will
       NOT work.

     * Move the blinking routine into atkbd.c, and make it rely
       on interrupts to deliver the command responses, properly
       handling them. Scrollback will work, LEDs will not blink
       if IRQs are dead.

IMO the second option is better, since when a panic() happens, interrupts
still work usually, unlike when a hard hang happens.

Andi, what's your thoughts on this?
Comment 4 Andreas Kleen 2005-09-07 10:29:38 UTC 
Doing it interrupt driven would be fine for me. Leaving to you.
Comment 5 Vojtech Pavlik 2005-09-07 10:47:06 UTC 
OK, I'll do that,
Comment 6 Vojtech Pavlik 2007-02-22 08:08:11 UTC 
It is not possible anymore with the new libps2 where atkbd_command() sleeps.
I'll take a look again at just getting rid of the messages that atkbd produces
when in panic().
Comment 8 Vojtech Pavlik 2008-06-07 13:53:53 UTC 
I'm afraid this bug can't really be fixed - the only way is to simply disable the panic blink feature if the result of it is too bothersome. Closing as WONTFIX.
Comment 9 Ulrich Windl 2008-06-26 09:07:16 UTC 
Could it be made configurable at least (Either via sysconfig or kernel parameter ("boot string"))?