Ausgehend von des GrandAdmiralThrawn s Problem hier :
Display Spoiler
Na klar kann ich das so einstellen, daß es gar nicht läuft, habe ich ja schon gesagt, aber das ist nicht die Idee dahinter. Die Idee ist es, ihn grade soweit instabil zu machen, daß ich tatsächliche ECC Korrekturen im Memtest 4.20 nachweisen kann...
Worum es mir geht ist es zu testen, ob das ASUS P6T Deluxe nun wirklich ECC RAM kann oder nicht. Weil diese ganzen "brauchst nur dmidecode schauen"- oder "wenn dir Tool A das im Windows anzeigt wird's schon da sein"-Beiträge, die man überall im Internet findet kann man leider komplett und vollständig vergessen bei dem Thema. Und den kommerziellen memtest kann man leider gleichsam in die Tonne treten was das auf X58 oder sonstigen BIOS Systemen angeht.
Was ich provozieren möchte sind halt nicht irgendwelche Fehler, sondern explizit ein Auslösen des ECC. Aber vielleicht funktioniert das ja mit dem Test, wenn man das Windows Log auf ECC Fehler mit überwacht? Gibt's dazu Erfahrungswerte?
Display MoreEtwas ernsthafter und sachdienlicher:
Soweit ich das Datenblatt zum Xeon 5600 Vol. 2 verstehe, werden ECC-Fehler in den Registern MC_COR_ECC_CNT_0 bis
MC_COR_ECC_CNT_5, gleich Indizes 80h, 84h, 88h, 8C, 90h, 94h des Device 3, Function 2: Integrated Memory Controller RAS Registers, gezählt (Seite 23). Möglicherweise spielt da auch noch das Register MC_SMI_DIMM_ERROR_STATUS (Device 3, Function 0, Offset 50h) mit. Über das Zusammenspiel dieser beiden bin ich mir nicht so ganz sicher.
Der Grenzwert, der zum Auslösen eines NMI oder SMI überschritten werden muß, wird im Register MC_SMI_CNTRL (Device 3, Function 0, Offset 54h, Bit 14-0) festgelegt (Seite 43, 62).
Ob überhaupt ein NMI oder SMI gesendet wird, bestimmen die Bits 16 bzw. 15 desselben Offsets.
Also bräuchtest Du eigentlich nur zu wissen, ob entweder das NMI- oder das SMI-Bit gesetzt ist. Beides sollte man wohl nicht tun (Seite 62).
Du könntest nun also Device 3, Function 0, Offset 54h auslesen oder probehalber selbst ein Bit in den Zählregistern auf 1 setzen, um zu sehen, ob sich die CPU, die Überwachungssoftware oder wie auch immer man das ausliest, den Interrupt abfängt oder was weiß ich, meldet.
Diese Zählregister werden wohl für mich als Nutzer nur lesbar sein? Aber ist ja egal, ich schau einfach Mal rein mit pciconf oder unter Windows mit WPCREdit! Danke für die Recherche!
PS.: Paar Euro würde ich für einen garantiert Fehler erzeugenden ECC DDR3 Stein direkt wirklich zahlen. Nur um sicher zu gehen. Weil bei der Herumexperimentiererei kann ich mir auch nie zu 100% sicher sein, ob es nur nicht geklappt hat, weil ich es vielleicht einfach falsch mache. Oder weil das so nicht reicht.
Display MoreIm Datenblatt steht neben den Zählregistern
MC_SMI_DIMM_ERROR_STATUS (Device 3, Function 0, Offset 50h)
ein RW0C dran.
Dazu heißt es auf Seite 9: "Read/Write 0 Clear. A register bit with this attribute can be read or cleared by software.
In order to clear this bit, a zero must be written to it. Writing a one will have no effect."
Also kannst Du es da schon mal vergessen.
Zu den
MC_COR_ECC_CNT_0 bis MC_COR_ECC_CNT_5 (Device 3, Function 2, Offsets 80h, 84h, 88h, 8C, 90h, 94h)
habe ich gar nichts gefunden.
Das Auslesen des Registers MC_SMI_CNTRL (Device 3, Function 0, Offset 54h, Access: Dword) dürfte wohl am einfachsten sein.
Das ist RW: "Read/Write. A register bit with this attribute can be read and written by software."
Ich bin mir nicht sicher, ob WPCRedit auch auf die CPU zugreifen kann. Ist mir bisher jedenfalls nicht aufgefallen. Chipsatz (North and South, ach welch schönes Spiel. Wer erinnert sich noch daran?), USB-, AGP-Controller ja, aber die CPU???
Du bräuchtest vermutlich eine eigene Konfigurationsdatei. Ich hab mir neulich mal so eine PCR-Datei dafür angeschaut. Hier ein kurzer Ausschnitt:
CodePCR(PCI Configration Registers) Editor / WPCREDIT for WIN32 Copyright (c) 1998 H.Oda! [COMMENT]=Author R.Ruck [MODEL]=Aladdin V [VID]=10B9:ALi [DID]=1541:Host Bridge (00)=Vendor Identification (01)=Vendor Identification (02)=Device Identification (03)=Device Identification (0D)=Device Latency [40:6]=Use Internal TAG Ram (1/0 Enables/Disables) [40:5]=Use Internal MESI (0/1 Enables/Disables) [40:4]=M1/M2 Burst & K6 Write Alloc. (1/0 Enables/Disables) [40:3]=M1/M2 Linear Burst (1/0 Enables/Disables) [40:2]=L1 Cache Snoop Point (0-3T 1-2T) [40:1]=L2 Cache Check Point (0-3T 1-2T) [40:0] =L1 Cache (1/0 Enables/Disables) [41:6]=Fast DRAM Read (1/0 Enables/Disables) ...Die CPU müßte man wohl irgendwie im Header einbinden oder die Werte in den eckigen Klammern also z. B. [40:6] durch die PCI-Adresse der CPU ersetzen. Keine Ahnung, ob das Programm das dann beim Auslesen auch so versteht.
Vielleicht geht es aber auch mit XCPUid: http://hp.vector.co.jp/authors/VA002374/src/download.html
oder https://falconfly.vogonswiki.com/download.html
EDIT: Ist wohl nur die Linuxversion von WCPUid???
und da ich ihm mal vor langer Zeit versprochen hatte, mir das BIOS des Boards anzuschauen, aber diese Arbeit vor einem Jahr unterbrechen mußte wegen anhaltender Kopfschmerzen, sobald ich auf den Code stierte, hab ich mir mal gedacht, selbst ein Programm zu schreiben, das die Register der CPU auslesen kann. So was scheint es ja nicht zu geben. WPCRedit macht das für den Chipsatz und ein paar PCI-Geräte, CPU-Daten konnte ich damit jedoch noch nie abrufen.
Okay, nach 10 Tagen C für dummies Lesen und parallel dazu schnell das Programm schreiben, mal die erste, halbgare Version getestet:
RegQuery: Quick'n'Dirty - in allerbester Microsoft-Manier 
aber unter Linux mit root-Rechten 
und Linux läuft danach ohne Zicken weiter 
Unter Linux liest das Programm jedenfalls schon mal irgendwelche DWORDs aus, die sich nach Erhöhung des Offsets um 4 dann ändern. Soweit so logisch, da ein Offset 1 Byte speichert und 4 Bytes = 1 DWORD sind. Chipsatz (abgekürzt mit M für Motherboard) und CPU (abgekürzt mit C) ergeben unterschiedliche Werte. Auch gut.
Leider kann ich nicht beurteilen, ob die Werte Sinn ergeben, da mir die Datenblätter zur Hardware meines Linuxrechners
- CPU: Intel Core2 Duo E8200
- Chipsatz: nVidia nForce 650i SLI (Northbridge C55) + 570i SLI (Southbridge MCP55P)
fehlen.
Die Ausgabe von FFFFFFFFh bei Eingabe von C 0 0 44 deutet jedenfalls darauf hin, das ich versucht habe, ein nicht existendes Register zu lesen.
Auch ein Vergleich mit WPCRedit-Werten geht nicht, da ich das Programm trotz WINE unter Linux nicht starten kann. Keine Rechte. 
Mit Windowsrechnern bin ich zur Zeit nicht verflucht. 
Wenn mir jemand die Datenblätter zur oben genannter Hardware schicken könnte, käme ich schon einen guten Schritt weiter. 
