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

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

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

[]

[]

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.

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