Re: BUG in kernel: Wrong Handling of USB HDDâsin 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@xxxxxxxxx> 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@xxxxxxxxx>
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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/