Re: TYPE_RBC cache fixes (sbp2.c affected)

[Douglas Gilbert <dougg@torque.net>]

Al Viro wrote:
> 	a) TYPE_SDAD renamed to TYPE_RBC and taken to scsi.h
> 	b) in sbp2.c remapping of TYPE_RPB to TYPE_DISK turned off
> 	c) relevant places in midlayer and sd.c taught to accept TYPE_RBC
> 	d) sd.c::sd_read_cache_type() looks into page 6 when dealing with
> TYPE_RBC - these guys have writeback cache flag there and are not guaranteed
> to have page 8 at all.
> 	e) sd_read_cache_type() got an extra sanity check - it checks that
> it got the page it asked for before using its contents.  And screams if
> mismatch had happened.  Rationale: there are broken devices out there that
> are "helpful" enough to go for "I don't have a page you've asked for, here,
> have another one".  For example, PL3507 had been caught doing just that...
> 	f) sbp2 sets sdev->use_10_for_rw and sdev->use_10_for_ms instead
> of bothering to remap READ6/WRITE6/MOD_SENSE, so most of the conversions
> in there are gone now.

Al,
I applied this patch and tested it with a Lava
Firewire-HC enclosure and a Seagate 7200.7 ATA disk.
The enclosure uses a OXFW900-TQ-A bridge chip.

It works ok, with a few wrinkles. MODE SENSE+SELECT
(6) work properly but MODE SENSE(10) responds with
the 6 byte variant response!? If nothing else it
was useful for testing sdparm and sg_modes coping
with such cases.

I will submit a patch for driver/scsi/scsi.c so it
stops saying the device type (in the output of
"cat /proc/scsi/scsi") is "unknown" for RBC devices.

Here is some output from sdparm (version 0.92):

# sdparm /dev/sdd -a
     /dev/sdd: ST380011  A                    [pdt=0xe]
RBC device parameters (RBC) mode page:
 >>> warning: mode page seems malformed, try '--flexible'
   WCD         0  [ def:  0, saved:  0]
   LBS       45310  [ def:45310, saved:45310]
   NLBS        0  [ def:  0, saved:  0]
   P_P         0  [ def:  0, saved:  0]
   READD       0  [ def:  0, saved:  0]
   WRITED      0  [ def:  0, saved:  0]
   FORMATD     0  [ def:  0, saved:  0]
   LOCKD       0  [ def:  0, saved:  0]

# sdparm /dev/sdd -a -f
     /dev/sdd: ST380011  A                    [pdt=0xe]
RBC device parameters (RBC) mode page:
   WCD         0  [ def:  0, saved:  0]
   LBS       512  [ def:512, saved:512]
   NLBS      156301488  [ def:156301488, saved:156301488]
   P_P       254  [ def:254, saved:254]
   READD       0  [ def:  0, saved:  0]
   WRITED      0  [ def:  0, saved:  0]
   FORMATD     0  [ def:  0, saved:  0]
   LOCKD       0  [ def:  0, saved:  0]

# sdparm /dev/sdd -a -6
     /dev/sdd: ST380011  A                    [pdt=0xe]
RBC device parameters (RBC) mode page:
   WCD         0  [ def:  0, saved:  0]
   LBS       512  [ def:512, saved:512]
   NLBS      156301488  [ def:156301488, saved:156301488]
   P_P       254  [ def:254, saved:254]
   READD       0  [ def:  0, saved:  0]
   WRITED      0  [ def:  0, saved:  0]
   FORMATD     0  [ def:  0, saved:  0]
   LOCKD       0  [ def:  0, saved:  0]

# sdparm /dev/sdd -s WCD -6
     /dev/sdd: ST380011  A                    [pdt=0xe]

# echo $?
0

# sdparm /dev/sdd -g WCD -6
WCD         1  [ def:  1, saved:  1]

# sdparm -i /dev/sdd
     /dev/sdb: ST380011  A                    [pdt=0xe]
Device identification VPD page:
   Addressed logical unit:
     id_type: EUI-64 based,  code_set: Binary
       [0x00043b000000071d]

I found that the WCD field and no others could
be changed with sdparm. When other fields were
changed there was no complaint from the device
but a subsequent get showed no change.

This experiment shows that if sd and the mid level rely
on the response from a MODE SENSE (10) without doing a
sanity check, then they will be using corrupted data.

Doug Gilbert