Hoofdcategorieën

Linux brengt Athlon bug aan het licht

Door Gabi Gaasenbeek, maandag 21 januari 2002 15:19
Bron: Linux Today, views: 855

Op de site van Linux Today wordt melding gemaakt van een grote Athlon bug. Deze net ontdekte bug bleek niets, zoals men in eerste instantie zou denken, met de Linux kernel te maken te hebben: het probleem zit in de processor zelf. Naast de Athlon zijn er ook Duron processoren met hetzelfde euvel. Deze bug bestaat met Linux kernel 2.4 en het gebruik van een AGP videokaart. Wie regelmatig last heeft van vastlopers bij het kijken naar filmbeelden in Linux heeft misschien last van dit probleem:

AMD Athlon 4 core (klein)Here are the details. As you may know, x86 systems have traditionally managed memory using 4K pages. However, with the introduction of the Pentium processor, Intel added a new feature called extended paging, which allows 4Mb pages to be used instead.

Here's the problem -- many Athlon and Duron CPUs experience memory corruption when extended paging is used in conjunction with AGP. And, this problem hits us because Linux 2.4 kernels compiled with a Pentium-Classic or higher Processor family kernel configuration setting will automatically take advantage of extended paging (for kernel hackers out there, this is the X86_FEATURE_PSE constant defined in include/asm-i386/cpufeature.h.)

Er is een eenvoudige oplossing voor dit probleem: zet de setting 'mem=nopentium' in de Linux bootloader. Kernel hacker Alan Cox probeert nu met een nieuw stukje code in de linux kernel de bug te detecteren. Als de processor de bug inderdaad blijkt te hebben, dan zal de kernel het beheer van het virtueel geheugen aanpassen.

Met dank aan Gezmo voor de suggestie.

Volgende 15:46
Vorige 13:59

Reacties

«  1  2  3  »


Hmm, wie heeft t over een nieuwe proc?

Gewoon een stukkie code schrijven, dat ie deze functie niet gebruikt. :) En AMD zal deze bug er vast wel uit hebben in de XP-serie. Anders brengen ze wel een rev op de markt (net zoals die ernstige fout bij de de vorige Pentium).


net zoals die ernstige fout bij de de vorige Pentium
Toen heeft Intel zelfs alle CPU's teruggehaald, het ging toen om de eerste versie van de Pentium1. In dit geval zal AMD zeker geen CPU's gaan terughalen omdat deze situatie niet gevaarlijk is. Bij de Pentium-bug was dat wel het geval aangezien er zelfs ziekenhuizen waren die op dit soort dingen werkten!!!

tegenwoordig kan de microcode enigszins aangepast worden met via een bios-update... Intel heeft dit ingebouwd, om dat Pentium fiasco niet weer te herhalen

AMD heeft dat ook ingebouwd hoor...
Het lijkt mij alleen raar dat zij hiervoor moeite gaan doen vermits het enkel aan het licht komt in Linux, als je je AGPbus zwaar belast. Linux begint op te komen in de 3D design wereld - maar die markt is zeer klein, en het aandeel dat AMD daarin heeft waarschijnlijk ook zeer klein. De desktop markt van linux stelt ook niet veel voor - en indien toch een gebruikt als desktop meestal niet mission-critical bij de hobbyist thuis (ik hier natuurlijk weer de uitzondering op :P) - de meeste linuxdingen dienen als servers - die de agp-bus toch niet gebruiken.
Als er bovendien dan nog kernelpatches uitkomen die dit probleem oplossen is er voor AMD helemaal geen probleem meer denk ik...

Ik vind ook wel dat je hieraan ziet hoe pentium-optimized de windows kernel is... NOT - daar hoor je toch nooit van zulke problemen...

en waarom moet een nieuwe proc gekocht worden :?

er staat duidelijk dat het heel makkelijk op te lossen is door een regeltje aan te passen, en dat er spoedig een kernel patch voor komt.

Hmm, ik kom niet op www.gentoo.org/ waar de het hele verhaal op zou moeten staan :?

Ik denk niet dat AMD jou een nieuwe proc gaat geven. Er wordt blijkbaar al een patch voor linux geschreven en misschien ook voor windows (als deze er last van heeft?) ?

Er wordt blijkbaar al een patch voor linux geschreven en misschien ook voor windows (als deze er last van heeft?) ?


Windows 2000 heeft er ook last van, maar daar is de bug al veel eerder ontdekt (september 2000) en AMD had al meteen voor windows 2000 een patch geschreven. Pas nu werd duidelijk dat het probleem zich ook voordoet onder linux.

Waar staat die patch? Dit verklaart die irri vastlopers onder OpenGL applicaties (halflife, URT).

even de meest voor de hand liggende route op AMD site volgen (Suppert -> Utilities drivers patches updates -> CPU's) doet wonderen.

http://www.amd.com/us-en/assets/content_type/utilities/largePageMinimu m.reg

Werkt hier ook niet helaas, daarom dus niet meer details in deze nieuwsposting.....

Die site is 'slashdotted' zoals dat wordt genoemd.

Dat betekent zoveel als dat wanneer een site op slashdot.org wordt genoemd, er zoveel verkeer naar zo'n site wordt gegenereerd dat die vastloopt...

Wat overigens een hele eer is, tweakers.net is het weleens overkomen toen ze de primeur om de intel Itanium te mogen testen hadden :)

Hier het relevante stukje van de mailinglist, gentoo.org is inderdaad vaak down / onbereikbaar.

daniel Robbins
When testing this kernel, I experienced a problem with my hardware-accelerated NVIDIA drivers where my system would lock up whenever I started a multithreaded* OpenGL application. I was able to work around this problem by typing 'export _GL_SINGLE_THREADED="yes"' before starting the program from the shell. However, I of course wanted
to be able to use NVIDIA's OpenGL implementation in all its multithreaded glory. Fortunately, I was able to reach Terrence Ripperda from the NVIDIA Linux driver team. He didn't have a solution but did mention that there quite a few Athlon CPUs have a particular bug where the Athlon will corrupt memory if it is using 4Mb page tables with AGP. He said that you could tell the kernel to *not* use 4Mb page tables by
passing the 'mem=nopentium' option to the kernel at boot-time, ie via GRUB. I tried this and my problems completely disappeared. I immediately contacted some kernel developers, and now Alan Cox and Terrence are going to try to track down this particular bug and add support for autodetecting it to the Linux kernel.

Microsoft seems to have discovered this bug, too. See: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q270715 Their fix involves changing the default page table size (preventing a big page table) by tweaking the registry.


Ja en dan weet je niet waarom ie vast loopt nee das lekker :*)

Als er een Bug zit in een AMD dan maakt het dus niet uit of je linux of windows draait...... |:(

Alleen in linux verander je dus je kernel gewoon.
En bij windows zal je moeten wachten op een patch van onze vriend billy 8-)

Wie weet heb je er in Win95/85/ME ook last van, maar door de bomen zie je daar het bos niet,..?
}>

Niet mee eens.
Ik draai op Win2000 Prof en krijg ook veel vastlopers bij het afdraaien van films. Heeft naar mijn mening te maken met DivX3 samen met DivX4.
Vindt het zelf ook vreemd, maar toch hangt het bij mij regelmatig.


In Win2k was dit ook een probleem, maar daar is een patch voor uitgebracht ruim een jaar geleden.
Je mag aannemen dat XP deze patch ook bevat.
De Linux-developers wisten niets van de hardware bug af, en AMD heeft het ook nooit als hardware bug naar buiten gebracht.

'mem=nopentium'
Volgens mij ligt het dus WEL aan de kernel, want als je dit bovenste erin zet gebeurd het niet. Op zich niet raar dat een AMD een beetje anders omgaat met zijn extended paging dan een INTEL (aangezien het geen INTEL is :P)

edit:
Deze bug bestaat met Linux kernel 2.4 en het gebruik van een AGP videokaart
De AMD ATHLON bug treed echter alleen op met kernel 2.4 maar het ligt niet aan de kernel :?

Het ligt volgens mij niet aan de kernel, de regel die jij hier quote, zegt alleen maar dat de CPU geen Pentuim class CPU is, dus dat hij geen Pentium compatible core gebruikt.

Alleen gebruikt de Athlon dat dus wel, aangezien de CPU volledig x86 compatible is.

Veel bedrijven gebruiken de naam Pentium nou eenmaal in hun programma's en om aan te geven welke CPU er minimaal vereist is of welke CPU er gebruikt wordt.. Bij de systeemeisen zie je toch ook vaak "Pentium compatible CPU" staan.
De AMD ATHLON bug treed echter alleen op met kernel 2.4 maar het ligt niet aan de kernel
Het kan best zo zijn dat de 2.4 kernel de eerste kernel is die de Athlon op een bepaalde manier benaderd en wel zo dat voor het eerst deze "bug" naar voren komt.
edit:
Verder is deze bug niet echt problematisch, er bestaat dus al een workaround. Verder kan het natuurlijk niet anders dan dat de CPU's bepaalde bugs of rare feature's hebben, het is en blijft voorlopig nog wel mensenwerk en waar gewerkt wordt, worden fouten gemaakt. De CPU is nou eenmaal een ingewikeld stukje zand.

Mem=nopentium is een workaround.

edit /beaves was eerder, mijn verhaal kan weg.

Nee, het ligt aan de processor.
De functie waar de fout inzit is echter zo 'nieuw' dat hij bij de oudere kernels nog niet werd gebruikt. (Laat staan in windows XX)
De oplossing is ook: gebruik de geavanceerde optie van de pentium niet. (mem=nopentium)

Nee, het ligt aan de processor.
De functie waar de fout inzit is echter zo 'nieuw' dat hij bij de oudere kernels nog niet werd gebruikt. (Laat staan in windows XX)
De oplossing is ook: gebruik de geavanceerde optie van de pentium niet. (mem=nopentium)
Het ligt niet echt aan geavanceerde of nieuwe kernel-opties hoor. Dit is al zolang als de 2.4.X kernel er is.

Als je de kernel optimaliseert voor alles boven een pentium-classic dan zal er door de kernel gebruik gemaakt worden van extended paging. Dat is nou net de bug in de processor.

Het vreemde aan dit artikel vind ik wel dat er gezegd wordt, dat er een nieuwe bug ontdekt is, terwijl deze bug al 2 jaar bekend is. Het is alleen pas nu aan het licht gekomen, dat deze bug ook Linux systemen treft.

[edit]
overbodig?? :D
Er worden hierboven gewoon dingen gezegd die niet waar zijn, die ik even verduidelijk en dat is overbodig?

Ik heb het nog niet eens gehad over de uitspraak dat WinXX hier niet door beinvloed wordt. :/

Verder maak ik een opmerking over het artikel, die ik nog nergens heb terug gelezen.

Zoals er al staat gebeurd het met 2.4 kernel en AGP kaarten, dat betekent dat je dus wel gebruik moet maken van je AGP kaart.
Er zijn nu nog maar relatief weinig mensen die fanatiek gebruik maken van Linux EN een 2.4 kernel gebruiken EN een ondersteunde AGP kaart hebben EN ook nog eens een Athlon met deze bug.
Oja, en ook nog eens de kernel zelf gecompiled hebben met optimalisaties.

Aangezien AGP support nog erg primitief is zullen veel mensen de crashes niet gelinked hebben aan de processor, maar gewoon aan de kernel.

Blijkbaar is er nu iemand geweest die het als nieuws door de queue van een nieuwssite heeft gekregen.

Dus fanatieke Linux gamers !
Waarvan er ook best wel wat zijn ....
of tweakers die ook Linux draaien

Zoals er al staat gebeurd het met 2.4 kernel en AGP kaarten, dat betekent dat je dus wel gebruik moet maken van je AGP kaart.
Er zijn nu nog maar relatief weinig mensen die fanatiek gebruik maken van Linux EN een 2.4 kernel gebruiken EN een ondersteunde AGP kaart hebben EN ook nog eens een Athlon met deze bug.
Oja, en ook nog eens de kernel zelf gecompiled hebben met optimalisaties.
Alleen dat laatste is een vallide argument, omdat een kernel standaard met agpgart support wordt gecompileerd. Dit moet je specifiek uitzetten! Het betekent dat allen distro's die ik ken (zijn er toch aardig wat), daar gewoon mee gecompileerd worden.

Daarnaast zal juist de gamer onder Linux iemand zijn die zijn kernel zal optimaliseren. Dan heb ik het nog niet eens over een distro gehad die al bijvoorbeeld standaard geoptimaliseerd geleverd wordt voor een bepaalde cpu. Er zijn sowieso heel wat mensen (gamer of non-gamer) die hun kernel optimaliseren en dan kan je dus tegen bovengenoemde problemen aanlopen.
Aangezien AGP support nog erg primitief is zullen veel mensen de crashes niet gelinked hebben aan de processor, maar gewoon aan de kernel.
:? Hoe kom je erbij dat AGP-support primitief is? Het is er al zolang als AGP er is in Linux. Het is er in de vorm van de kernels agpgart of in de vorm van een vendor's eigen agp-driver.

De AMD ATHLON bug treed echter alleen op met kernel 2.4 maar het ligt niet aan de kernel
Het kan toch ook zijn dat de kernel code gewoon klopt. Alleen dat die code in sommige situaties gewoon op die bug stuit. Dan ligt het dus niet aan de kernel en toch aan de proc.

Fortunately, there is a quick and easy fix for this problem. If you have been experiencing lockups on your Athlon, Duron or Athlon MP system when using AGP video, try passing the mem=nopentium option to your kernel (using GRUB or LILO) at boot-time. This tells Linux to go back to using 4K pages, avoiding this CPU bug. In addition, it should also be possible to avoid this problem by not using AGP on affected systems.

Dus het ligt aan de manier van paging.....

edit: wow wat zijn jullie snel hierboven :)

Dit ligt dus niet aan de kernel zelf, want:
Here's the problem -- many Athlon and Duron CPUs experience memory corruption when extended paging is used in conjunction with AGP.
De Athlon en Duron ondersteunen dus wel extended paging. Echter, door een bug in de processors krijg je memory corruption door het gebruik van extended paging en AGP. Aangezien de kernel dus (terecht) probeert gebruik te maken van extended paging, krijg je door die bug in de processor vastlopers.

Dat je de bug niet ervaart door de optie "mem=nopentium" te gebruiken, wil niet zeggen dat de kernel de oorzaak is, maar dat je zo de bug in de processor vermijdt.

En dat AMD anders omgaat met extended paging dan Intel is hier niet het geval, het is blijkbaar gewoon een bug in de extended paging.

De patch voor Windows (2000) is al sinds september 2000 uit.

De grote vraag is natuurlijk om welke procs het allemaal gaat.
Waarschijnlijk gaat het zowiezo om:
- AMD Slot A
- AMD Duron (Spitfire)
- AMD Thunderbird (oude Socket A serie).

Dan maar hopen dat ie is opgelost in de nieuwe XP's, MP's en Duron (Morgan)

De performance-hit voor het aanpassen mbv mem=nopentium is vrijwel verwaarloosbaar...

Dus waarschijnlijk zit de bug niet in XP?

Of zou XP toch op 16bit 486 code gebaseerd zijn :+

Ik denk dat deze bug niet zo'n groot probleem is. Hij komt namelijk maar in een paar enkele gevallen voor. En de mensen die er last van hebben kunnen hem zo omzeilen.

Ik vraag me alleen af of deze bug ook tevoorschijn kan komen bij andere operating systems.

De patch voor Windows (2000) is al sinds september 2000 uit.
Ja dus :9

ik snap nu de titel niet meer.. brengt bug in AMD aan het licht.. in sept 2K was de patch voor windoos al uit? dan heeft windoos hem toch aan het licht gebracht?

Jawel, maar toen hebben ze het naar buiten gebracht als fout in Windows 2000 icm de CPU.
Nu blijkt het dus om een hardware fout te gaan.

Ik vraag me eigenlijk af, of je wel van 'n bug kunt spreken. Om ome Bill maar ff te quoten; "this is not a bug, but a feature" :) Het lijkt me iig dat die 4K pages toch al heel lang bekend moeten zijn bij div. programmeurs.
Wat ik me ook afvraag, of je door deze workaround 'mem=nopentium' niet meerdere dingen in je CPU uitschakeld.

Memory corruption bij het gebruiken van paging geen bug? Hoe wil je het wel noemen dan? Als de K7 het nou gewoon niet ondersteunde ofzo.. Bij progammeurs was ie dus kennelijk nog niet zo heel bekent (bij de developers van de linux kernel in ieder geval niet kennlijk). Dat komt ook omdat je als gewone progammeur er vrij weinig mee te maken hebt. Je alloceert geheugen via de kernel en kennelijk in sommige situaties gebruikt de 2.4 kernel page sizes van 4MB ipv 4K en dan gaat het in sommige situaties fout.. geen kleine bug hoor.

Ben nou beniewd wat de performance hit is van het uitzetten van deze feature (zowel specifiek alleen deze feature als de workaround die nu gebruikt wordt)..

Het scheelt behoorlijk in snelheid ja, dan kan je net zo goed op een 486 draaien.

And, this problem hits us because Linux 2.4 kernels compiled with a Pentium-Classic or higher Processor family kernel configuration setting will automatically take advantage of extended paging
Of te wel een bug in de kernel omdat men er vanuit gaat dat AMD Athlon/Duron dezelfde implementatie heeft van deze instructie als de Pentium chip. Het zou goed kunnen dat men bij het ontwerp van de "extended paging" in de athlon/duron niet helemaal strak heeft gehouden aan de norm, maar misschien ligt het ook gewoon aan de kernel.

Zelfde idee als zeg maar heel simpel, zijn je kleren te klein of ben jij te groot, waar leg je de schuld. Hier doet men dat bij de cpu maar kan net zo goed aan de aanroep van deze functie liggen.

Even over dat voorbeeld van die kleren, het is zelfs nog leuker.

Als die kleren te klein zijn gaat je moeder nog eens zeuren dat toen je broertje ze pastte in de winkel ze wel goed zaten en dat ze nu te klein zijn omdat jij ze niet past.

Het probleem is dat de Pentium en de Athlon families over de jaren uiteen zijn gegroeid. Het manifesteert zich hier doordat een optimalisatie voor de ene proc gezien wordt als een bug voor de andere.

Om op de kleren terug te komen. De kleren zijn niet te klein, jij bent niet te groot, maar jij bent gewoon niet je broertje.

AMD geeft aan dat de Athlon een Pentium (II) compatible chip is qua interface (en dan praten we over de instructieset), maar voldoet daar door die bug dus niet volledig aan. Dan moet je maar niet aangeven dat je Pentium (II) compatible bent. Dit is hoe je het went of keert gewoon simpelweg een fout van AMD en niet van de programmeurs van de kernel.


Kun je de volgende keer die merk namen niet weg laten. Je doet nu net alsof MSI altijd kut mobo's maakt. Terwijl dat helemaal niet zo is.

daarom zeg ik ook een "" goedkoop "" msi bordje..
MSI heeft gewoon heel veel verschillende series.
en als ik me niet vergis komt dit door veel handwerk.

( je moet het af en toe gewoon treffen ) :)
[edit] het gaat me er niet echt om welke merken precies maar wel om de testresultaten doordat er gezegt wordt dat mensen een computer hebben die blijft hangen bij films kijken door die bug.. kan aan meer dingen liggen wou ik daar even bij vermelden.[edit]

Een fout in de processor heeft echt niets te maken met het moederbord hoor. Dan kun je nog zo'n dure hebben, dat helpt echt niet die bug in je proc te verhelpen...
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 15:46
Vorige 13:59
VNU Media logo Powered by True

© 1998 - 2009 Tweakers.net - Alle rechten voorbehouden - Uw Privacy - Algemene Voorwaarden

Uitgever van: