Bug 115352 - Blinking keyboard LEDs after kernel panic considered harmful
Summary: Blinking keyboard LEDs after kernel panic considered harmful
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Beta 3
Hardware: i686 All
: P5 - None : Normal
Target Milestone: ---
Assignee: Vojtech Pavlik
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-06 06:38 UTC by Ulrich Windl
Modified: 2008-06-26 09:07 UTC (History)
2 users (show)

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


Attachments
Screen shot with repeated kernel messages after panic (13.15 KB, image/png)
2005-09-06 06:39 UTC, Ulrich Windl
Details

Note You need to log in before you can comment on or make changes to this bug.
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"))?