Hi,
Here is an attempt to make panicblink only active in X so there is a
chance of keyboard still working after panic in text console. Any reason
why is should not be done this way?
--
Dmitry
Input: i8042 - blink keyboard LEDs during panic only when in X
This gives keyboard a chance to work in text console so user
can attempt to exctract more useful data form crashed box
(for example some backtraces from SysRq)
Signed-off-by: Dmitry Torokhov <[email protected]>
---
drivers/input/serio/i8042.c | 10 ++++++++++
1 files changed, 10 insertions(+)
Index: work/drivers/input/serio/i8042.c
===================================================================
--- work.orig/drivers/input/serio/i8042.c
+++ work/drivers/input/serio/i8042.c
@@ -20,6 +20,7 @@
#include <linux/err.h>
#include <linux/rcupdate.h>
#include <linux/platform_device.h>
+#include <linux/vt_kern.h>
#include <asm/io.h>
@@ -831,6 +832,15 @@ static long i8042_panic_blink(long count
static char led;
/*
+ * Only blink while in X because it messes up scrollback in console
+ * preventing users to see the entire oops.
+ */
+#ifdef CONFIG_HW_CONSOLE
+ if (vc_cons[fg_console].d->vc_mode != KD_GRAPHICS)
+ return 0;
+#endif
+
+ /*
* We expect frequency to be about 1/2s. KDB uses about 1s.
* Make sure they are different.
*/
--
VGER BF report: H 0.00257812
On Sat, 2 Sep 2006 23:20:36 -0400, Dmitry Torokhov <[email protected]> wrote:
>To: LKML <[email protected]>
>Subject: [RFC/PATCH-mm] i8042: activate panic blink only in X
>From: Dmitry Torokhov <[email protected]>
>Date: Sat, 2 Sep 2006 23:20:36 -0400
>Cc: Andrew Morton <[email protected]>, Grant Coady <[email protected]>
>
>Hi,
>
>Here is an attempt to make panicblink only active in X so there is a
>chance of keyboard still working after panic in text console. Any reason
>why is should not be done this way?
>
Works as expected here on console, I cannot test the X function.
Grant.
--
VGER BF report: U 0.480126
Dmitry Torokhov <[email protected]> writes:
> Hi,
>
> Here is an attempt to make panicblink only active in X so there is a
> chance of keyboard still working after panic in text console. Any reason
> why is should not be done this way?
>
Looks good to me.
Of course it would be even better to fix the panic stuff to not disrupt scrollback,
but short of that it's a good idea.
-Andi (original panic blink author)
On 04 Sep 2006 16:58:33 +0200, Andi Kleen <[email protected]> wrote:
>Dmitry Torokhov <[email protected]> writes:
>
>> Hi,
>>
>> Here is an attempt to make panicblink only active in X so there is a
>> chance of keyboard still working after panic in text console. Any reason
>> why is should not be done this way?
>>
>
>Looks good to me.
>
>Of course it would be even better to fix the panic stuff to not disrupt scrollback,
>but short of that it's a good idea.
>
>-Andi (original panic blink author)
I'd like to have panic blink and also be able to Shft-Up to previous
console screens.
If possible, kill the console blank timer too? (dunno if you have).
Example: Oops screen on 2.4 recently I paged up to where the fault
started, the screen blanker kicked in while I was hand copying info
and wiped previous screens :( Caused significant delay in working
out what the issue was (slackware-10.2 2.4.33.1 glibc nptl boo-boo).
Is it safe / easy to do on oops/panic?
Grant.
Hi,
On Tue, Sep 05, 2006 at 08:29:09AM +1000, Grant Coady wrote:
> If possible, kill the console blank timer too? (dunno if you have).
>
> Example: Oops screen on 2.4 recently I paged up to where the fault
> started, the screen blanker kicked in while I was hand copying info
> and wiped previous screens :( Caused significant delay in working
> out what the issue was (slackware-10.2 2.4.33.1 glibc nptl boo-boo).
>
> Is it safe / easy to do on oops/panic?
It should be as easy as e.g. doing a
int system_oopsed __read_mostly = 0;
if (!system_oopsed)
blank();
in the timer handler as opposed to painfully deregistering the whole handler
in the critical system state after an OOPS.
A funny side effect is that this way even improves system stability
after OOPS, since the blanking (which doesn't happen then)
might bomb, too ;)
Andreas Mohr
On Tue, 5 Sep 2006 01:03:58 +0200, Andreas Mohr <[email protected]> wrote:
>Hi,
>
>On Tue, Sep 05, 2006 at 08:29:09AM +1000, Grant Coady wrote:
>> If possible, kill the console blank timer too? (dunno if you have).
>>
>> Example: Oops screen on 2.4 recently I paged up to where the fault
>> started, the screen blanker kicked in while I was hand copying info
>> and wiped previous screens :( Caused significant delay in working
>> out what the issue was (slackware-10.2 2.4.33.1 glibc nptl boo-boo).
>>
>> Is it safe / easy to do on oops/panic?
>
>It should be as easy as e.g. doing a
>
>int system_oopsed __read_mostly = 0;
Can't see where to set this one, from the kernel/panic.c notifier chain?
>if (!system_oopsed)
> blank();
drivers/char/vt.c:
...
static void blank_screen_t(unsigned long dummy)
{
if (unlikely(!keventd_up())) {
mod_timer(&console_timer, jiffies + blankinterval);
return;
}
blank_timer_expired = 1;
schedule_work(&console_work);
}
Looks like the place to stop the screen blanker, that's as far as I'm game
to travel.
Hooking the panic notifier chain looks too scary for this little black duck ;)
Grant.
>
>in the timer handler as opposed to painfully deregistering the whole handler
>in the critical system state after an OOPS.
>A funny side effect is that this way even improves system stability
>after OOPS, since the blanking (which doesn't happen then)
>might bomb, too ;)
>
>Andreas Mohr
On Monday 04 September 2006 18:29, Grant Coady wrote:
> On 04 Sep 2006 16:58:33 +0200, Andi Kleen <[email protected]> wrote:
>
> >Dmitry Torokhov <[email protected]> writes:
> >
> >> Hi,
> >>
> >> Here is an attempt to make panicblink only active in X so there is a
> >> chance of keyboard still working after panic in text console. Any reason
> >> why is should not be done this way?
> >>
> >
> >Looks good to me.
> >
> >Of course it would be even better to fix the panic stuff to not disrupt scrollback,
> >but short of that it's a good idea.
> >
> >-Andi (original panic blink author)
>
> I'd like to have panic blink and also be able to Shft-Up to previous
> console screens.
Ok, so here is my attempt at keeping panic blink in console whithout
atkbd bitching at us about ACKs/NAKs. Console scrollback still does
not work for me, most likely because it needs scheduler to run, but
SysRq seems to be working well.
Please try it and tell meif it works for you. Thanks!
--
Dmitry
Subject: i8042 - supress ACK/NAKs when blinking during panic
Input: i8042 - supress ACK/NAKs when blinking during panic
This allows using SysRq and not fill logs with complaints from atkbd.
Signed-off-by: Dmitry Torokhov <[email protected]>
---
drivers/input/serio/i8042.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
Index: work/drivers/input/serio/i8042.c
===================================================================
--- work.orig/drivers/input/serio/i8042.c
+++ work/drivers/input/serio/i8042.c
@@ -106,6 +106,7 @@ static unsigned char i8042_ctr;
static unsigned char i8042_mux_present;
static unsigned char i8042_kbd_irq_registered;
static unsigned char i8042_aux_irq_registered;
+static unsigned char i8042_suppress_kbd_ack;
static struct platform_device *i8042_platform_device;
static irqreturn_t i8042_interrupt(int irq, void *dev_id, struct pt_regs *regs);
@@ -316,7 +317,7 @@ static irqreturn_t i8042_interrupt(int i
unsigned char str, data;
unsigned int dfl;
unsigned int port_no;
- int ret;
+ int ret = 1;
spin_lock_irqsave(&i8042_lock, flags);
str = i8042_read_status();
@@ -378,10 +379,16 @@ static irqreturn_t i8042_interrupt(int i
dfl & SERIO_PARITY ? ", bad parity" : "",
dfl & SERIO_TIMEOUT ? ", timeout" : "");
+ if (unlikely(i8042_suppress_kbd_ack))
+ if (port_no == I8042_KBD_PORT_NO &&
+ (data == 0xfa || data == 0xfe)) {
+ i8042_suppress_kbd_ack = 0;
+ goto out;
+ }
+
if (likely(port->exists))
serio_interrupt(port->serio, data, dfl, regs);
- ret = 1;
out:
return IRQ_RETVAL(ret);
}
@@ -842,11 +849,13 @@ static long i8042_panic_blink(long count
led ^= 0x01 | 0x04;
while (i8042_read_status() & I8042_STR_IBF)
DELAY;
+ i8042_suppress_kbd_ack = 1;
i8042_write_data(0xed); /* set leds */
DELAY;
while (i8042_read_status() & I8042_STR_IBF)
DELAY;
DELAY;
+ i8042_suppress_kbd_ack = 1;
i8042_write_data(led);
DELAY;
last_blink = count;