Re: TYPE_RBC cache fixes (sbp2.c affected)

Stefan Richter
2006-02-11T09:51:02Z

Al Viro wrote on 2006-02-09:
> On Thu, Feb 09, 2006 at 12:39:20AM +0100, Stefan Richter wrote:
>>Could the fact that Linux reboots (if sbp2 does not mangle the SCSI
>>commands) mean that the SBP-2 target is overwriting memory outside of a
>>data buffer? Or does the SCSI stack perform reckless things like jumps
>>based on pointer tables, using unchecked data? Or...?
>
> Interesting... What's the last command sent before reboot? Note that
> original driver would remap 6byte commands to 10byte ones, but new one
> should not _get_ those commands. At all. What happens if you take old
> driver, put
> sdev->use_10_for_rw = 1;
> sdev->use_10_for_ms = 1;
> into sbp2scsi_slave_configure() and leave remapping code alone? Then
> see if remapper is ever triggered - if it does, we have a problem in
> midlayer. If not... I'd love to see the last commands.

Yes, I will do so as soon I got spare time.
MODE_SENSE_10 seemed to be the trigger, as mentioned in
http://marc.theaimsgroup.com/?l=linux-scsi&m=112128914912105 . Also note
that this device reports to implement Direct-Access, unlike most other
SBP-2 HDDs which pose as Direct-Access-RBC.

I have one other bridge which reports type Direct-Access. It is based on
the first generation fon TI StorageLynx. This does not work under Linux
either because it requires the 36 byte inquiry workaround. Sbp2's
version has become ineffective in recent kernels and I have not yet
figured out how to enable the SCSI layer's version of this workaround.
(But that's another issue.)

> BTW, I've seen PL3507-based enclosure <spit> with the following lovely
> bug: if it _ever_ got INQUIRY (any INQUIRY) other than immediately in
> the beginning of session, it got 8 bytes stuck in FIFO. All subsequeunt
> reads got shifted by 8 bytes, no matter what. With old driver, new driver...
> Just scsiinfo -i would be enough to screw it. With massive fs corruption,
> obviously...

Interesting. Many PL3507 come with buggy firmware which is noticed under
other OSs too. Newer hardware revisions can be reprogrammed but I don't
know where the latest firmware is available and whether it fixes this
INQUIRY related bug.

Do you think a workaround (like perhaps "reject all INQUIRY commands
except the first one after login") would be justified?
--
Stefan Richter
-=====-=-==- --=- -=-==