Slashdot Mirror


Microsoft Advice Against Nehalem Xeons Snuffed Out

Eukariote writes "In an article outlining hidden strife in the processor world, Andreas Stiller has reported the scoop that Microsoft advised against the use of Intel Nehalem Xeon (Core i7/i5) processors under Windows Server 2008 R2, but was pressured by Intel to refrain from publishing this advisory. The issue concerns a bug causing spurious interrupts that locks up the Hypervisor of Server 2008. Though there is a hotfix, it is unattractive as it disables power savings and turbo boost states. (The original German-language version of the article is also available.)"

11 of 154 comments (clear)

  1. Broken processors by Anonymous Coward · · Score: 5, Insightful

    The processors are clearly broken, and anyone who bought them should get a refund or an exchange. End of story.

    1. Re:Broken processors by Bengie · · Score: 5, Informative

      so much FUD.

      #1. MS classified this interrupt as "unreliable" for all previous hypervisors and randomly decided to use it for this version of their hyper visor

      #2. ONLY MS uses this interrupt, not vmware or anyone else.

      #3. Intel's new Xeons still use less power and out perform AMD and any previous CPUs. It's still the best CPU, even if you use the "work around"

    2. Re:Broken processors by Waynelson · · Score: 5, Informative

      I don't know if anyone actually read the kb article on the Microsoft website, but it appears that you don't lose the power saving features and what not with the hot fix installation, the loss of those features only occurs when you directly modify the registry to disable some of the c-states in the apci system as a quick fix. Either that or i'm reading the kb article wrong.

  2. Windows specific? by Anonymous Coward · · Score: 5, Funny

    It sounds like microsoft should retract the advice and issue a warning that no OS should be run on a processor with such spurious interrupts?

    Or is this the sort of crappy hardware kernels are supposed to put up with in which case it should be Intel advising against running windows on it's hardware?

    Int€l bashing..check
    M$ bahing...check
    now i just sit back and watch the karma roll in

  3. Re:What about for Windows 7? by Viros · · Score: 5, Informative

    I've got an i7 920 on my desktop and run Windows 7 for gaming/home use purposes and it works fine. Don't let the problems with the server software dissuade you from a very good processor for home and gaming use. The kind of stuff you're describing doing will never run into anything close to the problems from this article.

  4. Please Explain Further by Anonymous Coward · · Score: 5, Informative

    I read the article, I read the MS support report, and I read the Intel advisory. And I don't think that the summary is correct.

    The summary says that the hotfix disables power savings and turbo boost. But my reading of the MS report is that an affected system has two options, (1) a workaround, and (2) the hotfix. The difference is that the workaround disables advanced power savings and is known to be stable without side effects, but the hotfix actually fixes the problem with the vector table, presumably by following the instructions provided in the Intel advisory note.

    Said another way, the hotfix doesn't disable power savings and doesn't disable turbo boost.

    I expect that this is another fine example where Slashdot editors misunderstand a situation. Someone prove me wrong.

    1. Re:Please Explain Further by Anonymous Coward · · Score: 5, Informative

      Your explanation is exactly how I interpreted the KB article. I think Slashdot was going for some sensationalistic journalism. :-)

      Taken from TFA:
      You can disable the Advance Configuration and Power Interface (ACPI) C-states by using a BIOS firmware option on the computer. If the firmware does not include this option, a software workaround is available. You can disable the ACPI C2-state and C3-state by setting a registry key. To do this, follow these steps:

            1. At a command prompt, run the following command:
                  reg add HKLM\System\CurrentControlSet\Control\Processor /v Capabilities /t REG_DWORD /d 0x0007c044
            2. Restart the computer.

      Note The computer idle power consumption will increase significantly if the deeper ACPI C-states (processor idle sleep states) are disabled. Windows Server 2008 R2 uses these deeper C-states on the Xeon 5500 series as a key energy saving feature.

      To continue to benefit from these energy saving states, remove this registry key after you install the hotfix that this article describes. To do remove this registry key, follow these steps:

            1. At a command prompt, run the following command:
                  reg delete HKLM\System\CurrentControlSet\Control\Processor /v Capabilities /f
            2. Restart the computer.

    2. Re:Please Explain Further by oldhack · · Score: 5, Funny

      Your explanation is exactly how I interpreted the KB article. I think Slashdot was going for some sensationalistic journalism. :-)

      NO WAY!

      --
      Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
  5. Isn't it really a bug in Windows Server? by tomhudson · · Score: 5, Insightful

    FTFA:

    For the integrated hypervisor of Windows Server 2008 R2, Microsoft has bravely resorted to a timer function that they themselves had classified as unreliable for former processors: the timer of the Advanced Programmable Interrupt Controller (APIC). Unlike, for example, the CPU timer (Time Stamp Counter, TSC) - which by now is comparatively resistant to power-saving, SpeedStep and turbo-boost modes, but is also virtualised by virtual machines - the APIC timer can also trigger interrupts. Unfortunately, right now, the Nehalem has too many of those, so that the hypervisor falters and then stops, returning the message "Clock_Watchdog_Time-out".

    So yes, if you depend on something that generates an interrupt whose code path may be suspended in certain power-saving modes, don't be surprised if it doesn't get serviced promptly. It looks more like a bug in Windows Server.

    Back in the old days, when you issued a CLI instruction, you made sure your routine didn't do too much work before issuing an STI, because that code isn't re-entrant (it's directly modifiable by the hardware, which is why you have to use the "volatile" keyword to make sure that compilers didn't "optimize away" any loops, etc). Kind of hard to guarantee that if you're putting that portion of the hardware to sleep between interrupts. As the article points out, disabling those power-saving modes fixes the problem.

  6. Re:What about for Windows 7? by Anonymous Coward · · Score: 5, Funny

    No problems at all. I'm running an i7 920 with 12 GB of RAM and Windows 7 64-Bit Ultimate. I've been playing BF2, GTA4, COD:MW/MW2, Batman: AA and others without any problem. Not to mention running 2 or 3 VMWare sessions, putty sessions, winscp, IE8, pidgin and streaming TV through Windows Media Center all at the same time.

    Okay you have a big penis (not literally). We get it.

  7. AMD looking better? Bullshit by TopSpin · · Score: 5, Informative

    AMD has also built parts with equally screwed up timers, particularly TSC clock skew on multi-cores. Timers are just messed up on x86 from either company. This nonsense goes back years. There are now at least four distinct general purpose clock sources that must be present on modern systems; tsc, apci_pm, hpet and pit (as labeled by the Linux kernel.) There will probably be further proliferation in the future as ALL of the existing timers are inadequate in subtle ways. Implementations from both manufacturers have been plagued with bugs that require nasty work-arounds; google "clocksource tsc unstable", "pm-timer bug" or "athlon x2 tsc" for some examples. This nonsense that Microsoft has stumbled upon is just the latest in a long and colorful history of failure that we'll now have to add to the list.

    Computers are supposed to keep time. Today that means high resolution clocks that work correctly regardless of power saving, concurrency, etc. Using these crucial timers is not suppose to cause spurious interrupts, bus contention or other subtle problems. People that must work with this stuff are thoroughly fed up with this ever growing pile of half-baked bullshit.

    --
    Lurking at the bottom of the gravity well, getting old