linux-kernel - Re: Regression?: keyboard state/LED inconsistency in 2.6.32-rc1/2,3,4

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] [day] [month] [year] [list]

Message-ID: <20091013051903.GE2887@core.coreip.homeip.net>
Date:	Mon, 12 Oct 2009 22:19:03 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Marin Mitov <mitov@...p.bas.bg>
Cc:	Vojtech Pavlik <vojtech@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: Regression?: keyboard state/LED inconsistency in
	2.6.32-rc1/2,3,4

On Mon, Oct 12, 2009 at 10:17:38PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 13, 2009 at 07:55:43AM +0300, Marin Mitov wrote:
> > On Tuesday 13 October 2009 06:03:14 am Dmitry Torokhov wrote:
> > > On Mon, Oct 12, 2009 at 01:57:08AM -0700, Dmitry Torokhov wrote:
> > > > On Mon, Oct 12, 2009 at 10:30:15AM +0200, Vojtech Pavlik wrote:
> > > > > On Mon, Oct 12, 2009 at 11:18:28AM +0300, Marin Mitov wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > I'm testing 2.6.32-rc1/2,3,4 and I'm using 2.6.31.3.
> > > > > > There is a difference in keyboard/LED behavior.
> > > > > > If in BIOS NumLock is set on, when the kernel starts
> > > > > > it puts NumLock off and the LED state is off in 2.6.31.3
> > > > > > (which is consistent), but in 2.6.32-rc1/2,3,4 the LED
> > > > > > stays on (and this is not consistent with keyboard's state).
> > > > > > 
> > > > > > Comparing drivers/input/keyboard/atkbd.c (I'm using it)
> > > > > > in 2.6.31.3 and 2.6.32-rc1/2,3,4 among others changes I
> > > > > > found the following lines (see the patch bellow) deleted,
> > > > > > so I propose either to add them again (this will restore 
> > > > > > keyboard/LED consistency) or revert the patch that has 
> > > > > > deleted them.
> > > > > 
> > > > > Oh, wow, those lines are quite clearly needed, I wonder why they got
> > > > > deleted, and I'm too lazy to find the commit comment ...
> > > > > 
> > > > 
> > > > Hmm, it appears I deleted a bit too much.. At some point I was thinking
> > > > the input core would reset LEDs and repeat rate on newly created device
> > > > but it was wrong idea. Unfortunately I was careless in applying atkbd
> > > > patch removing resume support (which should be handled by the input
> > > > core)...
> > > > 
> > > 
> > > Could you please try the patch below and let me know if it fixes
> > > things?
> > > 
> > > Thanks!
> > > 
> > 
> > Yes, Dmitry, it fixes the problem, thank you.
> > 
> 
> Thank you for testing. Mouse re-initialization is pretty delicate topic,
> may I ask you to test some more just to make sure fix is reliable - a
> few more resumes and cold/warm boots would do...
> 

Oh, wait, scratch that... I mixed up the issues ;) Sorry about the
confusion.

-- 
Dmitry
--
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/