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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.44L0.0703131155050.2509-100000@iolanthe.rowland.org>
Date:	Tue, 13 Mar 2007 12:01:41 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jiri Slaby <jirislaby@...il.com>
cc:	Jiri Kosina <jikos@...os.cz>, <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

On Mon, 12 Mar 2007, Jiri Slaby wrote:

> Alan, sorry for the previous bad post, I mismatched 2 files. This is 
> hopefully correct.
> 
> > thanks. Could you also please redo the test with the offending uhci patch 
> > reverted and send the output of a working situation?
> 
> - BAD kernel:
> 
> USBMON output:
> d28dba40 1882513063 C Ii:008:01 0 8 = 00005300 00000000
> d28dba40 1882513090 S Ii:008:01 -115 8 <
> f7b31340 1882515363 S Co:008:00 s 21 09 0200 0000 0001 1 = 00
> f7b31340 1882517065 C Co:008:00 0 1 >

> *******************************************************************
> - GOOD kernel (reverted):
> 
> USBMON output:
> f7b31ec0 2545055172 C Ii:004:01 0 8 = 00005300 00000000
> f7b31ec0 2545055198 S Ii:004:01 -115 8 <
> f588aec0 2545055215 S Co:004:00 s 21 09 0200 0000 0001 1 = 01
> f588aec0 2545057168 C Co:004:00 0 1 >
> f7b31ec0 2545135153 C Ii:004:01 0 8 = 00000000 00000000
> f7b31ec0 2545135166 S Ii:004:01 -115 8 <

I don't see anything in the UHCI snapshots to explain the difference in 
behavior.  One thing that stands out is the other, low-speed device (a 
mouse?) -- in the bad kernel dump its driver was running and in the good 
kernel dump its driver wasn't.

But that shouldn't have affected the result.  In fact, nothing in your
data was significant.  It could be that the problem occurs earlier, at the
time when the keyboard is first plugged in.

Can you get another pair of usbmon logs, starting from before you plug in
the keyboard?  Don't bother with the UHCI snapshots for now.

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/