It's a buggy device.  And, I might add, perhaps the most creative bug I've
ever seen in a device like this.

2.5.x should work for this device, as the probing sequence was changed.

Matt

On Mon, Jun 09, 2003 at 03:05:08PM +0900, asterr wrote:
> Is there a bug in the USB code for 2.4.18-14 for SCSI/BULK?  
> 
> I have written to the list a couple of times before, but was slightly off in 
> what the issue was.  I have a TOSHIBA/DVD-ROM SD-R5002, packaged by Melco.
> The DVD-ROM is attached to a Melco Inc. USB2-IDE Bridge.
> 
> When scan_scsis_single from drivers/scsi/scsi_scan.c does the inquiry, the 
> first byte in the request_buffer is 0x13, which is an unknown device.  The rest
> of the request_buffer is also corrupted.  But, when dvdrecord scans with 
> libscg, the scsi inquiries show the proper results with a device of 0x05
> and the proper Vendor/Product strings.  
> 
> The differences between scsi_mod and scg behavior seem to be:
> 1) scg does a test unit ready before the inquiry, but scsi_mod does not
> 2) scg requests 36 bytes and then 96 bytes, but scsi_mod requests 255 bytes
> 
> I hacked scsi_scan.c so that the inquiry only requests 254 bytes, and now
> the scsi inquiry from scsi_mod also returns the correct results.  Is there
> a bug in my device?  or is there a bug in the usb-storage code?  What is the
> best way to fix/patch this?
> 
> I am happy to do testing and send logs/configuration/etc. as needed.
> 
> Thank you,
> Aaron Sterr

-- 
Matthew Dharm                              Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

G:   Baaap booop BAHHHP.
Mir: 9600 Baud?
Mik: No, no!  9600 goes baap booop, not booop bahhhp!
                                        -- Greg, Miranda and Mike
User Friendly, 12/31/1998

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to