linux-kernel - Re: [RFC/PATCH-mm] i8042: activate panic blink only in X

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Sep 2006 01:03:58 +0200
From:	Andreas Mohr <andi@...x01.fht-esslingen.de>
To:	Grant Coady <gcoady.lk@...il.com>
Cc:	Andi Kleen <ak@...e.de>, Dmitry Torokhov <dtor@...ightbb.com>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH-mm] i8042: activate panic blink only in X

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/