Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
AMD

Tracking Down The AMD "Processor Bug" 237 237

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."
This discussion has been archived. No new comments can be posted.

Tracking Down The AMD "Processor Bug"

Comments Filter:
  • Bug? (Score:4, Funny)

    by smack_attack (171144) on Thursday January 24, 2002 @03:26PM (#2896180) Homepage
    2+2=3.9999999999999999999999999999983774

    Oh wait that ws Intel.
  • by SpookComix (113948) <spookcomix@@@gmail...com> on Thursday January 24, 2002 @03:26PM (#2896181) Homepage Journal
    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."

    --SC

    • All of the above. (Score:5, Informative)

      by Christopher Thomas (11717) on Thursday January 24, 2002 @03:42PM (#2896286)
      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.
      • by denzo (113290)
        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.

        I think this revelation makes this parent worthy of being modded up.
      • 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.


        I don't know about that... if you'll recall there have already been pre-emptive blamings from the Linux gurus, so since they're always right, well, it must be something else.

        So I quote from Gentoo.org:
        The bad news is that a major Athlon CPU bug has been discovered, and it affects Linux 2.4. Note that this is a bug in the actual CPU itself, and is not a Linux bug.

        And:
        And, the kind folks at AMD even created a simple patch for Windows 2000 that disables extended paging by tweaking the registry.

        Cache coherency aside, what about logic coherency? These were posts in the same article. To me, it seems as if the Linux guys and gals are ready to blame everyone else but themselves (sounds like the phone company!).

        So quick to blame others... but why not? I mean, if everyone believes you, then you're good to go!
        • And, the kind folks at AMD even created a simple patch for Windows 2000 that disables extended paging by tweaking the registry.
          Cache coherency aside, what about logic coherency? These were posts in the same article. To me, it seems as if the Linux guys and gals are ready to blame everyone else but themselves (sounds like the phone company!).
          Ermh, the bit about that windows registry tweak actually speaks in favor of Linux (i.e. t'is indeed a hardware bug). Indeed, the following questions come to mind:
          • Wow, Windows and Linux stricken by the same bug. What's the probability of that?
          • Why didn't they simply tweak the registry to make that 4MB AGP section non-cacheable, rather than switching off 4MB paging altogether?
      • by Stiletto (12066)
        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.


        I thought one of the main benefits of AGP was the ability to remap a bunch of non-contiguous physical blocks into one address space, so the entire bunch could be marked as cachable (for instance when DMA'ing a bunch of vertices across the bus).
        • Why would you cache memory for DMA? It doesn't go through the processor (that's the Direct part) so you certainly wouldn't store it in the processor's cache. In fact, you'll only be accessing each location once, to copy it across the bus. Unless the memory can be read from ram faster than it can cross the bus, but I don't think that's the case...
        • The main motivation for the development of AGP was to allow the graphics contoller to use main memory rather than its own separate memory, at a time when memory was getting more expensive.
    • by 4of12 (97621)

      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.

      • I was going to mod you up till I read your last sentence. :)

        Open sepcification? The OS is open source. That doesn't mean that anybody in their right mind would want to read through it, but it's available.

        Chipset specs are all agreed upon by a standards body, as are the bus specs. It's not like any one manufacturer was keeping a protocol secret so everybody just guessed at it. If you want to see them, go ahead, I'm sure you can find information. It's not going to be dumbed down and summarized for you though. It's going to be white papers with lots of weird electrical diagrams and acronyms.

        What we're seeing here is when several layers don't correctly define or handle an error condition. You can compare it to U.S. laws. They define the general outline but don't actually define every possible parameter, they let the courts handle the specific details. Consider the OS the court.

        So most likely, something was left out of the spec and assumptions were made by several different manufacturers who each has their own take on how it should be done.

        But, since the software is easier to change than the hardware, that's the logical place to fix it. It doesn't take all the complaining and finger pointing that's going on this site. Just fix the damn thing, release an update, and move on. Although it's very interesting to see how so many bruised egos defend themselves in the ways that so many of us complain about when our enemies use those tactics.
    • AMD claims it's not a bug with the Athlon processor, but with the motherboard
      I got a question.

      WHICH MOTHERBOARD?? I've got a bunch of customers with AMD's and NVIDIA-custom-driver setups out there in the field, KT-133A and KT266 and AMD-760 chipsets, that are seeing zero problems and wondering WTF is going on.

      So am I.

      Is this specific to the NVIDIA chipset or something? I've never seen this thing manifest.... what does it look like? I saw the guy say Windows went blooey... what would it do in Windows? Signal 11 the X server? Hang the box? Oops?

      The world wonders here, and I'm not getting very many details.

  • by Anonymous Coward on Thursday January 24, 2002 @03:28PM (#2896194)
    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."
    • "Yes sir, we've patched around the OS problem and this should get rid of that nasty bug you were seeing."

      So you code Windows apps then...

  • by ekrout (139379) on Thursday January 24, 2002 @03:30PM (#2896202) Journal
    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.
    • It would have been fixed months ago if AMD had labeled it a hardware bug. It was billed as a "Win2k Bug" and quite naturally Linux hackers don't tend to pay much attention to that class of problems.

  • by ender-iii (161623) <adam@nullr[ ]r.com ['ive' in gap]> on Thursday January 24, 2002 @03:30PM (#2896206) Homepage
    It's an optimization for Windows XP!!
  • what exactly is the percentage of chips affected? i've been personally in the presence of 3 different athalon-based systems for extended periods of time that did not seem to have this problem.
    • Information is still sketchy, but this appears to be a design issue (i.e., different components interacting badly due to assumptions) rather than a bug. It could even happen on non-Athlon systems, if the processor in use happens to tickle the same conditions.
    • Good question. The day this news was posted to Slashdot was the very day I went home from work and installed a new video card to create the nightmare scenario:

      Red Hat 7.1
      PNY Verto AGP vidcard (nVidia GeForce 2 MX400)
      AMD Athlon 1200
      Asus A7A-266 motherboard with ALi 1647 chipset (bad AGP problems)

      The result? It's working like a dream so far.

      To be fair I should point out that I've not tested the video card with anything more stressful than playing a few DVDs, and the longest I've had the computer turned on was about 4 hours.

      One thing that confused me was that the documentation for the nVidia driver said it would automatically disable AGP if it detected the chipset I have on my motherboard, but the drivers output from X startup says it's running in 4x AGP mode. Curious, but not unpleasing as long as things keep running well.
  • Today, software and hardware vendors across the world have finally released full specs on all their previously 'closed-source' products, taking blame for inherant 'bugs' or flaws.

    In other news, Nintendo has signed a deal with Microsoft and Sony to port their world known games to the competitors console systems, and slashdot users deem Windows XP 'pretty okay'.

    Film at 11.

  • by jidar (83795) on Thursday January 24, 2002 @03:38PM (#2896259)
    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?
    • by Grelli (98061)
      This is embarassing to the Linux community as a whole

      Actually, it isn't embarassing at all. It wasn't the "Linux Community"'s fault. This is the fault of AMD who anounced/classified the bug as a Windows 2000 issue instead of a hardware issue. Many posters have pointed out that kernel hackers probably don't follow hardware bug reports for OTHER operating systems.

      The failing was on AMD's part, and nobody else. But don't get me wrong, I love AMD, and this won't change my overall opinion of them. If things like this continually happen, then I may have to reconsider. But if this is a one time thing, I'm not going to get overly mad, and I hope no-one else does either.

      • by Dahan (130247)
        Actually, it isn't embarassing at all. It wasn't the "Linux Community"'s fault. This is the fault of AMD who anounced/classified the bug as a Windows 2000 issue instead of a hardware issue.

        If you read the technical writeup on LKML, you'll see that it's not a hardware issue, but a software bug. Which is why AMD announced the bug as a Windows 2000 issue--it is one. Linux also happens to have the same bug (it's a subtle issue and an easy mistake to make, IMO), but how was AMD supposed to know that Linux was doing the same bad thing--mapping the AGP GART area cacheable, when the GART is non-cacheable?

        • by LordNimon (85072)
          but how was AMD supposed to know that Linux was doing the same bad thing

          Oh, that's easy. The engineer who discovered the problem should have realized that it's not necessarily a Windows-specific issue, but a problem that any OS could have. He should have then tried to contact all the OS vendors, not just Microsoft.

          Considering how Linux is used by a higher percentage of AMD customers than Intel customers, AMD should have paid more attention to an important segment of its customer base.

        • by Arker (91948) on Thursday January 24, 2002 @04:25PM (#2896539) Homepage

          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.

          • by Salamander (33735) <jeff@nospaM.pl.atyp.us> on Thursday January 24, 2002 @05:26PM (#2896879) Homepage Journal
            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...

            There are different types and levels of compatibility. The Athlon claims base-instruction-set and register compatibility with the Pentium, but it's not pin-compatible and may also differ in any number of behavioral/timing characteristics. This is one such case. The behavior in question is perfectly acceptable within the bounds of the compatibility and standards compliance that AMD claims.

            Why does disabling large pages fix the problem?

            Because it's the large pages that are (incorrectly) marked as cacheable. No large pages, no incorrect mappings, no problem.

            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.

            Nope. It's a bug in the OS. Anyone who works with memory systems should know the dangers inherent in mixing cache-coherent and non-coherent accesses to the same memory, and should mark pages accordingly.

            It's very tempting to criticize AMD for their handling of speculative writes, but that handling is really irrelevant. It seems to me that the cache line's contents should not be marked dirtybefore the processor has actually written to it (which in this case it never does). Under normal conditions, though, this would only be a performance issue. If a coherent access were made from elsewhere, invalidation and writeback would ensue; the writeback would be unnecessary but not harmful, because it would be writing the same data that were already in main memory. However, the cache wouldn't be involved in the first place if the pages were mapped correctly. There would be no write-allocate, no invalidation, no writeback, and no problem. The invalid mapping turns a slightly silly but legal and normally-harmless processor behavior into a serious coherency problem.

            • It's very tempting to criticize AMD for their handling of speculative writes, but that handling is really irrelevant. It seems to me that the cache line's contents should not be marked dirtybefore the processor has actually written to it (which in this case it never does).

              That's only half of the issue -- and certainly not illegal behavior. If the line first went into 'E' state, you would still have a coherency problem if you later did a write. Although, true, the issue only becomes visible if you go straight into 'M' state.

              I think the real root of the problem is that they are doing speculative writes (obviously, they mean 'speculative reads-for-ownership' since speculative writes are highly illegal in IA32) into a page which the processor is not storing to.

              If the OS knows that it is not going to do any loads or stores to a page, it should have the right to give the page any memory type it wants, and it shouldn't have to worry about coherency issues, because, as far as the software is concerned, the processor is not a participating agent on the bus.

              IMHO, it's a processor bug, but obviously one that's very easy to workaround (make the memory UC, even though you're not using it).
          • by Dahan (130247) <khym@azeotrope.org> on Thursday January 24, 2002 @05:29PM (#2896904)
            Apparently the GART is cacheable on pentium systems?

            There are Pentium systems with an AGP port? If you mean the Pentium II and up, I don't see why the GART would be cacheable there either; I don't know if the P4 chipsets have changed things, but with the PII and PIII, here's what Intel had to say about the subject:

            For current hardware implementations,
            the OS will make AGP memory (like other video memory) non-cacheable, so that there is no coherency problem between the CPU caches and the data that the graphics controller uses. Otherwise, graphics controller accesses to AGP memory would require "snooping" the CPU caches, which would cause delays in execution in some cases.

            -- AGP and Graphics Optimization Techniques [google.com]

            (Emphasis added). As for why the bug doesn't happen on Intel CPUs, it sounds like the Athlon has more aggressive speculative writes and can change memory that wasn't explicitly written to, dirtying the cache. But in any case, even on Intel CPUs, the AGP area is supposed to be mapped non-cacheable.

            Why does disabling large pages fix the problem?

            Don't know about that one; I haven't read the various tech docs for the Athlon. Perhaps the cache works slightly differently with 4MB pages vs 4KB pages?

        • by whovian (107062)
          how was AMD supposed to know that Linux was doing the same bad thing-

          How did AMD know that Windows-* was doing the bad things? I guess it didn't occur to AMD to download and inspect the kernel source code or talk to the linux kernel mailing list(s) and developers? It seems to me that that is effectively what they would have had to do with Microsoft.

          OFF-TOPIC: This sort of touches on the point another poster made 1-2 weeks ago or so. I probably will recall the specific accusations incorrectly (and hence flamed), but the gist of that post was the hypothesis that AMD has a loyal following of users, in particular linux users, and it would be nice if AMD reciprocated a little in recognition of that. I am largely ignorant of AMD's contributions to the community per se, so put the flame on a low setting, ok?, as I am an AMD newlywed myself :)
          • by Dahan (130247)
            How did AMD know that Windows-* was doing the bad things?

            Maybe because Microsoft reported the problem to them and asked for help?

            Perhaps I worded my question poorly--why would AMD even think that Linux had the same bug as Windows 2000? Whenever you see a Windows bug, do you usually wonder if Linux has the same bug? They're completely different codebases, and there's no reason to think that a bug in one OS would be present in the other.

  • More information (Score:5, Informative)

    by DragonHawk (21256) on Thursday January 24, 2002 @03:39PM (#2896264) Homepage Journal
    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.

    More information is now available at http://www.gentoo.org [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/762 6960/ [geocrawler.com].

    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.
    • I have a Soyo Dragon Plus with an XP 1700+. When I don't run X, my system works fine. However, under X, I get random lockups of the entire system. I've tried the mem=nopentium, and while it doesn't crash as often, it still crashes. I've also tried the kernel AGPGART code, and tried using on the AGP stuff included with Nvidia's kernel driver, but I still get the same crashes.

      This is actually getting quite annoying. When I was running kernel 2.4.8, it only locked up once every couple of days, but using 2.4.13 or 2.4.17, I get lockups almost every time I'm using X. My system is basically unusable right now, which really sucks. I hope they find a solution soon because I don't really like having to drag a windows laptop home with me every night.
  • by Anonymous Coward on Thursday January 24, 2002 @03:42PM (#2896280)
    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."

    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:

    12413AEB2ED4FA5E6F7D78E78BEDE820945092OF923A40EE lO E5IOCC98D444AA08EI324

    '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.'"
  • it's not a bug with the Athlon processor, but with the motherboard

    I somehow wonder if this is related! I had a P3 system, with Gforce 2head card everything was working fine, I replaced the motherboard for an ASUS P4B, and a intel P4 chip. Ever since I intermitently get a BSOD, (bad pool caller).

    Point is, isn't this very similar to the problems that AMD were reported on Win2k system without the patch?

  • Well, I'll be (Score:1, Informative)

    by Anonymous Coward
    Well, I'll be darned. Vendors pointing the finger at each other. Who'd have thought?
  • I'm running M$ Windoze on an Athlon 750. I noticed that the system crashes on a few occasions. Specific incidents where a crash can be predicted is when I
    • Play Diablo II on Battle.net. The crash occurs when I try to join an Open game after leaving another Open game.
    • Run M$ Word for an extended period of time. The crash comes when I scroll through a large document or paste a lot of text or images from another source.

    I also noticed that as I run programs, not all the memory used by the program is freed when the program terminates. I ran the System Monitor and it revealed to me this information. I'm not sure if this is Athlon or Windoze related. Anyways, I'm suspecting that the problem may not be limited to Linux boxes.
    • Not sure about the MS Word thing, but I'd say your Diablo II crashes are a Blizzard issue. I've had plenty of problems with that game; lots of crashes, mostly, although crashes are a lot less severe and a lot less frequent with the current patch. The most irritating problem, though, is that my Play disc is unreadable by my DVD drive. This forces me to use my 4x8x CD-R (that's right, no -RW) which is painfully slow. I suspect it's the totally ineffective copy-protection that's causing that particular problem.

  • I have been to the AMD site, the Microsoft site,
    and all of the others mentioned, but I have yet to see any mention of any version of Windows being affected other than Windows 2000. Windows XP is not affected - I found that out here and on the AMD site (Microsoft's site, oddly enough, does not mention this). Does anyone know if the bug affects Windows 98?
  • if my computer hasn't had any lockups in 3d? I use a voodoo card and they don't take advantage of agp so that doesn't help me. Is there another way to find out?
  • This is a problem with the way the AGP GART memory mapping is handled in the linux kernel. So once again, slashdot got it wrong. Please, skim the articles in question before posting..It is a minor, elusive buglet in the linux kernel memory management.

    This is all caused by AGP. Once again, the race for more frames per second in quake3 has caused a stability damaging technology to become mainstream.

    ugh..

    john.c
    • by barawn (25691) on Thursday January 24, 2002 @04:24PM (#2896535) Homepage
      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...
      • 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.
  • by Papineau (527159) on Thursday January 24, 2002 @03:52PM (#2896346) Homepage
    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).
    • Excuse my ignorance, but what the heck are "MiB" and "KiB" ??

      T

      • Excuse my ignorance, but what the heck are "MiB" and "KiB" ??

        Mibibytes and kibibytes. They refer to 2^20 and 2^10 bytes, respectively. (I.e., what many other people call megabytes and kilobytes.)

        The scientific community had decided on SI unit prefixes like 100 years ago. "Mega" means 10^6 and "kilo" means 10^3. The computer science people came along and said "no, those will be powers of two for us." These units are a (probably futile) attempt to correct that particular stupidity.

        I think it won't work out, because there's too much legacy stuff that there will always be confusion at this point about what "mega" and "kilo" mean with computers. Besides, "mibi" and "kibi" sound stupid enough that they'll probably never catch on.

        • They won't catch on if nobody uses them, as Divx showed us (not the one you're using, the other, older one). But I still think that these units are better, if only resulting in better advertisement from the HD makers.
        • Well, thanks for the info... that jogged some sort of neurons... lost in a sea of beer and television. :-)

          T

        • "I think it won't work out, because there's too much legacy stuff that there will always be confusion at this point about what "mega" and "kilo" mean with computers."

          Not to mention the fact that computers are incapable of "thinking" in anything but a power of two. You will not find a discrete quantity of 10 (or a power thereof) bytes anywhere in a computer system. This makes the SI units useless for computers. While re-defining them for use in computers was and still is an abuse, the lack of applicability of the conventional SI units makes it largely a non-issue. The only people who care are are HDD manufacturers who rate drives in "millions of bytes" so they can swindle stupid customers.
      • Excuse my ignorance, but what the heck are "MiB" and "KiB" ??

        The are "MibbleBytes" and "KibbleBytes" respectively.

        ;-)
  • It could be either the motherboard or the OS which is collecting and writing stall data. About the only conclusion to be truly drawn so far is that it is unlikely an AMD defect. I'm sure AMD would like this to be the case too!
  • battle realms keeps crashing on my machine?
  • by crandall (472654)
    If the bug doesn't appear on intel chips, then how are we supposed to believe that it's not an AMD bug? Sure, we could blame the motherboard... but wouldn't that mean via/intel solutions would carry the same issue?

    Anyone have any knowledge as to how intel treats this 4mb pages different?

    I mean, if the bug is caused by AMD's precaching of AGP Gart mapped memory, and intel just doesn't precache that memory, then now is it NOT an AMD processor bug?

    When two processors aren't equal, there has to be a reason for the difference in running software.

    (Note that I prefer AMD, so I'm just looking for answers, not trolling).
    • by tommck (69750) on Thursday January 24, 2002 @04:08PM (#2896453) Homepage
      If the bug doesn't appear on intel chips, then how are we supposed to believe that it's not an AMD bug?

      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

      • Right. And I fully understand this, and figured that's probably what the case was. After all, this same issue is the main reason why you ever found hardware that was 'incompatible' with Athlon systems. intel never adhered to any kind of specs, and hardware developers could be sloppy as they wanted, assuming it worked. Then AMD/Via came along, and made hardware that conformed to spec, and all of a sudden all this out of spec hardware wouldn't work.

        It's unfortunate really, because it's all a matter of numbers. Since more people use intel stuff (for now anyway), whenever those people hear about a bug like this, they assume (again, and wrongly), that AMD produces inferior processors, when it is actually a case of people being out of spec to begin with.
    • If the bug doesn't appear on intel chips, then how are we supposed to believe that it's not an AMD bug?

      AMD's CPUs support something (speculative writing) that Intel processors don't, and the Linux kernel has a bug that is only noticeable when this feature is used.

      Setting device memory as cacheable is a kernel bug, no matter what the processor does. It's a kernel bug even if you're using Intel chips.

      This sort of thing is commonplace in computers. A certain piece of software or hardware doesn't follow some specification to the letter, but because the components involved don't support any features that require strict compliance, the bug isn't noticed for years. Then, one component is updated to support a new feature that relies on strict compliance. That's when all the bugs appear.

  • .... "don't blame me, its a motherboard problem"
  • I recently put together an HTPC (Home Theater PC) based on an ASUS A7V133 (Via) motherboard with AMD Duron processor. It runs Windows 98. I had been experiencing an unbelievable number of random lockups (no blue-screen, no error... just locks). For the most part, I couldn't keep the system running for more than an hour or so.

    In doing extensive research on the problem, I found very large numbers of people with the same problem and very little explanation. I tried MANY different solutions and eventually found one that worked. It involved wiping everything out and installing hardware and software in a VERY specific order. It seems that if you don't install the VIA 4-in-1 drivers (which include GART) at just the right time in the system building, the drivers don't work properly and thus the random lockups.

    I wonder if this is in any way related to the problem here.

    -S
    • If you have a SB Live! series soundcard in your system, remove it and see if that helps. If it does, buy something else. I went with a Turtle Beach Santa Cruz (which is also well supported by Linux).

      Very, VERY common problem.
  • And I hope AMD feels a pinch from this. Don't get me wrong, I don't want to see it break them. But, if hardware manufacturers realize that turning their backs on Linux can hurt the bottom line, then it will probably be better for all of us in the long run.
  • Because geocrawler seems to be /.ed: Athlon/AGP issue update [theaimsgroup.com].
  • VM Implications? (Score:4, Insightful)

    by mjh (57755) <mark.hornclan@com> on Thursday January 24, 2002 @04:16PM (#2896499) Homepage Journal
    From the gentoo article, I found the following very interesting:
    Yesterday, Rik van Riel, William Lee Irwin and myself were able to discuss this issue of Athlon/AGP instability with AMD....

    ...But now that the problem is out in the open, the solution is clear. The Linux kernel's approach to memory management must become more sophisticated in order to address potential conflicts between the highly-speculative nature of Athlon processors and the non-cache-coherent AGP GART.

    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!

    • Re:VM Implications? (Score:4, Interesting)

      by WNight (23683) on Thursday January 24, 2002 @06:24PM (#2897458) Homepage
      I think most people see the VM as eventually becoming quite complex. Profiling memory and disk usage (well, having hooks to allow the disk cache to cache based on memory use) allows you to guess when something will be needed and not page it out if it's needed immediately, or to page out something because you know it's not going to be needed for a while.

      And eventually, all memory management systems will either reach an out of memory issue (even with a reserved cache, the OS can still grow beyond safety margins) and either stall or kill processes. While some people feel that RIk is focusing a little heavily on the killing processes side, it is something you have to be prepared to do so you want to kill a less useful task (a forked apache server, not the main process, for example) instead of killing something critical to operation.

      You can usually come up with a simple solution that covers 95% of the cases very well, but it'll fall apart on that last 5% in a bad way. The complex solutions often offer lower performance in everyday situations but guarantee performance will never get as bad as the easy solutions would allow.

      So, I think anyone with design experience expects Rik's VM (or one like it) to go back into the kernel eventually.

      Personally, I think Rik should look at the issue of having "Emergency" swap that you don't go into except for OS processess. Once main swap is filled all non-OS processes fail to allocate any new RAM. This lets the system function well enough for non-kernel code (ideally more customizable) to make a system-specific determination on how to proceed. For instance, kill any processes from /usr/bin/games and see if that helps the issue... But, I'll admit to not being an expert and that this is only an educated guess.
  • OS Bug (Score:3, Informative)

    by kenneth_martens (320269) on Thursday January 24, 2002 @04:21PM (#2896520)
    According to the article [lwn.net], 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.
    • If the OS os doing something to spec. that causes the coherency problem, then It's not the OS.
      quite frankly, it's to early to know the truth of this problem.
  • I am not familiar with the kernel mechanisms for allocating GARTs, but it sounds like all you need to do is have the agpgart.o module, when it's creating a GART, somehow tell the kernel memory allocator and the page table handling code not to set up this region as cacheable.

    The problem is that probably none of the page table code cares to distinguish between cacheable and non-cacheable pages. But anyway it shouldn't be too bad to set up such a distinction.

    Anyway I haven't looked at the kernel code that relates to this yet so I am not sure if I am over-simplifying things... but I trust that someone will have a hack to fix this soon (a hack that doesn't cost anything in performance, unlike that mem=nopentium option), and a proper patch that is more beautiful would probably come out a few days after that....

    However, since NVIDIA's stupid bloated drivers contain their *own* agp GART code, we would also have to coordinate with that vendor to get them to change their GART code to behave properly. Either that or you can try using the linux kernel's agpgart.o with NVdriver, but in my experience Very Bad Things happen why you do that! :)

    -Calin
    • by himi (29186)
      I believe that's the currently proposed fix - it may change as people understand the details more, but I think that's the basic idea.

      himi
  • Last November, I upgraded my motherboard to a new DFI one with the AMD 761 chipset, but kept using the same processor (a Duron 700).

    After the upgrade the bug hit me (the computer would lock HARD every time X started)- at first I just thought it was bad RAM, but replacing that didn't help. Eventually I figured out by my own troubleshooting that unchecking the AMD 761 AGP chipset fixed the bug....

    Since the bug only appeared after the upgrade to a motherboard with an AMD 761 chipset, this makes a lot more sense. (Using the kernel option mem=nopentium fixes my problem, so it must be the same bug....)
  • by Anonymous Coward
    Get the story straight:

    "Our conclusion is that the operating system is creating coherency problems within the system by creating cacheable translation to AGP GART-mapped physical memory."
  • by Refrag (145266) on Thursday January 24, 2002 @05:32PM (#2896935) Homepage
    ...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.

Outside of a dog, a book is man's best friend. Inside of a dog, it is too dark to read.

Working...