Re: SCSI Controllers

From: J Wunsch <j(at)uriah.heep.sax.de>
Date: Thu, 28 Oct 1999 03:49:26 +0200

(Jaja, ist schon ein Weilchen her, aber ich war zwischendrin zur
FreeBSDCon.)

As Harold Gutch wrote:

SymBios-Logic Controller & BIOS:

> > Das BIOS ist nur vonnöten, wenn von solchen Controllern gebootet
> > werden soll.

> Hat das was mit dieser "BIOS-Translation" oder so zu tun ?

Nein.

> Ich habe irgendwie im Hinterkopf, dass man Platten, die am
> Controller eines Herstellers formatiert (was auch immer genau damit
> gemeint sein mag) wurden, nur an Controllern dieses einen
> Herstellers betreiben kann.

Verschiedene SCSI-Controller benutzen gelegentlich verschiedene
Translations. Adaptec allein kennt zwei verschiedene, während einer
Übergangszeit konnte man sich für eine von beiden entscheiden
("DOS-Mode > 1 GB" oder so hieß das).

Das BIOS der SymBios-Controller versucht in aller Regel
herauszufinden, wie die fdisk-Tabelle aufgebaut ist, und sich dieser
Translation anzuschließen. Wurde die fdisk-Tabelle also mit einer der
beiden Adaptec-Varianten erzeugt, sollte sie hinterher auch von
SymBios benutzt werden können. Adaptecs haben aber eine starre
Vorstellung und können daher mit der von SymBios-BIOSen (:-) auf einer
jungfräulichen Platte angelegten fdisk-Tabelle wohl nicht arbeiten.

Das ganze Problem liegt im krankhaften Design der fdisk-Tabelle
begründet. Anfang und Ende einer fdisk-Partition sind in den dort
enthaltenen Angaben überspezifiziert. Sie werden einerseits angegeben
als Beginn und Länge in 512-Byte Sektoren als 32-Bit-Zahlen. Diese
Angabe wird von praktisch allen heutigen Betriebssystemen benutzt (bei
alten MS-DOSen bin ich mir hier nicht sicher), um herauszufinden, wo
die Grenzen der Partition sind. (Die adressierbare Grenze dieser
Angaben liegt bei 2 TB, wenn ich richtig gerechnet habe.)

Da man in den 512 Byte (minus 64 für die fdisk-Tabelle selbst minus 2
für die `magic number') des master boot record aber nicht diese
32-Bit-Zahlen umrechnen wollte in die kranken Aufrufparameter des
BIOS, die in Zylindern, Köpfen und Sektoren denken und dies dann alles
in einem einzelnen 16-Bit-Register übergeben bekommen, wird parallel
dazu der erste und der letzte Sektor eine Partition zusätzlich als
`vorkompilierter' Wert für ebendieses 16-Bit-Register für den Aufruf
des (BIOS-)Interrupt 0x13 mit abgelegt. Diese Angabe wird vom MBR
dann selbst benutzt, um sich mit dem Bootsektor der eigentlichen
Partition zu überlagern, die gebootet werden soll. Die einzige
Überprüfung, die noch vorgenommen wird ist, ob dieser geladene Sektor
ebenfalls in der `magic number' (0x55aa) endet. Tut er dies nicht, so
gibt's das beliebte "missing operating system".

Stimmt nun die Translation des benutzten BIOS nicht mit der überein,
die die fdisk-Tabelle geschrieben hat, so wird statt des Bootblocks
der aktiven Partition `random garbage' gelesen.

Sofern das BIOS nicht schlauer als der Operator der Maschine sein will
und der Meinung ist, daß es eigene constraint checks durchführen
müßte, kann man natürlich die in der 16-Bit-Zahl verscrambelten
CHS-Werte an die Realität anpassen, wenn man die Platte woanders
betreibt. Problem ist, daß dann die Partition nach steinzeitlicher
Meinung des BIOS in aller Regel nicht mehr auf einer Spurgrenze
beginnt. FreeBSD hat damit allerdings kein Problem, andere Systeme
könnten sich jedoch weigern.

FreeBSD's "dangerously dedicated mode" umgeht das Problem, indem MBR
und Bootblock des Betriebssystems ineinander fallen auf den
allerersten Block der Platte, der natürlich unabhängig von jeder
Translation stets als C=0, H=0, S=1 angesprochen werden kann. (Die
weitere Bedingung, daß dies funktioniert ist, daß es mindestens 15
Sektoren pro fiktiver Spur gibt, da die nachfolgenden weiteren 14
Sektoren nur duch Hochzählen der Sektornummer sofort nachgeladen
werden.) Damit ist eine solche Platte beliebig zwischen verschiedenen
Translations portabel.

-- 
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-chat" in the body of the message
Received on Thu 28 Oct 1999 - 03:51:37 CEST

search this site