Messages in this thread | | | Date | Fri, 19 Mar 2004 14:58:19 +0100 | From | Vojtech Pavlik <> | Subject | Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode |
| |
On Fri, Mar 19, 2004 at 12:05:36AM -0500, Dmitry Torokhov wrote:
> > Could this be the bit that indicates whether the report is coming from > > an internal or external device? > > That is what I suspect, but I can not prove it and in fact I am quite > surprised that KBC would mangle data requested via CMD_AUX_LOOP. So far > I have seen the following sequences (* denotes 4th bit flipped): > > 2.6.1: > IN: FO > OUT: F8* > > 2.6.2-rc1-bk1: > IN: 5A F0 56 A4 > OUT: 5A F0 56 AC* > > 2.6.3 + my debug > IN: 5A A4 5B A4 53 F0 56 > OUT: 5A A4 5B AC* AC F0 5E* > > 2.6.3 + my other debug > IN: 5A A4 A4 A4 A4 F0 56 A4 A4 A4 A4 > OUT: 5A A4 A4 A4 A4 F0 56 A4 A4 A4 A4 > > ... and I am waiting on sequence: > 5A 00 00 00 00 F0 56 A4 00 00 00 00 > > As you can see it does not always flip that bit, but if it will mangle the > last sequence I think we can claim that we see "hidden multiplexor" and > abort active multiplexor test.
So far on every machine I've got a report from it was caused by BIOS emulation of PS/2 mouse using an USB mouse (even when USB mouse wasn't present). Compiling the USB modules into the kernel fixes the problem.
-- Vojtech Pavlik SuSE Labs, SuSE CR - 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/
| |