linux-kernel - Re: blink driver power saving

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]

Message-ID: <d120d5000707020642j752ca814l501aaa543f9babcf@mail.gmail.com>
Date:	Mon, 2 Jul 2007 09:42:04 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Andi Kleen" <ak@...e.de>
Cc:	"Indan Zupancic" <indan@....nu>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Stephen Hemminger" <shemminger@...ux-foundation.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, bwalle@...e.de
Subject: Re: blink driver power saving

On 7/2/07, Andi Kleen <ak@...e.de> wrote:
>
> > > Perhaps one of you geniuses who all hate it can find a better way to
> > > solve the "video output dead after kexec; but need visual feedback to the user
> > > while crash dumping" problem. I'm waiting for your patches.
> > >
> >
> > I don't don't like it ;) Unfortunately too many people end up enabling
>
> Yes that's pretty weird. I admit I hadn't expected
> that problem. blink is equivalent to "annoy me" and it
> is a mystery why so many people should willingly ask their computer to
> annoy them.
>
> Or perhaps they update their configs with yes | make oldconfig?
>
> User psychology can be mysterious.
>
> I wonder if the kernel offered a CONFIG_FORMAT_FILESYSTEMS_AT_BOOT
> how many people would enable that @) Might be an interesting experiment
> for next April.
>

Heh ;) That could be interesting.

> > it and having issues with their keyboards.
>
> Forcing a suitable slow rate should fix that shouldn't it? We need
> that anyways to stop the "setleds DOS".
>

I already have a patch that throttles AT keyboard when switching LED
state. However there is another problem - i8042's interrupt hanler is
racing with panic_blink polling the keyboar controller and they both
don;t quite like that.

> > Can we have it depend on
> > DEBUG_KERNEL?
>
> Yes that would be probably a good idea; even though it is technically
> not correct: the debug kernel doesn't try to debug itself. But anyways,
> it's probably the best place.
>
> > And probably KEXEC as well?
>
> The kcrash kernel doesn't necessarily need to have kexec enabled by
> itself.
>

OK.

> > Another option would be for it not use panic_blink. Do your kexec
> > kernels have atkbd support enabled? You could write an new "blink"
> > input handler that would latch to keyboards supporting leds and blink
> > by sending EV_LED events.
>
> Yes that would be probably a better implementation. Also hook something
> for USB keyboards. iirc Bernhard Walle (cc'ed) was looking at that.
>

I was thinking about something like the atached (untested and sorry
for using attachment). It shoudl blink just one led (numLock) on any
keyboard that has such LED (and allows to control it).

-- 
Dmitry

View attachment "blink.c" of type "text/plain" (2852 bytes)