Re: Lenovo 3000 N100 i8042 problems

From: Dmitry Torokhov
Date: Wed Sep 03 2008 - 15:06:51 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/