linux-kernel - Re: [linux-usb-devel] USB deadlock after resume

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: <d9def9db0711210914m47885980gffd789d30a817b88@mail.gmail.com>
Date:	Wed, 21 Nov 2007 18:14:01 +0100
From:	"Markus Rechberger" <mrechberger@...il.com>
To:	"Alan Stern" <stern@...land.harvard.edu>
Cc:	"Oliver Neukum" <oliver@...kum.org>,
	"Laurent Pinchart" <laurentp@...-semaphore.com>,
	"Mark Lord" <lkml@....ca>, linux-kernel@...r.kernel.org,
	linux-usb-devel@...ts.sourceforge.net
Subject: Re: [linux-usb-devel] USB deadlock after resume

On 11/21/07, Alan Stern <stern@...land.harvard.edu> wrote:
> On Wed, 21 Nov 2007, Markus Rechberger wrote:
>
> > > > it's not just usb_set_interface that hangs actually.
> > > > It seems to hang at
> > > >
> > > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
> > > >
> > > > in drivers/usb/core/urb.c after resuming. I disabled access to the usb
> > > > subsystem in the uvc driver, although connecting any other usb storage
> > > > fails too, just at the same point.
> > >
> > > Which URB is usb_kill_urb() called for?
> > >
> >
> > it's the usb_control_message which calls usb_kill_urb if I haven't got
> > it wrong. (if you're looking for some other information please let me
> > know)
> > Although, I got a bit further with it. The error seems to happen
> > earlier already.
> > If I load the driver, and do not access the device after suspending
> > all usb_control commands fail with -71 eproto.
>
> That's very strange.  Getting -71 errors is understandable; it
> indicates that the device can't handle being suspended.  But the
> wait_event() line still shouldn't hang.  If it does, it indicates that
> there's something wrong with the USB host controller, not just the
> device.
>
> Can you try testing this on a different sort of computer?
>

Not really, suspending doesn't work at all on my other notebook it
just freezes..
I'm basically trying to get that driver work on my eee PC [1], it's
cheap and tiny so I don't expect anything special in there..
The system is preloaded with Xandros (it's debian etch with a few
custom applications) and linux 2.6.21.4.

The system still locks up, although only if I leave the video
application running during suspending. I don't have to reload the
driver anymore after resuming if the video node doesn't get accessed
(I'm looking for races in the uvc driver at the moment).

thanks,
Markus

[1] http://eeepc.asus.com
-
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/