Nachgefragt: Athlon XP und der Extended Pages Issue
- Ersteller Nero24
- Erstellt am
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.066
- Renomée
- 10.446
Vorgestern haben wir über den Athlon LargePages-Issue mit dem neuen Linux-Kernel 2.4 <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1011664883">berichtet</a> und meldeten, der Fehler würde bei der gesamten K7-Reihe inklusive Duron und Athlon XP/MP/4 auftreten. Das wurde gestern von der US-Seite <a href="http://www.amdzone.com" TARGET="b">AMDZone</a> (<i>"Athlon AGP Bug Eliminated"</i>) erstmal dementiert:<ul><i>It is not in the Palomino core. I wish before people spread word about these kinds of bugs they would look into which revisions of the CPUs are effected.</i></ul>In der Tat weist der <a href="http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24332.pdf" TARGET="b">Revision Guide</a> des Athlon Model 6 (Palomino) ein Erratum namens "<b>INVLPG Instruction Does Not Flush Entire Four-Megabyte Page Properly with Certain Linear Addresses</b>" (Erratum 16) auf. Der Fehler ist wie folgt beschrieben:<ul><i>Non-conformance: When the logical address designated by the INVLPG instruction is mapped by a 4-MB page mapping and LA[21] is equal to one it is possible that the TLB will still retain translations after the instruction has finished executing.
Potential Effect on System: The residual data in the TLB can result in unexpected data access to stale or invalid pages of memory.</i></ul>Der Fehlerbeschreibung nach könnte man meinen, daß dies der Bug in der Verwaltung der Extended Pages sei. In der Tat wird dieser mit der Revision A5 (Stepping 662) des Athlon Model 6 (Palomino) als gefixt angegeben. Damit hätte AMDZone recht. Aber dieses Erratum hat nach unserer Nachfrage bei AMD nichts mit der Win2k-LargePages-Geschichte zu tun:<ul><i>The INVLPG erratum in the revision guide has nothing to do with Win2k patch issue</i></ul>Bestätigt wird das durch die <a href="http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_871,00.html" TARGET="b">Beschreibung</a> des LargePages-Bugs bei AMD ("<i>Microsoft Windows® 2000 Patch for AGP Applications</i>") folgendes stehen würde:<ul><i>An issue has been identified that could result in the corruption of video data shared between AGP graphics adapters and AMD Athlon™ or AMD Duron™ processors, <b>including the AMD Athlon™ MP processor</b> when running Microsoft Windows®2000 Professional, Windows®2000 Server, or Windows®2000 Advanced Server. This issue is independent of system chipset and has been observed when running Ziff-Davis 3D Winbench™ 2000 and Mad Onion 3DMark™ 2000 in benchmarking mode. </i></ul>Wie auch immer. Wir hatten die Spekulationen satt und haben daher bei AMD nachgefragt. Public Relations Manager Jan Gütter war so freundlich unsere Fragen zu beantworten. Das ist die offizielle Stellungnahme dazu:<ul><i>Um eines vorweg zu nehmen: Wir gehen nicht davon aus, dass die Ursache des Phänomens in der CPU selbst begründet liegt. Wäre dem so, wäre Windows XP auch betroffen, da Windows XP auch Large Pages benutzt. In Windows XP tritt dieses Phänomen aber nicht auf.
Der Large Pages Issue unter Win2k tritt bei allen K7 CPUs auf. Inklusive Athlon XP
Was Linux angeht: Wir wissen noch nicht, was die Ursache ist, warum Linux ähnliche Phänomene zeigt wie Windows 2000. Wir konnten das Phänomen intern noch nicht reproduzieren. Bevor wir dies nicht tun können, wäre jede Aussage, was die Ursache ist, reine Spekulation. Insofern können wir auch (noch) nicht sagen, welche Prozessoren betroffen sind, wenn überhaupt einer betroffen ist.
Die Nutzung von Large Pages abzuschalten, hat offensichtlich bei einigen Usern das Problem behoben. Doch das Abschalten der Large Pages ist bekannt dafür, viele andere Dinge auch zu maskieren. Es mag im Moment helfen, stellt jedoch keine dauerhafte Lösung dar.
Wir nehmen die Angelegenheit jedoch sehr ernst und arbeiten angestrengt daran, das Phänomen intern nachzustellen, um eine Lösung anzubieten.
Sollte jemand ähnliche Phänomene mit seiner CPU haben, sollte er die technische Hotline kontaktieren.</i></ul>Danke erstmal an Jan Gütter für die schnelle Stellungnahme. Die erwähnte technische Hotline von AMD erreicht Ihr im Falle eines Falles unter 089/450-53199. Wie man sieht sind die Schäfchen in Sachen LargePages noch nicht im Trockenen. Also abwarten und Tee trinken. Wir bleiben auf jeden Fall dran...
Potential Effect on System: The residual data in the TLB can result in unexpected data access to stale or invalid pages of memory.</i></ul>Der Fehlerbeschreibung nach könnte man meinen, daß dies der Bug in der Verwaltung der Extended Pages sei. In der Tat wird dieser mit der Revision A5 (Stepping 662) des Athlon Model 6 (Palomino) als gefixt angegeben. Damit hätte AMDZone recht. Aber dieses Erratum hat nach unserer Nachfrage bei AMD nichts mit der Win2k-LargePages-Geschichte zu tun:<ul><i>The INVLPG erratum in the revision guide has nothing to do with Win2k patch issue</i></ul>Bestätigt wird das durch die <a href="http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_871,00.html" TARGET="b">Beschreibung</a> des LargePages-Bugs bei AMD ("<i>Microsoft Windows® 2000 Patch for AGP Applications</i>") folgendes stehen würde:<ul><i>An issue has been identified that could result in the corruption of video data shared between AGP graphics adapters and AMD Athlon™ or AMD Duron™ processors, <b>including the AMD Athlon™ MP processor</b> when running Microsoft Windows®2000 Professional, Windows®2000 Server, or Windows®2000 Advanced Server. This issue is independent of system chipset and has been observed when running Ziff-Davis 3D Winbench™ 2000 and Mad Onion 3DMark™ 2000 in benchmarking mode. </i></ul>Wie auch immer. Wir hatten die Spekulationen satt und haben daher bei AMD nachgefragt. Public Relations Manager Jan Gütter war so freundlich unsere Fragen zu beantworten. Das ist die offizielle Stellungnahme dazu:<ul><i>Um eines vorweg zu nehmen: Wir gehen nicht davon aus, dass die Ursache des Phänomens in der CPU selbst begründet liegt. Wäre dem so, wäre Windows XP auch betroffen, da Windows XP auch Large Pages benutzt. In Windows XP tritt dieses Phänomen aber nicht auf.
Der Large Pages Issue unter Win2k tritt bei allen K7 CPUs auf. Inklusive Athlon XP
Was Linux angeht: Wir wissen noch nicht, was die Ursache ist, warum Linux ähnliche Phänomene zeigt wie Windows 2000. Wir konnten das Phänomen intern noch nicht reproduzieren. Bevor wir dies nicht tun können, wäre jede Aussage, was die Ursache ist, reine Spekulation. Insofern können wir auch (noch) nicht sagen, welche Prozessoren betroffen sind, wenn überhaupt einer betroffen ist.
Die Nutzung von Large Pages abzuschalten, hat offensichtlich bei einigen Usern das Problem behoben. Doch das Abschalten der Large Pages ist bekannt dafür, viele andere Dinge auch zu maskieren. Es mag im Moment helfen, stellt jedoch keine dauerhafte Lösung dar.
Wir nehmen die Angelegenheit jedoch sehr ernst und arbeiten angestrengt daran, das Phänomen intern nachzustellen, um eine Lösung anzubieten.
Sollte jemand ähnliche Phänomene mit seiner CPU haben, sollte er die technische Hotline kontaktieren.</i></ul>Danke erstmal an Jan Gütter für die schnelle Stellungnahme. Die erwähnte technische Hotline von AMD erreicht Ihr im Falle eines Falles unter 089/450-53199. Wie man sieht sind die Schäfchen in Sachen LargePages noch nicht im Trockenen. Also abwarten und Tee trinken. Wir bleiben auf jeden Fall dran...
PuckPoltergeist
Grand Admiral Special
So, da kann ich in diesem Zusammenhang gleich mal eine Frage loswerden. Hab ein NMC Board (7VAX, also Slot A) mit einem Athalon 750MHz. Wenn ich unter Windows irgendwas mit 3D starte, friert mir der Rechner ein (dachte eigentlich immer).
Dabei ist es egal, ob D3D oder OpenGL (mit UT und 3DMark 2000 getestet). Es liegt nicht an der GraKa (gleiches Phänomen mit TNT2/M64, Rage128 und Radeon8500) oder einer Windows-Version (mit Win98SE, Win2k und XP probiert). Kann das mit den LargePages-Problem zusammen hängen (ich hatte aber den Patch unter 2k installiert
).
Es sind noch 256MB RAM (Micron), ein TekramU2W, eine FritzPCI und eine SB128 PCI (CT4700) im Rechner (ein die CT4700 ist es nicht, die hatte ich schon draußen).
puck
Dabei ist es egal, ob D3D oder OpenGL (mit UT und 3DMark 2000 getestet). Es liegt nicht an der GraKa (gleiches Phänomen mit TNT2/M64, Rage128 und Radeon8500) oder einer Windows-Version (mit Win98SE, Win2k und XP probiert). Kann das mit den LargePages-Problem zusammen hängen (ich hatte aber den Patch unter 2k installiert
).Es sind noch 256MB RAM (Micron), ein TekramU2W, eine FritzPCI und eine SB128 PCI (CT4700) im Rechner (ein die CT4700 ist es nicht, die hatte ich schon draußen).
puck
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.066
- Renomée
- 10.446
<b>Update:</b>
Mittlerweile hatten wir auch die Gelegenheit mit Daniel Robbins, Chief Architect/President von Gentoo Technologies Inc. zu sprechen, welche die Extended Pages Geschichte veröffentlicht hatten. Wie es scheint ist hier mittlerweile ein Umschwenk in Gange, der die AMD Prozessoren in der Linux-Geschichte entlastet:<ul><i>The issue we are talking about is a subtle interaction between speculative writes, extended paging and the GART (not a CPU bug, this was a misunderstanding). This quirk results in corruption of AGP and system memory, and it's really the responsibility of the Linux kernel and drivers to make sure that this issue doesn't happen. See my post at <a href="http://www.geocrawler.com/lists/3/Linux/35/75/7626960/" TARGET="b">GeoCrawler</a> which contains an update including an official explantion from AMD of a problem that can happen and may be happening to Linux people. Follow the thread and you'll see that it's a real issue. It is a very interesting problem.
The Linux kernel developers are currently investigating this speculative write/GART interaction to see if it could affect Linux users. So far, the consensus seems to be that it *does* affect Linux AGP users and developers are currently trying to find a solution that doesn't not hurt performance as "mem=nopentium" (turning off extended translation) does.</i></ul>
Mittlerweile hatten wir auch die Gelegenheit mit Daniel Robbins, Chief Architect/President von Gentoo Technologies Inc. zu sprechen, welche die Extended Pages Geschichte veröffentlicht hatten. Wie es scheint ist hier mittlerweile ein Umschwenk in Gange, der die AMD Prozessoren in der Linux-Geschichte entlastet:<ul><i>The issue we are talking about is a subtle interaction between speculative writes, extended paging and the GART (not a CPU bug, this was a misunderstanding). This quirk results in corruption of AGP and system memory, and it's really the responsibility of the Linux kernel and drivers to make sure that this issue doesn't happen. See my post at <a href="http://www.geocrawler.com/lists/3/Linux/35/75/7626960/" TARGET="b">GeoCrawler</a> which contains an update including an official explantion from AMD of a problem that can happen and may be happening to Linux people. Follow the thread and you'll see that it's a real issue. It is a very interesting problem.
The Linux kernel developers are currently investigating this speculative write/GART interaction to see if it could affect Linux users. So far, the consensus seems to be that it *does* affect Linux AGP users and developers are currently trying to find a solution that doesn't not hurt performance as "mem=nopentium" (turning off extended translation) does.</i></ul>
PuckPoltergeist
Grand Admiral Special
Ich sollte vielleicht noch hinzufügen, daß ich gerade NFS4 High Stakes ohne Probleme stundenlang spielen konnte. Bis auf daß das Bild nach einer Weile angefangen hat zur SlideShow zu mutieren ist nichts passiert (also nix Freeze).
Ich verstehs nicht mehr. Die einzige Möglichkeit dafür die mir noch einfällt ist, daß das Board irgendein Problem hat (ist da was bekannt beim KX133, ob der Probleme mit dem AGP hat?)
puck
Ich verstehs nicht mehr. Die einzige Möglichkeit dafür die mir noch einfällt ist, daß das Board irgendein Problem hat (ist da was bekannt beim KX133, ob der Probleme mit dem AGP hat?)
puck
@Puck: Mit dem Thema hier hat das (leider oder glücklicherweise) nichts zu tun. Deswegen gehört das hier eigentlich nicht hin, aber ich schreib trotzdem mal was 
Da ich das gleiche Board hatte (zwar ein Epox 7KXA, aber das ist völlig baugleich), würde ich darauf tippen, daß das Board schuld ist. Ich hatte auch dauernd Probleme damit, u.a. weil die 3,3V-I/O-Spannung nicht hoch genug ist (nur ca. 3,1V). Ich hab einen Poti eingebaut, um die Spannung hochregeln zu können, allerdings brauchte ich dann auch einen besseren Northbridge-Kühler. Das hat zwar einiges gebracht, aber auch nicht alle Probleme gelöst.
Bei Dir sind ja auch viele Komponenten drin, die einiges an Strom ziehen (Karten, Speicher, ...), und ein Board, das nicht genug Saft abgibt, trägt nicht gerade zur Stabilität bei, besonders nicht bei Anwendungen, die diese Teile extra stark auslasten. NFS5 ist immerhin der AGP-Stabilitätstest bei planet3dnow.de, bei anderen 3D-Anwendungen darf der AGP aber auch schön schaufeln.
IMHO ist das ein Mist-Board, und von Epox+Via halte ich mit erstmal fern.
Das Asus A7M266 mit AMD760, was ich mir danach gekauft habe, war zwar teuer, aber das stabilste und problemloseste Board, was ich je hatte (trotz 686B-SB!). Selbst die TV-Karte ist absturzsicher, beim Epox 7KXA konnte ich drauf wetten, daß dadurch die Kiste abstürzen würde.
Ich würde Dir raten, die Timings (RAM) und andere Performance-Einstellungen (also AGP auf 2x, FastWrites aus, etc.) sehr konservativ einzustellen, um den Komponenten möglichst viel Spielraum zu lassen, aber wenn Du keinen Voltage-Mod machen willst, bleiben wenig Alternativen übrig. Auf ein neues Board zu sparen, dürfte aber auf die Dauer am besten sein.
Der ist aber nicht schwierig; wenn ich nachher wieder zu Hause bin (wo das Board liegt), schreib ich hier noch was hin, evtl. Foto. Aber wie gesagt, erhoff Dir keine Wunder davon.
Da ich das gleiche Board hatte (zwar ein Epox 7KXA, aber das ist völlig baugleich), würde ich darauf tippen, daß das Board schuld ist. Ich hatte auch dauernd Probleme damit, u.a. weil die 3,3V-I/O-Spannung nicht hoch genug ist (nur ca. 3,1V). Ich hab einen Poti eingebaut, um die Spannung hochregeln zu können, allerdings brauchte ich dann auch einen besseren Northbridge-Kühler. Das hat zwar einiges gebracht, aber auch nicht alle Probleme gelöst.
Bei Dir sind ja auch viele Komponenten drin, die einiges an Strom ziehen (Karten, Speicher, ...), und ein Board, das nicht genug Saft abgibt, trägt nicht gerade zur Stabilität bei, besonders nicht bei Anwendungen, die diese Teile extra stark auslasten. NFS5 ist immerhin der AGP-Stabilitätstest bei planet3dnow.de, bei anderen 3D-Anwendungen darf der AGP aber auch schön schaufeln.
IMHO ist das ein Mist-Board, und von Epox+Via halte ich mit erstmal fern.
Das Asus A7M266 mit AMD760, was ich mir danach gekauft habe, war zwar teuer, aber das stabilste und problemloseste Board, was ich je hatte (trotz 686B-SB!). Selbst die TV-Karte ist absturzsicher, beim Epox 7KXA konnte ich drauf wetten, daß dadurch die Kiste abstürzen würde.
Ich würde Dir raten, die Timings (RAM) und andere Performance-Einstellungen (also AGP auf 2x, FastWrites aus, etc.) sehr konservativ einzustellen, um den Komponenten möglichst viel Spielraum zu lassen, aber wenn Du keinen Voltage-Mod machen willst, bleiben wenig Alternativen übrig. Auf ein neues Board zu sparen, dürfte aber auf die Dauer am besten sein.
Der ist aber nicht schwierig; wenn ich nachher wieder zu Hause bin (wo das Board liegt), schreib ich hier noch was hin, evtl. Foto. Aber wie gesagt, erhoff Dir keine Wunder davon.
Also, Foto gibt´s nicht, aber die Stelle findest Du auch so:
In der Ecke mit der Southbridge und dem Bios, bei der Stromversorgung, genauergesagt zwischen den 5 Elkos und dem Anschluß für den Chassis Fan, suchst Du einen Widerstand namens R19.
An beide Seiten des Widerstandes lötest Du jeweils ein kurzes Kabel an und packst einen Poti (1Ohm z.B.) dazwischen, so daß er parallel geschaltet ist und Du ihn als Ersatz verwenden kannst (den Poti kann man dann mit doppelseitigem Klebeband irgendwo ans Gehäuse kleben).
Damit kann man die Spannung bis auf 5V hochregeln, was Dein Board natürlich sofort grillen würde, deswegen achte unbedingt darauf, daß er auf max. Widerstand gestellt ist, wenn du die Kiste wieder startest.
Im Bios gibt´s ja das Hardware-Monitoring, und während Du auf die Anzeige der 3,3V-Spannung guckst, drehst Du ganz vorsichtig daran, bis naja, etwa 3,35V, 3,4V erreicht sind, das sollte reichen.
Aber vergiss nicht, der Northbridge einen besseren Kühler (z.B. Grafikkartenkühler) zu verpassen, sonst schmiert Dir die Kiste bald wegen Wärmefehlern ab.
Viel Spaß beim Basteln
In der Ecke mit der Southbridge und dem Bios, bei der Stromversorgung, genauergesagt zwischen den 5 Elkos und dem Anschluß für den Chassis Fan, suchst Du einen Widerstand namens R19.
An beide Seiten des Widerstandes lötest Du jeweils ein kurzes Kabel an und packst einen Poti (1Ohm z.B.) dazwischen, so daß er parallel geschaltet ist und Du ihn als Ersatz verwenden kannst (den Poti kann man dann mit doppelseitigem Klebeband irgendwo ans Gehäuse kleben).
Damit kann man die Spannung bis auf 5V hochregeln, was Dein Board natürlich sofort grillen würde, deswegen achte unbedingt darauf, daß er auf max. Widerstand gestellt ist, wenn du die Kiste wieder startest.
Im Bios gibt´s ja das Hardware-Monitoring, und während Du auf die Anzeige der 3,3V-Spannung guckst, drehst Du ganz vorsichtig daran, bis naja, etwa 3,35V, 3,4V erreicht sind, das sollte reichen.
Aber vergiss nicht, der Northbridge einen besseren Kühler (z.B. Grafikkartenkühler) zu verpassen, sonst schmiert Dir die Kiste bald wegen Wärmefehlern ab.
Viel Spaß beim Basteln
Ähnliche Themen
