On Tue, 30 Jan 2007, Vaclav Barta wrote:
> > work. The patch causes the SCSI core to send an INQUIRY command to each
> > LUN before registering any of them, which is more or less what Windows
> > does. (You might have to apply the patch by hand, like the other one, but
> > it shouldn't be too bad.)
> Actually it did apply OK (with some warnings about mismatched line numbers),
> and it does make some difference, but not quite the desirable
> one... /var/log/messages on stick insertion:
> Jan 30 18:12:28 quanxi kernel: usb 1-1: new high speed USB device using
> ehci_hcd and address 2
> Jan 30 18:12:28 quanxi kernel: usb 1-1: Product: Nu Drive
> Jan 30 18:12:28 quanxi kernel: usb 1-1: Manufacturer:
> Jan 30 18:12:28 quanxi kernel: usb 1-1: SerialNumber: 075A141402A5
> Jan 30 18:12:28 quanxi kernel: usb 1-1: configuration #1 chosen from 1 choice
> Jan 30 18:12:28 quanxi kernel: scsi0 : SCSI emulation for USB Mass Storage
> devices
> Jan 30 18:12:33 quanxi kernel: Vendor: Model: Nu Drive
> Rev: PMAP
> Jan 30 18:12:33 quanxi kernel: Type: Direct-Access
> ANSI SCSI revision: 00
> Jan 30 18:12:33 quanxi kernel: Vendor: Model: Nu Drive
> Rev: PMAP
> Jan 30 18:12:33 quanxi kernel: Type: Direct-Access
> ANSI SCSI revision: 00
That's good; it found both LUNs before trying to access either one.
> Jan 30 18:12:34 quanxi kernel: SCSI device sda: 2048 512-byte hdwr sectors (1
> MB)
> Jan 30 18:12:34 quanxi kernel: sda: Write Protect is off
> Jan 30 18:12:34 quanxi kernel: SCSI device sda: 2048 512-byte hdwr sectors (1
> MB)
> Jan 30 18:12:34 quanxi kernel: sda: Write Protect is off
> Jan 30 18:12:34 quanxi kernel: sda:<7>usb-storage: queuecommand called
> Jan 30 18:12:34 quanxi kernel: sd 0:0:0:0: SCSI error: return code =
> 0x08000002
> Jan 30 18:12:34 quanxi kernel: sda: Current: sense key=0x3
> Jan 30 18:12:34 quanxi kernel: ASC=0x11 ASCQ=0x0
> Jan 30 18:12:34 quanxi kernel: end_request: I/O error, dev sda, sector 0
> Jan 30 18:12:34 quanxi kernel: sd 0:0:0:0: SCSI error: return code =
> 0x08000002
But that's bad. Apparently the device needs more than an INQUIRY on LUN 1
before it will allow LUN 0 to be read.
> I notice that write protect on sda is off, but I can't mount sda1:
> # mount -t vfat /dev/sda1 /mnt/stick
> mount: special device /dev/sda1 does not exist
>
> sdb1 can be mounted, read-only. Do you want the usbmon log?
No; this is effectively the same as what you were getting originally.
Well, there's one more approach I can think of. Go back to the regular
kernel, and make sure to build sd_mod as a module. Rename or move
sd_mod.ko so that it can't be loaded automatically.
After plugging in the stick, run plscsi with the two TEST UNIT READY
commands:
plscsi -x '0 0 0 0 0 0' /dev/sg0
plscsi -x '0 0 0 0 0 0' /dev/sg1
You might want to run each command twice, because each one will probably
get an error the first time. Then insmod the renamed sd_mod.ko driver.
Perhaps then it will work.
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
