SCSI: Parity und Disconnect gekoppelt?

22/10/2009 - 05:34 von K. Martinen | Report spam
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
 

Lesen sie die antworten

#1 Michael Baeuerle
22/10/2009 - 11:05 | Warnen spam
"K. Martinen" wrote:

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."



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.

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).

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.

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.

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

Ähnliche fragen