Re: sdparm: change_mode_page: failed setting page: Caching (SBC)

[Michael Tokarev <mjt@tls.msk.ru>]

Douglas Gilbert wrote:
> Michael Tokarev wrote:
>> We've got a bunch of SATA Seagate Barracuda ES drives,
>> namely, ST3250620NS -- "enterprize" class.  And now I
>> wonder what's wrong with - either those drives, or
>> sdparm, or kernel.
>>
>> In particular, sdparm can't change WCE bit, like this:
>> change_mode_page: failed setting page: Caching (SBC)
>> # _
[]
>> What I also observed is that `sdparm -a' output is a bit different
>> for the two.  For the NS series, it looks like this:
>>
>>   WCE         1
>>
>> While for the AS series, it is like:
>>
>>   WCE         1  [cha: y]
>>
>> The difference is that for the AS drives, sdparm displays
>> whenever the parameter is changeable, while for the NS
>> ("enterprise") disk, it does not.
[]
> Michael,
> My information may be out of date, but last time I
> looked libata didn't support MODE SELECT which is
> the SCSI command to change mode page settings.
> [I have sent patches several times to add support
> for this in libata but ...]

Ahhha!!!

That looks exactly the case.

I tested the two drives (AS and NS ones) on different
machines, and currently, NS (where things doesn't work)
is connected to AHCI controller, while the AS one is
behind mptsas.  So it just looks like mptsas is doing
the right thing in the first place, while ahci (or
libata, whatever) is failing.

> So, if /dev/sda is connected directly via libata, and
> libata hasn't been fixed (as per the SAT standard)
> then exactly the error message you have shown above
> will be reported by libata. [BTW the error message
> is wrong too ... it should be 20h,0h not 24h,0h ...
> sent a patch for that too.]
> 
> hdparm should do the trick for you. sdparm (or a very
> recent version of hdparm) may be needed if the SATA
> disk is behind a SAS (USB or 1394) interconnect that
> implements a decent SAT layer somewhere.

Well, even not-so-recent (tried 0.98) works just fine
with a drive connected to mptsas controller.  And indeed,
hdparm did the trick with the NS drive on AHCI controller.

Hooray!

Thank you!

/mjt

(the only (unrelated) prob left with those drives is to
figure out why NCQ doesn't seem to work even if all 3 --
drive, controller and kernel - claims it's enabled with
queue depth = 31/32...  But that's entirely different
story... ;)