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
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
