On Sat, 10 Jul 2004, David Brownell wrote:
> The issue was whether providing one "global" mutex could do the
> whole job, I thought.
>
> Consider: one userspace program would be able to issue a read
> (or write) on an endpoint that's NAKing. That can take weeks to
> complete. It would then mak
On Sun, 11 Jul 2004, Gerd v. Egidy wrote:
> Ok, here we go with full logging:
>
> [...]
> Jul 11 00:11:38 fire kernel: usb-storage: *** thread awakened.
> Jul 11 00:11:38 fire kernel: usb-storage: Command READ_10 (10 bytes)
> Jul 11 00:11:38 fire kernel: usb-storage: 28 00 00 00 4d 97 00 00 40 0
On Sat, 10 Jul 2004, David Brownell wrote:
> That's part of the point. It doesn't fix those problems which
> will show up most easily with suspend/resume of a device tree.
> We've been over that one before, not long after I first posted
> locktree() code and early CONFIG_USB_SUSPEND patches.
Yes
> > You could try increasing the length of the delay that the patch adds to
> > transport.c. Make it 200us instead of 100us and see what happens.
>
> Ok, at first glance it looks like it's working with delay >= 350us
> (I tried 200, 600, 400, 300, 350).
> I can mount and have transferred some gigs
Am Sonntag, 11. Juli 2004 05:08 schrieb David Brownell:
> Oliver Neukum wrote:
>
> > That tells us the there is a multitude of operations that need locking.
> > Not that these operations are common. Maybe except usbfs. Wouldn't
> > usbfs be happy with down_read()?
>
> The issue was whether provid
