linux-kernel - Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0703121100460.2489-100000@iolanthe.rowland.org>
Date:	Mon, 12 Mar 2007 11:09:03 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jiri Slaby <jirislaby@...il.com>
cc:	Jiri Kosina <jikos@...os.cz>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>, Richard Purdie <rpurdie@...ys.net>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

On Mon, 12 Mar 2007, Jiri Slaby wrote:

> Bisecting figured out the culprit:
> Commit: 17230acdc71137622ca7dfd789b3944c75d39404
> Author: Alan Stern <stern@...land.harvard.edu> Mon, 19 Feb 2007 15:52:45 -0500
> 
>      UHCI: Eliminate asynchronous skeleton Queue Headers
> 
>      This patch (as856) attempts to improve the performance of uhci-hcd by
>      removing the asynchronous skeleton Queue Headers.  They don't contain
>      any useful information but the controller has to read through them at
>      least once every millisecond, incurring a non-zero DMA overhead.
> 
>      Now all the asynchronous queues are combined, along with the period-1
>      interrupt queue, into a single list with a single skeleton QH.  The
>      start of the low-speed control, full-speed control, and bulk sublists
>      is determined by linear search.  Since there should rarely be more
>      than a couple of QHs in the list, the searches should incur a much
>      smaller total load than keeping the skeleton QHs.
> 
>      Signed-off-by: Alan Stern <stern@...land.harvard.edu>
>      Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
> 
> 
> -mm minus (only) this one is OK.

Okay, here's how to track this down.  I assume that even after the
keyboard stops working you can access the machine via a network
connection.

So turn on CONFIG_USB_DEBUG, CONFIG_USB_MON, and CONFIG_DEBUG_FS.  Then
modprobe uhci-hcd with debug=2, and mount a debugfs filesystem.  Before
using the keyboard, start a cat process to capture the usbmon output for
the keyboard's bus (see the instructions for usbmon in
Documentation/usb/usbmon.txt).

After hanging the keyboard, get a copy of the appropriate controller's 
file in the uhci/ subdirectory of the debugfs filesystem.  Post it along 
with the usbmon log, and I'll try to figure out what happened.

Alan Stern

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