On Sat, 21 Jun 2003, Matthew Dharm wrote:
>
> 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.
Registering the device is indeed very much what causes all probing to
happen.
When you register the thing, that's the point where the rest of the kernel
sees "Oh, somebody added a new device", and that's also obviously the
point where the rest of the kernel will then go on to say "Oh, if they
added a new device, then we had better try to see what it is".
In short, if the code registers something before it is actually ready to
accept commands, then yes, it's _seriously_ buggy. It had better be ready
to accept commands by the time it is registered.
> 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()?
Yes.
I also have this strong urge make the default "use_10_for_ms" value be 1,
since making the default value 0 doesn't make much sense (we have code to
automatically downgrade, but for that code to trigger, it must have been
upgraded first).
Clearly MS uses the 10-byte versions, since a lot of flash readers don't
even appear to support the 6-byte version. So it's arguably a lot safer to
always start out with the 10-byte version, and this shouldn't be a USB
storage special case.
Linus
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
