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.)"
I've been experiencing problems with intermittent lockups under VMWare as well. DL370-G6 boxes. HP has given us BIOS fixes and is even shipping new boxes, but if there's a suspect problem
with working with MS' hypervisor, I wonder if this is the same issue?
Harrison's Postulate - "For every action there is an equal and opposite criticism"
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.
No, this only applies to the Hyper-V component of Server 2008 R2. Normal people do not use Windows Server for "home use/gaming purposes" (cue a dozen replies of people talking about how cool they are because they use pirated copies for said purpose), so its not a big deal. Also, Core i5/i7 is already a Quad Core, I assume you mean Core 2 Quad.
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.
A generation to skip for servers (or move to AMD for a generation) but Core i7s are amazing for home/gaming use. For just about anything other than visualization and server-specific stuff, Core i7s and CPUs with the same architecture have no comparison with what AMD has to offer.
Taxation is legalized theft, no more, no less.
From the pdf file linked from the Intel site, I think it's AAK36, as it's the only one that mentions the word "spurious." This has to do with writing to the interrupt vector table when a local interrupt is pending. That doesn't look terribly serious from my perspective. If I'm mistaken and it's a different errata, please reply with the correction.
Xeon is just a marketing name. The Xeon 3400 are identical with the i5-7xx, i7-8xx CPUs, the Xeon 3500 are identical with the i7-9xx CPUs and the Xeon 5500 CPUs are basically i7-9xx with two QPI Links.
For example, this issue also affects als i5 and i7 CPUs.
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"
It's a processor bug exposed by a new hypervisor technique used by MS and nobody else.
I'm not sure why you want to blame this on MS.
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.
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
The hotfix fixes the problem and allows the use of power saving states.
Done!
There is a price to pay for being on the "bleeding edge" of technology.
You are essentially being an unpaid BETA tester for both Microsoft, Intel, and whatever other components you happen to be using.
You are paying for the privilige of BETA testing , and since your software comes with NO WARRANTY, or FITNESS FOR A PARTICULAR PURPOSE, and contains, KNOWN DEFECTS, you should be happy to know your hard work will be used to make other peoples life easier.
I didn't see a link to the KB article in question. I assume this is the one: http://support.microsoft.com/kb/975530