* BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) @ 2011-09-28 15:42 Amit Sahrawat 2011-09-28 15:54 ` BUG in kernel: Wrong Handling of USB HDD?s " Christoph Hellwig 2011-09-28 15:57 ` BUG in kernel: Wrong Handling of USB HDD’s " Amit Sahrawat 0 siblings, 2 replies; 17+ messages in thread From: Amit Sahrawat @ 2011-09-28 15:42 UTC (permalink / raw) To: linux-kernel, linux-fsdevel When a USB HDD is connected to the device, it invokes slave_configure to configure the USB HDD. In this function, whenever there is a SCSI device of type TYPE_DISK, it sets: /* A number of devices have problems with MODE SENSE for * page x08, so we will skip it. */ sdev->skip_ms_page_8 = 1; Now, as a part of SCSI device probing, in the function sd_revalidate_disk()-->sd_read_cache_type(), there is a condition if (sdp->skip_ms_page_8) goto defaults; which becomes always true for all the USB HDD’s – the net result is that the Write Cache is never considered for USB HDD(WCE = 0) – “Assuming drive cache: write through” What’s more – the QUEUE ordering which is marked for WCE=0 is QUEUE_ORDERED_DRAIN, instead of QUEUE_ORDERED_DRAIN_FLUSH This means there is no flushing of USB HDD internal cache (although SYNCHRONIZE_CACHE is implemented as passed as command in sd_prepare_flush) – queue_flush()(called in function blk_do_ordered()-->start_ordered()) does not gets called in case of QUEUE_ORDERED_DRAIN. This causes a serious impact on USB HDD’s. Please let me know in case I have missed something in my observations. Thanks & Regards, Amit Sahrawat ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD?s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-28 15:42 BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) Amit Sahrawat @ 2011-09-28 15:54 ` Christoph Hellwig 2011-09-28 15:57 ` BUG in kernel: Wrong Handling of USB HDD’s " Amit Sahrawat 1 sibling, 0 replies; 17+ messages in thread From: Christoph Hellwig @ 2011-09-28 15:54 UTC (permalink / raw) To: Amit Sahrawat; +Cc: linux-kernel, linux-fsdevel You'll have much more luck if you send this to linux-scsi. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-28 15:42 BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) Amit Sahrawat 2011-09-28 15:54 ` BUG in kernel: Wrong Handling of USB HDD?s " Christoph Hellwig @ 2011-09-28 15:57 ` Amit Sahrawat 2011-09-28 21:29 ` James Bottomley 1 sibling, 1 reply; 17+ messages in thread From: Amit Sahrawat @ 2011-09-28 15:57 UTC (permalink / raw) To: linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig Marking mail to linux-scsi. Thanks Christoph. Regards, Amit Sahrawat On Wed, Sep 28, 2011 at 9:12 PM, Amit Sahrawat <amit.sahrawat83@gmail.com> wrote: > When a USB HDD is connected to the device, it invokes slave_configure > to configure the USB HDD. In this function, whenever there is a SCSI > device of type TYPE_DISK, it sets: > /* A number of devices have problems with MODE SENSE for > * page x08, so we will skip it. */ > sdev->skip_ms_page_8 = 1; > > Now, as a part of SCSI device probing, in the function > sd_revalidate_disk()-->sd_read_cache_type(), there is a condition > if (sdp->skip_ms_page_8) > goto defaults; > which becomes always true for all the USB HDD’s – the net result is > that the Write Cache is never considered for USB HDD(WCE = 0) – > “Assuming drive cache: write through” > > What’s more – the QUEUE ordering which is marked for WCE=0 is > QUEUE_ORDERED_DRAIN, instead of QUEUE_ORDERED_DRAIN_FLUSH > This means there is no flushing of USB HDD internal cache (although > SYNCHRONIZE_CACHE is implemented as passed as command in > sd_prepare_flush) – queue_flush()(called in function > blk_do_ordered()-->start_ordered()) does not gets called in case of > QUEUE_ORDERED_DRAIN. > > This causes a serious impact on USB HDD’s. > > Please let me know in case I have missed something in my observations. > > Thanks & Regards, > Amit Sahrawat > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-28 15:57 ` BUG in kernel: Wrong Handling of USB HDD’s " Amit Sahrawat @ 2011-09-28 21:29 ` James Bottomley 2011-09-29 9:19 ` Amit Sahrawat 0 siblings, 1 reply; 17+ messages in thread From: James Bottomley @ 2011-09-28 21:29 UTC (permalink / raw) To: Amit Sahrawat; +Cc: linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig On Wed, 2011-09-28 at 21:27 +0530, Amit Sahrawat wrote: > Marking mail to linux-scsi. > > Thanks Christoph. > > Regards, > Amit Sahrawat > > On Wed, Sep 28, 2011 at 9:12 PM, Amit Sahrawat > <amit.sahrawat83@gmail.com> wrote: > > When a USB HDD is connected to the device, it invokes slave_configure > > to configure the USB HDD. In this function, whenever there is a SCSI > > device of type TYPE_DISK, it sets: > > /* A number of devices have problems with MODE SENSE for > > * page x08, so we will skip it. */ > > sdev->skip_ms_page_8 = 1; > > > > Now, as a part of SCSI device probing, in the function > > sd_revalidate_disk()-->sd_read_cache_type(), there is a condition > > if (sdp->skip_ms_page_8) > > goto defaults; > > which becomes always true for all the USB HDD’s – the net result is > > that the Write Cache is never considered for USB HDD(WCE = 0) – > > “Assuming drive cache: write through” > > > > What’s more – the QUEUE ordering which is marked for WCE=0 is > > QUEUE_ORDERED_DRAIN, instead of QUEUE_ORDERED_DRAIN_FLUSH > > This means there is no flushing of USB HDD internal cache (although > > SYNCHRONIZE_CACHE is implemented as passed as command in > > sd_prepare_flush) – queue_flush()(called in function > > blk_do_ordered()-->start_ordered()) does not gets called in case of > > QUEUE_ORDERED_DRAIN. > > > > This causes a serious impact on USB HDD’s. > > > > Please let me know in case I have missed something in my observations. This should be working in 3.0 ... what version of the kernel are you testing. The actual patch that relaxes the caching mode page check is this one: commit 0bcaa11154f07502e68375617e5650173eea8e50 Author: Luben Tuikov <ltuikov@yahoo.com> Date: Thu May 19 00:00:58 2011 -0700 [SCSI] Retrieve the Caching mode page (version 2) James ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-28 21:29 ` James Bottomley @ 2011-09-29 9:19 ` Amit Sahrawat 2011-09-29 18:27 ` James Bottomley 0 siblings, 1 reply; 17+ messages in thread From: Amit Sahrawat @ 2011-09-29 9:19 UTC (permalink / raw) To: James Bottomley Cc: linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig The patch did not work, although it did get pass the earlier condition which I mentioned- but still Write Cache is not taken into account – seems mode sensing in sd_read_cache_type() does not send proper request to the device – or does not read in proper bytes for this(as per hdparm command analysis): Logs After Connecting: scsi 0:0:0:0: Direct-Access Seagate Portable 0130 PQ: 0 ANSI: 4 sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] No Caching mode page present sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] No Caching mode page present sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: [sda] No Caching mode page present sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] Attached SCSI disk Second Hard-Disk usb 4-1.4: new high speed USB device using ehci-sdp and address 3 usb 4-1.4: New USB device found, idVendor=152d, idProduct=2339 usb 4-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=5 usb 4-1.4: Product: USB to ATA/ATAPI Bridge usb 4-1.4: Manufacturer: JMicron usb 4-1.4: SerialNumber: 3446184AA01C scsi0 : usb-storage 4-1.4:1.0 usb 3-1.1.1: new full speed USB device using ehci-sdp and address 4 usb 3-1.1.1: New USB device found, idVendor=0a5c, idProduct=4502 usb 3-1.1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 3-1.1.2: new full speed USB device using ehci-sdp and address 5 usb 3-1.1.2: New USB device found, idVendor=0a5c, idProduct=4503 usb 3-1.1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 3-1.1.3: new full speed USB device using ehci-sdp and address 6 usb 3-1.1.3: New USB device found, idVendor=0a5c, idProduct=2046 usb 3-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1.1.3: Product: BCM2046B1 usb 3-1.1.3: Manufacturer: Broadcom Corp usb 3-1.1.3: SerialNumber: E4E0C53861A2 scsi 0:0:0:0: Direct-Access SAMSUNG HM501IX PQ: 0 ANSI: 2 CCS sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk Device Identification Retrieved using “hdparm –I” shows this: #> hdparm --verbose -I /dev/sda3 /dev/sda3: outgoing cdb: 85 08 0e 00 00 00 01 00 00 00 00 00 00 40 ec 00 SG_IO: ATA_16 status=0x0, host_status=0x0, driver_status=0x0 SG_IO: sb[]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 incoming_data: 5a 0c ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00 00 00 00 00 20 20 20 20 20 20 20 20 20 20 20 20 56 36 51 43 4e 33 35 57 00 00 00 40 04 00 30 30 32 30 53 42 31 4d 54 53 32 39 30 35 31 33 41 35 20 53 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 80 00 00 00 2f 00 40 00 02 00 02 07 00 ff 3f 10 00 3f 00 10 fc fb 00 10 01 ff ff ff 0f 00 00 07 00 03 00 78 00 78 00 78 00 78 00 00 00 00 00 00 00 00 00 00 00 00 00 1f 00 02 05 00 00 48 00 40 00 f0 01 29 00 6b 34 09 7d 23 61 69 34 09 bc 23 61 7f 40 24 00 24 00 80 80 fe ff 00 00 00 fe 00 00 00 00 00 00 00 00 00 00 70 59 1c 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 50 00 c5 dc 32 73 79 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1e 40 1c 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 21 00 70 59 1c 1d 70 59 1c 1d 20 20 02 00 40 01 00 01 00 50 06 3c 0a 3c 00 00 3c 00 00 00 08 00 00 00 00 00 1f 00 80 02 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3c 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3b 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 15 00 00 00 00 00 00 00 00 10 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a5 d4 SG_IO: desc[]: 00 00 ATA_16 stat=00 err=00 nsect=00 lbal=00 lbam=00 lbah=00 dev=00 ATA device, with non-removable media Model Number: ST9250315AS Serial Number: 6VCQ3NW5 Firmware Revision: 0002BSM1 Transport: Serial Standards: Used: unknown (minor revision code 0x0029) Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBA user addressable sectors: 268435455 LBA48 user addressable sectors: 488397168 Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 238475 MBytes device size with M = 1000*1000: 250059 MBytes (250 GB) cache/buffer size = 8192 KBytes Nominal Media Rotation Rate: 5400 Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Advanced power management level: 128 Recommended acoustic management value: 254, current value: 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cache * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command * DOWNLOAD_MICROCODE * Advanced Power Management feature set SET_MAX security extension * 48-bit Address feature set * Device Configuration Overlay feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test * General Purpose Logging feature set * 64-bit World wide name * IDLE_IMMEDIATE with UNLOAD Write-Read-Verify feature set * WRITE_UNCORRECTABLE_EXT command * {READ,WRITE}_DMA_EXT_GPL commands * Segmented DOWNLOAD_MICROCODE * Gen1 signaling speed (1.5Gb/s) * Native Command Queueing (NCQ) * Phy event counters Device-initiated interface power management * Software settings preservation * SMART Command Transport (SCT) feature set * SCT Long Sector Access (AC1) * SCT Error Recovery Control (AC3) * SCT Features Control (AC4) * SCT Data Tables (AC5) unknown 206[12] (vendor specific) Security: Master password revision code = 65534 supported not enabled not locked not frozen not expired: security count supported: enhanced erase 72min for SECURITY ERASE UNIT. 72min for ENHANCED SECURITY ERASE UNIT. Logical Unit WWN Device Identifier: 5000c50032dc7973 NAA : 5 IEEE OUI : 000c50 Unique ID : 032dc7973 Checksum: correct And the impact of Enabling/Disabling Cache can be seen in: Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set Write cache – Changes after doing ‘hdparm –W 0/1’ * Look-ahead * Host Protected Area feature set * WRITE_BUFFER command * READ_BUFFER command Looking at corresponding code in ‘hdparm’ to fetch this: an ioctl with command ‘ATA_OP_IDENTIFY’ is passed to the device using SG_IO interface (function – get_identify_data()) – which receives the buffer data and that is passed to identify the device specification. file:identify.c, function: void identify (__u16 *id_supplied) printf("Commands/features:\n\tEnabled\tSupported:\n"); print_features(val[CMDS_SUPP_0] & 0x7fff, val[CMDS_EN_0], feat_word82_str); static const char *feat_word82_str[16] = { "obsolete 82[15]", /* word 82 bit 15: obsolete */ "NOP cmd", /* word 82 bit 14 */ "READ_BUFFER command", /* word 82 bit 13 */ "WRITE_BUFFER command", /* word 82 bit 12 */ "WRITE_VERIFY command", /* word 82 bit 11: obsolete */ "Host Protected Area feature set", /* word 82 bit 10 */ "DEVICE_RESET command", /* word 82 bit 9 */ "SERVICE interrupt", /* word 82 bit 8 */ "Release interrupt", /* word 82 bit 7 */ "Look-ahead", /* word 82 bit 6 */ "Write cache", /* word 82 bit 5 */ "PACKET command feature set", /* word 82 bit 4 */ "Power Management feature set", /* word 82 bit 3 */ "Removable Media feature set", /* word 82 bit 2 */ "Security Mode feature set", /* word 82 bit 1 */ "SMART feature set" /* word 82 bit 0 */ }; static void print_features (__u16 supported, __u16 enabled, const char *names[]) { int i; for (i = 0; i < 16; ++i) { __u16 mask = 1 << i; if ((supported & mask) && names[15 - i]) printf("\t %c\t%s\n", (enabled & mask) ? '*' : ' ', names[15 - i]); } } In this, the corresponding ‘Words’ which are passed are: 011010001101011 – 34 6b -val[82] – Supported 011010001101001 – 34 69 -val[85] – When Write Cache is Enabled 011010001001001 – 34 49 -val[85] – When Write Cache is Disabled Val[82], val[85] indicates Words from the buffer received in response to the ATA_OP_IDENTIFY – IOCTL For Disabled Write Cache: Identify Data: 5a 0c ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00 00 00 00 00 20 20 20 20 20 20 20 20 20 20 20 20 56 36 51 43 4e 33 35 57 00 00 00 40 04 00 30 30 32 30 53 42 31 4d 54 53 32 39 30 35 31 33 41 35 20 53 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 80 00 00 00 2f 00 40 00 02 00 02 07 00 ff 3f 10 00 3f 00 10 fc fb 00 10 01 ff ff ff 0f 00 00 07 00 03 00 78 00 78 00 78 00 78 00 00 00 00 00 00 00 00 00 00 00 00 00 1f 00 02 05 00 00 48 00 40 00 f0 01 29 00 6b 34 09 7d 23 61 49 34 09 bc 23 61 7f 40 24 00 24 00 80 80 fe ff 00 00 00 fe 00 00 00 00 00 00 00 00 00 00 70 59 1c 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 50 00 c5 dc 32 73 79 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1e 40 1c 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 For Enabled Write Cache: Identify Data: 5a 0c ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00 00 00 00 00 20 20 20 20 20 20 20 20 20 20 20 20 56 36 51 43 4e 33 35 57 00 00 00 40 04 00 30 30 32 30 53 42 31 4d 54 53 32 39 30 35 31 33 41 35 20 53 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 80 00 00 00 2f 00 40 00 02 00 02 07 00 ff 3f 10 00 3f 00 10 fc fb 00 10 01 ff ff ff 0f 00 00 07 00 03 00 78 00 78 00 78 00 78 00 00 00 00 00 00 00 00 00 00 00 00 00 1f 00 02 05 00 00 48 00 40 00 f0 01 29 00 6b 34 09 7d 23 61 69 34 09 bc 23 61 7f 40 24 00 24 00 80 80 fe ff 00 00 00 fe 00 00 00 00 00 00 00 00 00 00 70 59 1c 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 50 00 c5 dc 32 73 79 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1e 40 1c 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 So, probably the kernel code for sensing the disk and reading to check for the presence of the cache is not working for these USB HDD’s, I have tried with a number of hard-disk’s(different manufactures – with/without write cache) just to make sure that the observation is correct. The corresponding effect of enabling/disabling the write cache can be seen on the write performance also - . Please share your opinion on this. Thanks & Regards, Amit Sahrawat On Thu, Sep 29, 2011 at 2:59 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On Wed, 2011-09-28 at 21:27 +0530, Amit Sahrawat wrote: >> Marking mail to linux-scsi. >> >> Thanks Christoph. >> >> Regards, >> Amit Sahrawat >> >> On Wed, Sep 28, 2011 at 9:12 PM, Amit Sahrawat >> <amit.sahrawat83@gmail.com> wrote: >> > When a USB HDD is connected to the device, it invokes slave_configure >> > to configure the USB HDD. In this function, whenever there is a SCSI >> > device of type TYPE_DISK, it sets: >> > /* A number of devices have problems with MODE SENSE for >> > * page x08, so we will skip it. */ >> > sdev->skip_ms_page_8 = 1; >> > >> > Now, as a part of SCSI device probing, in the function >> > sd_revalidate_disk()-->sd_read_cache_type(), there is a condition >> > if (sdp->skip_ms_page_8) >> > goto defaults; >> > which becomes always true for all the USB HDD’s – the net result is >> > that the Write Cache is never considered for USB HDD(WCE = 0) – >> > “Assuming drive cache: write through” >> > >> > What’s more – the QUEUE ordering which is marked for WCE=0 is >> > QUEUE_ORDERED_DRAIN, instead of QUEUE_ORDERED_DRAIN_FLUSH >> > This means there is no flushing of USB HDD internal cache (although >> > SYNCHRONIZE_CACHE is implemented as passed as command in >> > sd_prepare_flush) – queue_flush()(called in function >> > blk_do_ordered()-->start_ordered()) does not gets called in case of >> > QUEUE_ORDERED_DRAIN. >> > >> > This causes a serious impact on USB HDD’s. >> > >> > Please let me know in case I have missed something in my observations. > > This should be working in 3.0 ... what version of the kernel are you > testing. The actual patch that relaxes the caching mode page check is > this one: > > commit 0bcaa11154f07502e68375617e5650173eea8e50 > Author: Luben Tuikov <ltuikov@yahoo.com> > Date: Thu May 19 00:00:58 2011 -0700 > > [SCSI] Retrieve the Caching mode page (version 2) > > James > > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-29 9:19 ` Amit Sahrawat @ 2011-09-29 18:27 ` James Bottomley 2011-09-29 18:31 ` James Bottomley 0 siblings, 1 reply; 17+ messages in thread From: James Bottomley @ 2011-09-29 18:27 UTC (permalink / raw) To: Amit Sahrawat; +Cc: linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig On Thu, 2011-09-29 at 14:49 +0530, Amit Sahrawat wrote: > The patch did not work, although it did get pass the earlier condition > which I mentioned- but still Write Cache is not taken into account – > seems mode sensing in sd_read_cache_type() does not send proper > request to the device – or does not read in proper bytes for this(as > per hdparm command analysis): > > Logs After Connecting: > scsi 0:0:0:0: Direct-Access Seagate Portable 0130 PQ: 0 ANSI: 4 > sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB) > sd 0:0:0:0: [sda] Write Protect is off > sd 0:0:0:0: [sda] No Caching mode page present This line means that a request for page 0x0 didn't turn up the caching mode page in the list of supported pages. What does sg_inq --page=0x0 /dev/sda show? James ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-29 18:27 ` James Bottomley @ 2011-09-29 18:31 ` James Bottomley 2011-09-30 6:56 ` Amit Sahrawat 0 siblings, 1 reply; 17+ messages in thread From: James Bottomley @ 2011-09-29 18:31 UTC (permalink / raw) To: Amit Sahrawat; +Cc: linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig On Thu, 2011-09-29 at 13:27 -0500, James Bottomley wrote: > On Thu, 2011-09-29 at 14:49 +0530, Amit Sahrawat wrote: > > The patch did not work, although it did get pass the earlier condition > > which I mentioned- but still Write Cache is not taken into account – > > seems mode sensing in sd_read_cache_type() does not send proper > > request to the device – or does not read in proper bytes for this(as > > per hdparm command analysis): > > > > Logs After Connecting: > > scsi 0:0:0:0: Direct-Access Seagate Portable 0130 PQ: 0 ANSI: 4 > > sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB) > > sd 0:0:0:0: [sda] Write Protect is off > > sd 0:0:0:0: [sda] No Caching mode page present > > This line means that a request for page 0x0 didn't turn up the caching > mode page in the list of supported pages. > > What does > > sg_inq --page=0x0 /dev/sda Um, lets try that again, this time with the correct information. What we're looking for is the list of mode pages, so sg_modes --page=0x3f /dev/sda Should return it. Thanks, James ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-29 18:31 ` James Bottomley @ 2011-09-30 6:56 ` Amit Sahrawat 2011-09-30 7:06 ` NamJae Jeon 2011-09-30 12:18 ` James Bottomley 0 siblings, 2 replies; 17+ messages in thread From: Amit Sahrawat @ 2011-09-30 6:56 UTC (permalink / raw) To: James Bottomley Cc: linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig Hi James, [root@localhost Tools]# sg_inq --page=0x0 /dev/sdb Only hex output supported. sg_vpd decodes more pages. VPD INQUIRY, page code=0x00: [PQual=0 Peripheral device type: disk] Supported VPD pages: 0x1f [root@localhost Tools]# [root@localhost Tools]# sg_modes --page=0x3f /dev/sdb SAMSUNG HM501IX peripheral_type: disk [0x0] Mode parameter header from MODE SENSE(10): Mode data length=66, medium type=0x00, WP=0, DpoFua=0, longlba=0 Block descriptor length=0 >> Read-Write error recovery, page_control: current 00 01 0a 00 00 00 00 00 00 00 00 00 00 >> Flexible geometry (obsolete), page_control: current 00 05 0a ff ff 10 3f 02 00 3f ff 00 00 >> Caching, page_control: current 00 08 12 00 00 00 00 00 00 00 00 00 00 01 00 00 00 10 00 00 00 00 >> page_code: 0x1b, page_control: current 00 1b 0a 00 01 00 00 00 00 00 00 00 00 >> Unit Attention condition [vendor specific format], page_control: current 00 00 00 [root@localhost Tools]# [root@localhost Tools]# sginfo -A /dev/sdb INQUIRY response (cmd: 0x12) ---------------------------- Device Type 0 Vendor: SAMSUNG Product: HM501IX Revision level: No serial number (bad format for supported VPDs) Read-Write Error Recovery mode page (0x1) ----------------------------------------- AWRE 0 ARRE 0 TB 0 RC 0 EER 0 PER 0 DTE 0 DCR 0 Read Retry Count 0 Correction Span 0 Head Offset Count 0 Data Strobe Offset Count 0 Write Retry Count 0 Recovery Time Limit (ms) 0 mode page: 0x05 [Flexible Disk] --------------- 0x02 0xff 0x03 0xff 0x04 0x10 0x05 0x3f 0x06 0x02 0x07 0x00 0x08 0x3f 0x09 0xff 0x0a 0x00 0x0b 0x00 Caching mode page (0x8) ----------------------- Initiator Control 0 ABPF 0 CAP 0 DISC 0 SIZE 0 Write Cache Enabled 0 MF 0 Read Cache Disabled 0 Demand Read Retention Priority 0 Demand Write Retention Priority 0 Disable Pre-fetch Transfer Length 0 Minimum Pre-fetch 0 Maximum Pre-fetch 0 Maximum Pre-fetch Ceiling 0 FSW 0 LBCSS 0 DRA 0 NV_DIS 1 Number of Cache Segments 0 Cache Segment size 0 Non-Cache Segment size 0 mode page: 0x1b --------------- 0x02 0x00 0x03 0x01 0x04 0x00 0x05 0x00 0x06 0x00 0x07 0x00 0x08 0x00 0x09 0x00 0x0a 0x00 0x0b 0x00 mode page: 0x00 [Vendor (non-page format)] --------------- 0x00 0x00 0x01 0x00 [root@localhost Tools]# Comparision for USB HDD and Normal Hard disk connected to system.(For USB HDD it showing Write Cache - False, for normal Hard disk - Write Cache - True) [root@localhost Tools]# sg_modes --page=0x3f /dev/sdb SAMSUNG HM501IX peripheral_type: disk [0x0] Mode parameter header from MODE SENSE(10): Mode data length=66, medium type=0x00, WP=0, DpoFua=0, longlba=0 Block descriptor length=0 >> Read-Write error recovery, page_control: current 00 01 0a 00 00 00 00 00 00 00 00 00 00 >> Flexible geometry (obsolete), page_control: current 00 05 0a ff ff 10 3f 02 00 3f ff 00 00 >> Caching, page_control: current 00 08 12 00 00 00 00 00 00 00 00 00 00 01 00 00 00 10 00 00 00 00 >> page_code: 0x1b, page_control: current 00 1b 0a 00 01 00 00 00 00 00 00 00 00 >> Unit Attention condition [vendor specific format], page_control: current 00 00 00 [root@localhost Tools]# sg_modes --page=0x3f /dev/sda ATA SAMSUNG HD502HJ 1AJ1 peripheral_type: disk [0x0] Mode parameter header from MODE SENSE(10): Mode data length=60, medium type=0x00, WP=0, DpoFua=0, longlba=0 Block descriptor length=8 > Direct access device block descriptors: Density code=0x0 00 00 00 00 00 00 00 02 00 >> Read-Write error recovery, page_control: current 00 01 0a 80 00 00 00 00 00 00 00 00 00 >> Caching, page_control: current 00 08 12 04 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 >> Control, page_control: current 00 0a 0a 02 00 00 00 00 00 ff ff 00 1e [root@localhost Tools]# Now, for the USB HDD which do have write cache - sginfo is showing them to Write Cache Enabled as false. Why do the result of hdparm identification and sginfo varies- (I know they have different interface to work with and hdparm takes care of that by using SG_IO interface from it's code)? hdparm showed me correct results - that lead me to digging in the kernel code and checking the performance for USB HDD with Write cache enabled/disabled - which also showed that QUEUE ordering chosen for USB HDD is not correct. I have a large number of USB HDD's - with different vendors, and for all of them - it is showing Write Cache Enabled as false. The code works only for the Pen Drives or the USB HDD which do not have internal cache. Also, for journalling filesystem being used on USB HDD - it does becomes a cause of concern. Please share your opinion, I guess we need a change for mode sensing in the kernel code for USB HDD. Thanks & Regards, Amit Sahrawat On Fri, Sep 30, 2011 at 12:01 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On Thu, 2011-09-29 at 13:27 -0500, James Bottomley wrote: >> On Thu, 2011-09-29 at 14:49 +0530, Amit Sahrawat wrote: >> > The patch did not work, although it did get pass the earlier condition >> > which I mentioned- but still Write Cache is not taken into account – >> > seems mode sensing in sd_read_cache_type() does not send proper >> > request to the device – or does not read in proper bytes for this(as >> > per hdparm command analysis): >> > >> > Logs After Connecting: >> > scsi 0:0:0:0: Direct-Access Seagate Portable 0130 PQ: 0 ANSI: 4 >> > sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB) >> > sd 0:0:0:0: [sda] Write Protect is off >> > sd 0:0:0:0: [sda] No Caching mode page present >> >> This line means that a request for page 0x0 didn't turn up the caching >> mode page in the list of supported pages. >> >> What does >> >> sg_inq --page=0x0 /dev/sda > > Um, lets try that again, this time with the correct information. What > we're looking for is the list of mode pages, so > > sg_modes --page=0x3f /dev/sda > > Should return it. > > Thanks, > > James > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-30 6:56 ` Amit Sahrawat @ 2011-09-30 7:06 ` NamJae Jeon 2011-09-30 12:18 ` James Bottomley 1 sibling, 0 replies; 17+ messages in thread From: NamJae Jeon @ 2011-09-30 7:06 UTC (permalink / raw) To: Amit Sahrawat Cc: James Bottomley, linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig 2011/9/30 Amit Sahrawat <amit.sahrawat83@gmail.com>: > Hi James, > > [root@localhost Tools]# sg_inq --page=0x0 /dev/sdb > Only hex output supported. sg_vpd decodes more pages. > VPD INQUIRY, page code=0x00: > [PQual=0 Peripheral device type: disk] > Supported VPD pages: > 0x1f > [root@localhost Tools]# > > > > [root@localhost Tools]# sg_modes --page=0x3f /dev/sdb > SAMSUNG HM501IX peripheral_type: disk [0x0] > Mode parameter header from MODE SENSE(10): > Mode data length=66, medium type=0x00, WP=0, DpoFua=0, longlba=0 > Block descriptor length=0 >>> Read-Write error recovery, page_control: current > 00 01 0a 00 00 00 00 00 00 00 00 00 00 >>> Flexible geometry (obsolete), page_control: current > 00 05 0a ff ff 10 3f 02 00 3f ff 00 00 >>> Caching, page_control: current > 00 08 12 00 00 00 00 00 00 00 00 00 00 01 00 00 00 > 10 00 00 00 00 >>> page_code: 0x1b, page_control: current > 00 1b 0a 00 01 00 00 00 00 00 00 00 00 >>> Unit Attention condition [vendor specific format], page_control: current > 00 00 00 > [root@localhost Tools]# > > > > [root@localhost Tools]# sginfo -A /dev/sdb > INQUIRY response (cmd: 0x12) > ---------------------------- > Device Type 0 > Vendor: SAMSUNG > Product: HM501IX > Revision level: > > No serial number (bad format for supported VPDs) > > Read-Write Error Recovery mode page (0x1) > ----------------------------------------- > AWRE 0 > ARRE 0 > TB 0 > RC 0 > EER 0 > PER 0 > DTE 0 > DCR 0 > Read Retry Count 0 > Correction Span 0 > Head Offset Count 0 > Data Strobe Offset Count 0 > Write Retry Count 0 > Recovery Time Limit (ms) 0 > > mode page: 0x05 [Flexible Disk] > --------------- > 0x02 0xff > 0x03 0xff > 0x04 0x10 > 0x05 0x3f > 0x06 0x02 > 0x07 0x00 > 0x08 0x3f > 0x09 0xff > 0x0a 0x00 > 0x0b 0x00 > > Caching mode page (0x8) > ----------------------- > Initiator Control 0 > ABPF 0 > CAP 0 > DISC 0 > SIZE 0 > Write Cache Enabled 0 > MF 0 > Read Cache Disabled 0 > Demand Read Retention Priority 0 > Demand Write Retention Priority 0 > Disable Pre-fetch Transfer Length 0 > Minimum Pre-fetch 0 > Maximum Pre-fetch 0 > Maximum Pre-fetch Ceiling 0 > FSW 0 > LBCSS 0 > DRA 0 > NV_DIS 1 > Number of Cache Segments 0 > Cache Segment size 0 > Non-Cache Segment size 0 > > mode page: 0x1b > --------------- > 0x02 0x00 > 0x03 0x01 > 0x04 0x00 > 0x05 0x00 > 0x06 0x00 > 0x07 0x00 > 0x08 0x00 > 0x09 0x00 > 0x0a 0x00 > 0x0b 0x00 > > mode page: 0x00 [Vendor (non-page format)] > --------------- > 0x00 0x00 > 0x01 0x00 > > [root@localhost Tools]# > > Comparision for USB HDD and Normal Hard disk connected to system.(For > USB HDD it showing Write Cache - False, for normal Hard disk - Write > Cache - True) > [root@localhost Tools]# sg_modes --page=0x3f /dev/sdb > SAMSUNG HM501IX peripheral_type: disk [0x0] > Mode parameter header from MODE SENSE(10): > Mode data length=66, medium type=0x00, WP=0, DpoFua=0, longlba=0 > Block descriptor length=0 >>> Read-Write error recovery, page_control: current > 00 01 0a 00 00 00 00 00 00 00 00 00 00 >>> Flexible geometry (obsolete), page_control: current > 00 05 0a ff ff 10 3f 02 00 3f ff 00 00 >>> Caching, page_control: current > 00 08 12 00 00 00 00 00 00 00 00 00 00 01 00 00 00 > 10 00 00 00 00 >>> page_code: 0x1b, page_control: current > 00 1b 0a 00 01 00 00 00 00 00 00 00 00 >>> Unit Attention condition [vendor specific format], page_control: current > 00 00 00 > [root@localhost Tools]# sg_modes --page=0x3f /dev/sda > ATA SAMSUNG HD502HJ 1AJ1 peripheral_type: disk [0x0] > Mode parameter header from MODE SENSE(10): > Mode data length=60, medium type=0x00, WP=0, DpoFua=0, longlba=0 > Block descriptor length=8 >> Direct access device block descriptors: > Density code=0x0 > 00 00 00 00 00 00 00 02 00 > >>> Read-Write error recovery, page_control: current > 00 01 0a 80 00 00 00 00 00 00 00 00 00 >>> Caching, page_control: current > 00 08 12 04 00 00 00 00 00 00 00 00 00 00 00 00 00 > 10 00 00 00 00 >>> Control, page_control: current > 00 0a 0a 02 00 00 00 00 00 ff ff 00 1e > [root@localhost Tools]# > > Now, for the USB HDD which do have write cache - sginfo is showing > them to Write Cache Enabled as false. > Why do the result of hdparm identification and sginfo varies- (I know > they have different interface to work with and hdparm takes care of > that by using SG_IO interface from it's code)? hdparm showed me > correct results - that lead me to digging in the kernel code and > checking the performance for USB HDD with Write cache enabled/disabled > - which also showed that QUEUE ordering chosen for USB HDD is not > correct. > I have a large number of USB HDD's - with different vendors, and for > all of them - it is showing Write Cache Enabled as false. > The code works only for the Pen Drives or the USB HDD which do not > have internal cache. > > Also, for journalling filesystem being used on USB HDD - it does > becomes a cause of concern. Filesystem can not prevent important data(ex, jounal data) by wrtite barrier on this issue. write barrier should be also support on USB HDD(usb driver) like ATA driver. > > Please share your opinion, I guess we need a change for mode sensing > in the kernel code for USB HDD. > > Thanks & Regards, > Amit Sahrawat > > > > On Fri, Sep 30, 2011 at 12:01 AM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: >> On Thu, 2011-09-29 at 13:27 -0500, James Bottomley wrote: >>> On Thu, 2011-09-29 at 14:49 +0530, Amit Sahrawat wrote: >>> > The patch did not work, although it did get pass the earlier condition >>> > which I mentioned- but still Write Cache is not taken into account – >>> > seems mode sensing in sd_read_cache_type() does not send proper >>> > request to the device – or does not read in proper bytes for this(as >>> > per hdparm command analysis): >>> > >>> > Logs After Connecting: >>> > scsi 0:0:0:0: Direct-Access Seagate Portable 0130 PQ: 0 ANSI: 4 >>> > sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB) >>> > sd 0:0:0:0: [sda] Write Protect is off >>> > sd 0:0:0:0: [sda] No Caching mode page present >>> >>> This line means that a request for page 0x0 didn't turn up the caching >>> mode page in the list of supported pages. >>> >>> What does >>> >>> sg_inq --page=0x0 /dev/sda >> >> Um, lets try that again, this time with the correct information. What >> we're looking for is the list of mode pages, so >> >> sg_modes --page=0x3f /dev/sda >> >> Should return it. >> >> Thanks, >> >> James >> >> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-30 6:56 ` Amit Sahrawat 2011-09-30 7:06 ` NamJae Jeon @ 2011-09-30 12:18 ` James Bottomley 2011-09-30 17:53 ` Amit Sahrawat 1 sibling, 1 reply; 17+ messages in thread From: James Bottomley @ 2011-09-30 12:18 UTC (permalink / raw) To: Amit Sahrawat; +Cc: linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig On Fri, 2011-09-30 at 12:26 +0530, Amit Sahrawat wrote: > Now, for the USB HDD which do have write cache - sginfo is showing > them to Write Cache Enabled as false. > Why do the result of hdparm identification and sginfo varies- (I know > they have different interface to work with and hdparm takes care of > that by using SG_IO interface from it's code)? hdparm showed me > correct results - that lead me to digging in the kernel code and > checking the performance for USB HDD with Write cache enabled/disabled > - which also showed that QUEUE ordering chosen for USB HDD is not > correct. Well, what all this means is the SATL in the USB device is implemented wrongly. Since USB devices only preset SCSI interfaces, that's what we have to believe. hdparm when used correctly sends an ATA inquiry command wrapped in an ATA_12 or ATA_16 SCSI command. A large number of legacy SATLs are known to crash on these commands. Are you sure the ATA command is reporting correctly? A write back cache is a remarkably silly thing to enable for a USB device because they're highly likely to be surprise ejected which powers the device down. > I have a large number of USB HDD's - with different vendors, and for > all of them - it is showing Write Cache Enabled as false. > The code works only for the Pen Drives or the USB HDD which do not > have internal cache. > > Also, for journalling filesystem being used on USB HDD - it does > becomes a cause of concern. > > Please share your opinion, I guess we need a change for mode sensing > in the kernel code for USB HDD. Well that's a nastily complex problem. It really needs to be whitelisted in the USB stack, but if every drive is doing it, that's quite a task. The question becomes how do we detect in a SCSI fashion that the device has a write back cache if none of the standard SCSI mechanisms reports it? James ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-30 12:18 ` James Bottomley @ 2011-09-30 17:53 ` Amit Sahrawat 2011-09-30 17:56 ` Amit Sahrawat 0 siblings, 1 reply; 17+ messages in thread From: Amit Sahrawat @ 2011-09-30 17:53 UTC (permalink / raw) To: James Bottomley Cc: linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig On Fri, Sep 30, 2011 at 5:48 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On Fri, 2011-09-30 at 12:26 +0530, Amit Sahrawat wrote: >> Now, for the USB HDD which do have write cache - sginfo is showing >> them to Write Cache Enabled as false. >> Why do the result of hdparm identification and sginfo varies- (I know >> they have different interface to work with and hdparm takes care of >> that by using SG_IO interface from it's code)? hdparm showed me >> correct results - that lead me to digging in the kernel code and >> checking the performance for USB HDD with Write cache enabled/disabled >> - which also showed that QUEUE ordering chosen for USB HDD is not >> correct. > > Well, what all this means is the SATL in the USB device is implemented > wrongly. Since USB devices only preset SCSI interfaces, that's what we > have to believe. > > hdparm when used correctly sends an ATA inquiry command wrapped in an > ATA_12 or ATA_16 SCSI command. A large number of legacy SATLs are known > to crash on these commands. > > Are you sure the ATA command is reporting correctly? A write back cache > is a remarkably silly thing to enable for a USB device because they're > highly likely to be surprise ejected which powers the device down. > In addition to the problem reported - there is one more thing I have noticed with USB HDD - they should be shown as 'removable' but the removable is marked only for USB PEN Drives. This seems to be a bit of confusing, any mass storage media connected on USB port should be recognized as removable. So, for handling the issue, I would consider adding the handling in slave_configure()(usb/storage/scsiglue) which marks the HDD/pen drives as removable also signifying them to be USB based. Then, as part of sd_revalidation – how about adding the ATA_IDENTIFY command part if the device is USB HDD? As far as the result of ATA_IDENTIFY is concerned – they return proper ‘256’ bytes - response and the Words – 82, 85 used for feature supported and enabled/disabled returns proper values for the USB HDD’s I have seen. In case of USB pen drives – they return failure – I did not see any crash – maybe I don’t have one of the legacy SATL based disk. Since, I am new to this – I will check more on this to get a viable solution. Please add your opinion. Can you share the name of the device which causes crash with these ATA commands, If I am able to get one I can try on that also. >> I have a large number of USB HDD's - with different vendors, and for >> all of them - it is showing Write Cache Enabled as false. >> The code works only for the Pen Drives or the USB HDD which do not >> have internal cache. >> >> Also, for journalling filesystem being used on USB HDD - it does >> becomes a cause of concern. >> >> Please share your opinion, I guess we need a change for mode sensing >> in the kernel code for USB HDD. > > Well that's a nastily complex problem. It really needs to be > whitelisted in the USB stack, but if every drive is doing it, that's > quite a task. > > The question becomes how do we detect in a SCSI fashion that the device > has a write back cache if none of the standard SCSI mechanisms reports > it? As far as detecting in SCSI fashion – I wonder using that I would have never reached the conclusion that it is the Write Cache of USB HDD which is causing problem instead I would have been focusing on particular file system (XFS in my case –which in itself is complex) – there BARRIER support and also the Queue handling in the elevator with I/O scheduler. None of the sg utils is showing anything related with the Write Cache in USB HDD – which provide any hint that the Cache is enabled – this is a bit surprising because most of the high end USB mass storages device in the market have Write Cache in them. Thanks & Regards, Amit Sahrawat > > James > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-30 17:53 ` Amit Sahrawat @ 2011-09-30 17:56 ` Amit Sahrawat 2011-09-30 18:11 ` James Bottomley 2011-09-30 18:17 ` Alan Stern 0 siblings, 2 replies; 17+ messages in thread From: Amit Sahrawat @ 2011-09-30 17:56 UTC (permalink / raw) To: James Bottomley, linux-usb Cc: linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig Adding linux-usb - to get more insight's into the problem. On Fri, Sep 30, 2011 at 11:23 PM, Amit Sahrawat <amit.sahrawat83@gmail.com> wrote: > On Fri, Sep 30, 2011 at 5:48 PM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: >> On Fri, 2011-09-30 at 12:26 +0530, Amit Sahrawat wrote: >>> Now, for the USB HDD which do have write cache - sginfo is showing >>> them to Write Cache Enabled as false. >>> Why do the result of hdparm identification and sginfo varies- (I know >>> they have different interface to work with and hdparm takes care of >>> that by using SG_IO interface from it's code)? hdparm showed me >>> correct results - that lead me to digging in the kernel code and >>> checking the performance for USB HDD with Write cache enabled/disabled >>> - which also showed that QUEUE ordering chosen for USB HDD is not >>> correct. >> >> Well, what all this means is the SATL in the USB device is implemented >> wrongly. Since USB devices only preset SCSI interfaces, that's what we >> have to believe. >> >> hdparm when used correctly sends an ATA inquiry command wrapped in an >> ATA_12 or ATA_16 SCSI command. A large number of legacy SATLs are known >> to crash on these commands. >> >> Are you sure the ATA command is reporting correctly? A write back cache >> is a remarkably silly thing to enable for a USB device because they're >> highly likely to be surprise ejected which powers the device down. >> > In addition to the problem reported - there is one more thing I have > noticed with USB HDD - they should be shown as 'removable' but the > removable is marked only for USB PEN Drives. This seems to be a bit of > confusing, any mass storage media connected on USB port should be > recognized as removable. > So, for handling the issue, I would consider adding the handling in > slave_configure()(usb/storage/scsiglue) which marks the HDD/pen drives > as removable also signifying them to be USB based. > Then, as part of sd_revalidation – how about adding the ATA_IDENTIFY > command part if the device is USB HDD? As far as the result of > ATA_IDENTIFY is concerned – they return proper ‘256’ bytes - response > and the Words – 82, 85 used for feature supported and enabled/disabled > returns proper values for the USB HDD’s I have seen. In case of USB > pen drives – they return failure – I did not see any crash – maybe I > don’t have one of the legacy SATL based disk. > Since, I am new to this – I will check more on this to get a viable > solution. Please add your opinion. Can you share the name of the > device which causes crash with these ATA commands, If I am able to get > one I can try on that also. > >>> I have a large number of USB HDD's - with different vendors, and for >>> all of them - it is showing Write Cache Enabled as false. >>> The code works only for the Pen Drives or the USB HDD which do not >>> have internal cache. >>> >>> Also, for journalling filesystem being used on USB HDD - it does >>> becomes a cause of concern. >>> >>> Please share your opinion, I guess we need a change for mode sensing >>> in the kernel code for USB HDD. >> >> Well that's a nastily complex problem. It really needs to be >> whitelisted in the USB stack, but if every drive is doing it, that's >> quite a task. >> >> The question becomes how do we detect in a SCSI fashion that the device >> has a write back cache if none of the standard SCSI mechanisms reports >> it? > As far as detecting in SCSI fashion – I wonder using that I would have > never reached the conclusion that it is the Write Cache of USB HDD > which is causing problem instead I would have been focusing on > particular file system (XFS in my case –which in itself is complex) – > there BARRIER support and also the Queue handling in the elevator with > I/O scheduler. > None of the sg utils is showing anything related with the Write Cache > in USB HDD – which provide any hint that the Cache is enabled – this > is a bit surprising because most of the high end USB mass storages > device in the market have Write Cache in them. > > Thanks & Regards, > Amit Sahrawat >> >> James >> >> >> > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-30 17:56 ` Amit Sahrawat @ 2011-09-30 18:11 ` James Bottomley 2011-09-30 18:30 ` Amit Sahrawat 2011-09-30 18:17 ` Alan Stern 1 sibling, 1 reply; 17+ messages in thread From: James Bottomley @ 2011-09-30 18:11 UTC (permalink / raw) To: Amit Sahrawat Cc: linux-usb, linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig On Fri, 2011-09-30 at 23:26 +0530, Amit Sahrawat wrote: > Adding linux-usb - to get more insight's into the problem. > > On Fri, Sep 30, 2011 at 11:23 PM, Amit Sahrawat > <amit.sahrawat83@gmail.com> wrote: > > On Fri, Sep 30, 2011 at 5:48 PM, James Bottomley > > <James.Bottomley@hansenpartnership.com> wrote: > >> On Fri, 2011-09-30 at 12:26 +0530, Amit Sahrawat wrote: > >>> Now, for the USB HDD which do have write cache - sginfo is showing > >>> them to Write Cache Enabled as false. > >>> Why do the result of hdparm identification and sginfo varies- (I know > >>> they have different interface to work with and hdparm takes care of > >>> that by using SG_IO interface from it's code)? hdparm showed me > >>> correct results - that lead me to digging in the kernel code and > >>> checking the performance for USB HDD with Write cache enabled/disabled > >>> - which also showed that QUEUE ordering chosen for USB HDD is not > >>> correct. > >> > >> Well, what all this means is the SATL in the USB device is implemented > >> wrongly. Since USB devices only preset SCSI interfaces, that's what we > >> have to believe. > >> > >> hdparm when used correctly sends an ATA inquiry command wrapped in an > >> ATA_12 or ATA_16 SCSI command. A large number of legacy SATLs are known > >> to crash on these commands. > >> > >> Are you sure the ATA command is reporting correctly? A write back cache > >> is a remarkably silly thing to enable for a USB device because they're > >> highly likely to be surprise ejected which powers the device down. > >> > > In addition to the problem reported - there is one more thing I have > > noticed with USB HDD - they should be shown as 'removable' but the > > removable is marked only for USB PEN Drives. This seems to be a bit of > > confusing, any mass storage media connected on USB port should be > > recognized as removable. I don't really think so. Removable to sd means that the drive can be removed from the housing, not that the connector cable is hot plug so the whole disk can disappear. I think your disk is the latter, and therefore removable probably isn't what you want (otherwise the sd driver will start probing for medium change and other things your device won't understand). > > So, for handling the issue, I would consider adding the handling in > > slave_configure()(usb/storage/scsiglue) which marks the HDD/pen drives > > as removable also signifying them to be USB based. > > Then, as part of sd_revalidation – how about adding the ATA_IDENTIFY > > command part if the device is USB HDD? As far as the result of > > ATA_IDENTIFY is concerned – they return proper ‘256’ bytes - response > > and the Words – 82, 85 used for feature supported and enabled/disabled > > returns proper values for the USB HDD’s I have seen. In case of USB > > pen drives – they return failure – I did not see any crash – maybe I > > don’t have one of the legacy SATL based disk. > > Since, I am new to this – I will check more on this to get a viable > > solution. Please add your opinion. Can you share the name of the > > device which causes crash with these ATA commands, If I am able to get > > one I can try on that also. How? There are many USB devices whose SATL crashes and burns on ATA_12 or ATA_16, so this would add fragility to the detection path. The detection path has to be cast iron because it has to work on a vast range of devices. The only way this could really work is to add it in the usb storage driver and then replace the bad mode pages. James ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-30 18:11 ` James Bottomley @ 2011-09-30 18:30 ` Amit Sahrawat 0 siblings, 0 replies; 17+ messages in thread From: Amit Sahrawat @ 2011-09-30 18:30 UTC (permalink / raw) To: James Bottomley Cc: linux-usb, linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig Thanks James, I got your point will look more on this. Regards, Amit Sahrawat On Fri, Sep 30, 2011 at 11:41 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On Fri, 2011-09-30 at 23:26 +0530, Amit Sahrawat wrote: >> Adding linux-usb - to get more insight's into the problem. >> >> On Fri, Sep 30, 2011 at 11:23 PM, Amit Sahrawat >> <amit.sahrawat83@gmail.com> wrote: >> > On Fri, Sep 30, 2011 at 5:48 PM, James Bottomley >> > <James.Bottomley@hansenpartnership.com> wrote: >> >> On Fri, 2011-09-30 at 12:26 +0530, Amit Sahrawat wrote: >> >>> Now, for the USB HDD which do have write cache - sginfo is showing >> >>> them to Write Cache Enabled as false. >> >>> Why do the result of hdparm identification and sginfo varies- (I know >> >>> they have different interface to work with and hdparm takes care of >> >>> that by using SG_IO interface from it's code)? hdparm showed me >> >>> correct results - that lead me to digging in the kernel code and >> >>> checking the performance for USB HDD with Write cache enabled/disabled >> >>> - which also showed that QUEUE ordering chosen for USB HDD is not >> >>> correct. >> >> >> >> Well, what all this means is the SATL in the USB device is implemented >> >> wrongly. Since USB devices only preset SCSI interfaces, that's what we >> >> have to believe. >> >> >> >> hdparm when used correctly sends an ATA inquiry command wrapped in an >> >> ATA_12 or ATA_16 SCSI command. A large number of legacy SATLs are known >> >> to crash on these commands. >> >> >> >> Are you sure the ATA command is reporting correctly? A write back cache >> >> is a remarkably silly thing to enable for a USB device because they're >> >> highly likely to be surprise ejected which powers the device down. >> >> >> > In addition to the problem reported - there is one more thing I have >> > noticed with USB HDD - they should be shown as 'removable' but the >> > removable is marked only for USB PEN Drives. This seems to be a bit of >> > confusing, any mass storage media connected on USB port should be >> > recognized as removable. > > I don't really think so. Removable to sd means that the drive can be > removed from the housing, not that the connector cable is hot plug so > the whole disk can disappear. I think your disk is the latter, and > therefore removable probably isn't what you want (otherwise the sd > driver will start probing for medium change and other things your device > won't understand). > >> > So, for handling the issue, I would consider adding the handling in >> > slave_configure()(usb/storage/scsiglue) which marks the HDD/pen drives >> > as removable also signifying them to be USB based. >> > Then, as part of sd_revalidation – how about adding the ATA_IDENTIFY >> > command part if the device is USB HDD? As far as the result of >> > ATA_IDENTIFY is concerned – they return proper ‘256’ bytes - response >> > and the Words – 82, 85 used for feature supported and enabled/disabled >> > returns proper values for the USB HDD’s I have seen. In case of USB >> > pen drives – they return failure – I did not see any crash – maybe I >> > don’t have one of the legacy SATL based disk. >> > Since, I am new to this – I will check more on this to get a viable >> > solution. Please add your opinion. Can you share the name of the >> > device which causes crash with these ATA commands, If I am able to get >> > one I can try on that also. > > How? There are many USB devices whose SATL crashes and burns on ATA_12 > or ATA_16, so this would add fragility to the detection path. The > detection path has to be cast iron because it has to work on a vast > range of devices. The only way this could really work is to add it in > the usb storage driver and then replace the bad mode pages. > > James > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-30 17:56 ` Amit Sahrawat 2011-09-30 18:11 ` James Bottomley @ 2011-09-30 18:17 ` Alan Stern 2011-09-30 18:36 ` Amit Sahrawat 1 sibling, 1 reply; 17+ messages in thread From: Alan Stern @ 2011-09-30 18:17 UTC (permalink / raw) To: Amit Sahrawat Cc: James Bottomley, linux-usb, linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 5439 bytes --] On Fri, 30 Sep 2011, Amit Sahrawat wrote: > Adding linux-usb - to get more insight's into the problem. > > On Fri, Sep 30, 2011 at 11:23 PM, Amit Sahrawat > <amit.sahrawat83@gmail.com> wrote: > > On Fri, Sep 30, 2011 at 5:48 PM, James Bottomley > > <James.Bottomley@hansenpartnership.com> wrote: > >> On Fri, 2011-09-30 at 12:26 +0530, Amit Sahrawat wrote: > >>> Now, for the USB HDD which do have write cache - sginfo is showing > >>> them to Write Cache Enabled as false. > >>> Why do the result of hdparm identification and sginfo varies- (I know > >>> they have different interface to work with and hdparm takes care of > >>> that by using SG_IO interface from it's code)? hdparm showed me > >>> correct results - that lead me to digging in the kernel code and > >>> checking the performance for USB HDD with Write cache enabled/disabled > >>> - which also showed that QUEUE ordering chosen for USB HDD is not > >>> correct. > >> > >> Well, what all this means is the SATL in the USB device is implemented > >> wrongly. Since USB devices only preset SCSI interfaces, that's what we > >> have to believe. > >> > >> hdparm when used correctly sends an ATA inquiry command wrapped in an > >> ATA_12 or ATA_16 SCSI command. A large number of legacy SATLs are known > >> to crash on these commands. > >> > >> Are you sure the ATA command is reporting correctly? A write back cache > >> is a remarkably silly thing to enable for a USB device because they're > >> highly likely to be surprise ejected which powers the device down. A usbmon trace would be very helpful for understanding this. Instructions can be found in the kernel source file Documentation/usb/usbmon.txt. Post a trace showing what happens when the drive is first plugged in. > > In addition to the problem reported - there is one more thing I have > > noticed with USB HDD - they should be shown as 'removable' but the > > removable is marked only for USB PEN Drives. This seems to be a bit of > > confusing, any mass storage media connected on USB port should be > > recognized as removable. That is not true. The word "removable" refers to the storage media. Thus, a cdrom drive is removable because you can remove the disc from the drive. The same for a card reader, because you can remove the card from the reader. But a flash drive is not removable, because you can't take the flash memory chip out of the device. You are confusing "removable" with "hot-unpluggable". All USB drives are hot-unpluggable, but relatively few of them are removable. Vendors often get this wrong, however. > > So, for handling the issue, I would consider adding the handling in > > slave_configure()(usb/storage/scsiglue) which marks the HDD/pen drives > > as removable also signifying them to be USB based. This does not happen in usb-storage at all. The SCSI core is responsible for determining whether or not a device is removable, and it does this by looking at second byte of the data returned by the SCSI INQUIRY command. > > Then, as part of sd_revalidation – how about adding the ATA_IDENTIFY > > command part if the device is USB HDD? As far as the result of > > ATA_IDENTIFY is concerned – they return proper ‘256’ bytes - response > > and the Words – 82, 85 used for feature supported and enabled/disabled > > returns proper values for the USB HDD’s I have seen. In case of USB > > pen drives – they return failure – I did not see any crash – maybe I > > don’t have one of the legacy SATL based disk. > > Since, I am new to this – I will check more on this to get a viable > > solution. Please add your opinion. Can you share the name of the > > device which causes crash with these ATA commands, If I am able to get > > one I can try on that also. > > > >>> I have a large number of USB HDD's - with different vendors, and for > >>> all of them - it is showing Write Cache Enabled as false. This indicates those drives do not implement the SCSI MODE SENSE command correctly. usbmon will help track down the problem. > >>> The code works only for the Pen Drives or the USB HDD which do not > >>> have internal cache. > >>> > >>> Also, for journalling filesystem being used on USB HDD - it does > >>> becomes a cause of concern. > >>> > >>> Please share your opinion, I guess we need a change for mode sensing > >>> in the kernel code for USB HDD. > >> > >> Well that's a nastily complex problem. It really needs to be > >> whitelisted in the USB stack, but if every drive is doing it, that's > >> quite a task. > >> > >> The question becomes how do we detect in a SCSI fashion that the device > >> has a write back cache if none of the standard SCSI mechanisms reports > >> it? > > As far as detecting in SCSI fashion – I wonder using that I would have > > never reached the conclusion that it is the Write Cache of USB HDD > > which is causing problem instead I would have been focusing on > > particular file system (XFS in my case –which in itself is complex) – > > there BARRIER support and also the Queue handling in the elevator with > > I/O scheduler. > > None of the sg utils is showing anything related with the Write Cache > > in USB HDD – which provide any hint that the Cache is enabled – this > > is a bit surprising because most of the high end USB mass storages > > device in the market have Write Cache in them. Alan Stern ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-09-30 18:17 ` Alan Stern @ 2011-09-30 18:36 ` Amit Sahrawat 0 siblings, 0 replies; 17+ messages in thread From: Amit Sahrawat @ 2011-09-30 18:36 UTC (permalink / raw) To: Alan Stern Cc: James Bottomley, linux-usb, linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig On Fri, Sep 30, 2011 at 11:47 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Fri, 30 Sep 2011, Amit Sahrawat wrote: > >> Adding linux-usb - to get more insight's into the problem. >> >> On Fri, Sep 30, 2011 at 11:23 PM, Amit Sahrawat >> <amit.sahrawat83@gmail.com> wrote: >> > On Fri, Sep 30, 2011 at 5:48 PM, James Bottomley >> > <James.Bottomley@hansenpartnership.com> wrote: >> >> On Fri, 2011-09-30 at 12:26 +0530, Amit Sahrawat wrote: >> >>> Now, for the USB HDD which do have write cache - sginfo is showing >> >>> them to Write Cache Enabled as false. >> >>> Why do the result of hdparm identification and sginfo varies- (I know >> >>> they have different interface to work with and hdparm takes care of >> >>> that by using SG_IO interface from it's code)? hdparm showed me >> >>> correct results - that lead me to digging in the kernel code and >> >>> checking the performance for USB HDD with Write cache enabled/disabled >> >>> - which also showed that QUEUE ordering chosen for USB HDD is not >> >>> correct. >> >> >> >> Well, what all this means is the SATL in the USB device is implemented >> >> wrongly. Since USB devices only preset SCSI interfaces, that's what we >> >> have to believe. >> >> >> >> hdparm when used correctly sends an ATA inquiry command wrapped in an >> >> ATA_12 or ATA_16 SCSI command. A large number of legacy SATLs are known >> >> to crash on these commands. >> >> >> >> Are you sure the ATA command is reporting correctly? A write back cache >> >> is a remarkably silly thing to enable for a USB device because they're >> >> highly likely to be surprise ejected which powers the device down. > > A usbmon trace would be very helpful for understanding this. > Instructions can be found in the kernel source file > Documentation/usb/usbmon.txt. Post a trace showing what happens when > the drive is first plugged in. Thanks Alan, I will go through the usbmon and check all the information I can retrieve using that. > >> > In addition to the problem reported - there is one more thing I have >> > noticed with USB HDD - they should be shown as 'removable' but the >> > removable is marked only for USB PEN Drives. This seems to be a bit of >> > confusing, any mass storage media connected on USB port should be >> > recognized as removable. > > That is not true. The word "removable" refers to the storage media. > Thus, a cdrom drive is removable because you can remove the disc from > the drive. The same for a card reader, because you can remove the card > from the reader. But a flash drive is not removable, because you can't > take the flash memory chip out of the device. > > You are confusing "removable" with "hot-unpluggable". All USB drives > are hot-unpluggable, but relatively few of them are removable. Vendors > often get this wrong, however. I got your point. > >> > So, for handling the issue, I would consider adding the handling in >> > slave_configure()(usb/storage/scsiglue) which marks the HDD/pen drives >> > as removable also signifying them to be USB based. > > This does not happen in usb-storage at all. The SCSI core is > responsible for determining whether or not a device is removable, and > it does this by looking at second byte of the data returned by the SCSI > INQUIRY command. > >> > Then, as part of sd_revalidation – how about adding the ATA_IDENTIFY >> > command part if the device is USB HDD? As far as the result of >> > ATA_IDENTIFY is concerned – they return proper ‘256’ bytes - response >> > and the Words – 82, 85 used for feature supported and enabled/disabled >> > returns proper values for the USB HDD’s I have seen. In case of USB >> > pen drives – they return failure – I did not see any crash – maybe I >> > don’t have one of the legacy SATL based disk. >> > Since, I am new to this – I will check more on this to get a viable >> > solution. Please add your opinion. Can you share the name of the >> > device which causes crash with these ATA commands, If I am able to get >> > one I can try on that also. >> > >> >>> I have a large number of USB HDD's - with different vendors, and for >> >>> all of them - it is showing Write Cache Enabled as false. > > This indicates those drives do not implement the SCSI MODE SENSE > command correctly. usbmon will help track down the problem. Yes, this seems to be the problem. But, almost all the manufacturer's HDD is behaving the same way. They are showing the effectof switching Write Cache on/off but not able to detect the same at plug-on. Anyway, I will look at the 'usbmon' option you have provided. > >> >>> The code works only for the Pen Drives or the USB HDD which do not >> >>> have internal cache. >> >>> >> >>> Also, for journalling filesystem being used on USB HDD - it does >> >>> becomes a cause of concern. >> >>> >> >>> Please share your opinion, I guess we need a change for mode sensing >> >>> in the kernel code for USB HDD. >> >> >> >> Well that's a nastily complex problem. It really needs to be >> >> whitelisted in the USB stack, but if every drive is doing it, that's >> >> quite a task. >> >> >> >> The question becomes how do we detect in a SCSI fashion that the device >> >> has a write back cache if none of the standard SCSI mechanisms reports >> >> it? >> > As far as detecting in SCSI fashion – I wonder using that I would have >> > never reached the conclusion that it is the Write Cache of USB HDD >> > which is causing problem instead I would have been focusing on >> > particular file system (XFS in my case –which in itself is complex) – >> > there BARRIER support and also the Queue handling in the elevator with >> > I/O scheduler. >> > None of the sg utils is showing anything related with the Write Cache >> > in USB HDD – which provide any hint that the Cache is enabled – this >> > is a bit surprising because most of the high end USB mass storages >> > device in the market have Write Cache in them. > > Alan Stern > > Regards, Amit Sahrawat ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) @ 2011-10-03 14:25 Alan Stern 2011-10-03 16:06 ` Douglas Gilbert 0 siblings, 1 reply; 17+ messages in thread From: Alan Stern @ 2011-10-03 14:25 UTC (permalink / raw) To: Amit Sahrawat Cc: James Bottomley, linux-usb-u79uwXL29TY76Z2rM5mHXA, linux-scsi-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig On Mon, 3 Oct 2011, Amit Sahrawat wrote: > Hi, > > Please find the USB Analyzer - logs for '6' USB based Mass Storage > devices attached. Too bad the analyzer log presents only the response, not the command. > So, only for one of the USB HDD(Seagate - Free Agent), the response > obtained is correct. I don't understand the format of the Seagate Free Agent MODE SENSE data. Maybe someone else can interpret it; here it is for reference: SCSI Op(3) ADDR(4) Tag(0x00000004) SCSI CDB MODE SENSE(6) _______| Data( __ 000: 1C 00 00 00 86 0B 00 02 00 00 12 A1 9E B0 3C 01 00 1A 0A 00 01 00 00 00 00 00 00 0B B8 00 00 00 __ 032: 00 00 00 00 1A 0A 00 01 00 00 00 00 00 00 0B B8 A2 06 00 00 00 00 00 00 78 20 55 53 42 32 2E 30 __ 064: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 7F FF 00 00 00 00 80 FA 0B C2 50 21 4E 41 30 42 __ 096: 36 58 33 4C 00 30 00 00 00 32 43 46 45 39 42 00 70 F5 12 00 74 FF 00 00 00 00 00 00 00 00 00 00 __ 128: 3C 00 00 0B B8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 02 50 01 __ 160: 46 72 65 65 41 67 65 6E 74 20 47 6F 46 6C 65 78 10 50 11 46 72 65 65 41 67 65 6E 74 20 47 6F 46) For the other devices this seems clear enough. In most of the cases, the data doesn't include the Caching page. The Samsung and Transcend devices _do_ provide their Caching pages, and in both of them the data says that write caching is disabled. (In the Samsung case this is wrong undoubtedly because of the JMicron bridge -- JMicron's firmware is notoriously buggy.) If you can suggest a robust way of determining whether or not a drive supports SAT (one which won't cause non-supporting devices to crash), it could be added. In the meantime, I'm not sure what else we can do. Would it make sense to assume write caching is present and enabled if the drive does not provide a Caching page? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) 2011-10-03 14:25 Alan Stern @ 2011-10-03 16:06 ` Douglas Gilbert 0 siblings, 0 replies; 17+ messages in thread From: Douglas Gilbert @ 2011-10-03 16:06 UTC (permalink / raw) To: Alan Stern Cc: Amit Sahrawat, James Bottomley, linux-usb, linux-scsi, linux-kernel, linux-fsdevel, Christoph Hellwig On 11-10-03 04:25 PM, Alan Stern wrote: > On Mon, 3 Oct 2011, Amit Sahrawat wrote: > >> Hi, >> >> Please find the USB Analyzer - logs for '6' USB based Mass Storage >> devices attached. > > Too bad the analyzer log presents only the response, not the command. > >> So, only for one of the USB HDD(Seagate - Free Agent), the response >> obtained is correct. > > I don't understand the format of the Seagate Free Agent MODE SENSE > data. Maybe someone else can interpret it; here it is for reference: > > SCSI Op(3) ADDR(4) Tag(0x00000004) SCSI CDB MODE SENSE(6) > _______| Data( > __ 000: 1C 00 00 00 86 0B 00 02 00 00 12 A1 9E B0 3C 01 00 1A 0A 00 01 00 00 00 00 00 00 0B B8 00 00 00 > __ 032: 00 00 00 00 1A 0A 00 01 00 00 00 00 00 00 0B B8 A2 06 00 00 00 00 00 00 78 20 55 53 42 32 2E 30 > __ 064: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 7F FF 00 00 00 00 80 FA 0B C2 50 21 4E 41 30 42 > __ 096: 36 58 33 4C 00 30 00 00 00 32 43 46 45 39 42 00 70 F5 12 00 74 FF 00 00 00 00 00 00 00 00 00 00 > __ 128: 3C 00 00 0B B8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 02 50 01 > __ 160: 46 72 65 65 41 67 65 6E 74 20 47 6F 46 6C 65 78 10 50 11 46 72 65 65 41 67 65 6E 74 20 47 6F 46) The RBC device parameters mode page followed by a Power Condition mode page. The RBC device parameters mode page is the only SCSI page I have seen (mode, log, VPD, etc) with a 5 byte field! Decoded response to a probable MODE SENSE(6) "fetch all pages" command: RBC device parameters mpage: WCD=0 [double negative: write cache enabled] Logical block size: 512 bytes Number of logical blocks: 0x12A19EB0 *** [160 GB] Power/performance: 0x3c READD: 0 [READ enabled] WRITED: 0 [WRITE enabled] FORMATD: 0 [FORMAT UNIT enabled] LOCKD: 1 [media cannot be locked] Power Condition mpage: IDLE=0 STANDBY=1 IDLE_CONDITION_TIMER=0 STANDBY_CONDITION_TIMER=0xbb8 [300 seconds] References: rbc-r10a.pdf [1999] + spc3r26 [2005] Hopefully Seagate will switch to UAS(P) in the near future. *** That is _not_ the address of the last valid LB as in the SCSI READ CAPACITY command! > For the other devices this seems clear enough. In most of the cases, > the data doesn't include the Caching page. The Samsung and Transcend > devices _do_ provide their Caching pages, and in both of them the data > says that write caching is disabled. (In the Samsung case this is > wrong undoubtedly because of the JMicron bridge -- JMicron's firmware > is notoriously buggy.) > > If you can suggest a robust way of determining whether or not a drive > supports SAT (one which won't cause non-supporting devices to crash), > it could be added. In the meantime, I'm not sure what else we can do. > > Would it make sense to assume write caching is present and enabled if > the drive does not provide a Caching page? No. You need to also take into account the RBC device parameters mode page if present. See above. Doug Gilbert ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-10-03 16:06 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-28 15:42 BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type) Amit Sahrawat 2011-09-28 15:54 ` BUG in kernel: Wrong Handling of USB HDD?s " Christoph Hellwig 2011-09-28 15:57 ` BUG in kernel: Wrong Handling of USB HDD’s " Amit Sahrawat 2011-09-28 21:29 ` James Bottomley 2011-09-29 9:19 ` Amit Sahrawat 2011-09-29 18:27 ` James Bottomley 2011-09-29 18:31 ` James Bottomley 2011-09-30 6:56 ` Amit Sahrawat 2011-09-30 7:06 ` NamJae Jeon 2011-09-30 12:18 ` James Bottomley 2011-09-30 17:53 ` Amit Sahrawat 2011-09-30 17:56 ` Amit Sahrawat 2011-09-30 18:11 ` James Bottomley 2011-09-30 18:30 ` Amit Sahrawat 2011-09-30 18:17 ` Alan Stern 2011-09-30 18:36 ` Amit Sahrawat -- strict thread matches above, loose matches on Subject: below -- 2011-10-03 14:25 Alan Stern 2011-10-03 16:06 ` Douglas Gilbert
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).