Slashdot Mirror
Major Linux/Athlon CPU bug discovered
GeorgeFrancisco writes "I recently installed the nVidia drivers so I could play TuxRacer on my Athlon. Problem is it kept inexplicably hanging Linux. Now I know why. The CPU bug affects Athlon/Duron/Athlon MP AGP users. Fortunately there's a way around it, and: "Alan [Cox] is going to try to add some kind of Athlon/AGP CPU bug detection code to the kernel so that it will be able to auto-downgrade to 4K pages when necessary." Read more on the Gentoo Linux site."
http://support.microsoft.com/support/kb/articles/Q 270/7/15.ASP
Since September of 2000..
It really shows up if you use the pre-empt kernel patch. Ever since I added the workaround, things have been pretty solid. (not that it's been that long)
I don't think so. AMD reverse engineered the x86 and made their own implementation without Intel's crap in it.
AMD's version of the x86 that is in the Athlon and the Duron runs faster than Intel's chips because of this reverse engineering.
This bug could be a problem of reverse engineering the x86. It doesn't say Intel's chips have the problem.
--Metrollica
Add 'mem=nopentium' to your lilo/grub/whatever bootup or compile the kernel for i386 to avoid extended cpu operations. The fault is something in the page size extension and agp.. which is strange because I though agp would be more of a chipset issue than processor.
Karma whoring, here I come. Hopefully this server can withstand a mild slashdotting. Link
The site seems to be down. However, last week, I contacted nVidia about this problem on my two dual Ahtlon MP workstations (random hangs when OpenGL is invoked). So the quick answer is you can
Boot your system with following option on your kernel command line: "mem=nopentium"
or
Disable AGP in XFree86 config (i.e. Option "NvAGP" "0" in the "Devices" section).
nVidia clued me into the first approach about a week and a half ago. It made my system completely stable. However, there was still some texture flakiness in some OpenGL applications. Since my workstations are number crunchers (and thus Quake FPS don't matter to me), the latter option eliminated both the stability problems and the texture flakiness (at the expense of some graphics speed).
By the way, nVidia mentioned the same issue exists on Win2K / Athlon boxes.
Enjoy,
Kevin
Disable Fast AGP write (AGP Turbo?) in your BIOS.
. txt
Read the manual. http://205.158.109.140/XFree86_40/1.0-2313/README
It is impossible to debug closed-source
drivers like the NVIDIA one. So any NVIDIA
bugs can't be found.
But you say "this is an AMD bug"...
How could we know that? The presence of
closed-source drivers in the kernel made
us unable to determine what was at fault.
Video drivers can cause non-video problems,
so in all cases only NVIDIA can help you.
Shit happens. Work around it.
If their flow is the same as most other semis, they do functional verification both before (in simulation) and after tapeout. A chip is almost always rev'ed a few times before it get 'prodution' status and ships to customers in large quantities. Looks like they had a hole in their functional test plan and missed this one.
Almost definitely not. It sounds like the existence of this bug was not known until recently and K7 options almost definitely enable all memory enhancements.
Just as an aside, if you ever deal with ultrasparcs, you'll quickly find that the majority of the code used is 32 bit.
The reason for it is simple; most applications will run slower at 64 bit than at 32 bit. The ultrasparc chips were designed to take this into account. Hell, due to a firmware bug, solaris on my ultra 1 installs as a 32 bit kernel by defualt - and runs no slower because of it (although it can't run 64 bit apps that way). After a firmware patch, it is easy to change to running the 64 bit kernel though.
In all reality, why would most apps need 64 bit integers and whatnot? Most don't, and doing so is a waste of memory. If the processor is designed right, it can handle 32 bit code with no problems whatsoever.
Those who can't do, teach. Those who can't teach either, do tech support.
Funny, I knew something was wrong...
dominionrd.blogspot.com - Restaurants on
Thank you for your attention.
-- Could you use my software consulting serv
Quake 3 demo was run with \timedemo 1 and \demo DEMO001 . Each test was run three times. The system load average was < 0.5 before Quake 3 was run.
Without mem=nopentium
FPS = 79.4 (79.4, 79.4, 79.4)
With mem=nopentium
FPS = 79.2 (79.1, 79.3, 79.2)
System tested:
Athlon 850, 384MB RAM, Geforce 1 DDR, VIA KT133 Chipset
Athlon/Duron/K7 optimised 2.4.17 kernel (optimising the kernel above pentium makes very little difference though)
NVidia 1.0-2313 video drivers using agpgart
Mandrake 8.0
Quake 3 settings
Texture depth = 16 bits
Colour depth = 16 bits
Geometric detail = High
Texture detail = High
Dynamic lights = On
Video mode = 1024x768
Looks like there is a difference but it's very slight (0.003%) but my benchmarks aren't very scientific. Either way, if there is an improvement in stability this tradeoff is easily worth it. Here's hoping that you don't run linux just for it's Quake 3 scores though...
Several processors had self-test instructions known as "HCF". The 6800 family and the 6502 had such instructions. They caused the processor to start fetching consecutive locations, thus continuously incrementing the address bus. Didn't damage the processor, even if you left it running that way. The "Catch Fire" was a figurative description of what was happening on the address bus, nothing more.
On the original NMOS 6502, about 13 of the undefined opcodes had this effect. This was the most common cause of computer lockups if the code went into the weeds.
On some of the later 6800 family members, the test instructions were actually documented, but Motorola's published description did not include any mnemonmic for them.
You may want to take a look at the benchmarks posted later.
no problems on FreeBSD, apparently
Maybe it sheds some light on this issue.
Recently purchased 2 XP 1600+s (1 in Dec and 1 in Jan) - both indicate they are Rev A5 (CPUID 662) and do not have the INVLPG bug according to AMD's errata sheet.
Yes, UltraSPARC's run significantly slower in 64 bit mode. IIRC, this is because it takes more instructions to load 64 bit constants and access 64 bit pointers. This is not true of all 64 bit processors -- and it is not true of x86-64.
The x86-64 architecture allows 64 bit programs to take advantage of the extra precision (and doubles the number of general-purpose registers, which x86 desperately needs), without forcing them to take the performance hit of using the full 64 bit addressing. It also adds a new, IP-relative addressing, which makes position-independant code (ie, shared libraries) much more efficient. There will be an increase in code size (and possibly a performance drop, but this depends on how AMD implements the 'movabs' instruction) when you start using more than 4GB of data. And, when you start using >4GB of code, things get yucky (requiring indirect jumps).
But, the point is, x86-64 will run all your 32 bit x86 code at full speed, and if you're able to re-compile your programs for 64 bit mode, you should get a performance boost, if only from getting 9 more registers (8 + no longer need to keep a pointer to the GOT).
It's not a matter of the type or quality of the memory but how the chip address the memory. There is a flaw in the chip itself. A layman's analogy might be: if a telephone book only list the first 5 numbers of a phone number. What you are suggesting is to replace all the telephones in the world. Even if you do, the phone book still won't work because the phone numbers are incorrect. What has to be fixed is the phone book [or the way of finding phone numbers]. Go here for more technical information.
_______________________________
"I'm not Conceited...I'm just a realist..."
Basically, if you run "cat /proc/cpuinfo" and see these:
cpu family: 6
model : 6
stepping : 2
Then you should be safe.
I've posted this elsewhere but to clarify - it looks like this will still happen regardless of which processor you have selected (even i386!). This is because the test for whether your processor does pse seems to be run on startup (I think it's done by arch/i386/mm/init.c __init pagetable_init).
As an aside, as far as I can tell the only (extra) things that optimising a kernel for a K7 seems to set are gcc options (someone please correct me if I'm wrong).
The AMD erratum says that it is an issue if bit 21 of an address is actually 1. Thus you may have been lucky in where your video card got mapped.
Roger.
Cool, that includes my Athlon XP which I picked up this week!
It saves page table entries, which saves an irrelevantly small amount of memory.
Much more importantly, it saves TLB entries, which makes more room for user memory, speeding up virtual->physical translations.
I have an AGP Nividia Geforce 2 MX, and an AMD K6-3 333 MHz. I have experienced these memory corruption, graphical anomolies, and lockups in linux and windows 95.
I noticed that AMD K6-3 was not mentioned, but it has to exist on it. The K6-3 was made with the same instruction set as a pre-Athlon. Thus the bug definately exists.
Not sure about K6/K6-2, but it is possible.