From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756059AbYICTGu (ORCPT ); Wed, 3 Sep 2008 15:06:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752543AbYICTGl (ORCPT ); Wed, 3 Sep 2008 15:06:41 -0400 Received: from py-out-1112.google.com ([64.233.166.178]:33102 "EHLO py-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752499AbYICTGk (ORCPT ); Wed, 3 Sep 2008 15:06:40 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=qJSXYDTxcil0j6bxvjAG9vx/kyWWO4jIl7pOjFvhRypfv5GzBIqJzMCjXmiBGRm+OI cz8KHxPCpDPwlfKbnflhEljbyQRickMgWFUJ/kXxCSL9tT2A2BVXJ2o12GSCWTf0MyRt G3JZrlgS8fF9oLAgYLJmOjQPdY2JYHWVz/Mhw= Date: Wed, 3 Sep 2008 15:06:33 -0400 From: Dmitry Torokhov To: Daniel Barkalow Cc: Jiri Kosina , linux-kernel@vger.kernel.org, Christopher Desjardins Subject: Re: Lenovo 3000 N100 i8042 problems Message-ID: <20080903150241.ZZRA012@mailhub.coreip.homeip.net> References: <20080902083940.ZZRA012@mailhub.coreip.homeip.net> <20080903102047.ZZRA012@mailhub.coreip.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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