DMAMask
Raphael Pilarczyk
Welche DMA mask ist fuer die internen SCSI-Hosts von A3000/A4000T
richtig ??
--
PIK
Niels Knoop
> Welche DMA mask ist fuer die internen SCSI-Hosts von A3000/A4000T
> richtig ??
0x7fffffff
--
| Bye! /// Niels Knoop /// e-mail:
ni...@rbg.informatik.tu-darmstadt.de |
--
Eric Wick
Am 21 Nov 98 hast Du All folgendes geschrieben:
RP> Welche DMA mask ist fuer die internen SCSI-Hosts von A3000/A4000T
RP> richtig ??
Die HD-Toolbox setzt beim A3 von sich aus 0x7ffffffc, allerdings lese ich
immer oefters von 0xffffffff was ich hier auch problemlos auf allen
Partitionen benutze.
--
---
B4NOW
Eric
eMail:(eric...@funclub.antar.com)
Raphael Pilarczyk
Thema: "Re: DMAMask"
> > Welche DMA mask ist fuer die internen SCSI-Hosts von A3000/A4000T
> > richtig ??
>
> 0x7fffffff
thx
--
PIK
Olaf Kordwittenborg
> Hi
>
> Welche DMA mask ist fuer die internen SCSI-Hosts von A3000/A4000T
> richtig ??
Ältere A3000 haben Probleme mit bytealigned Zugriffen, also ist dort
0xFFFFFFFC sinvoller, schadet aber auch bei keinem anderen Rechner,
da sowas sehr selten passiert.
Ansonsten gibts Probleme mit alten Filesystemen, die mögen das nicht
und vertragen nur 2GB Angaben also 0x7FFFFFFF...
Da der Amiga soundso nur 2GB Speicher adressieren kann störts nicht.
Mit 0x7FFFFFFC ist man also immer auf der sicheren Seite und
verschenkt nichts...
Olaf
Olaf Kordwittenborg
> Hallo Raphael.
>
> Am 21 Nov 98 hast Du All folgendes geschrieben:
>
> RP> Welche DMA mask ist fuer die internen SCSI-Hosts von A3000/A4000T
> RP> richtig ??
>
> Die HD-Toolbox setzt beim A3 von sich aus 0x7ffffffc, allerdings lese ich
> immer oefters von 0xffffffff was ich hier auch problemlos auf allen
> Partitionen benutze.
IMHO gehört sogar FFS39.x noch dazu.
Das C am Ende ist wegen Fehlern im alten DMAC, ist dort evtl. schneller
und stabiler, aber auf anderen Rechner nicht langsamer...
Olaf
Niels Knoop
[DMA-Mask A3000(T)/A4000(T): 0x7fffffff]
> Das mit der 7 am Anfang kommt daher das alte Filesysteme sonst
> abnippeln :-( IMHO gehört sogar FFS39.x noch dazu.
Es kann laut Commodore-Definition keinen Hauptspeicher oberhalb der
2GB-Grenze geben. Somit kann es ohnehin keinen Sinn haben, das
oberste Bit der DMA-Mask zu setzen.
> Das C am Ende ist wegen Fehlern im alten DMAC, ist dort evtl. schneller
> und stabiler, aber auf anderen Rechner nicht langsamer...
Wenn man das unterste Bit oder die untersten beiden Bits loescht
(0x7ffffffe bzw. 0x7ffffffc), verbietet man DMA-Transfers an ungerade
bzw. nicht an Langwortgrenze liegende Adressen und erzwingt ein
extrem langsames Ausweichprogramm mit Einzelblocktransfer (sehr gut
erkennbar in DiskSpeed). Auch wenn der Hostadapter selbst nicht alle
Faelle direkt beherrscht, ist es immer Sache des SCSI-Treibers,
entsprechende Alternativprogramme zu fahren, die erheblich schneller
sein sollten. Mit einem korrekten Treiber kann man also immer ein "f"
am Ende der Maske einstellen, oder andersherum: Treiber, die mit
dieser Einstellung Probleme machen, sind defekt. A3000(T) und A4000T
mit OS 3.1 sollten an sich keine Probleme haben.
Wie haeufig Transfers mit ungeraden Adressen in der Praxis vorkommen,
ist eine andere Frage (die ich nicht beantworten kann).
Thomas Richter
ni...@rbg.informatik.tu-darmstadt.de (Niels Knoop) writes:
>Olaf Kordwittenborg (OKordwi...@t-online.de) schrieb:
>[DMA-Mask A3000(T)/A4000(T): 0x7fffffff]
>> Das mit der 7 am Anfang kommt daher das alte Filesysteme sonst
>> abnippeln :-( IMHO gehört sogar FFS39.x noch dazu.
>Es kann laut Commodore-Definition keinen Hauptspeicher oberhalb der
>2GB-Grenze geben. Somit kann es ohnehin keinen Sinn haben, das
>oberste Bit der DMA-Mask zu setzen.
Nun, sagen wir so, die Memory-Map besagt, dass hier kein Speicher
liegen sollte, aber mit ein paar Patches ist auch das hinzubekommen,
sollten irgendwann 2GB Hauptspeicher nicht mehr ausreichen.
Sorgenkinder sind AllocEntry(), die Resident-Liste von Exec und die
APTR->BPTR Umwandlung im Dos.
Die ersten beiden verwenden Bit 31 der Addresse als "Flag", das letztere ist
eine vorzeichenbehaftete Umwandlung statt einer Umwandlung ohne Vorzeichen.
Eventuell gibt's noch ein paar mehr dieser Spezies...
Allerdings, nichts was sich IMHO nicht in den Griff bekommen sollte, und
besser ist's schon, die DMA-Maske richtig zu setzen.
Grüße,
Thomas
______________don't_cut_here,_it_could_damage_your_terminal____________________
_______ _____ _____
/ / / / / / / EMAIL: th...@einstein.math.tu-berlin.de
/ /____/ / / /____/ http://www.math.tu-berlin.de/~thor/thor/index.html
/ / / / / / \ PGP available on request, finger print:
/ / / /____/ / / 11 FC 46 B0 7F 42 43 AC 38 A4 78 9A 24 BC 77 BE
_______________________________________________________________________________
Eric Wick
Am 24 Nov 98 hast Du All folgendes geschrieben:
OK> Das mit der 7 am Anfang kommt daher das alte Filesysteme sonst abnippeln
OK> :-( IMHO gehoert sogar FFS39.x noch dazu.
Aha, das Update von PFS2 schrieb naemlich wieder von 0xFFFFFFFF fuer die
Mask.
OK> Das C am Ende ist wegen Fehlern im alten DMAC, ist dort evtl. schneller
OK> und stabiler, aber auf anderen Rechner nicht langsamer...
Ist nicht ein "c" statt "f" eine Beschraenkung des Datentransfers an
irgendwelche Adressen?
f = 1111
c = 1100 ?
Ich werde es mal mit dem 0x7fffffff probieren, sollte es mit dem DMAC von
1989 zu Problemen kommen, setze ich am Ende das "c" wieder ein.
--
---
BYE4NOW
Eric
eMail:(eric...@funclub.antar.com) No binarys please!
Olaf Kordwittenborg
> Olaf Kordwittenborg (OKordwi...@t-online.de) schrieb:
>
> [DMA-Mask A3000(T)/A4000(T): 0x7fffffff]
>
>
> Es kann laut Commodore-Definition keinen Hauptspeicher oberhalb der
> 2GB-Grenze geben. Somit kann es ohnehin keinen Sinn haben, das
> oberste Bit der DMA-Mask zu setzen.
Aber die Probleme das das in alten device Vorzeichenbehaftet interpretiert
wurde umgeht man.
> > Das C am Ende ist wegen Fehlern im alten DMAC, ist dort evtl. schneller
> > und stabiler, aber auf anderen Rechner nicht langsamer...
>
> Wenn man das unterste Bit oder die untersten beiden Bits loescht
> (0x7ffffffe bzw. 0x7ffffffc), verbietet man DMA-Transfers an ungerade
> bzw. nicht an Langwortgrenze liegende Adressen und erzwingt ein
> extrem langsames Ausweichprogramm mit Einzelblocktransfer (sehr gut
> erkennbar in DiskSpeed). Auch wenn der Hostadapter selbst nicht alle
Dann ist das device schrottig, denn mit der Mask 0x7ffffffe kann ein
16Bit DMA Adapter den kompletten Speicher erreichen, nur 1Byte muss evtl.
per CPU kopiert werden wenn irgendein Chaosprogramm auf Bytealigned
Adressen lädt.
> Faelle direkt beherrscht, ist es immer Sache des SCSI-Treibers,
> entsprechende Alternativprogramme zu fahren, die erheblich schneller
> sein sollten. Mit einem korrekten Treiber kann man also immer ein "f"
Richtig, aber die alten waren eben nicht korrekt. Den Fehler im DMAC
haben sie wahrscheinlich umgangen indem sie den DMA 3 * mit 1Byte Länge
angestossen (dauert ewig) und dann auf der Langwordgenze richtig losgelegt
haben. Mit der beschränkten Mask aber werden die 1...3 bytes per PIO
transferiert was deutlich schneller ist dann den DMA angeworfen...
Naja, zumindest ging es sehr viel schneller.
Bei Rechnern mit modernen CPU (040/060) wäre es eigentlich sogar extrem
vorteilhaft die Mask auf 16Byte Grenze zu beschränken. Man könnte damit
einige schwerwiegende Performanceprobleme mit dem CopybackCache umgehen.
> am Ende der Maske einstellen, oder andersherum: Treiber, die mit
> dieser Einstellung Probleme machen, sind defekt. A3000(T) und A4000T
> mit OS 3.1 sollten an sich keine Probleme haben.
Ja, mit OS3.1 umgeht man den Fehler im DMAC.
>
> Wie haeufig Transfers mit ungeraden Adressen in der Praxis vorkommen,
> ist eine andere Frage (die ich nicht beantworten kann).
Wenn der Programmierer nicht gepfuscht hat garnicht, aber...
Olaf
Niels Knoop
> Dann ist das device schrottig, denn mit der Mask 0x7ffffffe kann
> ein 16Bit DMA Adapter den kompletten Speicher erreichen
Nicht unbedingt. Der Hostadapter des A3000(T) mit altem DMAC/RAMSEY
beherrscht DMA anscheinend nur an Langwortadressen. Aber sowas weiss
und beruecksichtig eben das scsi.device; die Maske braucht und sollte
nicht eingeschraenkt werden.
> Mit der beschränkten Mask aber werden die 1...3 bytes per PIO
> transferiert was deutlich schneller ist dann den DMA angeworfen...
> Naja, zumindest ging es sehr viel schneller.
Du irrst. Ein beschraenkter Mask-Wert ist in den betreffenden Faellen
immer langsamer als ein unbeschraenkter. Nur eine unbeschraenkte Maske
gibt dem Device ueberhaupt die Moeglichkeit, ein intelligentes Ausweich-
programm wie PIO oder gepufferten DMA zu fahren. Was hingegen im Mask-
Sieb haengenbleibt, wird unweigerlich schneckenlangsam.
> Bei Rechnern mit modernen CPU (040/060) wäre es eigentlich sogar
> extrem vorteilhaft die Mask auf 16Byte Grenze zu beschränken.
Auf keinen Fall. Es waere wuenschenswert, wenn die Programme ihre
Puffer auf 16-Byte-Grenzen ausrichten wuerden, aber kompletter
Unsinn, Transfers an andere Adressen durch Kastrieren der Mask
zur Schnecke zu machen.
> Man könnte damit einige schwerwiegende Performanceprobleme mit dem
> CopybackCache umgehen.
Schwerwiegende Performanceprobleme beim DMA-Transfer? :-)
Olaf Kordwittenborg
> Hallo Olaf.
>
> Am 24 Nov 98 hast Du All folgendes geschrieben:
>
> OK> Das mit der 7 am Anfang kommt daher das alte Filesysteme sonst abnippeln
> OK> :-( IMHO gehoert sogar FFS39.x noch dazu.
>
> Aha, das Update von PFS2 schrieb naemlich wieder von 0xFFFFFFFF fuer die
> Mask.
>
> OK> Das C am Ende ist wegen Fehlern im alten DMAC, ist dort evtl. schneller
> OK> und stabiler, aber auf anderen Rechner nicht langsamer...
>
> Ist nicht ein "c" statt "f" eine Beschraenkung des Datentransfers an
> irgendwelche Adressen?
32Bit DMA macht kann er die folgenden 3 Byte dennoch erreichen...
> f = 1111
> c = 1100 ?
>
> Ich werde es mal mit dem 0x7fffffff probieren, sollte es mit dem DMAC von
> 1989 zu Problemen kommen, setze ich am Ende das "c" wieder ein.
Mit meinem A3000 unter OS2.0 ging es nicht stabil...
Olaf
Eric Wick
Am 27 Nov 98 hast Du All folgendes geschrieben:
OK> Mit meinem A3000 unter OS2.0 ging es nicht stabil...
Das mag natuerlich sein, das scsi-device des Kick 3.1 (40.12) macht damit
ein gutes Bild. Ich behalte das mal im Auge ob der Zuszand stabil bleibt.
Joern Rink
Also ich habe einen A4000T mit Kick 3.1 (40.70) und einen 060.
Was fuer eine Maske muss ich denn nun setzen?
Default ist 7ffffffffffc , stelle ich nun maxtransfer auf fffffffffe dann
bekomme ich read errors auf meinen
scsi hds.
CU
--
Nine ( not 9 :-)
Never trust a hippie
Niels Knoop
> Also ich habe einen A4000T mit Kick 3.1 (40.70) und einen 060.
> Was fuer eine Maske muss ich denn nun setzen?
> Default ist 7ffffffffffc
Wohl kaum; das sind vier "f" zuviel. Ein sinnvoller Defaultwert
ist 0x7ffffffc, aber beim Hostadapter des A4000T sollte man auch
0x7fffffff verwenden koennen, was Transfers mit krummen Adressen
erheblich beschleunigt, siehe DiskSpeed.
> stelle ich nun maxtransfer auf fffffffffe dann bekomme ich read
> errors auf meinen scsi hds.
MaxTransfer und Mask sind zwei voellig verschiedene Dinge.
Fuer MaxTransfer sollte man keinesfalls Werte hoeher als
0x7fffffff einstellen, weil der Wert vom Filesystem eventuell
als vorzeichenbehaftet betrachtet wird und dann negativ wird.
Einige SCSI-Treiber haben anscheinend Probleme mit Transfers
groesser als 16 MB (24 Bit), so dass man sicherheitshalber
hoechstens 0xffffff eintragen sollte.
P.S. Weiss jemand, wie das Filesystem einen zu grossen Block
dann aufspaltet? Sollte MaxTransfer eine "glatte" Zahl
sein (z.B. 0x800000 oder 0xfffe00), oder spielt das keine
Rolle?