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: <20070702105000.73e50500@freepuppy.localdomain.hemminger.net>
Date:	Mon, 2 Jul 2007 10:50:00 -0700
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	Andi Kleen <ak@...e.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: blink driver power saving

On Mon, 2 Jul 2007 01:59:50 +0200
Andi Kleen <ak@...e.de> wrote:

> On Monday 02 July 2007 00:14, Linus Torvalds wrote:
> > On Sun, 1 Jul 2007, Andi Kleen wrote:
> > > What is so bad with it? Note it's a debugging facility and used
> > > for kcrash kernels where the video output doesn't work. But they
> > > normally only run a few minutes to dump the previous state to disk
> > > and then reboot.
> >
> > It has been a total disaster from beginning to end.
> >
> > It wastes power.
> 
> Again:
> It's not intended for normal kernels. It's a debugging feature.
> It's not intended for normal kernels. It's a debugging feature.
> It's not intended for normal kernels. It's a debugging feature.

It can be generally useful. Until/unless we get proper screen support,
how do you know hang from panic? If you can talk to some other
device it would help.

> Got it now? Power wasting or not just doesn't matter for it.
>  
> > It hangs machines when it tries to blink.
> 
> Yes, there seem to be more buggy keyboard controllers
> around than I anticipated. Very sad that IBM couldn't even
> get such a simple thing right.
> 
> Well only those that could be already hung from user space
> with setleds (that was also confirmed).  Actually I thought
> they didn't hang completely, but just stopped reacting to 
> the keyboard (which is actually pretty bad for every user
> to be able to trigger)
> 
> I guess the better way to handle those would be to find out the 
> minimum frequency of blinking that is still ok and rate limit it to that in 
> the keyboard driver. 
> 
> Anyways, Stephen's patch just doesn't make sense: 
> he clearly didn't understand the code at all. Before you
> apply it and cripple it better drop the driver completely.

The patch makes sense. You don't need to poll every jiffie to find
out if system has panic.  But I agree with Linus, it is the kind
of patch that doesn't belong in the mainline kernel.  Every developer
seems to have built up a set of crappy/fragile debug tools, but these
don't belong in the wild.



-- 
Stephen Hemminger <shemminger@...ux-foundation.org>
-
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/