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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ