On Fri, Jun 20, 2003 at 08:22:16PM -0700, Linus Torvalds wrote: > > On Fri, 20 Jun 2003, Linus Torvalds wrote: > > > > Are you sure that your devices don't just handle READ_6 and SENSE_6 ok? > > I'm pretty sure your devices just handle it.
I'm dead certain they don't. My logs (USB Mass Storage Verbose Debugging)
only show MODE_SENSE_10 and READ_10 being issued.
> Because adding some debugging code seems to clearly show that when you
> moved the setting of "use_10_for_XX" to the scanning phase, you moved it
> to _after_ it tries to actually identify the drive. And since it uses mode
> sense and "read" to identify the drive status, those commands now won't
> work, and the result is crap.
I moved the code to scsi_add_lun, which is called from
scsi_probe_and_add_lun (where the sdev is actually allocated).
> I see:
>
> hub 1-0:0: new USB device on port 4, assigned address 3
> usb-storage: USB Mass Storage device detected
> scsi1 : SCSI emulation for USB Mass Storage devices
> Vendor: SanDisk Model: SDCFB-256 Rev: 0811
> Type: Direct-Access ANSI SCSI revision: 02
These lines (above) are printed from scsi_add_lun(). Below comes from sd.c
-- how did we make that jump without completing scsi_add_lun, where the
slave_configure() function should be called?
> SCSI device sda: 501760 512-byte hdwr sectors (257 MB)
> use_10_for_ms clear? Fix it! /* force mode sense 10 */
> sda: Write Protect is off
> sda: Mode Sense: 06 00 00 00
> SCSI device sda: drive cache: write through
> sda:use_10_for_rw clear?? Fix it! /* force read 10 */
> sda1
> Setting use_10 to 1 0 !
> Setting use_10 to 1 1 !!
> Ie note how the "setting use_10" messages (which are from scsi_scan) come
> after we have already tried to use the flags.
Clearly, something is wrong. After all, right before my code tries to set
use_10 to 1, the scsi scanning code goes processing BLIST_ entries -- if
slave_configure isn't getting called until later, then sd.c is starting to
process the device without having the device properly setup.
I'm not clear on where the probing code for sd.c gets called from.
However, my top suspect is the call to scsi_device_register() in
scsi_add_lun(), which takes place _well_ before the sdev is properly
configured. At first, I thought that just creates some devfs entries, but
if that is what triggers the probing to sd.c, then that would explain all
of this behavior.
Is that the case? I just don't know. As I said before, the USB tree works
just fine on my (old and slow) test machine. I'm building and testing the
Linus tree right now. My guess is that it will show the same behavior on
the same machine. So, if my theory sounds correct to you, can you try
moving the call to scsi_device_register() to the end of scsi_add_lun()?
> Why don't we just initialize both to 1 when we create the device? We
> should not wait until scanning.
When the code goes to scan a LUN, it creates a struct scsi_device and uses
that for probing. Once the code believes there is a device thee, it then
'adds' that device (setting BLIST_ entries and calling slave_configure() ).
So we don't want to do too much until _after_ we know there is a real
device there.
Also, I was trying to keep the same behavior for 'legacy' devices.
Matt
--
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
pgp00000.pgp
Description: PGP signature
