BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Amit Sahrawat]

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

Re: BUG in kernel: Wrong Handling of USB HDD?s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Christoph Hellwig]

You'll have much more luck if you send this to linux-scsi.

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Amit Sahrawat]

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
>

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[James Bottomley]

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

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Amit Sahrawat]

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

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[James Bottomley]

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

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[James Bottomley]

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

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Amit Sahrawat]

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
>
>
>

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[NamJae Jeon]

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/
>

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[James Bottomley]

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

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Amit Sahrawat]

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
>
>
>

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Amit Sahrawat]

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
>>
>>
>>
>

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[James Bottomley]

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

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Amit Sahrawat]

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
>
>
>

Re: Re: Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Alan Stern]

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

Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Douglas Gilbert]

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

Re: Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Alan Stern]

On Mon, 3 Oct 2011, Douglas Gilbert wrote:

> 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!

Thanks for the explanation.

> > 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.

All right, suppose neither page is present.  Does it then make sense to 
assume by default that write caching is enabled?

Alan Stern

Re: Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[James Bottomley]

On Mon, 2011-10-03 at 14:10 -0400, Alan Stern wrote:
> > No. You need to also take into account the RBC
> > device parameters mode page if present. See above.
> 
> All right, suppose neither page is present.  Does it then make sense to 
> assume by default that write caching is enabled?

You're the USB expert ... if we do that, we'll start sending
SYNCHRONIZE_CACHE commands down to a whole slew of devices we didn't
before ... is that going to cause problems with any USB SATLs?

James


--
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

Re: Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

[Alan Stern]

On Mon, 3 Oct 2011, James Bottomley wrote:

> On Mon, 2011-10-03 at 14:10 -0400, Alan Stern wrote:
> > > No. You need to also take into account the RBC
> > > device parameters mode page if present. See above.
> > 
> > All right, suppose neither page is present.  Does it then make sense to 
> > assume by default that write caching is enabled?
> 
> You're the USB expert ... if we do that, we'll start sending
> SYNCHRONIZE_CACHE commands down to a whole slew of devices we didn't
> before ... is that going to cause problems with any USB SATLs?

Hmmm...  Actually, I doubt it would bother any SATLs, but it might well
bother other sorts of USB translation layers.  No way to tell without
trying it, and I don't really want to deal with the fallout.

Maybe a better question to be asking is this: What happens when one of 
these drives (the ones that report their caching capabilities 
incorrectly) is plugged into a Windows system?

Alan Stern