Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Ich hab mir mal die Speicheradressen angeschaut, die im BSOD auftauchen (BlueScreenView) und mit dem Gerätemanager abgeglichen. Laut den Adressangaben lesen und schreiben die rot hinterlegten Prozesse ausschliesslich im PCI-Bus herum. (0x80000000-0xFEBFFFFF)
ati2mtag.sys in 0xBFD30000
hal.dll in 0x80062000
ntoskrnl.exe in 0x80400000
Das Adressen der Treiber/des Kernels sind virtuelle Adressen. Der Adressbereich auf dem PCI Bus sind physische Adressen. Diaraus lässt sich leider nicht auf das Problem schließen. Im Prozessor sorgt die MMU per Paging für die Umrechnung, auf dem AGP Bus der GART.
Ich tippe auf ein schlechtes Chipsatz+BIOS Design. Im Linux Kernel gibt es auch einen Workaround für nicht-standardkonformes sortieren der Pakete / Ansprechen der Geräte auf den PCI Bussen (AGP ist auch nur ein PCI+).
Kommentar aus dem Linux Kernel
* Following the PCI ordering rules is optional on the AMD762. I'm not sure
* what the designers were smoking but let's not inhale...
*
* To be fair to AMD, it follows the spec by default, it's BIOS people who
* turn it off!
Danke fürs raussuchen. Ein Tyan MPX hatte ich mal liegen, da haben aber wie dem im Thread meine Wasserkühler nicht gepasst. Deswegen kams wieder weg.
Zu den Kommentaren aus dem Linuk-Kernel: Geht es speziell ums Gigabyte-Board oder allgemein um den 762er? Um welche Einstellung geht es genau? Evtl. wär es ja möglich, vor dem Start von Windows die Register entsprechend zu manipulieren, denn eine PCI-Karte in den PCI-X-Slot mag ich nur als allerletztes in Betracht ziehen, weil das sonst den SCSI-Controller bremst.
^ Das scheint der entsprechende Faden auf der MAilingliste dazu zu sein. Sieht für mich so aus, das AMD wohl zwei Modi vorgesehen hat und die Jungs bei Gigabyte den nicht 100% PCI Spec konformen nutzen. Sprich sollte ein Problem vom Board (bzw. Einstellung im Bios) sein und nicht generell eins vom Chipsatz. Das heisst im Umkehrschluss aber auch, das man das Ändern können sollte. Bei den Nforce 2 Biosen laden wir ja auch Code in Form eines OptionROM nach, der PCI Register manipuliert. Sprich wenn das Gigabyte auch ohne den Fix bootet, dann kann man das während des Bootens ändern, sofern die PCI Register schreibbar sind und sich während die Kiste läuft ändern lassen.
Der Linux Fix sieht so aus:
C++:
DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_cardbus_legacy);
DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_ANY_ID, PCI_ANY_ID, quirk_cardbus_legacy);
/*
* Following the PCI ordering rules is optional on the AMD762. I'm not
* sure what the designers were smoking but let's not inhale...
*
* To be fair to AMD, it follows the spec by default, its BIOS people
* who turn it off!
*/
static void quirk_amd_ordering(struct pci_dev *dev)
{
u32 pcic;
pci_read_config_dword(dev, 0x4C, &pcic);
if ((pcic&6)!=6) {
pcic |= 6;
dev_warn(&dev->dev, "BIOS failed to enable PCI standards compliance; fixing this error\n");
pci_write_config_dword(dev, 0x4C, pcic);
pci_read_config_dword(dev, 0x84, &pcic);
pcic |= (1<<23); /* Required in this mode */
pci_write_config_dword(dev, 0x84, pcic);
}
}
Es scheint so, dass B0:D0:F0:4Ch und B0:D0:F0:84h eingelesen werden, das sind 32bit PCI Konfigurationsregister. In 4Ch setzt man dann Bit 1 und Bit 2 (siehe Screenshot aus dem Datasheet im Spoiler). Dabei ist Bit 1 "Ordering Rules Compliance" und Bit 2 "Delayed Transactions". Und in 84h muss Bit 3 "Target latency timer disable" auf 0 gesetzt sein um Bit 23 "Tgt_Latency" auf 1 stellen zu können.
Was du nun machen kannst @bschicht86: Les doch mal testweise mit RWEverything oder WPCREdit die PCI Register von B0:D0:F0 aus. Man sollte eigentlich sehen wie die gesetzt sind bzw. wir sollten sehen das die nicht so gesetzt sind wie im Linux Patch angedacht.
B0:D0:F0:4Ch müsste also für Bit 1 und Bit 2 (von 32 insgesamt) auf 0 gesetzt werden, deshalb nutzen die im Patch |= 6, was bitweises ODER bedeutet. Und 6 ist binär 110, sprich Bit 1 und 2 werden so auf 0 gezogen. B0:D0:F0:84h müsste für Bit 23 auf 1, dafür muss bit 3 auf 0 sein. Das sollte beides mittels Optionrom machbar sein.
EDIT:
Also das Board scheint ein Award 6.00PG Bios zu haben. Im Bios sind wie immer diverse Module vorhanden, auch ein PXE Boot Modul. Das kann man (sofern PXE man nicht braucht...) für einen Mod missbrauchen. Außerdem sind sogar noch freie Biosoptionen vorhanden, sprich man könnte den Fix sogar im Bios abschaltbar machen...
Problem dabei: um sowas durchzutesten brauchts meist mehrere Anläufe. Sprich es kann sein das man zwischendurch beim Testen das Bios brickt. Biosflasher oder Hotflashen wäre dann nötig.
Es gibt noch eine Alternative zum BIOS Mod -> Custom MBR/Bootloader. Wenn man den Standardbootloader an eine andere bekannte Stelle verschiebt (oder garnicht benögt), kann man sein eigenes Programm im "vorderen" Bereich der Festplatte unterbringen, seine Anpassungen im PCI space durchführen und dann den Originalbootloader nachladen und ausführen (sog. Chainloading). Hat den Vorteil, dass das BIOS nicht verändert wird, aber den Nachteil, dass es an eine Festplatte gebunden ist. Hab ich in meinem Compaq Portable 486 so gelöst. Man kann auch eine SD Karte o.ä. als erstes Bootdevice einrichten und dort den Custom Bootloader unterbringen, muss dann aber das Chainloading auf ein anderes Device umleiten.
Hab an der 5900xt pdf pixelview weiter gearbeitet. Display kann jetzt direkt ohne russian engineering an der Karte betrieben werden. Ein Taster wurde ausgelötet, dessen Funktion nicht benötigt wird und zum Glück sogar der original Optik dient, ansonsten wäre er drin geblieben. Ein Transistor sowie ein quäker schließen jetzt flach bündig mit der Platine ab, da ich den Platz auf der Rückseite zum Harzen des schiebeschalters benötige. Demnächst kommt auch noch ein Miniatur schiebeschalter den ich vermutlich auf die Platine Harzen muss. Dieser ermöglicht dann wie beim Original das Umschalten zwischen Fahrenheit und Celsius. Zwei prototypen für das Gehäuse werden noch gedruckt und final dann später ein durchsichtiges/milchiges Gehäuse
Drüben bei osdev.org gibt es einiges an Hilfe zu dem Thema, da es eigentlich in dortigem Kontext wichtig ist. Wie ein MBR Bootloader aufgebaut ist steht z.B. hier:
Aber in kurz: man braucht ein sehr kleines Programm, welches in 512 bytes die Partitionstabelle, den Code um sich selbst zu verschieben, zum Nachladen des Bootsektors der aktiven Partition und die eigene Logik quetschen muss. Darüber hinaus muss man beim Beschreiben die Partitionstabelle retten, sonst hat man andere Probleme.
Das klingt dann doch etwas komplizierter als ich mir das vorgestellt habe. Das Beispiel in einem der Links sieht aber erstaunlich kompakt aus. Wenn man das ganze als OptionROM implementiert, dann läuft es im Prinzip auf das folgende hinaus:
1. BIOS mit Modbin in seine Module zerlegen
2. Aus einem bestehenden PCI OptionROM Vendor und Device ID extrahieren
3. Ven_ID und Dev_ID im custom ROM einpflegen
4. CustomROM mit FASMW (oder einem ähnlichen Assembler Tool) schreiben und compilieren
5. OptionROM mit Modbin wieder ins Bios packen
6. Flashen und testen
Wobei Punkt 4 natürlich beliebig kompliziert gemacht werden kann. Sprich vom stumpfen Ausführen des ROM ohne weitere Konfiguration bis zum Anlegen einer Biosoption mit welcher man das ROM an- bzw. abschalten kann ist alles möglich. Und man verliert, sofern das alte OptionROM ersetzt wird, natürlich ein Feature des Bios. Ich nutze gerne das PXE Boot Modul dafür, dieses Feature braucht eh kaum einer...
Um jetzt Punkt 4 nochmal etwas weiter auszuführen:
Grundsätzlich schreibt man in PCI Register indirekt. Das heisst, das man quasi die gewünschte Adresse in ein Register schreiben muss, die Daten hinterher schiebt und der Prozessor bzw. das Bios erledigt den Rest. Das sieht im einfachsten Fall dann so aus:
Code:
; FASM Makro das pcireg, cmask und value als Parameter übernimmt und damit PCI Register manipuliert
macro writeregister pcireg, cmask, value
{
mov eax,pcireg ; 32bit pci register offset in EAX kopieren (beinhaltet die typische Bus, Device, Function Konvention und den Register offset. Also z.B. b0:d0:f0:4C)
mov dx,0CF8h ; 0CF8h ist das Register über das wir indirekten Zugriff auf die PCI Register erhalten. Dazu muss das Register in DX abgelegt werden
out dx,eax ; nach setzen von 0CF8h schieben wir nun unsere gewünschte Registeradresse hinterher
mov dx,0CFCh ; Das gleiche Prozedere muss für die PCI Register Daten gemacht werden, aber mit 0CFCh. Die CPU legt uns dabei die Daten des Registers in DX ab
in eax,dx ; wir holen die Daten aus DX in EAX um mit ihnen zu arbeiten.
and eax,cmask ; Da wir nicht alle 32bit des PCI Registers bearbeiten wollen maskieren wir die Daten mit unserer Eingangs an das Marko übergebenen Maske
or eax,value ; wir packen unsere geänderten Werte auf die maskierten Daten
out dx,eax ; und schreiben alles über den Bus in die PCI register zurück.
}
Natürlich braucht man noch etwas Code drumherum, damit das optionROM läuft, aber im Prinzip wars das. Für den hier benötigten Fix brauchen wir dieses Makro zweimal. Einmal für b0:d0:f0:4C und einmal für b0:d0:f0:84. Durch das Maskieren können wir gleichzeitig mehrere Bits pro Register schreiben.
Damit wäre der Fix dauerhaft aktiv und nicht abschaltbar. Als Erweiterung kann man nun noch die CMOS Register einbinden, das sind die Register wo das Bios seine Einstellungen speichert. Dazu muss man aber in den Tiefen des Bios rumfuddeln, Einstellungen via Hexeditor anpassen und erweitern. Ist aber alles machbar. Danach wäre es möglich den Hack im Bios an/abzuschalten und so zu testen ob es was bringt
Das Problem ist nicht der Speicherplatz im Bios, sondern die Tatsache das das Bios nicht einfach jedes PCI Optionrom lädt. Sprich ein vorhandenes ersetzen geht, ein zusätzliches reinbasteln (zumindest soweit ich aktuell weiß) nicht. Deshalb die Idee einfach das PXE rauszuwerfen bzw. zu ersetzen. Alternativ könnte man auch ein ISA Option Rom bauen (ja, das gibts auch ).
Ich muss man in meinen Ordner mit den Nforce 2 Mods schauen, ob wir dort den PCI oder ISA Weg gegangen sind. Ich meine mich dunkel zu erinnern, dass das ISA Option Rom immer ausgeführt wird, ohne das man was rauswerfen muss... Das würde bedeuten das die volle Funktionalität des Bios bleibt und es ne Option extra gibt.
Ansonsten müsste sich ein Hack, der lediglich die paar Bits patcht relativ leicht basteln lassen. Gucke ich in einer ruhigen Minute die Tage gerne mal. Ein Flasher macht uns das Leben natürlich erheblich leichter.
Das ist korrekt. ISA roms werden jedes mal ausgeführt, PCI rom nicht. Soweit ich es bis jetzt festgestellt habe, funktionieren ISA roms gut bei Award 6.0, Bei AMI habe ich es nicht hin bekommen. Bei AMI geht PCI rom.
PCI rom hat den Vorteil, dass man es auch abschalten kann. Es wird m.M.n. auch recht früh beim Start geladen.
Falls du eine PCI rom als Vorlage brauchst, kannst du die von einem ASRock BIOS (R1 versionen) laden.
Es wird kurioser. Habe heute WinXP installiert und die Grafiktreiber gleich danach und die Kiste läuft sauber ohne irgend einen BSOD. Lass ich SP1 weg ist alles gut, installier ich es aber, begrüsst mich wieder der Code 10 bei der Grafikkarte.
Nur das parallel installierte Win2k hat nachwievor sporadische BSOD's mit derselben Grafiktreiberversion inkl. SP4.
Dagegen war die Erstinstallation von XP (Grafiktreiber relativ am Ende installiert) ein reines BSOD-Fest.
Ja, das ist das richtige Device -1022:700c "AMD-760 MP [IGD4-2P] System Controller" in Revision C0 - immerhin die neueste mit weniger Bugs.
An Stelle 0x4c steht 0x00000020, also PCI_DT_En und PCI_OR_En sind noch abgeschaltet -> sollte 0x00000026 sein
An Stelle 0x84 steht 0x00031097, also Tgt_Latency ist ausgeschaltet und Tgt_Lat_Tim_Dis auch-> sollte 0x00831097 sein
Das ist wahrscheinlich schon das Problem. Laut Datenblatt sollten Tgt_Latency und Tgt_Lat_Tim_Dis gegensätzlich und nicht gleich geschaltet sein.
Wenn ich das datenblatt richtig verstanden habe müssen letztere nicht zwingend gleich geschaltet sein. Nur wenn Tgl_latency 1 ist, dann muss tgt_lat_tim_dis 0 sein. Die können aber auch beide 0 sein oder genau umgedreht, also 0/1 statt 1/0. nur 1/1 geht nicht. Wäre generell interessant zu sehen was auf einem msi, asus oder tyan in den registern hinterlegt ist, denn die scheinen das problem ja nicht zu haben.
----
Der Screenshot oben sieht gut aus. Die 32bit aus der Tabelle im Datenblatt beziehen sich hier auf alles was in 4C bis 4H steht, also die 20 00 00 00. wir brauchen ja nur bit 1 und 2, also reichen die ersten beiden byte in 4C aus:
Dann versuchen wir mal unser Glück mit dem ISA Option Rom... @bschicht86
Das Bios ist im Prinzip das letzte ofizielle (F6), nur mit dem Optionrom integriert und die POST Zeile ist angepasst.
Wie immer: ungetestet, bitte nur flashen wenn du eine Möglichkeit hast das Board wiederzubeleben falls es nicht laufen sollte
Das ungemoddete Bios hab ich auch mit reingepackt, damit klar ist welches Bios die Basis ist.
Wenn es bootet, dann sollten die PCI Register so wie @n3RoRocks oben vorgeschlagen hat angepasst sein. Hoffen wir das es hilft.
Den Quellcode vom Rom hab ich mit in die ZIP gepackt.
@Tzk
sauber geschriebener Code! Die Auflistung der bits und der Maske finde ich super! Werde das adaptieren.
Dein Code ist übersichtlicher. Ich habe die Schreibweise mit den einzelnen Makos von Infrared übernommen. Letzendlich das selbe, das eine hat weniger Text, das andere ist übersichtlicher.
Ich müsste eigentlich mehr darin üben. Man vergisst schnell wie das geht.
Mir gings ähnlich... Ich hatte nun seit über einem Jahr nichts mehr in FASM gemacht und durfte alles nochmal neu nachgucken. Deshalb ist auch alles so umfangreich dokumentiert, damit ich mich selbst nicht verzettel Im Prinzip hab ich die Markos aus unserem Sockel A OptionRom angepasst und mit festen Werten versehen, das ging wunderbar. Auf Spielereien wie eine Biosoption hab ich erstmal verzichtet, bevor wir nicht wissen ob der Fix überhaupt funktioniert.
Klar. Bios Optionen ist so eine Sache. Nicht alle gekaperten Optionen funktionieren. Das ist dann ärgerlich, wenn man das selber nicht testen kann oder überhaupt drauf zu kommen, wo das Problem ist. MSI Delta2 ist so ein Fall: das älteste BIOS ist auch eigentlich das beste. Problem ist nur, dass das BIOS oder NVMM eigenhändig die tRC und tRFC Werte zurück setzt (ein paar alpha-Werte auch). Wenn man das nicht an einem eigenen Rechner testen kann, kommt man da nie drauf.
Wenn der Fix funktioniert, kann man immer noch den fix abschaltbar machen.
Meine Voodoo 5 5500 AGP ist nahezu wieder einsatzbereit. Ich muss mir jetzt nur noch etwas Wärmeleitkleber besorgen, damit ich die Lüfter wieder ankleben kann.
Ein paar Elkos habe ich noch vorsichtshalber gewechselt, weil sie durchs Löten verfärbt waren und wahrscheinlich dadurch gelitten haben. Die beiden Puffer-Elkos oben habe ich ebenfalls ersetzt. Der Einfachheit halber sinds jetzt zwei 470 µF/16 V. Da oben kann man prinzipiell irgendwelche Elkos einlöten, da sie nichts mit dem Netzteil zu tun haben und nur die Eingangsspannung puffern.
Um die Karte vor erneutem Schaden an den GPUs zu schützen, habe ich eine Schaltung dazu entwickelt, die ich jetzt langsam aufbauen werde. Sie basiert auf einer Spannungsmessung am Schaltregler und löst ohne weiteres in knapp 100 Nanosekunden sicher aus und legt die Karte tot, also trennt die Stromversogung. Eine Schmelzsicherung an der richtigen Stelle erzwingt eine Stillegung der Karte auch nach etwaigem Wiedereinschalten. Weiterhin werde ich auf Arduino-Basis einen ICT für diese Karte entwickeln, damit ich Fehler schneller finden und beheben kann. Ich brauche dazu nur ne große Menge an schnellen Relais.
Eventuell kann ich auch diverse andere Dinge an den Testpunkten der Karte mit dem Arduino messen. Mal sehen.
Also die Register scheinen entsprechend gesetzt zu werden, jedoch bleibt der BSOD unter Win2k und Code 10 bei der Grafikkarte unter WinXP bestehen. Evtl. hilft ja eine Neuinstallation.
EDIT:
Ich war mal ein wenig verrückt und hab mir eine Windertüte voll AMD-Prozessoren zugelegt.
Für einen Euro pro Prozessor ist leider etwas Arbeit dabei:
Immerhin gabs ein paar interessante Modelle:
Das meiste ist jedoch AM2. Zu 939: Welches waren nochmal gute OC-Steppings? Damit ich weiß, was ich bevorzugt begradigen kann.
wird schon. Klinge vom Teppichmesser und ab gehts. Die CPUs sind robuster als man so denkt. so einen Kauf hab ich auch schon gemacht und fast alle CPUs laufen.
Also die Register scheinen entsprechend gesetzt zu werden, jedoch bleibt der BSOD unter Win2k und Code 10 bei der Grafikkarte unter WinXP bestehen. Evtl. hilft ja eine Neuinstallation.
Hmm... ist die Frage ob ich den linux fix richtig interpretiert habe, denke aber schon. Ansonsten schonmal super das es generell funktioniert und ich das bios nicht geschossen habe
Freilich. Da hab ich weniger Bedenken, es erfordert halt ein Haufen Zeit. Und ich kann schauen, wie gut mein Geduldskorsett in Schuss ist.
Und die ersten 4 (bedeutensten) Funde sind schon reaktiviert und funktionieren auch:
Im obigen Post die CPU mit den vielen flach liegenden Pins war übrigens der FX 53, welchem zusätzlich 4 Pins gefehlt hatten. (CPU links oben, angelötete Pins sind beim goldenen Pfeil)
Damit hat sich heute mein FX-Bestand verdoppelt, da steig ich sicher zum ernstzunehmenden Kontrahenten von stunned_guy auf.
EDIT: Gibts eigentlich Interessenten an AM2-CPU's? Weil wenn nicht, würd ich die links liegen lassen und zur Schrottkiste zurück legen. Bei Interesse könnte ich zumindestens mal eine Liste machen.
Wie kommt man eigentlich an so einen Haufen CPUs?