Messages in this thread |  | | Date | Wed, 3 Sep 2008 15:06:33 -0400 | | From | Dmitry Torokhov <> | | Subject | Re: Lenovo 3000 N100 i8042 problems |
| |
On Wed, Sep 03, 2008 at 01:16:59PM -0400, Daniel Barkalow wrote: > On Wed, 3 Sep 2008, Dmitry Torokhov wrote: > > > On Tue, Sep 02, 2008 at 12:16:15PM -0400, Daniel Barkalow wrote: > > > 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 > > > > It usually manifests with a touchpad/mouse missing because they don't > > responf to kernel's queries. Quite a few Fujitsus exibit this > > behavior. > > Right from the beginning?
Yes.
> I'm not seeing that on any kernel with this > hardware.
I understand. Jiri, how did active MUX problem manifest on Cristopher's box?
> I don't suppose the kernel could detect that it's using active > mux and one of the devices isn't responding, and use legacy mode in that > case, and only use quirks for systems where the active mux does something > particularly weird?
Well, we need a device to respond to our queries to figure out if it is present or not ;) The box may not have any devices attached but still have perfectly working active MUX implementation.
> > > > 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. > > > > > > > I am not sure, internally we the kernel still deals with 2 interrupt > > sources (KBD and AUX) regardless whether it is in legacy or active > > multiplexing mode... > > > > Does it take long to trigger the bug? You coudl try doing "echo 1 > > > /sys/modules/i8042/parameters/debug" and thend me dmesg or > > /var/log/messages after the bug was triggered - I might see something > > there. But please be aware that if you send me such a log I can decode > > everything that you have been typing... > > It's usually within an hour of the right usage pattern. I'll try to > trigger it with debugging on while not typing anything secret Thursday > evening. >
Coo, thanks.
> The other thing that might be useful, if there's some way to find out, is > whether the kernel lost an interrupt somehow, since this feels like the > hardware is waiting patiently for a lost interrupt to get serviced. Also, > is there some way to get the kernel to re-initialize the i8042? It might > be useful to see if the firmware has really stopped working or if the > kernel is just failing to do anything further with it. I can unbind the > driver, but I don't seem to be able to bind it again.
This is as close as it gets. Biding should cause the controller to be flushed of any pending data and start afresh.
-- Dmitry
|  |