SCSI: Parity und Disconnect gekoppelt?

[K. Martinen]

Hallo

in einem Manual eines Tekram DC-310 SCSI Controllers las ich etwas das mir neu
ist. Dort stand sinngemäß:

"Wenn man Parity deaktiviert dann muß auch Disconnect deaktiviert werden."

Erklärt wurde das damit das in der Reselect-Phase Parity nach wie vor benutzt
würde. Sollte dann also ein Gerät Disconnecten würde diese Phase nie beendet
werden können.

Mir ist das mit dieser Erklärung neu. Kann es sein das z.b. der Adaptec 2940(U)
oder andere Controller MIT eigenem BIOS (dieser Tekram soll keins haben) das
automatisch machen? Eventuell ist mir das darum nur nie aufgefallen.

Oder ist es möglich daß das oben zitierte nur für diesen Tekram-Controller gilt?
Oder für den Chipsatz der ein Symbios 53C810 ist.

Abgesehen davon halte ich es eh für eine schlechte Idee Parity und Disconnect zu
deaktivieren. Jedenfalls nicht wenn es nicht nötig ist.

Kann dazu eventuell jemand etwas konkretes sagen?

Gruß
Kay

[Michael Baeuerle]

Post by K. Martinen
in einem Manual eines Tekram DC-310 SCSI Controllers las ich etwas das mir neu
"Wenn man Parity deaktiviert dann muß auch Disconnect deaktiviert werden."

Dafuer gibt es prinzipiell keinen Grund. Die Frage ist auch was mit
"Parity" gemeint ist: Die Erzeugung von Parity, die Pruefung von Parity
oder beides.

Post by K. Martinen
Erklärt wurde das damit das in der Reselect-Phase Parity nach wie vor benutzt
würde. Sollte dann also ein Gerät Disconnecten würde diese Phase nie beendet
werden können.

Das ist Unfug. Erstens wird Parity erst _ab_der_ Reselection-Phase
benutzt und nicht "nach wie vor" und zweitens wird in einer
Reselection-Phase die Parity von dem Target erzeugt das die Reselection
durchfuehrt. Wenn der Tekram jetzt Parity ignoriert, funktioniert die
Reselection natuerlich trotzdem (kriegt das Target ja gar nicht mit).
Wenn der Tekram gar nicht antworten wuerde, wuerde die Reselection-Phase
ganz regulaer nach einer "Selection Abort Time" vom Target beendet das
zu diesem Zeitpunkt den Bus kontrolliert.

Auch das "disconnecten" selbst wuerde funktionieren. Dazu schickt das
Target zuerst eine DISCONNECT-Message mit gueltiger Parity und gibt
danach regulaer den Bus frei wenn der Tekram nicht ATN anlegt um zu
zeigen, dass er antworten moechte (was er nicht tun wuerde wenn er
lediglich Parity ignoriert, die Message aber akzeptiert).

Post by K. Martinen
Mir ist das mit dieser Erklärung neu. Kann es sein das z.b. der Adaptec 2940(U)
oder andere Controller MIT eigenem BIOS (dieser Tekram soll keins haben) das
automatisch machen? Eventuell ist mir das darum nur nie aufgefallen.

Das potentielle Problem hat mit dem BIOS nichts zu tun.

Post by K. Martinen
Oder ist es möglich daß das oben zitierte nur für diesen Tekram-Controller gilt?
Oder für den Chipsatz der ein Symbios 53C810 ist.

Das ist natuerlich moeglich aber technisch nicht erforderlich.

Post by K. Martinen
Abgesehen davon halte ich es eh für eine schlechte Idee Parity und Disconnect zu
deaktivieren. Jedenfalls nicht wenn es nicht nötig ist.

In der Tat, Parity ist seit geraumer Zeit Pflicht. Es muss also keinen
"Parity disable"-Jumper geben, man muss Parity aber an _allen_ Geraeten
auf dem Bus deaktivieren wenn man ganz ohne arbeiten will (weil die
Pruefung sonst natuerlich immer fehlschlagen wuerde).

Das alles hat mit Disconnect aber nichts zu tun: Schaltest du Parity am
Tekram komplett ab und laesst es am Target an, dann funktioniert mit
oder ohne Disconnect gar nichts. Andersrum kannst du problemlos
Disconnect benutzen wenn Parity ueberall aus ist.


Micha

[Richard W. Könning]

Post by Michael Baeuerle
Das alles hat mit Disconnect aber nichts zu tun: Schaltest du Parity am
Tekram komplett ab und laesst es am Target an, dann funktioniert mit
oder ohne Disconnect gar nichts. Andersrum kannst du problemlos
Disconnect benutzen wenn Parity ueberall aus ist.

http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/efi/87x_10000/lsi87xhelp.txt
sagt:

|SCSI Parity
|
| Specifies whether SCSI parity is enabled or disabled for an adapter.
| When disabled, it is also necessary to disable disconnects for all
| devices, as parity checking for the reselection phase is NOT disabled.
| If a non-parity generating device disconnects, its operation will never
| complete because the reselection fails due to parity error.
|
| Default value for this field is Yes.

Eine Begründung, warum der Parity-Check nach der Reselection nicht
auch dekativiert wird, habe ich nicht gefunden. Im Zweifelsfall ist
das also eine merkwürdige Entscheidung irgendeines
NCR/Symbios/LSI-Entwicklers.
Ciao,
Richard

[Michael Baeuerle]

Post by Richard W. Könning

Post by Michael Baeuerle
Das alles hat mit Disconnect aber nichts zu tun: Schaltest du Parity am
Tekram komplett ab und laesst es am Target an, dann funktioniert mit
oder ohne Disconnect gar nichts. Andersrum kannst du problemlos
Disconnect benutzen wenn Parity ueberall aus ist.

http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/efi/87x_10000/lsi87xhelp.txt
|SCSI Parity
|
| Specifies whether SCSI parity is enabled or disabled for an adapter.
| When disabled, it is also necessary to disable disconnects for all
| devices, as parity checking for the reselection phase is NOT disabled.
| If a non-parity generating device disconnects, its operation will never
| complete because the reselection fails due to parity error.
|
| Default value for this field is Yes.
Eine Begründung, warum der Parity-Check nach der Reselection nicht
auch dekativiert wird, habe ich nicht gefunden. Im Zweifelsfall ist
das also eine merkwürdige Entscheidung irgendeines
NCR/Symbios/LSI-Entwicklers.

Das war sicher keine Absicht, ist IMHO ein Errata im Chip. Parity ist
also schlicht nicht wirklich aus nachdem man sie abgeschaltet hat und
das Verhindern von Disconnects ist der Workaround fuer dieses Problem.

Danke für den Hinweis.


Micha

[K. Martinen]

Post by Michael Baeuerle

Post by Richard W. Könning
das also eine merkwürdige Entscheidung irgendeines
NCR/Symbios/LSI-Entwicklers.

Das war sicher keine Absicht, ist IMHO ein Errata im Chip. Parity ist
also schlicht nicht wirklich aus nachdem man sie abgeschaltet hat und
das Verhindern von Disconnects ist der Workaround fuer dieses Problem.

Wenn sich jemand überzeugen möchte, das Manual liegt mir vor. Mehrsprachig,
Wobei die deutsche Übersetzung auch auf "Kugellager" passen könnte, so
radebrechend ist die. Aber falls jemand die Landessprache des Herstellers
beherrscht sende ich ihm gern die entsprechenden Auszüge als Scan. Vielleicht
erhellt das die Sache ja schlußendlich.

Ich hab nach lesen der Deutschen Un-Übersetzung, den englischen Text bevorzugt.
Daher kommt auch meine Original frage. Denn ich hab noch einen anderen
Controller der m.w. den gleichen Symbios-Chip hat. Und ich kann mich erinnern
das es bei dem mit ein paar Laufwerken mal problematische Sachen gab. Näher weiß
ich das aber nicht mehr.

Post by Michael Baeuerle
Danke für den Hinweis.

Bin zwar nicht sicher ob ich damit gemeint war, dennoch danke. :-)

Gruß
Kay

[Michael Baeuerle]

Post by K. Martinen

Post by Michael Baeuerle
Das war sicher keine Absicht, ist IMHO ein Errata im Chip. Parity ist
also schlicht nicht wirklich aus nachdem man sie abgeschaltet hat und
das Verhindern von Disconnects ist der Workaround fuer dieses Problem.

Wenn sich jemand überzeugen möchte, das Manual liegt mir vor. Mehrsprachig,
Wobei die deutsche Übersetzung auch auf "Kugellager" passen könnte, so
radebrechend ist die. Aber falls jemand die Landessprache des Herstellers
beherrscht sende ich ihm gern die entsprechenden Auszüge als Scan. Vielleicht
erhellt das die Sache ja schlußendlich.
Ich hab nach lesen der Deutschen Un-Übersetzung, den englischen Text bevorzugt.
Daher kommt auch meine Original frage. Denn ich hab noch einen anderen
Controller der m.w. den gleichen Symbios-Chip hat. Und ich kann mich erinnern
das es bei dem mit ein paar Laufwerken mal problematische Sachen gab. Näher weiß
ich das aber nicht mehr.

Post by Michael Baeuerle
Danke für den Hinweis.

Bin zwar nicht sicher ob ich damit gemeint war, dennoch danke. :-)

Ich hatte Richard gemeint, aber dein Manual-Auszug (in Englisch
natuerlich) wuerde mich auch interessieren. Wegen ISDN darf das Mail
allerdings nicht groesser als 2.5MByte sein, wird vmtl. schwierig werden
die Sache so weit zu komprimieren.


Micha

[K. Martinen]

Post by Michael Baeuerle
aber dein Manual-Auszug (in Englisch
natuerlich) wuerde mich auch interessieren. Wegen ISDN darf das Mail

You have mail!

Oh, Sorry, natürlich, die Seite auf Englisch. Ja klar. :-)

Gruß
Kay

[Richard W. Könning]

Post by Michael Baeuerle

Post by Richard W. Könning
http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/efi/87x_10000/lsi87xhelp.txt
|SCSI Parity
|
| Specifies whether SCSI parity is enabled or disabled for an adapter.
| When disabled, it is also necessary to disable disconnects for all
| devices, as parity checking for the reselection phase is NOT disabled.
| If a non-parity generating device disconnects, its operation will never
| complete because the reselection fails due to parity error.
|
| Default value for this field is Yes.
Eine Begründung, warum der Parity-Check nach der Reselection nicht
auch dekativiert wird, habe ich nicht gefunden. Im Zweifelsfall ist
das also eine merkwürdige Entscheidung irgendeines
NCR/Symbios/LSI-Entwicklers.

Das war sicher keine Absicht, ist IMHO ein Errata im Chip. Parity ist
also schlicht nicht wirklich aus nachdem man sie abgeschaltet hat und
das Verhindern von Disconnects ist der Workaround fuer dieses Problem.

Die Lektüre von http://www.t10.org/ftp/x3t9.2/document.93/93-089r0.pdf
legt den Verdacht nahe, daß evtl. doch Absicht in Form Standard-treuer
Implementierung vorhanden war.
Ciao,
Richard

[Michael Baeuerle]

Post by Richard W. Könning

Post by Michael Baeuerle

Post by Richard W. Könning
Eine Begründung, warum der Parity-Check nach der Reselection nicht
auch dekativiert wird, habe ich nicht gefunden. Im Zweifelsfall ist
das also eine merkwürdige Entscheidung irgendeines
NCR/Symbios/LSI-Entwicklers.

Das war sicher keine Absicht, ist IMHO ein Errata im Chip. Parity ist
also schlicht nicht wirklich aus nachdem man sie abgeschaltet hat und
das Verhindern von Disconnects ist der Workaround fuer dieses Problem.

Die Lektüre von http://www.t10.org/ftp/x3t9.2/document.93/93-089r0.pdf
legt den Verdacht nahe, daß evtl. doch Absicht in Form Standard-treuer
Implementierung vorhanden war.

Sehe ich nicht so. SCSI2 schreibt vor, dass man Parity pruefen und
erzeugen muss. Egal ob man sich nun an die Regeln aus dem Adaptec-Paper
haelt oder nicht, das Problem mit SCSI1-Targets die kein Parity erzeugen
koennen hat man im SCSI2-konformen Modus immer - spaetestens bei den
INQUIRY-Daten die man wegen falscher Parity nicht empfangen kann.

Schaltet man jetzt Parity ab, will man damit doch also explizit
SCSI1-Kompatibilitaet in einer Weise erwingen die nicht SCSI2-konform
sein kann! In SCSI1 war Parity optional, d.h. man muss damit rechnen,
dass von SCSI1-Targets ggf. keine erzeugt werden kann und sie daher
_ueberall_ ignorieren. Das was der NCR mit abgeschalteter Parity tut ist
ja auch trotzdem nicht SCSI2-konform, deswegen kann das doch IMHO keine
Absicht gewesen sein.


Micha

[Marcel Müller]

Hallo,

Post by K. Martinen
"Wenn man Parity deaktiviert dann muß auch Disconnect deaktiviert werden."
Erklärt wurde das damit das in der Reselect-Phase Parity nach wie vor
benutzt würde. Sollte dann also ein Gerät Disconnecten würde diese Phase
nie beendet werden können.

das hört sich eher nach einer Einschränkung des verbauten
Controller-Chips an.

Post by K. Martinen
Oder ist es möglich daß das oben zitierte nur für diesen
Tekram-Controller gilt? Oder für den Chipsatz der ein Symbios 53C810 ist.

Vermutlich. Ziemlich altes Ding. Ist glaube ich ursprünglich von NCR.

Post by K. Martinen
Abgesehen davon halte ich es eh für eine schlechte Idee Parity und
Disconnect zu deaktivieren. Jedenfalls nicht wenn es nicht nötig ist.

Mir ist in den letzten 25 Jahren /nicht ein einziger/ Grund
untergekommen, der für die Deaktivierung eines der Features gesprochen
hätte. Ein SCSI-Device, was kein Parity erzeugen kann, habe ich noch nie
gesehen. Und Disconnect ist sowieso optional. Wenn man einen ollen
Scanner anschließt, der das nicht kann, dann wird es für diesen eben
nicht verwendet.


Marcel