On Wed, Sep 03, 2008 at 01:16:59PM -0400, Daniel Barkalow wrote:
quoted text
> 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.

quoted text
> I'm not seeing that on any kernel with this 
> hardware.

I understand. Jiri, how did active MUX problem manifest on
Cristopher's box?

quoted text
> 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.

quoted text
> 
> > > 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.

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