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."
Instead of saying "oops, there a hardware bug", they said, "oops, here' a patch for w2k". Looks like none of the kernel developers knew they had to look a w2k bug fixes to find out about hardware bugs.
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
The performance hit for using the smaller pages is mostly unrelated to paging. When a CPU loads an virtual address (all addressing in "protected mode" is virtual), there is a translation to a physical address before data can be accessed. This table is stored in memory and the CPU breaks into kernel mode to do the translation. To avoid this cost, there is a cache of translations (managed by the kernel) in the Translation Look-aside Buffer (TLB). Most of the entries in this cache are for 4kb pages, but there are a few 4mb pages which are generally used for kernel memory (I am unsure if any OSes use the big pages for user programs).
That said, there should be a modest performance hit. Bigger pages can store more data, which results in fewer TLB misses. Hopefully someone will post benchmarks.
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.
MShaft: "Not-a-bug-it's-a-feature"
Intel: "Not a bug it's erratum."
VIA: "We slowed it down to keep it cool."
Nvidia: "That was a leak! We are not doing public driver beta testing!"
ATI "Who the hell plays Quack3?"
AMD "the patch is here"
If voting were effective, it would be illegal by now.
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...
The current workaround gets around this problem by disabling 4M (2M?) pages (PSE). Hence we go back to 4K pages, and mapping large slabs of VM is a little slower and wastes memory (we need another Page table for each slab of 4M) and obviously more TLB misses/space wasted, because to touch the whole 4M region, the CPU needs to do up to 1024 page table lookups instead of 1.
:-)
As discussed this may have performance implications.
According to the AMD docs, the problem is only when flushing TLB entries with INVLPG and the page is a 4M page, _and_ the virtual address's bit 21 is set (which does not affect the 4M block of memory the address is in - eg: 0x400000 (2^22) vs 0x600000 (2^22|2^21) are both in the second 4M block).
Hence, when invlpg'ing a VA we just need to INVLPG(address&~(1 (leftshift) 21)). This only requires a single ANDL instruction. But we need to distinguish a 4M page first though, so I don't know?
Heck maybe we should just do it the FreeBSD way and recursively map the Pagedir
Any ideas? Will this work?
--JQuirke
None of the Athlons or Durons I've built have had any problems with Tux Racer (Mostly on Man8.1 default install).
My nephew spends hours Sliding that little penguin arround with that bloody elevator music going, & not once has there been a freeze or lockup, much to my dissapointment.
Maybe it sheds some light on this issue.
First of all, this bug is not that significant performance wise. Very little software is going to use 4 MB pages. I don't think you even have an option of allocating memory with 4 MB pages in user space. This appears to be an issue with being able to optimise drivers, however, if AMD's processors can't do this, and Intel's can, why don't we see Intel's processors greatly outperforming AMD's in Win2k? This is a minor bug, and it's easily worked around without patching the kernel in both Win2k and Linux.
The processors are basicly all their Athlon and Duron processors. For AMD or any chip maker to replace chips with bugs in them is VERY expensive. They already have a low profit margin. Replacing all "defective" Athlon and Duron processors would simply bankrupt AMD. Realisticly, all complex software or hardware has bugs. Bugs in hardware are much more difficult and expensive to fix. The truely significant hardware bugs are usually found early in testing. Other bugs are fixed in software, usually in the system BIOS, but sometimes in the OS code. This isn't something new. It's pretty much always been this way. Why has it been this way? Because no one wants to pay the outlandish prices that would result from trying to make hardware perfect. It costs a tremendous amount of money to reroll a processor. It's not as simple as making a quick code change and recompiling software. THERE WILL ALWAYS BE BUGS IN PROCESSORS! A truely significant bug like the Pentium floating point bug needs to be fixed in the hardware, and that one was even significant enough to deserve a recall of the processor. This bug is simple to work around, and isn't truely a significant problem.
The question you asked in the subject is "Should AMD do the right thing?" The answer is yes, they should correct their Technology Bulletin to actually say what the processor bug is, rather than just say here's a workaround to a bug that effects Win2k.
I'm really surprsed that someone at NVidia didn't pass this on to Linux kernel developers much sooner, since people at that company seem to have been aware of this for some time.
Basically, if you run "cat /proc/cpuinfo" and see these:
cpu family: 6
model : 6
stepping : 2
Then you should be safe.