linux-kernel - Re: broken access to a USB HID device after suspend

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.0803141020190.4478-100000@iolanthe.rowland.org>
Date:	Fri, 14 Mar 2008 10:34:06 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Tino Keitel <tino.keitel@....de>
cc:	Jiri Kosina <jkosina@...e.cz>, <linux-kernel@...r.kernel.org>,
	<linux-usb@...r.kernel.org>
Subject: Re: broken access to a USB HID device after suspend

On Fri, 14 Mar 2008, Tino Keitel wrote:

> On Thu, Mar 13, 2008 at 14:59:48 -0400, Alan Stern wrote:
> 
> [...]
> 
> > > Well, it seems to be "fixed" by a suspend/resume cycle. Do you have
> > > a
> > > hint how I could try to fix it without suspend/resume, to test if
> > > it is
> > > really the LCD's fault?
> >
> > Testing has to come before fixing -- you can't fix the problem if you
> > don't know which component is at fault.  For all we know, the
> > hardware
> > could be fine and the problem could lie in your application.
> 
> I meant a method other than suspend/resume to fix the broken behaviour,
> so that we get an indication where the problem exactly is.

There's the blunt-force method: Buy a new LCD device.  That's not 
entirely a joke; the information you have provided so far indicate a
fairly high probability that your device is broken.  (Although a new 
device might also be broken in exactly the same way...)

> > All I can think of for testing is to use usbmon to record the data
> > transfers when those -110 errors come up.
> 
> Well, I still don't have USB_DEBUG or usbmon enabled, but I just got
> that error again. I pulled the power plug from the LCD and replugged
> it, without success. Then I did a suspend/resume cycle, and it worked.

I was going to suggest that something might be going wrong with the
data toggles.  But if that were the problem then cycling the power on
the device would definitely have fixed it.

When you get these errors, do you exit from the hidmon program and 
restart it?  Do the errors still occur after restarting?

My earlier suggestions remain: Use CONFIG_USB_DEBUG and usbmon.  
However without knowing what requests the device will accept and what 
its responses ought to be, it will be very difficult to debug this
problem.

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/