Bug in usb-storage or scsi?

Hello,
I was able to access my Music Pen mp3 player using usb-storage driver in 2.4 without any problems. After updating to 2.6 this was not possible anymore. It seems that usb-storage driver in 2.6 detect the device but I was unable to access /dev/sda1. "mount -t vfat /dev/sda1 /mnt" returns this error: "mount: /dev/sda1 is not a valid block device"

Under 2.4.21-ck3, sda1 is corectly registered.

Please see the attached files containing dmesg snippets from 2.4 and 2.6 kerneles as well as 2.6 config. If you need more information I'll be glad to provide it.

The 2.4 kernel that I tested was 2.4.21-ck3
The 2.6 kernel that I tested was 2.6.0-test5-mm1, 2.6.0-test4 and 2.6.0-test1

--
Georgi Chorbadzhiyski
http://georgi.cybcom.net/

hub.c: new USB device 00:1f.2-1, assigned address 2 usb_control/bulk_msg: timeout
scsi1 : SCSI emulation for USB Mass Storage devices
Vendor: DIVA USB Model: Media Reader Rev: 2.13
Type: Direct-Access ANSI SCSI revision: 02
Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 SCSI device sda: 254976 512-byte hdwr sectors (131 MB)
sda: Write Protect is off
sda: sda1
WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 2

hub 1-0:0: debounce: port 1: delay 100ms stable 4 status 0x101 hub 1-0:0: new USB device on port 1, assigned address 2 scsi0 : SCSI emulation for USB Mass Storage devices
Vendor: DIVA USB Model: Media Reader Rev: 2.13
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 254976 512-byte hdwr sectors (131 MB)
sda: Write Protect is off
sda: Mode Sense: 13 00 00 00

hub 1-0:0: debounce: port 1: delay 100ms stable 4 status 0x101
hub 1-0:0: new USB device on port 1, assigned address 2
usb-storage: USB Mass Storage device detected
usb-storage: act_altsetting is 0, id_index is 101
usb-storage: -- associate_dev
usb-storage: Transport: Bulk
usb-storage: Protocol: Transparent SCSI
usb-storage: Endpoints: In: 0xca3c7cc0 Out: 0xca3c7cd4 Int: 0x00000000 (Period 0)
usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value=0000 index=00 len=1
usb-storage: GetMaxLUN command result is -32, data is 0
usb-storage: *** thread sleeping.
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command INQUIRY (6 bytes)
usb-storage: 12 00 00 00 24 00
usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes
usb-storage: Status code 0; transferred 36/36
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x1 R 0 Stat 0x0
usb-storage: Fixing INQUIRY data to show SCSI rev 2 - was 0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
Vendor: DIVA USB Model: Media Reader Rev: 2.13
Type: Direct-Access ANSI SCSI revision: 02

usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command TEST_UNIT_READY (6 bytes)
usb-storage:  00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x2 L 0 F 0 Trg 0 LUN 0 CL 6
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x2 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command READ_CAPACITY (10 bytes)
usb-storage:  25 00 00 00 00 00 00 00 00 00
usb-storage: Bulk Command S 0x43425355 T 0x3 L 8 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 8 bytes
usb-storage: Status code 0; transferred 8/8
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x3 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
SCSI device sda: 254976 512-byte hdwr sectors (131 MB)
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE_10 (10 bytes)
usb-storage:  5a 00 3f 00 00 00 00 00 08 00
usb-storage: Bulk Command S 0x43425355 T 0x4 L 8 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 8 bytes
usb-storage: Status code 0; transferred 8/8
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x4 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
sda: Write Protect is off
sda: Mode Sense: 13 00 00 00
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command MODE_SENSE_10 (10 bytes)
usb-storage:  5a 00 08 00 00 00 00 00 08 00
usb-storage: Bulk Command S 0x43425355 T 0x5 L 8 F 128 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_buf: xfer 8 bytes
usb-storage: Status code -32; transferred 0/8
usb-storage: clearing endpoint halt for pipe 0xc0010280
usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value=0000 index=82 len=0
usb-storage: usb_stor_clear_halt: result = 0
usb-storage: Bulk data transfer result 0x2
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes

CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_X86_PC=y
CONFIG_MPENTIUM4=y
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_PREEMPT=y
CONFIG_X86_TSC=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_ACPI_HT=y
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_BINFMT_ELF=y
CONFIG_PNP=y
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_IDE_TASK_IOCTL=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_PCI_WIP=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_SG=m
CONFIG_SCSI_REPORT_LUNS=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_MD_MULTIPATH=m
CONFIG_BLK_DEV_DM=m
CONFIG_DM_IOCTL_V4=y
CONFIG_I2O=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IPV6_SCTP__=y
CONFIG_VLAN_8021Q=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_NET_PCI=y
CONFIG_E100=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=m
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_DRM=y
CONFIG_DRM_MGA=m
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_UDF_FS=m
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_NTFS_FS=m
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
CONFIG_SMB_FS=y
CONFIG_CIFS=m
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_FB=y
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=y
CONFIG_SND=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_INTEL8X0=m
CONFIG_SOUND_PRIME=y
CONFIG_SOUND_ICH=y
CONFIG_USB=m
CONFIG_USB_DEVICEFS=y
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_HP8200e=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
CONFIG_USB_MDC800=m
CONFIG_USB_SCANNER=m
CONFIG_USB_MICROTEK=m
CONFIG_USB_HPUSBSCSI=m
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_X86_BIOS_REBOOT=y

More problems with that stupid MODE-SENSE cache page! There are so many USB storage devices that have problems with that -- I wonder if it's worth the effort to try to continue supporting it?

Georgi, the problem is with your mp3 player, not usb-storage or SCSI. It's crashing when given a perfectly legal SCSI command. Linux 2.4 doesn't issue the command; that's why it works okay.

If you want a temporary fix for 2.6.0, you can do this: Edit the routine sd_read_cache_type in the file drivers/scsi/sd.c (near line 1100). Get rid of (or #ifdef out) most of the function; just leave the last few lines where it does:

		printk(KERN_ERR "%s: assuming drive cache: write through\n",
		       diskname);
		sdkp->WCE = 0;
		sdkp->RCD = 0;

You might want to change the KERN_ERR to KERN_NOTICE.

However, you might also want to think twice before doing this if you have any other SCSI disks, because making this change will affect all of them.

Alan Stern

Well it probably is tested only with windows, so it's no suprise that device's USB implementation is buggy.

Thanks a lot! That worked fine! Now the device is detected and working.

Ugly patch is attached for reference. I hope some workaround for this kind of buggy devices is developed in the future. Thank again.

Georgi Chorbadzhiyski
http://georgi.cybcom.net/

@@ -1098,6 +1098,7 @@
 static void
 sd_read_cache_type(struct scsi_disk *sdkp, char *diskname,
 		   struct scsi_request *SRpnt, unsigned char *buffer) {
+#if 0
 	int len = 0, res;
 
 	const int dbd = 0;	   /* DBD */

@@ -1150,6 +1151,11 @@
 		sdkp->WCE = 0;
 		sdkp->RCD = 0;
 	}
+#endif
+	printk(KERN_NOTICE "%s: assuming drive cache: write through\n",
+	       diskname);
+	sdkp->WCE = 0;
+	sdkp->RCD = 0;
 }
 
 /**

Is there any feeling about how to handle these ongoing problems with the mode-sense cache page? There doesn't seem to be any general solution that can work with all USB storage devices. Some hang when asked to read the entire page; some hang when asked to read just part of the page; some hang when asked to read just the page header.

What do the SCSI folk have to say about it?

Alan Stern

Anyone?

Yes, much.

Maybe more feeling if you remind/teach me what breaks if we don't fetch page 8 re Cache. First I imagine automounters mount read-only disks rw, and then the write cache gets errors while flushing. I wonder what else breaks. Maybe thruput varies for devices that do or do not bother to claim they have write cache.

Maybe more feeling if you can say how in/accurate page 8 re Cache commonly is. For example, I know of no clear & broadly adopted standard that requires a device to declare write-behind or background defect map updates as a form of write cache.

I understand you to be saying we can settle for an sd solution, we don't mind if the sd heuristic we discover then doesn't apply to pdt x05 dvd/cd.

Device folk ship bugs, aye, same as host folk.

Are not two of these three failures disproportionately common?

Me, I would expect asking anything but what Windows asks would fail most often. Is that not so? Do we know what Windows asks? Do we know if/how Win ME/ 2K/ XP differ here? Have we matched CBWCB and dCBWDataTransferLength in every bit?

Pat LaVarre

In reply to modprobe -r sg, linux-2.6.0-test5 dmesg tells me:

Debug: sleeping function called from invalid context at include/linux/rwsem.h:66
...
bad: scheduling while atomic!

Those lines appear in the log below. The ... ellipses you see were typed by me, sorry I don't have a more complete intact log, nor have I yet repeated this result myself.

To provoke this log overnight I ran a shell script to repeat something like:
pldd of=/dev/sg1 if=/dev/zero bs=1m

The "usb 1-1: sg_complete, unlink --> -19" appeared when or before an ioctl SG_IO hung. The Debug/ Call Trace appeared in response to a modprobe -r sg that hung. I'm confident the cable was not unplugged because rebooting the system made sg work again. I'm confident the drive power was not cycled because reboot provoked only an SK ASC = x 6 29 Reset unit attention, without an SK ASC = x 6 28 GoneReady unit attention.

[usb-storage] folk tell me some linux-scsi folk may appreciate me mentioning this.

Pat LaVarre

...

usb-storage: Command WRITE_10 (10 bytes)
usb-storage:  2a 00 00 ce 26 00 00 02 00 00
usb-storage: Bulk Command S 0x43425355 T 0x439c9 L 1048576 F 0 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 1048576 bytes, 32 entries
usb-storage: Status code 0; transferred 1048576/1048576
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x439c9 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command WRITE_10 (10 bytes)
usb-storage:  2a 00 00 ce 28 00 00 02 00 00
usb-storage: Bulk Command S 0x43425355 T 0x439ca L 1048576 F 0 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 1048576 bytes, 32 entries
usb-storage: Status code 0; transferred 1048576/1048576
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x439ca R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command WRITE_10 (10 bytes)
usb-storage:  2a 00 00 ce 2a 00 00 02 00 00
usb-storage: Bulk Command S 0x43425355 T 0x439cb L 1048576 F 0 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 1048576 bytes, 32 entries
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19
usb 1-1: sg_complete, unlink --> -19

...

Debug: sleeping function called from invalid context at include/linux/rwsem.h:66

Call Trace:
 [<c0121f16>] __might_sleep+0x5f/0x72
 [<c0280ec0>] scsi_device_put+0x3c/0xfe
 [<df9179bc>] sg_remove+0x146/0x1bd [sg]
 [<c024db2f>] class_interface_unregister+0x7c/0xc0
 [<df91a7b3>] exit_sg+0x17/0x56 [sg]
 [<c013b533>] sys_delete_module+0x18e/0x1d1
 [<c0151695>] sys_munmap+0x58/0x77
 [<c010b46d>] sysenter_past_esp+0x52/0x71

bad: scheduling while atomic!

Call Trace:
 [<c012018e>] schedule+0x57a/0x57f
 [<c01251d6>] printk+0x180/0x1cc
 [<c01eca67>] rwsem_down_write_failed+0xa3/0x15c
 [<c010c279>] dump_stack+0x1e/0x22
 [<c0281189>] .text.lock.scsi+0xa7/0xce
 [<df9179bc>] sg_remove+0x146/0x1bd [sg]
 [<c024db2f>] class_interface_unregister+0x7c/0xc0
 [<df91a7b3>] exit_sg+0x17/0x56 [sg]
 [<c013b533>] sys_delete_module+0x18e/0x1d1
 [<c0151695>] sys_munmap+0x58/0x77
 [<c010b46d>] sysenter_past_esp+0x52/0x71

...

By the way, I notice I can quickly repeat the first couple of lines of Call Trace if I interrupt the default 0.25 MiB writes of sg_dd with Ctrl+C:

Where I quote ^C I mean I use Ctrl+C to interrupt sg i/o. I see I provoke such dmsg as:

...

usb-storage: Command WRITE_10 (10 bytes)
usb-storage:  2a 00 00 00 0f 80 00 00 80 00
usb-storage: Bulk Command S 0x43425355 T 0x1dfbf L 262144 F 0 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 262144 bytes, 8 entries
usb-storage: Status code 0; transferred 262144/262144
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x1dfbf R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command WRITE_10 (10 bytes)
usb-storage:  2a 00 00 00 10 00 00 00 80 00
usb-storage: Bulk Command S 0x43425355 T 0x1dfc0 L 262144 F 0 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 262144 bytes, 8 entries
usb-storage: Status code 0; transferred 262144/262144
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x1dfc0 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
Debug: sleeping function called from invalid context at include/linux/rwsem.h:66
Call Trace:
 [<c0121f16>] __might_sleep+0x5f/0x72
 [<c0280ec0>] scsi_device_put+0x3c/0xfe
 [<df9263e3>] sg_cmd_done+0x19e/0x266 [sg]
 [<c0280ba6>] scsi_finish_command+0x78/0xb0
 [<c0280ad2>] scsi_softirq+0xb4/0xd9
 [<c0128c0b>] do_softirq+0xd3/0xd5
 [<c012912f>] ksoftirqd+0xbf/0xf8
 [<c0129070>] ksoftirqd+0x0/0xf8
 [<c0109245>] kernel_thread_helper+0x5/0xb

Another time:

Debug: sleeping function called from invalid context at include/linux/rwsem.h:66

Call Trace:
 [<c0121f16>] __might_sleep+0x5f/0x72
 [<c0280ec0>] scsi_device_put+0x3c/0xfe
 [<df9263e3>] sg_cmd_done+0x19e/0x266 [sg]
 [<c021fa59>] read_chan+0x0/0x98c
 [<c0280ba6>] scsi_finish_command+0x78/0xb0
 [<c0280ad2>] scsi_softirq+0xb4/0xd9
 [<c0128c0b>] do_softirq+0xd3/0xd5
 [<c011b4a0>] smp_apic_timer_interrupt+0xd8/0x140
 [<c010beae>] apic_timer_interrupt+0x1a/0x20

Pat,
Thanks for bringing this up.

A user process is doing IO and the user decides to kill the process while a command is "in flight". After the user hits Ctrl+C, sg_close() is called and the sg driver lets it go through (i.e. doesn't hold the user process in an unkillable wait). Since the sg driver knows a command done notification is coming (callback to sg_cmd_done()) then it keeps all its related instances alive (including the scsi_device instance) and notes this situation by setting its sfp->close flag.

When the callback arrives, the respone is discarded and if this is the last outstanding command on this device then scsi_device_put(sdp->device) is called. scsi_device_put() isn't designed to be called from such a context. However sg (and all other upper level drivers I suspect) have no suitable context to call scsi_device_put() from in this situation.

Holding the sg_close() until the response arrives is an ugly solution. Any better suggestions?

Doug Gilbert

scsi_device_put() calls down_write() so it needs to be called in process context. Probably the best way to do this is by calling schedule_work(). An ickier solution would be to hijack an error handling thread ;-)

"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

The down_write was recently introduced and also hurts my scsi_device refcounting patches badly. I'll submit a patch make scsi_device_{get,put} nonblocking again ASAP.

linux-2.6.0-test7 I like better. As this thread detailed back in mid-September, if I boot to -test4, Ctrl+C does reliably spew dmesg if pressed during:

sg_dd of=/dev/sg0 if=/dev/zero bs=2k

-test7 with much the same .config accepts Ctrl+C without complaint.

Pat LaVarre

Seemingly linux disagrees with itself over how writable profiles are:

# /sbin/blockdev --setro /dev/scd1
# /sbin/blockdev --getro /dev/scd1
1
# dd of=/dev/scd1 if=/dev/zero bs=2K count=1
dd: opening `/dev/scd1': Read-only file system
#

So far so good, but then:

# /sbin/blockdev --setrw /dev/scd1
# /sbin/blockdev --getro /dev/scd1
0
# dd of=/dev/scd1 if=/dev/zero bs=2K count=1
dd: opening `/dev/scd1': Read-only file system
#

That is, no matter if --getro is 0 or 1, still we do not write. The default I see here is 0, but still I cannot write.

Pat LaVarre

Should sd.c and sr.c be calling set_device_ro (after adding a read only block device, or changing back to read/write)?

-- Patrick Mansfield

Here's another "kernel NULL pointer dereference", for we of linux-scsi to fix, again brought to us courtesy the [usb-storage] mailing list ...

Specifically I tried trivially repeating writes in 2.6.0-test5:

date ; sync
date ; dd of=/dev/scd1 if=/dev/zero bs=1M
date ; sync
...

Two days and five hours later, my 77th write completed normally:
dd: writing `/dev/scd1': No space left on device

But five minutes after that, my 78th write and all my following writes completed abnormally:
dd: opening `/dev/scd1': No such device or address

Some hours after that I collected the following tail of a dmesg:

Then I rebooted.

Pat LaVarre

...
lost page write due to I/O error on sr1
SCSI error : <2 0 0 0> return code = 0x10000
end_request: I/O error, dev sr1, sector 54044664 Buffer I/O error on device sr1, logical block 6755583 lost page write due to I/O error on sr1

Unable to handle kernel NULL pointer dereference at virtual address

00000000
printing eip:
c01e818f
*pde = 00000000

Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c01e818f>]    Not tainted
EFLAGS: 00010282

EIP is at get_kobj_path_length+0x19/0x30
eax: 00000000 ebx: 00000000 ecx: ffffffff edx: cb0eaef4
esi: 00000015 edi: 00000000 ebp: c9eb5e88 esp: c9eb5e7c
ds: 007b es: 007b ss: 0068
Process dd (pid: 29851, threadinfo=c9eb4000 task=de3dace0)

Stack: c9eb4000 000000a5 d2c1b900 c9eb5ed0 c01e834f c03f5b60 c17149ac
000000a5 
       d2c1b880 c1714800 c9eb5eb8 cddfb400 d2c1b880 cddfb419 c03ba0a0
c0383d13 
       00000000 c1714988 c17149ac d36778ac c1714800 c9eb5ee8 c01e881d
c037dfa5 
Call Trace:
 [<c01e834f>] kset_hotplug+0x15e/0x2b0
 [<c01e881d>] kobject_del+0x66/0x6d
 [<c02470fc>] device_del+0x72/0x98
 [<c027b92a>] scsi_device_put+0xc9/0xe7
 [<df9088d6>] cdrom_release+0x8c/0x105 [cdrom]
 [<c0164fb6>] blkdev_put+0x1df/0x20b
 [<c015d0c3>] __fput+0x123/0x135
 [<c015b79b>] filp_close+0x57/0x81
 [<c015b846>] sys_close+0x81/0xc7
 [<c010b409>] sysenter_past_esp+0x52/0x71

Code: f2 ae f7 d1 49 8b 52 24 8d 74 31 01 85 d2 75 e7 5b 89 f0 5e 
 <6>usb 1-2: USB disconnect, address 5

In linux-2.6.0-test5, I see sg3_utils-1.05/sg_dd plugs 'n play more than does sgp_dd.

A contributing factor seems to be usb/storage injecting an unsolicited request sense injected as if it were an auto sense, despite bCSWStatus = x00 Passed.

Specifically I tried the following, except where you see ^D in my terminal log I actually pressed Ctrl+D:

$

$ sudo ./sg_dd of=/dev/sg1 bs=2k bpt=512
^D
0+0 records in
0+0 records out
$
$ sudo ./sgp_dd of=/dev/sg1 bs=2k bpt=512
read capacity: Driver_status=0x08 (DRIVER_SENSE,SUGGEST_OK)
Current, Sense key: No Sense
[valid=0] Info fld=0x0, Raw sense data (in hex):
  70 00 00 00 00 00 00 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00
Unable to read capacity on /dev/sg1
Couldn't calculate count, please give one
$

CONFIG_USB_STORAGE_DEBUG=y gives contrasting dmesg traces.

For the unhappy sgp_dd we have 8 = Di < Hi = x40 = 64:

For the happy sg_dd we have Di = Hi = 8:

Pat LaVarre

The reason for the unsolicited REQUEST-SENSE is that usb-storage expects that certain commands will never yield a short transfer, so if they do it must mean something has gone wrong, even if Status = 0. READ-CAPACITY is one of those commands. Since sgp_dd asked for a 64-byte READ-CAPACITY, it gets what it deserves.

Alan Stern

Help, lost me.

I'm thinking usb-storage auto sense should always and only follow bCSWStatus = x01 Failed. I'm thinking unsolicited auto sense should occur only if the layers above request such an abuse - never automagically.

I'm thinking not injecting unsolicited auto sense is a part of the unwritten specification that "everyone knows" helps hosts get along with devices.

No? Where have I gone wrong?

I agree something has gone wrong, indeed I am delighted to see that linux usb-storage detects that something has gone wrong.

Ah, here we educate me.

I should prepare and forward a patch to correct sgp_dd?

We the community now broadly accept this rule? We say apps own the job of keeping the bus "on the thin diagonal" i.e. asking for precisely the expected count of data bytes?

I expect we can do better, but already I stumbled into a patch that works (-: because I needed one :-):

@@ -244,6 +244,9 @@
     io_hdr.mx_sb_len = sizeof(sense_b);
     io_hdr.dxfer_direction = SG_DXFER_FROM_DEV;
     io_hdr.dxfer_len = sizeof(rcBuff);
+#if 1 // PEL
+    io_hdr.dxfer_len = 8;
+#endif
     io_hdr.dxferp = rcBuff;
     io_hdr.cmdp = rcCmdBlk;
     io_hdr.sbp = sense_b;

Pat LaVarre

Experience tells us that this is a flawed algorithm.

Yes.

Matt

Matthew Dharm                              Home: [email protected] 
Maintainer, Linux USB Mass Storage Driver

Somebody call an exorcist!
					-- Dust Puppy
User Friendly, 5/16/1998

I don't mean to be stubborn - but I do not understand.

Are you saying we have experience of devices that work Better if we the host assault them with unsolicited request sense? Personally I have precisely the opposite history of pain: I know of Scsi transports that die if abused with an unsolicited request sense.

I know bInterfaceProtocol = x01 CB pretty much requires unsolicited request sense. I mean to be asking about bInterfaceProtocol = x50 BBB.

Clear now, thanks, will do.

Pat LaVarre

Below appears a patch to make sg3_utils sgp_dd.c as polite as sg_dd.c or sgm_dd.c. I know now, this patch sets Hi = Di in sgp_dd.c precisely as sg_dd.c and sgp_dd.c do.

This fixes my actual problem, but leaves me mystified over why we include in drivers/usb/storage/ any code path that assaults a bInterfaceProtocol = x50 BBB device with unsolicited sense.

Pat LaVarre

diff -ur sg3_utils-1.05/sgp_dd.c sg3_utils/sgp_dd.c
@@ -59,6 +59,7 @@
 /* #define SG_DEBUG */
 
 #define SENSE_BUFF_LEN 32       /* Arbitrary, could be larger */
+#define READ_CAP_REPLY_LEN 8
 #define DEF_TIMEOUT 60000       /* 60,000 millisecs == 60 seconds */
 
 #define SGP_READ10 0x28

@@ -234,7 +235,7 @@
 {
     int res;
     unsigned char rcCmdBlk [10] = {READ_CAPACITY, 0, 0, 0, 0, 0, 0, 0,

0, 0};
- unsigned char rcBuff[64];

+    unsigned char rcBuff[READ_CAP_REPLY_LEN];
     unsigned char sense_b[64];
     struct sg_io_hdr io_hdr;

Retransmitted with less line breaks. That's me wrong thrice now in two days, ouch sorry. This time I kept the [usb-storage] prefix, since that is the Subject of the google archived thread where all the replies have appeared.

Below appears a patch to make sg3_utils sgp_dd.c work precisely as hard to avoid nonzero residue as sg_dd.c and sgm_dd.c already do.

This fixes my actual problem, but leaves me mystified over why we include in drivers/usb/storage/ any code path that assaults a bInterfaceProtocol = x50 BBB device with unsolicited sense.

Pat LaVarre

diff -ur sg3_utils-1.05/sgp_dd.c sg3_utils/sgp_dd.c
@@ -59,6 +59,7 @@
 /* #define SG_DEBUG */
 
 #define SENSE_BUFF_LEN 32       /* Arbitrary, could be larger */
+#define READ_CAP_REPLY_LEN 8
 #define DEF_TIMEOUT 60000       /* 60,000 millisecs == 60 seconds */
 
 #define SGP_READ10 0x28

@@ -234,7 +235,7 @@
 {
     int res;
     unsigned char rcCmdBlk [10] = {READ_CAPACITY, 0, 0, 0, 0, 0, 0, 0, 0, 0};
-    unsigned char rcBuff[64];
+    unsigned char rcBuff[READ_CAP_REPLY_LEN];
     unsigned char sense_b[64];
     struct sg_io_hdr io_hdr;
 

There is a new (beta) version of sg3_utils-1.05.tgz on
http://www.torque.net/sg
that corrects this problem in sgp_dd.

Changelog for sg3_utils-1.05 [20030916]
- sgp_dd: reduce READ CAPACITY response size to 8 bytes
- utils/hxascdmp: add utility for displaying ASCII hex
- sg_readcap: show total size in bytes, MB, GB
- sg_logs: read log pages twice (first get response length), for fragile HBAs
- sg_modes: fix core dump when corrupted response, don't print extra pages
- sg_iovec.tst: added to examples, for testing sg_iovec
- sg_map: increase sg device scanning from 128 to 256

Doug Gilbert

There was at least this thread last April:

http://marc.theaimsgroup.com/?t=104839042700001&r=1&w=2

Matthew had a simple patch so that emulated hosts did not do any (sd.c) mode-sense cache checks, James had a filter commands patch.

There were changes since then in how the MODE SENSE is handled (sd.c only?).

In current 2.6 code, the scsi_host emulated flag does nothing, and can be deleted.

I don't like per-host (or transport) flags or filters that cannot be modified. They make some sense for hosts that process the scsi commands (like a RAID card). If you moved a device from one transport to another, the commands sent to the device should not change: for example, you move an iSCSI attached device onto your local system via SPI.

IMO we ought to go with two new BFLAGS, one to block the MODE SENSE page 8 (for the cache), and one to block the MODE SENSE page 0x3f (to check the write protect).

A per host bflags could be added, and overwritten by per device (devinfo) settings. I'd rather we black list the broken ones but that does not appear to be practical. usb-storage could then set the per-host bflag to include the two new flags.

We still end up sending some non-popular SCSI commands to all SCSI devices.

Such flags would not stop sg from sending those commands, but that is postive as well as negative in that you can override what the kernel is doing via user space (sort of what Pat LaVarre experienced).

Also mentioned in the above thread:

The EVPD code has been removed, and is not an issue.

There is now code to set BLIST_INQUIRY_36 (we can still potentially hang broken devices before it is set, but you should get a warning, and then could modify devinfo on the boot/module command line or via proc devinfo).

-- Patrick Mansfield

Thanks, there I find 44 posts dated since 2003-03 with Subject's like:
"PATCH: exclude certain commands from emulated SCSI hosts".

By the way, Google yields a slightly different set of 44 posts:
http://groups.google.com/groups?threadm=linux.scsi.20030322193705.C17056%40one-eyed-alien.net

In both archives I think I see much sense:

I haven't yet reviewed the rest.

Pat LaVarre

What do people think of just having per-device flags that the host driver could set during the slave_configure() callback? The point of these flags is not to prevent bad commands from being sent to the device -- user-generated commands sent via sg should always be allowed. Rather, the point is to prevent sd.c from generating these commands in the first place. (Apparently the commands don't present a problem for sr.c.)

So for example, usb-storage could set the BFLAG to block MODE-SENSE page 8 for any disk-type device. This isn't a perfect solution; consider an iSCSI-attached device that is actually a usb-storage disk on some server. Nevertheless, this might take care of the majority of the problems we see. (I haven't seen any MODE-SENSE page 0x3f problems, but others have.)

Alan Stern

I'm not in principle opposed to this. That's essentially what Andries did for the mode sense 6 vs 10 problem.

They can't be BLIST flags, they have to be flags in the struct scsi_device, but they're easy to add as long as we get a definitive list of what's necessary.

James

James and Matt:

Please tell us what you think of the two patches below. The first patch introduces 2 bitflags: one causes sd.c to skip the mode-sense request for page 0x08 and the other causes it to skip the request for page(s) 0x3f.

The other patch makes usb-storage set the page-8 flag for disk-type devices. I didn't set the page-3f flag because I haven't noticed that causing much problems. If Matt wants to add it that will be easy to do; if we end up not needing it then it will be easy to remove it from the first patch.

Alan Stern

PATCH: (as95)
===== include/scsi/scsi_device.h 1.5 vs edited =====

@@ -85,6 +85,8 @@
 				     * because we did a bus reset. */
 	unsigned use_10_for_rw:1; /* first try 10-byte read / write */
 	unsigned use_10_for_ms:1; /* first try 10-byte mode sense/select */
+	unsigned skip_ms_page_8:1;	/* do not MODE-SENSE for page 0x08 */
+	unsigned skip_ms_page_3f:1;	/* do not MODE-SENSE for page 0x3f */
 	unsigned no_start_on_add:1;	/* do not issue start on add */
 
 	unsigned int device_blocked;	/* Device returned QUEUE_FULL. */

===== sd.c 1.56 vs edited =====

@@ -1059,6 +1059,15 @@
 	struct scsi_mode_data data;
 
 	/*
+	 * Don't try to issue mode sense for page 0x3F if the device
+	 * won't like it.
+	 */
+	if (sdkp->device->skip_ms_page_3f) {
+		printk(KERN_NOTICE "%s: assuming Write Enabled\n", diskname);
+		return;
+	}
+
+	/*
 	 * First attempt: ask for all pages (0x3F), but only 4 bytes.
 	 * We have to start carefully: some devices hang if we ask
 	 * for more than is available.

@@ -1104,6 +1113,18 @@
 	const int modepage = 0x08; /* current values, cache page */
 	struct scsi_mode_data data;
 
+
+	/*
+	 * Don't try to issue mode sense for page 0x08 if the device
+	 * won't like it.
+	 */
+	if (sdkp->device->skip_ms_page_8) {
+		printk(KERN_NOTICE "%s: assuming drive cache: write through\n",
+		       diskname);
+		sdkp->WCE = 0;
+		sdkp->RCD = 0;
+		return;
+	}
 
 	/* cautiously ask */
 	res = sd_do_mode_sense(SRpnt, dbd, modepage, buffer, 4, &data);

PATCH: (as96)
===== drivers/usb/storage/scsiglue.c 1.59 vs edited =====

@@ -68,6 +68,12 @@
 	sdev->use_10_for_ms = 1;
 	sdev->use_10_for_rw = 1;
 
+	/* For disk-type devices, skip the mode-sense query for page 8
+	 * (the caching page).  Lots of USB Mass Storage devices crash
+	 * no matter how carefully we ask. */
+	if (sdev->type == TYPE_DISK)
+		sdev->skip_ms_page_8 = 1;
+
 	/* this is to satisify the compiler, tho I don't think the 
 	 * return code is ever checked anywhere. */
 	return 0;

Does write-protect work for dvd-ram?

How?

sr.c shows this problem by getting the wrong answer.

sr.c is getting cd->device->writeable wrong for all the seven-or-so mmc writable profiles except dvd-ram.

Some background from me and patches from Andy Polyakov and Jens Axboe appear in:
Subject: Re: [PATCH] mount -w of dvd+rw etc. in vanilla 2.6
http://marc.theaimsgroup.com/?t=106123318400007

More old good sense!

Following are relevant posts from me that some archives before now have not included in this thread.

Pat LaVarre

---

Subject: Re: PATCH: exclude certain commands from emulated SCSI hosts
Date: 2003-04-23 14:45:31 PST
From: Pat LaVarre ([email protected])

I have some reason to believe Windows often passes thru something like:
-x "1A 00 08 00 18 00" -i x18
i.e. a ModeSense6 of Cacheing page x08 for the whole 4 byte header plus one whole 8 byte block descriptor plus the whole xC byte standard page.

But I haven't studied this closely enough to know if that's precisely correct, nor do I know when it gets translated to op x5A ModeSense10, nor do I know when it is faked out in the host entirely, never reaching the bus.

Perhaps we mean:
http://lxr.linux.no/source/drivers/usb/storage/protocol.c?v=2.5.56#L274
/* again, for MODE_SENSE_10, we get the minimum (8) */

I don't know of any merely public standard that admits 8 (i.e. the whole standard header) is a minimum.

I do know Win 2K kernel dies if a root-privileged app is so rude as to express an x5A ModeSense10 ModeSense for less than 8 as op x1A ModeSense6:
http://support.microsoft.com/?kbid=813908
SCSI Pass-Through Mode Sense Command May Crash the Computer

A zeroed six byte CDB has been mandatory. Other forms of TUR are less widely supported.
...

-----Forwarded Message-----

From: [email protected]
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: [usb-storage] Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?
Date: 11 Sep 2003 14:04:54 -0600

Thanks, there I find 44 posts dated since 2003-03 with Subject's like:
"PATCH: exclude certain commands from emulated SCSI hosts".

By the way, Google yields [an interestingly] different set of 44 posts:
http://groups.google.com/groups?threadm=linux.scsi.20030322193705.C17056%40one-eyed-alien.net

In both archives I think I see much sense:

...

I think newbies still need a more emphatic hint, such as:

@@ -42,6 +42,9 @@
 encountered a bug!  If you're unsure what version you're currently
 running, the suggested command should tell you.
 
+Except also upgrade your module-init-tools if your depmod -V gives
+you a "depmod version" rather than a "module-init-tools" version.
+
 Again, keep in mind that this list assumes you are already
 functionally running a Linux 2.4 kernel.  Also, not all tools are
 necessary on all systems; obviously, if you don't have any PCMCIA (PC

Sure, 2.6.0-test5 helps some with:

$ cp /etc/redhat-release /dev/null
$ time sudo make install modules_install
...
Warning: you may need to install module-init-tools
See http://www.codemonkey.org.uk/post-halloween-2.5.txt
...

But I believe that hint is insufficient, because I know back when I was mystified, that url was unreachable.

I admit Google did eventually direct me to the seemingly more available alternate:
http://www.kernel.org/pub/linux/kernel/people/davej/misc/post-halloween-2.5.txt

Pat LaVarre

P.S. A fresh, but more complete, quote of what once mystified me is:

$ uname -r
2.4.20-6smp
$ /sbin/depmod -V
depmod version 2.4.22
depmod: Can't open /lib/modules/2.4.20-6smp/modules.dep for writing
$ sudo /sbin/depmod -V
depmod version 2.4.22
$
...

$ uname -r
2.6.0-test5
$ sudo /sbin/modprobe sr_mod
modprobe: QM_MODULES: Function not implemented

modprobe: QM_MODULES: Function not implemented

modprobe: Can't locate module sr_mod
$

Since being demystified, I've adopted a procedure I discovered only by combining in order from module-init-tools all of man depmod, May ./README, Feb ./FAQ, Nov ./INSTALL:

cp /sbin/lsmod /dev/null
./configure --prefix=/
make
./depmod -V
sudo make moveold
sudo make install
sudo ./generate-modprobe.conf /etc/modprobe.conf
sudo vi /etc/rc.d/rc.sysinit +/USEMODULES=

I see I should also submit a patch elsewhere for the module-init-tools README and FAQ. I believe the INSTALL is incorrect by design (by being generic).

Getting a wrong answer isn't quite as bad as crashing the peripheral's firmware. My proposed solution is meant to attack the problems of USB mass storage devices that crash when asked to report MODE-SENSE page 8, possible also when asked for page 0x3f.

Alan Stern

I imagine page x3F is an sd issue only?

I remember Ansi says the mode sense header reports writability only for pdt x00 hdd.

I remember pdt x05 dvd/cd devices misbehaving when their available x3f AllPages data exceeded the xFF bytes that x1A MODE_SENSE can copy, though x5A MODE_SENSE_10 worked fine.

And I often repeat, I remember clearly that the popular OS doesn't often ask only for a four-byte x1A MODE_SENSE header, because I saw that actually doing that crashes Win 2K kernels up thru SP3, if Windows has concluded the device needs the host to translate to x5A MODE_SENSE_10.

Pat LaVarre

Anybody know more?

Eh?

I thought in linux we have competing cdb authors on purpose. For example, how sr decides if a device is writable differs from how ide-cd decides if a device is writable. I thought that the powers that be like linux that way.

No?

Having multiple cdb authors necessarily means that the cdb's passed thru one kind of transport or another do differ any time the multiple versions of copy-edited authoring code differ.

In particular, people designing an unusual device to work with linux have to repeat their work: once for sr, again for ide-cd, and so on.

No?

Pat LaVarre

The mode sense 6 vs 10 that James mentioned, search the code for use_10_for_ms, used in scsi_lib.c, set to 0 in scsi_scan.c and set to 1 by drivers/usb/storage/scsiglue.c.

More specifically, if you are using some LLDD or transport X as a bridge to another transport Y, we might set flags - maybe what commands we can send - relative to transport X, when they might be inappropriate for transport Y.

Examples:

If USB (usb-storage) bridged to a remote device that is actually connected via SPI, today we will try and send 10 byte MODE SENSE commands to the device.

If iSCSI bridged to a remote USB device, we will only send 6 byte MODE SENSE commands.

There are also devices that work with FCP or SPI, but those generally don't have borken devices like the USB storage ones.

I don't get your point - I was talking about the transport (LLDD), not the actual scsi device or upper level drivers.

Code used for different upper level scsi devices should not be duplicated, I don't know ide or cd enough to comment in that area, except that there is common cd code (struct cdrom_device_ops).

sr could probably do some of the same things as sd to figure out if a device is writable, but we are best maintaining current algorithms (don't have sr send new mode sense commands) to avoid borken devices.

-- Patrick Mansfield

Re whether a pdt x05 dvd/cd device is writable, I think I see duplication among ide-cd, ide-scsi, and sr. I hear ide-scsi is dying, but that ide-cd and sr plan to continue competing.

For example:

sr.c get_capabilities decides CDC_DVD_RAM and cd->device->writeable by fetching & parsing as raw hex the 2Ah Capabilities mode page via scsi_lib.c scsi_mode_sense of page x2a, sending op MODE_SENSE = x1a or MODE_SENSE_10 = x5a.

ide-cd.c ide_cdrom_probe_capabilities decides CDC_DVD_RAM (also stored as CDROM_CONFIG_FLAGS(drive)->dvd_ram) by fetching & parsing as a asm/byteorder.h packed struct the 2Ah Capabilities mode page via ide_cdrom_get_capabilities via cdrom_mode_sense of page GPMODE_CAPABILITIES_PAGE = x2a, always sending op GPCMD_MODE_SENSE_10 = x5a.

Neither yet proceeds to try op 46h GET_CONFIGURATION to discover the other six writable mmc profiles.

Thank you for your patience, sorry at first I did not understand how narrowly we mean "transport" here.

Clear to me now (and cool) thank you.

Aye, helpful.

Pat LaVarre