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

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

[Michael Tokarev]

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:

# sdparm --clear=WCE -v -v /dev/sda
mp_settings: page,subpage=0x8,0x0  num=1
  pdt=0 start_byte=0x2 start_bit=2 num_bits=1  val=0  acronym: WCE
    inquiry cdb: 12 00 00 00 24 00
    /dev/sda: ATA       ST3250620NS       3.AE
    mode sense (10) cdb: 5a 00 08 00 00 00 00 00 04 00
    mode sense (10) cdb: 5a 00 08 00 00 00 00 00 24 00
    mode select (10) cdb: 55 10 00 00 00 00 00 00 24 00
    mode select (10) parameter block
        00 00 00 00 00 00 00 08  00 00 00 00 00 00 02 00
        08 12 00 00 00 00 00 00  00 00 00 00 00 00 00 00
        00 00 00 00
mode select (10):  Fixed format, current;  Sense key: Illegal Request
 Additional sense: Invalid field in cdb
 Raw sense data (in hex):
        70 00 05 00 00 00 00 0a  00 00 00 00 24 00 00 00
        00 00
change_mode_page: failed setting page: Caching (SBC)
# _

We also have several "desktop" drives similar to the ones above --
ST3250620AS.  And with those, I can change settings, unlike with
the NS series:

# sdparm --clear=WCE /dev/sda
    /dev/sda: ATA       ST3250620AS       J
# _

What I also observed is that `sdparm -a' output is a bit different
for the two.  For the NS series, it looks like this:

Caching (SBC) mode page:
  WCE         1
...

While for the AS series, it is like:

Caching (SBC) mode page:
  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.

So I wonder -- is it the drive which is bad, or something's
wrong with sdparm?  To me, it should work the opposite way
(IF there should be any difference at all) -- i.e., I can
understand when for a "desktop" (consumer) drive I can't
change some settings, while for "enterprise" class drive
I have more control.

Any ideas?  Should I RMA those drives and/or replace them
with the AS ones? :)

Thanks.

/mjt

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

[Douglas Gilbert]

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:
> 
> # sdparm --clear=WCE -v -v /dev/sda
> mp_settings: page,subpage=0x8,0x0  num=1
>   pdt=0 start_byte=0x2 start_bit=2 num_bits=1  val=0  acronym: WCE
>     inquiry cdb: 12 00 00 00 24 00
>     /dev/sda: ATA       ST3250620NS       3.AE
>     mode sense (10) cdb: 5a 00 08 00 00 00 00 00 04 00
>     mode sense (10) cdb: 5a 00 08 00 00 00 00 00 24 00
>     mode select (10) cdb: 55 10 00 00 00 00 00 00 24 00
>     mode select (10) parameter block
>         00 00 00 00 00 00 00 08  00 00 00 00 00 00 02 00
>         08 12 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>         00 00 00 00
> mode select (10):  Fixed format, current;  Sense key: Illegal Request
>  Additional sense: Invalid field in cdb
>  Raw sense data (in hex):
>         70 00 05 00 00 00 00 0a  00 00 00 00 24 00 00 00
>         00 00
> change_mode_page: failed setting page: Caching (SBC)
> # _
> 
> We also have several "desktop" drives similar to the ones above --
> ST3250620AS.  And with those, I can change settings, unlike with
> the NS series:
> 
> # sdparm --clear=WCE /dev/sda
>     /dev/sda: ATA       ST3250620AS       J
> # _
> 
> What I also observed is that `sdparm -a' output is a bit different
> for the two.  For the NS series, it looks like this:
> 
> Caching (SBC) mode page:
>   WCE         1
> ...
> 
> While for the AS series, it is like:
> 
> Caching (SBC) mode page:
>   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.
> 
> So I wonder -- is it the drive which is bad, or something's
> wrong with sdparm?  To me, it should work the opposite way
> (IF there should be any difference at all) -- i.e., I can
> understand when for a "desktop" (consumer) drive I can't
> change some settings, while for "enterprise" class drive
> I have more control.
> 
> Any ideas?  Should I RMA those drives and/or replace them
> with the AS ones? :)

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

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.

Doug Gilbert

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

[Michael Tokarev]

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