Re: TYPE_RBC cache fixes (sbp2.c affected)

Douglas Gilbert
2005-05-21T05:03:19Z

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