Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[Matthew Wilcox <matthew@wil.cx>]

On Sat, Nov 06, 2004 at 12:02:32AM -0000, Richard Waltham wrote:
> Good as a backup but the original PPR capability is defined in
> scan_scsi.c. Shouldn't scan_scsi.c take note of the bus mode and enable
> PPR capabilities accordingly? This would then cover this issue for all
> relevant LLDDs wouldn't it?

scan_scsi.c doesn't know what mode the bus is in.  scan_scsi.c doesn't
even know whether the bus is SPI, FC, iSCSI, SAS or SATA.

> > Thanks, those are interesting.  It's good to see that we 
> > really are spitting PPR out onto the wire when we shouldn't be.
> 
> And from what I've seen is the PPR negotiation keeps on being retied on
> all subsequent commands. So performance really is killed by this.

Yes, we'll do that as long as the device target parameters differ from
the achieved parameters.

> > I think disabling PPR on an SE bus should be a better fix than that.
> 
> And don't forget HVD as well;)   

Yes, I thought about HVD and decided that I wanted to code the check
against LVD rather than against SE ;-)

> My main concern with my patch to scan_scsi.c was to handle SCSI 3 LVD
> devices that caused problems. Scan_scsi.c sets all SCSI 3 devices as PPR
> capable - SE, HVD as well as LVD. I have no issue with explicitly
> disallowing PPR for SE and HVD devices. But what about SCSI 3 and LVD
> devices that don't handle PPR - OK they may be broken but...

I've got some devices that fail PPR when the bus is in SE mode but
work fine when the bus is in LVD mode.  So this patch certainly fixes
those problems.  THe question is whether there exist devices that:

 - Claim to be SCSI3 compliant
 - Fail PPR when on an LVD bus

> There is an issue that needs resolving where a drive appears to indicate
> it is capable of PPR, i.e. says it is SCSI 3 + LVD, but does not
> actually support PPR. Then when it receives at PPR message it causes
> problems in the driver because it terminates the PPR MSG OUT early with
> an unexpected phase change.

I think those devices need blacklisting.  Either that, or we need to do
DV in non-approved ways.  Perhaps start with SDTR+WDTR.  If we get up
to Fast-40, then try PPR.  I suspect James has Opinions on this though ;-)

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain