Re: [PATCH 7/8] don't mangle INQUIRY if cmddt or evpd bits are set

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Al Viro wrote:
> On Mon, Feb 13, 2006 at 09:28:17PM +0100, Stefan Richter wrote:
...
> > - The TI StorageLynx based bridge reports device type 0 (TYPE_DISK).
> >   The problem occurs apparently with page 4 and page 8. Sbp2 has a
> >   fix since yesterday which sets the skip_ms_page_8 flag.
>
> That's going to cause fun problems on reboot if it actually has write-behind
> cache...

Not only on reboot but always when sd is told to shut down. I did not 
notice an actual problem so far but I will keep an eye on it.

But AFAIU, sd's cache syncing (of devices with WCE set) is ineffective 
anyway if devices are unplugged without manually shutting the driver 
down beforehand.

> >   http://marc.theaimsgroup.com/?l=linux1394-devel&m=113969287630893
> > - Another bridge made by the same manufacturer but based on TI
> >   StorageLynx revision A features the same MODE SENSE bug. This bridge
> >   reports type 14 (TYPE_RBC).
>
> Pardon?  If it's type 14, we won't issue MODE SENSE for page 8 and will
> go for page 6 instead...

Correct. Which is why I did not notice the bug until testing with scsiinfo.

...
> > Of course sg does not care for any black list flags (like sd_mod and 
> > sr_mod do), but considering the nature of the bugs and anticipated usage 
> > of affected devices, there is hardly a reason for further safeguards in 
> > sbp2, let alone sg.
>
> Maybe, maybe not.  Note that e.g. aforementioned INQUIRY bug in pl3507 is
> triggered by dmraid, which works via SG_IO, just as scsiinfo.  And unlike
> scsiinfo it's run from /etc/rc.sysinit on current FC4...

Are they probing all devices or only those which are part of a RAID set?
--
Stefan Richter
-=====-=-==- --=- -===-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/