Es
gibt aber auch nForce4-4x-Chips, die von Werk aus mit den SATA-II- und
SLI-Brücken bestückt sind und SATA-II-fähig sind, wie das Bild von einem
GA-K8NF-9 zeigt. Auf dem Die steht bei beiden Varianten NF4-4X-A3.Bei jedem Systemstart werden auf der ersten Festplatte im System die letzten 2113 Blöcke überschrieben sowie die Plattengröße per HPA (resetfest) um diese Menge reduziert. Das ganze erinnert an die "Virtual DualBIOS"-Funktion oder "Xpress BIOS Rescue", auf die bei diesem Board an keiner Stelle der Dokumentation hingewiesen wird. In den englischen FAQs wird das "BIOS Rescue" erwähnt. Allerdings heißt es hier, dass das Xpress Bios Rescue auf allen Boards ist, die nach 03/2004 hergestellt wurden. Für andere Gigabyte-Boards, die mit der VDB-Funktion angeboten werden, gibt es BIOS-Updates, wodurch die Funktion abschaltbar wird.
Der BIOS-Sicherungsvorgang nach einem Start oder Reset läuft vermutlich so ab:
Dieser Vorgang wird bei unpartitionierten und partitionierten Platten durchgeführt, die vorhandenen Daten in den letzten 2113 Sektoren werden überschrieben. Damit wird die Verwaltungsinformation von dynamischen Datenträgern zerstört, da diese u.a. in den letzten Sektoren liegen. Bei Basisdatenträgern sind meist die letzten Sektoren durch die groben CHS-Partitionsgrenzen unbenutzt und es folgt keine Beeinträchtigung. (Partitionsgrenzen liegen im Raster von 16065 Sektoren = 7,84MB, abgeleitet von den CHS-Grenzen: 63 Köpfe*255 Zylinder=16065 Sektoren)
Probleme gibt es weiterhin mit Platten ab 1TB. Hier ist scheinbar ein Bug im BIOS, der ab einer bestimmten Plattengröße zum Vorschein tritt. Bei 1TB-Platten werden nur 65134 Sektoren im HPA aktiviert, das entspricht ca. 32MB. Er tritt aber wie beschrieben nur auf, wenn die 1TB-Platte die erste im System ist. Daten gehen solange nicht verloren, es sei denn, es wird ein Reparaturversuch mit z.B. CHKDSK ausgeführt. Durch geeignete Methoden muss nur das HPA wieder deaktiviert werden.
Die Einstellungen werden im HPA dauerhaft gespeichert. Eine Änderung kann erst nach einem Reset durchgeführt werden (z.B. mit HDAT2). Da das BIOS nach einem Reset den SET_MAX_ADDRESS ausführt, darf die Platte erst nach der Drive-Detection des BIOS' angeschlossen werden. HDAT2 kann nachträglich angeschlossene Platten erkennen. Es ist mit HDAT2 auch möglich die HPA mit Passwort zu schützen oder den SET_MAX_FREEZE_LOCK zu setzen - dann kann das BIOS die Einstellungen (bis zu nächsten Power-Cycle) nicht ändern.
Durch Drücken von F9 beim POST (zum Aufruf von Xpress-Recovery2) verläuft der Boot etwas anders. Es wird die Platte auf ihre native Größe gesetzt, das BIOS wird geschrieben und danach aber kein SET_MAX_ADDRESS ausgeführt, um die 2113 Blöcke zu verstecken. Für diesen einen Boot lang ist die Festplatte also freigegeben (auch wenn die Xpress-Recovery-Software nicht installiert ist). D.h. es ist damit möglich, "geschrumpfte" Platten wieder in ihren ursprünglichen Zustand zurückzusetzen, ohne spezielle Software anwenden zu müssen. Die betroffene Festplatte muss dazu als erste Festplatte in der BIOS-Reihenfolge sein. Die Boot-Reihenfolge ist unerheblich.
Anmerkung: Nach dem Druck von F9 beim POST erscheint vor dem Booten eine Meldung, dass Xpress-Recovery von der CD installiert werden muss, wenn auf der ersten Platte im System bereits einmal zuvor die 2113 Sektoren überschrieben worden waren. Ansonsten erscheint keine Meldung des Xpress-Recovery.
Beispiel: Eine WD10EACS besitzt 1.953.525.168 Blöcke. Da die Partitionsenden (aus historischen Gründen, CHS) auf Vielfache von 255*63 Blöcke (7,844MB) gelegt werden, sind i.d.R. einige der letzten Blöcke der Platte unbenutzt (WD10EACS: 5166 Blöcke) und können ohne Auswirkung durch das HPA ausgeblendet werden. Durch den BIOS-Bug wird jedoch die Festplatte auf ca. 32MB (65134 Blöcke) reduziert.
Sollen angeschlossene Festplatten vor dem Überschreiben geschützt werden, könnte eine Abhilfe darin bestehen, dafür zu sorgen, dass die erste Festplatte im System für das VDB benutzt werden kann. Beispielsweise durch Anschluss eines SSD am Primary-IDE-Master, welche dann z.B. als Laufwerk für die Auslagerungsdatei dienen kann.
Um die Funktion aus dem BIOS zu entfernen müsste man wohl die awardext.rom diassemblieren und den entsprechenden Teil überspringen...
Beispiel: Eine IC25N030ATMR04-0 hat 58.605.120 Blöcke. Auf der ersten Spur (Blöcke 0..62) liegt der MBR. Danach kann die erste Partition folgen. Die größtmögliche Partition muss auf einer 255*63-Block-Grenze enden, was bei dieser Platte auf den letzten Block zutrifft. Das resultierende Layout sieht dann so aus:
Ich habe nach den Anleitungen im Netz die zwei Brücken geschlossen. SATA-II-Platten werden nun als 3.0G-Platten erkannt. Meine Messungen mit Everest zum gepufferten Datendurchsatz hingen stark von der verwendeten Blockgröße ab - je größer desto schneller. Mit 64k-Blöcken wurden ca. 120MB/s erreicht, mit 1MB-Blöcken 200MB/s.
Beim Vergleich der Brücken von nForce4-4x und nForce4-Ultra ist mir aufgefallen, dass der nForce4-4x rechts unten noch eine Brücke geschlossen hat, die beim nForce4-Ultra offen ist.
Es
gibt aber auch nForce4-4x-Chips, die von Werk aus mit den SATA-II- und
SLI-Brücken bestückt sind und SATA-II-fähig sind, wie das Bild von einem
GA-K8NF-9 zeigt. Auf dem Die steht bei beiden Varianten NF4-4X-A3.
| Lot-Nr. | S/N | SATA-II-Brücken | Übertragungstest |
| 508261 | 07630 | - | 120MB/s, mit Brücke SATA-II |
| 509080 | 06208 | x | |
| 509080 | 06170 | x | |
| 509080 | 06318 | 120MB/s |
Ich habe zwei GA-K8NF-9 Boards, eins davon brachte nicht mal den POST, das andere arbeitet nur mit einer PCI-Grafikkarte, mit einer PCIe-Karte kommt es nicht zum POST. Grund waren kalte Lötstellen am nForce-Chip. Mit einem Gaslötkolben habe ich die Platinenunterseite unter dem nForce-Chip vorsichtig erhitzt (ca. 1 Minute) bis sich die Platine etwas färbte, was für mich ein Zeichen zum Aufhören war. Danach liefen beide Boards wieder, jedoch nach einem Stresstest traten wieder Fehler auf. Den Kühlkörper habe ich draufgelassen damit a) der Die nicht zu heiß wird und b) der Chip gleichmäßig auf das Board gepresst wird und so das Nachlöten unterstützt. Es kann davon ausgegangen werden, dass der Fehler an aufgebrochenen Lötungen am nForce-Chip liegt, eine Reparatur ist Glückssache.
Mit den nVidia-IDE-Treibern scheint es Probleme zu geben, die sich bei mir durch stark schwankende Übertragungsraten äußerten, insbesondere in RAID-Konfigurationen. Die Vermutung liegt nahe, dass die Probleme erst beim gleichzeitigen Zugriff auf mehrere Platten auftreten. Jede Platte einzeln hat keine Probleme gezeigt. Ich habe der Einfachheit halber verschiedene Soft-RAID-Konfigurationen gemessen. Die Probleme traten ursprünglich am nVidia-Hardware-RAID auf.
Versuch 1:
| XP-Treiber Lesen/Schreiben |
IDE-SW-5.52 Lesen/Schreiben |
HardRAID v5.52 |
IDE-SW-6.66 Lesen/Schreiben |
IDE-SW-10.3.0.42 Lesen/Schreiben |
HardRAID v10.3.0.42 |
|
| einfach | 32 / 29 | 31 / 30 | 31 / 30 | 32 / 27 | ||
| gepuffert 256kB | 112 / | 116 / | 364 / 304 | 113 / | 102 / | 178 / |
| gepuffert 512kB | 64..115 / | 116 / | 400 / 309 | 111 / | 178 / | |
| gepuffert 1MB | 23..111 / | 111 / | 377 / 310 | 10 / | 23 / | 178 / |
| Stripe 2 Platten | 61 / 48 | 62 / 48 | 61 / 50 | 10..16..26..55..61 / 51..58 | 62 / 49 | 62 / 45 |
| Stripe 3 Platten | 89 / 67 | 89 / 66 | 89 / 68 | 11..90 / 68 | 80..92 / 55..68 | 84..92 / 56..61 |
| Stripe 4 Platten | 117 / 76 | 115 / 75 | 117 / 80 | 13..20..47..58..113 / 80 | 117 / 76 | 107 / 67 |
| Mirror 2 Platten | 31 / 28 | 32 / 28 | 32 / 28 | 31 / 30 | 32 / 28 | 32 / 27 |
| Raid5 3 Platten | 61 / 21 | 61 / 21 | 60 / 19 | 56..60 / 21 | 56..60 / 21 | 53 / 14 |
| Raid5 4 Platten | 88 / 26 | 86 / 26 | 83 / 26 | 35..46..75..85 / 26 | 71..91 / 26 | 67..76 / 20 |
Versuch 2:
| XP-Treiber Lesen/Schreiben |
IDE-SW-5.52 Lesen/Schreiben |
HardRAID v5.52 |
|
| einfach | 70 / 70 | ||
| gepuffert 256kB | 172 | 327 / | |
| gepuffert 512kB | 174 | 414 / | |
| gepuffert 1MB | 174 | 447 / | |
| Stripe 2 Platten | 132 / 140 | 129 / 135 | |
| Stripe 3 Platten | 186..192 / 212 | 194 / 204 | |
| Mirror 2 Platten | 67 / 69 | 66 / 69 | |
| Raid5 3 Platten | 117 / 36 | 100 / 34 |
Versuch 3:
| Lesen | Schreiben | |
| Stripe 1+2 | 137 | 140 |
| Stripe 1+3 | 140 | 140 |
| Stripe 2+3 | 137 | 143 |
| Stripe 1+2+3 | 192 | 67 |
Versuch 6:
Gigabyte und nVidia bieten für das GA-K8NF-9 mit WinXP verschiedene Treiber an:
| Quelle | Version | Ethernet | Network Tool | SMBus | SATA IDE | PATA RAID | SATA RAID | RAID Tool |
|---|---|---|---|---|---|---|---|---|
| Gigabyte | v6.66 | 4.82 | 4.88 | 4.45 | 5.34 | 5.34 | 5.34 | 4.82 |
| Gigabyte | v6.85 | 50.11 | 50.11 | 4.50 | 5.52 | 5.52 | 5.52 | 5.52 |
| nVidia | v6.86 | 50.25 | 50.19 | 4.57 | 6.66 | 6.66 | 6.66 | 6.63 |
| nVidia | v15.23 | 67.89 | 67.93 Sedona | 4.69 | 10.3.0.42 | 10.3.0.42 | 10.3.0.42 | |
Mit den v15.23-Treibern wird der Windows-Logon durch den Ethernet-Treiber stark verzögert. Interessant ist die Möglichkeit nVidia-RAIDs zu konvertieren (Stripe<->RAID5 usw.) und die SMART-Überwachung.
In der Application Note von ITE (ITTM-AN-03001, 17-Feb-2003) wird Herstellern eine Designänderung empfohlen: die Pull-Up-Widerstände der Leitungen KRST# und GA20 zwischen ITE8712 und nForce-SB zu VCC3.3 sollen statt 8,2k nun 1k betragen.
Erweiterte Funktionen durch Drücken von Ctrl-F1 im BIOS-Menu.
Inhalt laut CBROM606:
CBROM V6.06 (C)Award Software 1999 All Rights Reserved.
******** k8nf-9.12k BIOS component ********
No. Item-Name Original-Size Compressed-Size Original-File-Name
================================================================================
0. System BIOS 20000h(128.00K)1454Eh(81.33K)tt.BIN
1. XGROUP CODE 0F370h(60.86K)0A887h(42.13K)awardext.rom
2. ACPI table 04CE5h(19.22K)01AEBh(6.73K)ACPITBL.BIN
3. EPA pattern 0168Ch(5.64K)002AAh(0.67K)AwardBmp.bmp
4. Other(403B:0000) 01420h(5.03K)00F68h(3.85K)ggroup.bin
5. YGROUP ROM 07510h(29.27K)04CCEh(19.20K)awardeyt.rom
6. Other(4029:0000) 06E00h(27.50K)02D0Dh(11.26K)_EN_CODE.BIN
7. OEM2 CODE 0BDA0h(47.41K)00642h(1.56K)BSMICODE.ROM
8. PCI driver[A] 0C000h(48.00K)06FFDh(28.00K)NVRAID.ROM
9. PCI driver[B] 0E800h(58.00K)07706h(29.76K)NVPXES.NIC
10. PCI driver[C] 0F000h(60.00K)074FFh(29.25K)5403.BIN
11. PCI driver[D] 0DE00h(55.50K)08768h(33.85K)yukpxe.lom
12. OEM0 CODE 0289Bh(10.15K)01E19h(7.52K)SBF.BIN
13. Other(4067:0000) 028BEh(10.19K)00BFEh(3.00K)AGESACPU.ROM
Total compress code space = 5B000h(364.00K)
Total compressed code size = 4A870h(298.11K)
Remain compress code space = 10790h(65.89K)
** Micro Code Information **
Update ID CPUID | Update ID CPUID | Update ID CPUID | Update ID CPUID
------------------+--------------------+--------------------+-------------------