Re: SCSI trow USB-STORAGE or SBP2 Debug for buggy device Kernels 2.6.X

["Gustavo Guillermo Pérez" <gustavo@compunauta.com>]

El Martes, 25 de Abril de 2006 01:09, escribió:
> Gustavo Guillermo Pérez wrote:
> > El Lunes, 24 de Abril de 2006 17:02, James Bottomley escribió:
> >>So, I could change the long write in progress to a retry.  However, I
> >>suspect the reason we got that return is because this device is untagged
> >>(doesn't accept multiple commands at once) and perhaps a better fix
> >>might be to reduce the queue depth down to one to prevent more than one
> >>command being outstanding at any one time.
> >
> > It would not be better to include some handling on the black list? it
> > means doing a new BLACK_CONST to handle just this special case?.
>
> For now you can and should test a queue depth of one via sbp2:
> # modprobe sbp2 serialize_io=1
>
> But isn't usb-storage's queue depth already 1?
Yes, I was tested it cause driver said something about this option, then I was 
checked the option 1 or 0, same result.
> Dou you use all the different Pioneer drives with the same
> IDE/USB+FireWire bridge or do you have different bridges?
Yes I have 3 diferent bridges, with 5 diferent DVDRW from pioneer other Drives 
I've tested with this same USB-IDE Bridges works without this problem.
I've tried the flag BLACK_XXX for non tagged queue for this drive but with no 
results.

{"PIONEER", "DVD-RW  DVR-110D", NULL, BLIST_RETRY_HWERROR | BLIST_NOTQ}

:S
-- 
Gustavo Guillermo Pérez
Compunauta uLinux
www.compunauta.com
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html