Gigabyte GA-K8NF-9

Festplattengröße geschrumpft / HPA / Dynamischer Datenträger zerstört

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:

Verwaltungsblöcke dynamischer Datenträger

Links zum Thema "Virtual DualBIOS"

Interessantes aus den englischen Gigabyte-FAQs

SATA-II auf nForce4-4x

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.

nForce4-4x mit SATA-II und SLInForce4-4x mit SATA-II und SLIEs 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

Kein POST, Board tot, PCIe-VGA funktioniert nicht

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.

Performanzprobleme mit SATA

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:

nVidia-Chipsatz-Treiber

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.

IT8712

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.

BIOS 12k

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
------------------+--------------------+--------------------+-------------------

Links


Erstellt 31.08.2009, zuletzt geändert 10.01.2020 14:23:35, Zugriffszähler Besuche. © Christian Enders

Home | Nach oben | Abit BX133-RAID | Asus A7V8X-X | Asus CUSL2 | Asus P2B-S | Asus P2B-DS | Asus P2B-F | Asus P5VD1-X | CT-7AJA0 | EP-8KTA+ | Fujitsu-Siemens D1184 | GA-K8NF-9 | GA-EP35-DS3 | Asus A8N-SLI | GA-8GE667pro | GA-6BXDS | MS-6178 | MS-6183 | MS-6340 | MS-7191 | H110H4-CM2 | MD3001 | AMD CPUs