Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
AMD

Major Linux/Athlon CPU bug discovered 402

Posted by chrisd from the a-bug-a-day-keeps-alan-at-play dept.
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."
This discussion has been archived. No new comments can be posted.

Major Linux/Athlon CPU bug discovered More

Major Linux/Athlon CPU bug discovered

Comments Filter:

  • I noticed too (Score:3, Interesting)

    by Fembot ( 442827 ) on Monday January 21, 2002 @03:55AM (#2875158)
    I noticed this too, it seems to only affect 3D games, mainly SDL based ones such as armagedtron, but strangly it hasent affected quake 3 at all. Unreal tournamet was affected, but i SWEAR it didnt use to do that.
    • 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)

  • Is this the same as the Win2k bug? (Score:4, Interesting)

    by sprayNwipe ( 95435 ) on Monday January 21, 2002 @03:55AM (#2875161) Homepage
    There was a Win2k bug a while back that did the exact same thing, and you had to install a "LargePageMinimum" patch for it to not crash. Is this the Linux equivilant of that? And if so, how come it has taken so long to surface and fix?

    • Re:Is this the same as the Win2k bug? (Score:5, Funny)

      by kilrogg ( 119108 ) on Monday January 21, 2002 @04:04AM (#2875192) Homepage
      RTFA, AMD released a patch for w2k but never mentioned anything to the kernel developers.

      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.

      • I find it rather interesting that for Win2k, you needed to install a patch. For Linux, you can just edit your bootloader with an option, and it does the same thing. Which seems more robust?
        Granted, the Win2k patch was probably just a registry tweak, but which could the average user do more easily? Which operating system gives more information to it's users?
      • Where is AMD in any way obligated to call the Kernel Developer Gods whenever they make a mistake? "Oh, Mr. Torvalds, I'm so sorry we made a mistake with our processor. Oh, Mr. Cox, please forgive us. Please don't tell RMS or ESR; we'll fix it, honest!"

        Here's the stark truth for you: 1)Money, 2)Userbase.

    • Re:Is this the same as the Win2k bug? (Score:4, Redundant)

      by Anonymous Coward on Monday January 21, 2002 @04:04AM (#2875195)
      It's slashdotted. Here's the article:

      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. However, it becomes our problem because there are very many semi-broken Athlon/Duron/Athlon MP CPUs out there.

      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.) 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. As soon as I discovered that this CPU bug existed (which happened, unfortunately, because my CPU has the bug), I informed kernel hacker Andrew Morton of the issue; he put me in touch with Alan Cox. Alan 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.

      The unfortunate thing about this situation is that AMD and others have known of this bug since September 2000. In fact, AMD's CPG technical marketing division announced this bug on September 21, 2000 in a technical note entitled Microsoft Windows 2000 Patch for AGP Applications on AMD Athlon and AMD Duron Processors (Technical Note TN17 revision 1). And, the kind folks at AMD even created a simple patch for Windows 2000 that disables extended paging by tweaking the registry. However, apparently AMD didn't realize that Linux 2.4 also uses extended paging when the kernel is compiled with a Pentium-Classic or higher Processor family kernel configuration setting. And, it looks like no one in the Linux community noticed that this "Microsoft Windows 2000/AGP Athlon/Duron bug" also applied to Linux 2.4 systems, probably because it was presented by AMD technical marketing as just that -- a Windows 2000-related AGP bug. An unfortunate miscommunication, which has resulted in lots of problems for Athlon, Duron and Athlon MP users. Here's something that's even more unsettling -- consider what kind of Linux users actually use AGP. That's right -- desktop users. And in what area has Linux been struggling? Yes, the desktop. One wonders how many negative desktop Linux experiences have resulted from this unfortunate problem. I don't know if any particular party is to blame for this issue. After all, AMD did prominently announce this bug when it was discovered. But due to an apparently unfortunate series of events, us Linux people never benefitted from this knowledge. But Microsoft Windows 2000 and XP users did. Let's hope that all parties involved can keep things like this from happening in the future.

  • old news again (Score:2, Interesting)

    by Afrosheen ( 42464 )
    I guess it takes awhile to pile through the submissions. This was posted on pclinuxonline.com recently.

    • Re:old news again (Score:2, Offtopic)

      by cymen ( 8178 )
      I guess it takes awhile to pile through the submissions. This was posted on pclinuxonline.com recently.

      Wow... That takes the cake. It's bad enough to bitch about deja vu reposts from /. itself, no need to bitch about reposts of stories at other sites. If you can't see the reasons why please bite yourself. I can't wait until it is unhip to be aloof.

  • Mirror/cache from Google! (Score:3, Redundant)

    by Metrollica ( 552191 ) <m etrollica AT hotmail D0T com> on Monday January 21, 2002 @04:03AM (#2875185) Homepage Journal
    Here [google.com] is the cached article.

    Thank Google again for this one!

  • Another mirror/summary here (Score:3, Informative)

    by Afrosheen ( 42464 ) on Monday January 21, 2002 @04:08AM (#2875204)
    Karma whoring, here I come. Hopefully this server can withstand a mild slashdotting. Link [tuxreports.com]

  • The quick answer: (Score:5, Informative)

    by Doctor K ( 79640 ) on Monday January 21, 2002 @04:08AM (#2875206) Homepage
    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

  • Simple Workaround (Score:3, Redundant)

    by Laven ( 102436 ) on Monday January 21, 2002 @04:10AM (#2875209)
    The Gentoo site says a simple workaround where you add "nopentium" to your kernel options at bootup and it will avoid the bug condition. Alan Cox is currently working on adding auto-detection of this bug in the kernel, so we wont have to worry about it soon.

    And yes, this is the same Athlon Windows 2000 AGP bug that was discovered and patched last year with that registry key. They just didn't realize that it also effected Linux until now. I now realize that was the cause of my TuxRacer crashes with my nVidia card on my Athlon computer.

  • Performance hit? (Score:4, Interesting)

    by mojo-raisin ( 223411 ) on Monday January 21, 2002 @04:32AM (#2875227)
    So does anyone know how performance is affected from this 4MB->4KB page thing?

    • Re:Performance hit? (Score:3, Informative)

      by Sits ( 117492 )
      You may want to take a look at the benchmarks posted later [slashdot.org].
    • First, as has already been pointed out, there is no performance hit.

      But I still did not get the answer to my question. What is the purpose of having 4MB pages in the first place? It is inconceivable that an OS would use 4MB pages exclusively. The internal fragmentation would be enourmous.

      To give you an analogy, think of what would happen if your file system used 4MB blocks. When you create a file, space would be allocated 4MB at a time so a 1 byte file would waste (4MB - 1byte) of disk space; (4MB + 1byte) file would take up two blocks, also wasting (4MB - 1byte) of disk space. On average, each file wastes 1/2 of the last block. Similarly, each process wastes on average 1/2 of the last page. That's not a problem if the pages are 4KB in size, but with 4MB pages there's lots of space wasted. That's like throwing away paging altogether.

      So, I ask again, what is the point of having 4MB pages?
  • from the article: 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

    so the question is, if I configure my kernel for the K7 family, do I need to pass the kernel "mem=nopentium" or is this the default?

  • Nvidia + AGP + Irongate + Athlon (Score:4, Interesting)

    by hack0rama ( 253610 ) on Monday January 21, 2002 @04:53AM (#2875271) Homepage Journal
    Nvdia drivers forces AGP to 1x due to corruptions caused by AMD Irongate chipset signal integrity [ Mentioned at the README [205.158.109.140] for Nvidia 1.0-2313 Drivers ]

    This newly discovered memory corruption with Athlon + AGP, is it contributing to the signal integrity of the Irongate ? Or is it a separate bug ?

    Anyway this makes AMD look very bad in my view. There is a bug in the CPU and their chipset screws up my AGP to 1x. Sigh.
  • I should start by saying I haven't read the article yet, can't get to it. *hopes the /. traffic dies down soon...*

    If it is a defect in the processor, I wonder if AMD will replace my existing processor. It may not seem like all that big of deal to most people here at Slashdot, but as a 3D artist I am *dependent* on OpenGL.

    Don't get me wrong, I'm not having this problem now. (I'm not a Linux user.) But when I built my Athlon I had to install a patch for a similar type of problem in order to get the machine to work. At what point do we say "it's no longer ok to work around a CPU bug"?

    If Intel has one set of bugs in their processors, and AMD has another, that divides the market. Software companies shouldn't have to put the effort into scrutinizing their code based on which CPU they are on, it's bad enough they are trying to optimize for one or the other. What happens when they get used to the workaround, but then it gets fixed? Worse yet, what happens when a company says "I'm sick of this, I'm only supporting one processor."

    So it's not so much that I think AMD should replace the processors with this specific bug, but I think we should be vigilent in not allowing them to let errors like that run rampant.
    • Heh, microcode bugs go back, WAYYYY back as far as microprocessors do themselves.



      Shit happens. Work around it. ;-)

      • Re:Should AMD do the right thing? (Score:4, Informative)

        by Eric Smith ( 4379 ) on Monday January 21, 2002 @06:11AM (#2875467) Homepage Journal
        That third article about the supposed "HCF" instruction on the 4004 is completely and utter BS. None of the instructions on the 4004 will cause it to burn up, even on the earliest production parts.

        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.

        • That third article about the supposed "HCF" instruction on the 4004 is completely and utter BS. None of the instructions on the 4004 will cause it to burn up, even on the earliest production parts.

          When the IBM System 360 series came out it had a large number of new opcodes (as compared with the 70x/70xx series). These were the days of CISC (Complex Instruction Set Computers), and the 360 really lived up to the name. It gave over a large amount of its word space to opcodes and opcode extensions, so it had a VERY large potential opcode space. Much of it was unpopulated, but some was populated with undocumented instructions. Further, the machine was microcoded, and the microcode was loaded when the machine powered up. (That's what floppy disks were invented for.) So the company could write new opcodes and add them later.

          Of course the new machine with the ENORMOUS list of opcodes and (true) rumors of hidden undocumented opcodes quickly lead to the circulation of a humorous list of perhaps 20ish additional "new undocumented opcodes". Things like XOE (Execute Operator Immediately), EK (Electrify Keyboard), SSJ (Select Stacker and Jam), BLNK (Blink Lights), WHR (Whirr), etc. The crown jewel of this list was HCF (Halt and Catch Fire).

          While this list was still funny Motorola released the 6800 single-chip microprocessor, predecessor to 650x knockoff that formed the core of the first Apple computers. To ease chip testing, the all-ones opcode threw the chip into a test mode, where it continuously incremented the program counter and performed memory reads. This wiggled all the address lines and most of the control lines, letting you know if the chip was alive and bonded.

          Of course they didn't tell you about it. And of course the only way out was hard reset. And of course a jump to an unpopulated region of the address space (i.e. most of it) would leave the bus floating and generate 0xFF. And of course jumping into random data or uninitialized memory would also quickly get you an 0xFF or jump you off into unpopulated address space. So the typical behavior for a program bug was to lock up the processor beyond the ability of a debugger to function.

          (Hell: I had one of the first round of solder-it-yourself evaluation kits, bent a pin on the debugger ROM putting it into the socket, and ended up with a board that booted into the test state. Was starving student and it took a couple days to get access to test equipment to find out what was wrong.)

          So of course programmers, once they found out about the instruction that hung the chip in a mode where it "twiddled its thumbs at maximum speed" and got a bit warmer than usual, and couldn't get out of the mode except by hard reset, quickly christened the opcode "Halt and Catch Fire". And this became the generic term for get-stuck-in-a-test-mode instructions on microprocessors, until the chip manufacturers finally came to their senses and stopped putting such instructions into instruction sets.

    • Re:Should AMD do the right thing? (Score:5, Interesting)

      by flatrock ( 79357 ) on Monday January 21, 2002 @10:23AM (#2875958)
      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.

  • Athlon bug, and NVIDIA drivers (Score:3, Interesting)

    by Rohan427 ( 521859 ) on Monday January 21, 2002 @05:24AM (#2875363)
    I have 2 Athlon systems, a dual Thundirbird 1.4GHz (Tyan Thunder K7) and a single Thunderbird 1.4GHz (Asus A7V133). The former runs a GeForce 3 and kernel 2.4.17, the later TNT2 and RH 7.2 (kernel 2.4.9 I believe). Both systems run semi-custom NVidia drivers (release 2313). By semi-custom, I mean I tweaked them to use SBA, the NVIDIA AGP driver (NOT agpgart) and to run in 4x mode. The later has never had a problem, the former (the dual) had some problems until kernel 2.4.14.

    The problems I had were frequent lockups with everything X, especially Q3A and Tribes 2. Some experimenting proved what worked and what didn't, and here's what I found:

    agpgart never worked worth a damn even with kernel 2.4.17, despite several attempts by me to make it work (I don't maintain it, so I gave up on messing with it). Earlier NVIDIA drivers were less stable, but the latest is great (although it does not support FW, which blows). Tweaking the NVIDIA driver to use SBA and it's own AGP driver instead of agpgart, along with kernel 2.4.14 - 2.4.17 makes for a very stable and fast system. Older kernels just did not work worth a damn whenever I enabled DMA on my IDE drive - they locked every time. These newer kernels don't exhibit this problem, and the NVIDIA driver works nicely with all 3D games as well as 3D development tools like Blender.

    My kernels have always been compiled as Athlon kernels as well. The bottom line is: don't blame this bug and/or the NVIDIA driver if your system is unstable and/or slow. There are other things at work, and in my case I seem to have found them all.

    - Rohan
    • Have you made this tweak available? How difficult is it to perform?

      I've got a dual Athlon MP 1900+ machine from Alienware coming in for work and I'd like to get it running like a dream, if at all possible.

  • How-To: lilo workaround (Score:4, Redundant)

    by Anonymous Coward on Monday January 21, 2002 @05:32AM (#2875385)
    If you're using lilo, and just want to apply the workaround quickly, edit /etc/lilo.conf.

    Before the first image= line, insert the line:

    append="mem=nopentium"

  • Does this happen if kernel compiled for K7? (Score:4, Interesting)

    by Nicolas MONNET ( 4727 ) <nicoaltiva@gm a i l.com> on Monday January 21, 2002 @05:35AM (#2875394) Journal
    The article says it happens when the kernel is compiled for Pentium processors; but does this happen if the kernel is compiled for a K7?

    By the way, I had to shelve my nVidia card a couple months ago because of this ... I have an Athlon and it kept hard freezing. The bug doesn't happen with a Voodoo card.
    • 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).
    • I assume so. Since PSE is supported in Athlons I would think the kernel people would enable it for a K7 compile.

      I would think that only people who compile their own kernels and those who use Mandrake would be affected by this since pretty much everyone else compiles for 386, which would turn off the use of the PSE capability.

  • The equivalent Win2k bug fix (Score:3, Informative)

    by LadyLucky ( 546115 ) on Monday January 21, 2002 @05:42AM (#2875406) Homepage
    can be found here [amd.com]

    Funny, I knew something was wrong...

  • Buggy Features (Score:5, Funny)

    by Perdo ( 151843 ) on Monday January 21, 2002 @05:43AM (#2875408) Homepage Journal
    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 [amd.com]"
  • ...seems they work for Intel. Their description was:
    "It's a major bug. We don't know how it happend. We will ask marketing. We don't remember ever sell that chip.".

    :-))

  • Using Test Suites to Validate the Linux Kernel (Score:5, Informative)

    by goingware ( 85213 ) on Monday January 21, 2002 @06:03AM (#2875452) Homepage
    Let me take this opportunity to plug Using Test Suites to Validate the Linux Kernel [sunsite.dk].

    Thank you for your attention.

  • Quake 3 benchmarks (Score:5, Informative)

    by Sits ( 117492 ) on Monday January 21, 2002 @06:05AM (#2875454) Homepage Journal
    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 [theregister.co.uk] though...
  • I just got a new box, Athlon 1.2GHz... Asus a7a266 mainboard... nice little box for general usage. Soon as I finish moving, I'll get cable modem back and stop using mom's AOL, and I'll go back to Linux. But now I see this, and I'm eyeing my AGP card, and wondering. AMD has earned a lot of respect from me in the last couple years, as I've found the Athlons to be simply the finest x86 CPU's I've ever got my hands on, at great prices with very reasonable motherboards/chipsets as well. Now this. I'm not sure. Yeah, it's an engineering mistake, but I'm not clear on how AMD is handling it, and I hope they don't disappoint me. Sure, you can do a workaround - but as others have asked, what's the story on the performance hit? What about AMD working with the kernel folks to find another, better solution? Or maybe AMD could consider offering serious discounts on new, un-flawed CPU's, for those who are already eyeing upgrades?
    • Also...

      AMD should seriously consider its response to this. The Linux community is well-informed, in general, and has been much quicker in moving to AMD than Windows users (mostly because Windows users are mainly Dell/Gateway/Compaq/Etc customers..), and AMD would do well to make attempts to avoid disappointing us.

  • I had a stroll through AMD erratas (Score:3, Interesting)

    by Anonymous Coward on Monday January 21, 2002 @06:46AM (#2875530)
    If I read the various PDFs correctly on AMDs site, all Athlons
    except model 1 (the very first K7 since it didn't have PSE) are affected,
    except the latest revision A5 (cpuid 662) of the Athlon XP, i.e. A0/660 and
    A2/661 are affected as well (similarly all 64x Thunderbirds etc.).
    (there was a model 1, 2, 4 and 6 Athlon, with 6 being XP)

    Some or all Durons might be affected too, but I didn't look at that closely.

    The above hinges on whether this is the correct bug description, feel free
    to flame the anonymous coward if this has got nothing to do with it :)


    "16 INVLPG Instruction Does Not Flush Entire Four-Megabyte Page Properly with Certain Linear Addresses

    Normal Specified Operation. After executing an INVLPG instruction the TLB should not contain any
    translations for any part of the page frame associated with the designated logical address.

    Non-conformance. When the logical address designated by the INVLPG instruction is mapped by a 4-MB
    page mapping and LA[21] is equal to one it is possible that the TLB will still retain translations after
    the instruction has finished executing.

    Potential Effect on System. The residual data in the TLB can result in unexpected data access to stale or
    invalid pages of memory.

    Suggested Workaround. When using the INVLPG instruction in association with a page that is mapped via
    a 4-MB page translation, always clear bit 21."

    (page 7 from Athlon Model 6 revision sheet [amd.com])

  • Alternate, faster? workaround (Score:5, Interesting)

    by jquirke ( 473496 ) on Monday January 21, 2002 @07:56AM (#2875638)
    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

  • Other Hackers did it better . . . (Score:5, Informative)

    by Jeff Kelly ( 309129 ) on Monday January 21, 2002 @08:04AM (#2875661)
    Here is a Posting from Terry Lambert on the FreeBSD -stable Mailing List regarding this "Bug".
    Maybe it sheds some light on this issue.


    > Recently I found Linux 2.4 kernel is affected by the
    > bug of extended paging in AMD Athlon through the
    > following link. I don't know if FreeBSD is also
    > affected.
    >
    > http://linuxtoday.com/news_story.php3?ltsn=2002-01 -21-001-20-NW-KN

    I am well aware of this bug.

    It does not affect FreeBSD, which only uses 4M pages for
    the first 4M of the kernel itself.

    I've worked on code that enables 4M pages on other memory
    used in FreeBSD, that had this problem, but only if you
    were really stupid in your allocation mechanism.

    There's a workaround for this problem which is fairly
    trivial to implement in software, and should probably be
    done when 4M pages are enabled, if you are using an Athlon,
    and are adding 4M pages.
    [...]
    In any case, this will not be a problem for FreeBSD, and is
    only a problem for Linux because of the strange way they
    initialize things.
    • When an OS doesn't use a CPU feature (4M pages, using it just for the kernel doesn't count), that doesn't make the hacker better, it makes the OS not taking advantage of all CPU features (and therefore not running into the related CPU bugs...).

      So this guy tried to do 4M pages, it didn't work well (he encountered the bug), and decided not to implement 4M pages at all. And for Linux, the guys just happened to implement 4M pages long before AMD created the processors with the bug.

      Different history, all good hackers.

      • When an OS doesn't use a CPU feature (4M pages, using it just for the kernel doesn't count), that doesn't make the hacker better, it makes the OS not taking advantage of all CPU features (and therefore not running into the related CPU bugs...).


        Read again. The Posting states that "I've worked on code that enables 4M pages on other memory
        used in FreeBSD, that had this problem, but only if you
        were really stupid in your allocation mechanism."

        He encountered the Problem in his _own_ code and fixed it there. He also states: "There's a workaround for this problem which is fairly
        trivial to implement in software, and should probably be
        done when 4M pages are enabled, if you are using an Athlon,
        and are adding 4M pages." He very clearly states that 4M pages are not currently supported in FreeBSD (should be in 4.5) but that a workaround exists. (And it is _not_ deactivating the 4M paging as in linux).

        So although they are not affected by the Bug because they do not use that particular feature at least they know that it exists and they do have a workaround ready _now_ so that by the time this feature is implemented this bug will not cause any troubles. Which is more than I can say about the Linux hackers, which don't even bother to read the docs provided by AMD.

        • It's rather hard to read non-existent documentation. This bug isn't listed in the AMD K7 errata, which is why it wasn't found - the only 'documentation' for this is the Win2k patch that AMD provided.

          Linux and *BSD just do things differently: it's not a matter of one set of hackers being better than the other.

          himi

  • grub workaround (Score:3, Redundant)

    by chongo ( 113839 ) on Monday January 21, 2002 @08:17AM (#2875685) Homepage Journal
    If you're using grub and want a quick but effective workaround, then edit your grub.conf file, which is usually under /boot/grub.conf or /etc. On the end of any line that begins with the word kernel add:

    mem=nopentium

    For good measure, re-install your grub config by running:

    /sbin/grub-install /dev/hda

    Where /dev/hda is your boot disk. For most PC users with IDE drives, it will be /dev/hda .

    Last, just reboot.

  • bad form AMD, realy bad form (Score:3, Troll)

    by budgenator ( 254554 ) on Monday January 21, 2002 @09:24AM (#2875792) Journal
    A lot of your market share is there only because we who use Linux® have stuck by you. We have been ridiculed because we are using an "off-brand" processor, we've rationalized a way thermal problem's and fragile cores to get the benefit of more bang for the buck. We have suffered through inadequate compiler support, until your market share has grown to the point where an honest push onto the main-stream desktop is possible.

    And what do we get for it, no real support, write your own fix, no; that we can, and often do. What we got was forgotten, you didn't even tell us. We are used to and demand full disclosure, and in real time. Linix people hang their dirty laundry out in public to give everyone a fair and equal chance at a fix.

    We're often treated as a minority because we are, but treat us as a second class minority at our own peril. In short don't ever let the marketing weenies convince you to hide something from us; if we wanted to be treated that way we would use Win/Intel products
  • So, if it was discovered over a year ago, was this hardware bug ever fixed? We bought a dual-athlon 1.53-GHz (1900+?) machine recently; do these processors still have the bug?
  • I'd been noticing this for ages -- just about anything that does GL will almost always hang my system (Oddly enough, I have never noticed this with Tuxracer.)

    I'd always assumed that it was just a crappy AGP implementation on my no-name motherboard, as I'd been following the Mesa/GLX groups for a while and hadn't seen the problem mentioned all that much. It's nice that there's a relatively easy fix for the problem. Maybe now I can get back into Tribes2 again :-)

  • Could somebody with more knowledge explain why you need 4MB pages in the first place? Pages are supposed to be small for a reason. With 4MB pages, internal fragmentation would go through the roof. It's almost like not having paging at all. I don't understand why this option is even available and used.

  • AMD Rev A5/CPUID 662 (Score:2, Informative)

    by lanalyst ( 221985 )

    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.

  • The other day I left my Dual Boot system (with a Nvidia GeForce 2 MX 400 and NVIDIA drivers) booted into Mandrake Linux for most of the day and it was fine. Of course I was at the system for most of the time. I decided to go to the store and when I came back the system was locked tighter then a drum. No big deal since I run ext3 for the file system. Rebooted and it was fine. How would one add this option to a GRUB bootloader?? I bet if I add it, the screensaver won't lock (Open GL screensaver.....). I don't play a whole lot of games so the texture flakiness would not bother me.

  • This is flaw in how Linux is (not) managed (Score:2, Insightful)

    by Anonymous Coward
    First off, yes, this is a rather major bug.

    But is it enough to warrant not buying the processor or flaming AMD???? Hardly!

    EVERY piece of hardware out there has some bug in it! Have any of you ever sat down and read the list of errata on Intel parts and the list of how many flaws are fixed in each stepping? The list of bugs fixed over the life of the P3/Celeron core is a rather lengthy document to say the least.

    And I can't really fault AMD at all on this one other than that they HAD a bug...for Win2K etc, they released a fix/patch in very short order and notified everyone rather quickly.

    And don't forget this was back in 2000! What version was the norm for deployed kernels back then (over a year ago!)???

    From what I gather, the 4Mb AGP paging didn't show up until kernel 2.4 builds -- which I do not think were final at that time. Regardless, I feel the Linux kernel community should have been a bit more proactive in noting a DOCUMENTED bug and correcting for it.

    Regardless, this bug in no way affects whether or not I would buy an Athlon/Duron. It is basically trivial to workaround and results in almost no performance loss. In essence, my Athlon XP 1900+ with the fix will still beat the crap of most P4 2Ghz machines in 90% of all applications (for half the price).

    This is basically a failing of the entire Linux concept more than a failing of AMD.
    Is there any central authority who regularly checks AMD, Intel, Via, Transmeta, etc. erratum sheets for bugs that might potentially affect the kernel? Based on this, I strongly doubt it.

    Don't get me wrong, Linux is a great OS, but the lack of centralized control and build management is starting to cause problems. There are so many changes to different modules that version dependencies crop up all the time and no one is managing them.

    I am not a big fan of Microshaft myself, but I would put money that they have at least one or two people whose job is to do nothing but monitor the processor manufacturers erratums to make sure no major problems submarine the sales of Windows XP! Bill Gates may be many things, but stupid is not one of them. H*ll, if I was Microshaft, I could have a marketing field day on this one -- it could be a very persuasive argument to lots of upper management types as to why Windows is better than Linux.

    Is this bug a problem? Yes.

    Was the original problem AMD's? Yes.

    Did they address it and notify people? Yes.

    Did anyone in the Linux community actually notice? NO

    Regardless, any bug that can be worked around this easily is not THAT big a deal people...but it does point out some serious flaws in how Linux kernel development is managed. If Linux is to survive, some order had better start arising out of the spiraling chaos!

    So to sum up the appropriate response to this bug: LEARN FROM YOUR MISTAKES AND GET OVER IT!!!!!!!!

    "The sky is falling! The sky is falling!"

    sheesh...
  • - what proccessor rev its fixed in. I'm wanting to buy a new machine, it's still gonna be AMD, but I don't want a processor with that bug, as I am a big gamer.
    - how to tell if my processor is affected. (I'd rather not have to wait for my system to crash to find out)
  • I think the k62 had this problem as well. Anyone know about that?

  • I've seen a number of mysterious X freezes in XFree86 4.1.0 and earlier on my Athlon/GeForce2MX system with NVidia kernel/X drivers. Most often the X server just seems to lock up when I'm doing nothing in particular. Occasionally I've had the whole system freeze during 3d gaming.

    This is all with Linux 2.2.18. Has anyone commented for sure on this bug in the 2.2 series?

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close