On Tue, 7 Dec 2004, David Brownell wrote:
> I think it might be a good idea to try out a cleaned-up
> version of this patch more widely.
Here's a cleaned-up patch that does what you wanted, plus a little more.
Its main feature is that the patch does a USB port reset whenever there's
a transpor
On Monday 13 December 2004 7:51 am, Alan Stern wrote:
> > I did notice two odd things with this patch though:
> >
> > - It deadlocked if I tried the "lock_for_reset" stuff,
> >so I commented that out.
>
> Yes, I see. You wrote:
>
> ...
> +// lock_device_for_reset() seems to deadlock things
On Tue, 7 Dec 2004, David Brownell wrote:
> > On Saturday 04 December 2004 11:51 am, Alan Stern wrote:
>
> > > In fact, I suggested skipping the class-specific reset entirely and
> > > proceeding directly to the port reset, because that's what Windows does.
>
> That worked for me, as in the att
> On Saturday 04 December 2004 11:51 am, Alan Stern wrote:
> > In fact, I suggested skipping the class-specific reset entirely and
> > proceeding directly to the port reset, because that's what Windows does.
That worked for me, as in the attached patch. It turned
out that the class-specific res
On Sat, 4 Dec 2004, David Brownell wrote:
> > Concerning the lack of resets... I don't fully understand the philosophy
> > used by the SCSI layer in its approach to error correction.
>
> Me either. I suspect part of it avoiding a "bus" reset in
> expectation that for "real SCSI" there will be
On Saturday 04 December 2004 11:51 am, Alan Stern wrote:
>
> Last question first... I don't know exactly what is going on between ext3
> and SCSI. And remember that the block layer sits in the middle, to
> confuse things even further. I suspect that the "device gone" information
> doesn't ge
