Slashdot Mirror
Tracking Down The AMD "Processor Bug"
tercero writes: "over at the Gentoo Linux website there is an update on the AMD processor bug mentioned here. The sum up is that AMD claims it's not a bug with the Athlon processor, but with the motherboard. More detailed information can be found on this LKML post."
An Anonymous Coward points to a similar explanation at Linux Weekly News.
Update: 01/25 01:25 GMT by T : Daniel Robbins from Gentoo clarifies: "AMD is not
calling this a 'motherboard' issue, it is an interaction between a
feature of the Athlon called 'speculative writes' and the design of the
GART, which is not cache-coherent. It's a 'Athlon/cache coherency/GART'
problem, not a 'motherboard' problem."
2+2=3.9999999999999999999999999999983774
Oh wait that ws Intel.
Hammer of Truth
According to young bald children everywhere, "There is no bug".
In related news, the motherboard manufacturers are quoted as saying, "It's not a bug with the motherboard, but with the Athlon processor."
--SC
You read fiction? I write it! Lemme know what you th
And it's never our program that has your bug.
Meanwhile, we're feverishly fixing your bug in our software.
"Yes sir, we've patched around the OS problem and this should get rid of that nasty bug you were seeing."
Don't blame AMD entirely. They acknowledged the bug back in September of 2000 and immediately released patches for Windows 2000. Consequently, it doesn't affect users of Windows XP either. It's been around for over a year and now it's "news"? This should've been fixed in the Linux kernel months ago. Sorry for sounding so harsh.
If you celebrate Xmas, befriend me (538
It's an optimization for Windows XP!!
ender-iii
The kernel will look for the parameter
/etc/lilo.conf configuration file.
mem=nopentium
and turn off 4MB pages (which may or may not prevent the problem from manifesting -- the situation is unclear at this time). You can do this at the boot prompt like this
LILO boot: linux mem=nopentium
or by placing the configuration directive
append="mem=nopentium"
in your
See the manual page for lilo.conf for the details.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Mac users don't have to worry about using the term 'Gigahertz' either.
"Derp de derp."
This is embarassing to the Linux community as a whole, and It also explains why I've had problems with crashes on two different systems running Linux and Athlons.
What I don't understand is how this could have made it so far? This is exactly the sort of problem I have been telling people we don't have in the Linux world, and now it looks like I was wrong. Is this pointing out an underlying problem we have with QA in the Linux kernel? With Open Source in general? What can we do to make sure that a bugs of this magnitude are detected more quickly?
Sigs are awesome huh?
Yesterday, information became widely available that described possible stability issues (system crashes, hangs, etc.) when using an AGP video card under Linux in conjunction with an AMD Athlon processor. It was generally called a "bug" in the Athlon CPU.
2 6960/.
More information is now available at http://www.gentoo.org, including an analysis of AMD's response. AMD's official response was posted to LKML, and is available at http://www.geocrawler.com/lists/3/Linux/35/175/76
There is apparently some kind of bad interaction between the AGP GART ("Graphics Address Remapping Table", I think?), speculative memory operations performed by the Athlon processor, the memory mappings used by the kernel, and cache coherency. The details are beyond me, but the practical upshot appears to be that the wrong data ends up being written back to main memory at some point.
I recommend reading the above LKML thread if you suspect you are affected by this issue. Information is still being uncovered, and it is not immediately clear how this occurs, what causes it, who is affected by it, and how to work around it.
In particular, there is some uncertainty as to whether the "mem=nopentium" option actually prevents the problem, or merely makes it less likely to occur.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Recently one of my friends, a computer wizard, paid me a visit. As we were talking I mentioned that I had recently installed Windows XP on my PC. I told him how happy I was with this operating system and showed him the Windows XP CD. To my surprise he threw it into my microwave oven and turned it on. Instantly I got very upset, because the CD had become precious to me, but he said, "Do not worry, it is unharmed."
E lO E5IOCC98D444AA08EI324
After a few minutes he took the CD out, gave it to me and said, "Take a close look at it."
To my surprise the CD was quite cold to hold and it seemed to be heavier than before. At first I could not see anything, but on the inner edge of the central hole I saw an inscription, an inscription finer than anything I had ever seen before. The inscription shone piercingly bright, and yet remote, as if out of a great depth:
12413AEB2ED4FA5E6F7D78E78BEDE820945092OF923A40E
'I cannot understand the fiery letters,' I said in a timid voice.
"No but I can," he said. '"The letters are Hex, of an ancient mode, but the language is that of Microsoft, which I shall not utter here. But in common English this is what it says:
'One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them.'
It is only two lines from a verse long known in System-lore:
'Three OS's from corporate-kings in their towers of glass,
Seven from valley-lords where orchards used to grow,
Nine from dotcoms doomed to die,
One from the Dark Lord Gates on his dark throne
In the Land of Redmond where the Shadows lie.
One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them,
In the Land of Redmond where the Shadows lie.'"
AMD claims it's not a bug with the Athlon processor, but with the motherboard
According to young bald children everywhere, "There is no bug".
In related news, the motherboard manufacturers are quoted as saying, "It's not a bug with the motherboard, but with the Athlon processor."
Funny, I didn't think I was bald...
It's an Athlon bug if you think doing speculative writes is a bug.
It's a motherboard chipset bug if you think that the AGP controller should play nicely with cache-coherence protocols (right now it doesn't, presumably to gain a speed boost).
It's an OS bug if you think that the OS should be bright enough not to make AGP-touched memory cacheable (it wasn't intended to be).
I'm voting for option 3), myself.
From the LKML post linked in the story, it seems it's because some 4MiB pages (I couldn't understand why 4KiB pages aren't affected, if they effectively are not) are allocated for the AGP (GART more specifically) with some bits set telling it is cacheable.
Why would somebody want to cache the AGP memory? I'm pretty sure it's used 99.99% of the time as write-only memory, because it's the main output method of most computers. What's the point of caching that? It can only prevent the use of the CPU cache by some more important things, no?
Feel free to correct me if I'm wrong, I'm not very familiar with the usage of AGP memory (or GARTs).
Hmmmm.
Is the Bug...
- (A) In the Athlon cache?
- (B) In the chipset?
- (C) In the AGP-using devices misusing memory?
- (D) In the Linux kernel?
Well, AFAICT, the real bug is in the communication of relevent knowledge.These kinds of bugs would have significantly shorter duration if the specifications for all four possible culprits in (A)-(D) were openly published, completely, for all to see.
"Provided by the management for your protection."
Well, based on my reading of other posts, it is a simple case of AMD taking advantage of some features of AGP that are within spec that Intel is not. When the OS assumes that things are done Intel's way instead of adhering to the spec, things will show up on an AMD processor and not on an Intel.
AMD is doing things correctly, albeit differently from Intel. This is exactly how we are supposed to believe that it's not an AMD bug.
T
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
When Linus switched to the AA VM, I got the impression that one of the key differences between the AA VM and the RvR VM is that Rik's VM is much more flexible, but with that flexibility comes complexity, which is why Linus switched to AA's VM. AA's was much simpler to understand and helped to stabalize the VM problems. Does the above quote mean that the AA VM isn't going to be able to handle the requirements to fix this bug? Is this a plug to put back RvR's VM?
I'm not trying to start a flame war here, just want to understand if I understood what the final paragraph was saying. Please mod me down if I'm way off base, but help me understand too!
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
>Lower costs typically means lower perfomance
.. in CPUs, it's the value of a larger consumer base, which essentially translates into a higher possibility of latent design flaws (ie, they exist in the costlier platform as well, but are found earlier because of the larger user base), and the value of being in the same boat as everyone else should a product fail in some fashion.
/doesnt/ work, thats not performance; it's either compatibility with the outside world or a design flaw. Anyhow, I feel sorry for your view, because I guess you're paying alot of money for brand security .. but everyone in-the-know computer geek I know (I'm a C++ developer, so I'm not talking tech fanboys here) knows that you'd have to enjoy wasting money to justify buying Intel CPUs at this point in time.
.. it has already been fixed in Windows, and there is a known Linux workaround. So really, there's not much of an issue, and my AMD chip still cost me half the price of an Intel CPU, and benchmarks faster than the Intel, to boot! Keep buying your Nikes! I just want the shoe. :)
What planet are you from? Lower costs (in the case of demonstrated similarity in performance) typically means lower demand and lower consumer valuation of the brand name, which means smaller user base, which means that it generally takes longer to run into compatibility flaws.
For instance, Nike is more expensive than Puma. Does that mean Nike shoes are better? Of course not, it means people are more willing to buy Nike, because they percieve that the brand gives them additional values. In the world of shoes, that value is the value of conformity and fashion
Thue funniest thing is you're talking about performance. Performance is how well something works when it works. When it
Lest you cite this situation as a reason why I might be wrong
"Old man yells at systemd"
According to the article, it is not a problem with the motherboard at all. The problem is "the operating system is creating coherency problems within the system by creating cacheable translation to AGP GART-mapped physical memory." That means it's a problem with the OS, not with the motherboard or processor.
In truth, we should probably say it is a combination of a problem with the OS and a problem with the processor. After all, Intel processors don't have the same problem, simply because they work differently. So while it may not technically be the CPU's fault, the CPU does play a part.
Interestingly enough, this feature of AGP is not really critical to increasing performance in games - in fact, it could be counterproductive to it.
The AGP GART (Graphics Address Remapping Table, I believe) maps "video card memory addresses" to "main memory addresses", i.e., it's to allow the graphics card to grab textures, etc. directly from main memory without going through the CPU.
Many motherboard manufacturers use this feature to provide on-board video without any dedicated memory so they don't have to include any additional memory for the graphics card.
Of course, since this blows so massively performance-wise, it's mostly abandoned now.
Is the GART actually useful for anything except extending the video card's onboard memory? I'm not really sure...
You are assuming that AMDs current explanation is 100% true, correct, and complete. There are good reasons to doubt this.
The "explanation" so far has just raised more questions. Why does the same code that causes the athlon to crash work fine on pentiums? Apparently the GART is cacheable on pentium systems? And the Athlon is billed as pentium-compatible...
Why does disabling large pages fix the problem? If their explanation is correct, that fix should not work, because it doesn't address the issue they claim to be the problem.
I'm sure this will get worked around in software (and the linux fix will actually workaround the underlying problem, rather than just making it less likely as the windows world seems to be satisfied with) once the real details of this are known. But to claim it's not a hardware bug is ludicrous. It's a bug with the Athlon CPU, or with certain GARTS found in Athlon chipsets, or both. If AMD were less worried about spin-controlling it and claiming it's the software at fault maybe they would be more forthcoming about what is really going on here.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
While the use of the GART you mention (video chipsets with no onboard memory) really does suck, performance-wise, the GART itself is not useless. Most games today limit themselves to 16MB or so of textures, so that they run properly, without swapping to main memory, with a 32MB video card. However, if you want a game with 256MB of textures, say, you have three options.
1) Get a video card with 270+MB of memory. (Yeah, right.)
2) Snatch from main memory the portions of the texture you need. (This gets slow AND ugly if you use more than ~16MB in a single frame.)
3) Use the GART, take (less of) a performance hit, and just keep the textures in system memory.
This was the original purpose of the GART, and is still important.
I've had this sig for three days.
...Slashdotters that always point out their favorite OS isn't vulnerable to a particular bug.
My Macintosh isn't affected by this bug due to its PowerPC processor.
I have a website. It's about Macs.
BOy where have I heard that before... oh yeah every 2 years since there have been macs..sheesh.
FYI I don't own a mac, but I will purchase one next time I want a computer.
The Kruger Dunning explains most post on