linux-kernel - Re: Lenovo 3000 N100 i8042 problems

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 2 Sep 2008 12:16:15 -0400 (EDT)
From:	Daniel Barkalow <barkalow@...ervon.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Jiri Kosina <jkosina@...e.cz>, linux-kernel@...r.kernel.org,
	Christopher Desjardins <cddesjardins@...il.com>
Subject: Re: Lenovo 3000 N100 i8042 problems

On Tue, 2 Sep 2008, Dmitry Torokhov wrote:

> On Tue, Sep 02, 2008 at 11:23:25AM +0200, Jiri Kosina wrote:
> > 
> > so the product name both of System and Base Board are different, and 
> > apparently the systems differ. Dmitry, what fields would you propose to be 
> > put in the DMI matching here? I will do the patch then.
> > 
> 
> I guess we could use System's product name to differentiate between
> Cristopher's and Daniel's boards. Although I must admit it is the very
> first time when I see a box that behaves better with active mux. DOes
> Vista use active mux nowadays? Because if it is not then I bet there
> is (or shortly will be) a BIOS update fixing legacy mode on Daniel's
> box.

Mine's actually old (came with XP). It's still got the original BIOS 
(because I haven't found a way to upgrade the BIOS without reformatting my 
hard drive to include Windows), and I remember there being an upgrade 
available, but I don't think it had anything to do with keyboard/trackpad 
stuff.

In what way does active mux usually behave badly? It's possible that 
legacy mode only has a bug that doesn't matter to Windows, and active mux 
may have some of the usual problems but nothing I particularly noticed.

I noticed that, when my i8042 would stop working, it would generally have 
just delivered one mouse interrupt to CPU1 after never previously doing 
so. Perhaps there's some sort of deadlock in the Linux i8042 driver when 
both cores are unexpectedly getting interrupts from the two devices at 
once? I could understand there being a Linux bug only triggered by quirky 
hardware that only applies to legacy mode, which was just uncovered by 
this patch.

	-Daniel
*This .sig left intentionally blank*
--
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/