Conroe bug can cause corruption

[galvelan]

Hey need some help here... Curious as to what triggers the bug or if anyone has experienced this issue that Intel just reported on...

http://www.theinquirer.net/default.aspx?article=33916

 

[koitsu]

A39, as mentioned by TI, is ***MAJOR***. This needs to become sticky IMMEDIATELY, and needs additional press focus.

{Edit: I'll explain the problem better...}
The trigger for the flaw is documented in the Errata. The flow would be this:

* Core#1: Attempts to fetch data via L1 cache (normal)
* Core#1: Data isn't in L1, which results in a cache miss (normal)
* Core#1: Data is fetched via L2 cache
* General: L2 cache data being fetched is actually from Core#2 L1 cache
* Core#1: Data returned from L2 cache fetch is incorrect/bad/corrupted
* Hello data corruption

The "General" item could also be, depending upon how you read the Errata:

* General: L2 cache contains data being modified via Core#2

Intel states in the Errata that they plan on releasing a fix for this (in English: a newer stepping (version) of the CPU should resolve the problem). For those who already own CPUs, you *might* be able to get a replacement CPU with a later stepping.

Intel states one can work around the problem via a modified BIOS. I don't see how this is possible via a BIOS tweak; if it was purely a problem with the L2 cache architecture between both cores, then yes, I could see how one could avoid it. But not when L1 is involved.

Again, I'll repeat myself: this is MAJOR.

 

[kpamir]

well ******.

 

[imported_Zeke]

Does this effect all current steppings?

 

[Maximilian]

Might get a replacement? I bet they will give out replacements if this is as serious as the FDIV bug from the pentium 60/66's.

 

[kpamir]

i sure as hell hope they do, $500 better not go to waste.

 

[imported_Zeke]

Its replace or class action

 

[mcmikemc]

I have all my parts for my new E6600 rig at home just waiting for my case to come in and now I hear this :-(

Oh well I will just live with it untill I can get a replacement or untill it affects me.

 

[eelw]

Yes, I'm jumping the gun, but for the floating point bug, did owners have to send back the old CPU?

 

[koitsu]

Originally posted by: eelw
Yes, I'm jumping the gun, but for the floating point bug, did owners have to send back the old CPU?

I'm old enough to remember this (as well as 486 CPU bugs too ) -- yes, owners of the CPU were required to send their CPU to Intel, where it would be processed in under a week and the owner sent a replacement (new -- not repaired!) CPU.

As for the Pentium 0xF00F bug, I don't think Intel ever offered replacements for that (because the problem could be avoided via operating system and BIOS code).

 

[koitsu]

Originally posted by: Zeke
Does this effect all current steppings?

Affects the following models and steppings:

Intel Core 2 Extreme Processor, stepping B1
Intel Core 2 Extreme Processor, stepping B2
Intel Core 2 Duo Desktop Processor, stepping B1
Intel Core 2 Duo Desktop Processor, stepping B2

 

[Henny]

Originally posted by: Zeke
Its replace or class action

Every processor on the market has errata. (they always have and always will). This is no big deal.

 

[fbrdphreak]

Originally posted by: koitsu
A39, as mentioned by TI, is ***MAJOR***. This needs to become sticky IMMEDIATELY, and needs additional press focus.

{Edit: I'll explain the problem better...}
The trigger for the flaw is documented in the Errata. The flow would be this:

* Core#1: Attempts to fetch data via L1 cache (normal)
* Core#1: Data isn't in L1, which results in a cache miss (normal)
* Core#1: Data is fetched via L2 cache
* General: L2 cache data being fetched is actually from Core#2 L1 cache
* Core#1: Data returned from L2 cache fetch is incorrect/bad/corrupted
* Hello data corruption

The "General" item could also be, depending upon how you read the Errata:

* General: L2 cache contains data being modified via Core#2

Intel states in the Errata that they plan on releasing a fix for this (in English: a newer stepping (version) of the CPU should resolve the problem). For those who already own CPUs, you *might* be able to get a replacement CPU with a later stepping.

Intel states one can work around the problem via a modified BIOS. I don't see how this is possible via a BIOS tweak; if it was purely a problem with the L2 cache architecture between both cores, then yes, I could see how one could avoid it. But not when L1 is involved.

Again, I'll repeat myself: this is MAJOR.

Now let's not make a mountain out of a mole-hill. With modern OOE architecture, it is pretty unlikely for the data needed by Core 1 to be in L1 cache of Core 2. Frankly I'd imagine this is going to be a one-in-a-million bug. Here's the actual text instead of someone's paraphrasing:

AI39. Cache Data Access Request from One Core Hitting a Modified Line in
the L1 Data Cache of the Other Core May Cause Unpredictable System
Behavior
Problem: When request for data from Core 1 results in a L1 cache miss, the request is
sent to the L2 cache. If this request hits a modified line in the L1 data cache
of Core 2, certain internal conditions may cause incorrect data to be returned
to the Core 1.
Implication: This erratum may cause unpredictable system behavior.
Workaround: It is possible for the BIOS to contain a workaround for this erratum.
Status: For the steppings affected, see the Summary Tables of Changes.

Honestly I think Intel is just covering their ass as technically the architecture could allow a data hazard like that, but frankly the way things are processed today I doubt you'd ever see C1 trying to reference data in C2's L1 while it is being modified. Again, I'd say one-in-a-million.

But that's just my opinion, I could be wrong.

EDIT It is funny how quickly the new sheep will turn on their new master

 

[imported_Zeke]

Originally posted by: fbrdphreak

Originally posted by: koitsu
A39, as mentioned by TI, is ***MAJOR***. This needs to become sticky IMMEDIATELY, and needs additional press focus.

{Edit: I'll explain the problem better...}
The trigger for the flaw is documented in the Errata. The flow would be this:

* Core#1: Attempts to fetch data via L1 cache (normal)
* Core#1: Data isn't in L1, which results in a cache miss (normal)
* Core#1: Data is fetched via L2 cache
* General: L2 cache data being fetched is actually from Core#2 L1 cache
* Core#1: Data returned from L2 cache fetch is incorrect/bad/corrupted
* Hello data corruption

The "General" item could also be, depending upon how you read the Errata:

* General: L2 cache contains data being modified via Core#2

Intel states in the Errata that they plan on releasing a fix for this (in English: a newer stepping (version) of the CPU should resolve the problem). For those who already own CPUs, you *might* be able to get a replacement CPU with a later stepping.

Intel states one can work around the problem via a modified BIOS. I don't see how this is possible via a BIOS tweak; if it was purely a problem with the L2 cache architecture between both cores, then yes, I could see how one could avoid it. But not when L1 is involved.

Again, I'll repeat myself: this is MAJOR.

Now let's not make a mountain out of a mole-hill. With modern OOE architecture, it is pretty unlikely for the data needed by Core 1 to be in L1 cache of Core 2. Frankly I'd imagine this is going to be a one-in-a-million bug. Here's the actual text instead of someone's paraphrasing:

AI39. Cache Data Access Request from One Core Hitting a Modified Line in
the L1 Data Cache of the Other Core May Cause Unpredictable System
Behavior
Problem: When request for data from Core 1 results in a L1 cache miss, the request is
sent to the L2 cache. If this request hits a modified line in the L1 data cache
of Core 2, certain internal conditions may cause incorrect data to be returned
to the Core 1.
Implication: This erratum may cause unpredictable system behavior.
Workaround: It is possible for the BIOS to contain a workaround for this erratum.
Status: For the steppings affected, see the Summary Tables of Changes.

Honestly I think Intel is just covering their ass as technically the architecture could allow a data hazard like that, but frankly the way things are processed today I doubt you'd ever see C1 trying to reference data in C2's L1 while it is being modified. Again, I'd say one-in-a-million.

But that's just my opinion, I could be wrong.

EDIT It is funny how quickly the new sheep will turn on their new master

I don't really see how the sheep comment is even vaguley relevant. If I buy a product that turns out to be defective, I want a replacement. Hopefully this isn't a major problem.

 

[fbrdphreak]

Originally posted by: Zeke
I don't really see how the sheep comment is even vaguley relevant. If I buy a product that turns out to be defective, I want a replacement. Hopefully this isn't a major problem.

It is funny because I'd bet if AMD had a similar errata on AM2 or something, all the new buyers wouldn't be like "OMG THEY ARE TRYING TO SCR3W US, C7@$$ ACTION LAWSUIT!!!"

 

[imported_Zeke]

Originally posted by: fbrdphreak

Originally posted by: Zeke
I don't really see how the sheep comment is even vaguley relevant. If I buy a product that turns out to be defective, I want a replacement. Hopefully this isn't a major problem.

It is funny because I'd bet if AMD had a similar errata on AM2 or something, all the new buyers wouldn't be like "OMG THEY ARE TRYING TO SCR3W US, C7@$$ ACTION LAWSUIT!!!"

Like I said, this has nothing to do with brands. Bad product = replacement. You must hang out with alot of fanboys.

 

[Henny]

Originally posted by: Zeke

Originally posted by: fbrdphreak

Originally posted by: koitsu
A39, as mentioned by TI, is ***MAJOR***. This needs to become sticky IMMEDIATELY, and needs additional press focus.

{Edit: I'll explain the problem better...}
The trigger for the flaw is documented in the Errata. The flow would be this:

* Core#1: Attempts to fetch data via L1 cache (normal)
* Core#1: Data isn't in L1, which results in a cache miss (normal)
* Core#1: Data is fetched via L2 cache
* General: L2 cache data being fetched is actually from Core#2 L1 cache
* Core#1: Data returned from L2 cache fetch is incorrect/bad/corrupted
* Hello data corruption

The "General" item could also be, depending upon how you read the Errata:

* General: L2 cache contains data being modified via Core#2

Intel states in the Errata that they plan on releasing a fix for this (in English: a newer stepping (version) of the CPU should resolve the problem). For those who already own CPUs, you *might* be able to get a replacement CPU with a later stepping.

Intel states one can work around the problem via a modified BIOS. I don't see how this is possible via a BIOS tweak; if it was purely a problem with the L2 cache architecture between both cores, then yes, I could see how one could avoid it. But not when L1 is involved.

Again, I'll repeat myself: this is MAJOR.

Now let's not make a mountain out of a mole-hill. With modern OOE architecture, it is pretty unlikely for the data needed by Core 1 to be in L1 cache of Core 2. Frankly I'd imagine this is going to be a one-in-a-million bug. Here's the actual text instead of someone's paraphrasing:

AI39. Cache Data Access Request from One Core Hitting a Modified Line in
the L1 Data Cache of the Other Core May Cause Unpredictable System
Behavior
Problem: When request for data from Core 1 results in a L1 cache miss, the request is
sent to the L2 cache. If this request hits a modified line in the L1 data cache
of Core 2, certain internal conditions may cause incorrect data to be returned
to the Core 1.
Implication: This erratum may cause unpredictable system behavior.
Workaround: It is possible for the BIOS to contain a workaround for this erratum.
Status: For the steppings affected, see the Summary Tables of Changes.

Honestly I think Intel is just covering their ass as technically the architecture could allow a data hazard like that, but frankly the way things are processed today I doubt you'd ever see C1 trying to reference data in C2's L1 while it is being modified. Again, I'd say one-in-a-million.

But that's just my opinion, I could be wrong.

EDIT It is funny how quickly the new sheep will turn on their new master

I don't really see how the sheep comment is even vaguley relevant. If I buy a product that turns out to be defective, I want a replacement. Hopefully this isn't a major problem.

Then you better get this:

Text

Every component of every computer has errata. The CPU, the memory, the chipsets, the OS, etc.

 

[jose]

Glad I didn't get a conroe now. I'll just wait till December when everything will probably be fixed .

In the mean time, couldn't you disable one of the cores ?


Regards,
Jose

 

[imported_Zeke]

Originally posted by: Henny

Originally posted by: Zeke

Originally posted by: fbrdphreak

Originally posted by: koitsu
A39, as mentioned by TI, is ***MAJOR***. This needs to become sticky IMMEDIATELY, and needs additional press focus.

{Edit: I'll explain the problem better...}
The trigger for the flaw is documented in the Errata. The flow would be this:

* Core#1: Attempts to fetch data via L1 cache (normal)
* Core#1: Data isn't in L1, which results in a cache miss (normal)
* Core#1: Data is fetched via L2 cache
* General: L2 cache data being fetched is actually from Core#2 L1 cache
* Core#1: Data returned from L2 cache fetch is incorrect/bad/corrupted
* Hello data corruption

The "General" item could also be, depending upon how you read the Errata:

* General: L2 cache contains data being modified via Core#2

Intel states in the Errata that they plan on releasing a fix for this (in English: a newer stepping (version) of the CPU should resolve the problem). For those who already own CPUs, you *might* be able to get a replacement CPU with a later stepping.

Intel states one can work around the problem via a modified BIOS. I don't see how this is possible via a BIOS tweak; if it was purely a problem with the L2 cache architecture between both cores, then yes, I could see how one could avoid it. But not when L1 is involved.

Again, I'll repeat myself: this is MAJOR.

Now let's not make a mountain out of a mole-hill. With modern OOE architecture, it is pretty unlikely for the data needed by Core 1 to be in L1 cache of Core 2. Frankly I'd imagine this is going to be a one-in-a-million bug. Here's the actual text instead of someone's paraphrasing:

AI39. Cache Data Access Request from One Core Hitting a Modified Line in
the L1 Data Cache of the Other Core May Cause Unpredictable System
Behavior
Problem: When request for data from Core 1 results in a L1 cache miss, the request is
sent to the L2 cache. If this request hits a modified line in the L1 data cache
of Core 2, certain internal conditions may cause incorrect data to be returned
to the Core 1.
Implication: This erratum may cause unpredictable system behavior.
Workaround: It is possible for the BIOS to contain a workaround for this erratum.
Status: For the steppings affected, see the Summary Tables of Changes.

Honestly I think Intel is just covering their ass as technically the architecture could allow a data hazard like that, but frankly the way things are processed today I doubt you'd ever see C1 trying to reference data in C2's L1 while it is being modified. Again, I'd say one-in-a-million.

But that's just my opinion, I could be wrong.

EDIT It is funny how quickly the new sheep will turn on their new master

I don't really see how the sheep comment is even vaguley relevant. If I buy a product that turns out to be defective, I want a replacement. Hopefully this isn't a major problem.

Then you better get this:

Text

Every component of every computer has errata. The CPU, the memory, the chipsets, the OS, etc.

....I realize this......someone already pointed it out. However, how many of these cause data corruption? If this happens at even a small rate it is a serious problem.

 

[Henny]

Originally posted by: Zeke

Originally posted by: Henny

Originally posted by: Zeke

Originally posted by: fbrdphreak

Originally posted by: koitsu
A39, as mentioned by TI, is ***MAJOR***. This needs to become sticky IMMEDIATELY, and needs additional press focus.

{Edit: I'll explain the problem better...}
The trigger for the flaw is documented in the Errata. The flow would be this:

* Core#1: Attempts to fetch data via L1 cache (normal)
* Core#1: Data isn't in L1, which results in a cache miss (normal)
* Core#1: Data is fetched via L2 cache
* General: L2 cache data being fetched is actually from Core#2 L1 cache
* Core#1: Data returned from L2 cache fetch is incorrect/bad/corrupted
* Hello data corruption

The "General" item could also be, depending upon how you read the Errata:

* General: L2 cache contains data being modified via Core#2

Intel states in the Errata that they plan on releasing a fix for this (in English: a newer stepping (version) of the CPU should resolve the problem). For those who already own CPUs, you *might* be able to get a replacement CPU with a later stepping.

Intel states one can work around the problem via a modified BIOS. I don't see how this is possible via a BIOS tweak; if it was purely a problem with the L2 cache architecture between both cores, then yes, I could see how one could avoid it. But not when L1 is involved.

Again, I'll repeat myself: this is MAJOR.

Now let's not make a mountain out of a mole-hill. With modern OOE architecture, it is pretty unlikely for the data needed by Core 1 to be in L1 cache of Core 2. Frankly I'd imagine this is going to be a one-in-a-million bug. Here's the actual text instead of someone's paraphrasing:

AI39. Cache Data Access Request from One Core Hitting a Modified Line in
the L1 Data Cache of the Other Core May Cause Unpredictable System
Behavior
Problem: When request for data from Core 1 results in a L1 cache miss, the request is
sent to the L2 cache. If this request hits a modified line in the L1 data cache
of Core 2, certain internal conditions may cause incorrect data to be returned
to the Core 1.
Implication: This erratum may cause unpredictable system behavior.
Workaround: It is possible for the BIOS to contain a workaround for this erratum.
Status: For the steppings affected, see the Summary Tables of Changes.

Honestly I think Intel is just covering their ass as technically the architecture could allow a data hazard like that, but frankly the way things are processed today I doubt you'd ever see C1 trying to reference data in C2's L1 while it is being modified. Again, I'd say one-in-a-million.

But that's just my opinion, I could be wrong.

EDIT It is funny how quickly the new sheep will turn on their new master

I don't really see how the sheep comment is even vaguley relevant. If I buy a product that turns out to be defective, I want a replacement. Hopefully this isn't a major problem.

Then you better get this:

Text

Every component of every computer has errata. The CPU, the memory, the chipsets, the OS, etc.

....I realize this......someone already pointed it out. However, how many of these cause data corruption? If this happens at even a small rate it is a serious problem.

Well guess what. Athlon 64 currently has 249 errata items and many of them can also cause data corruption:

AMD Errata

Errata IS, HAS, and ALWAYS will be part of any silicon design.

 

[galvelan]

I am sure with all the testing and excitement built up when the conroe was getting ready to launch the websites would have found something funny by now with their reviews or testing. I think the problem wont come up right now... if it is a problem it will probably show up when programmers really get their hands dirty and start making multi threaded programs that really push the two cores excessively. Games, speech recognition, etc. we will have to see. It may never show up

 

[koitsu]

Originally posted by: fbrdphreak
Now let's not make a mountain out of a mole-hill. With modern OOE architecture, it is pretty unlikely for the data needed by Core 1 to be in L1 cache of Core 2.

The way I understand CPU architecture (and admittedly I come from a purely CISC-based single-CPU background), the L1 caches on Core#1 and Core#2 are completely independant of one another.

The way I understand the Errata, what you've described is not what's happening. The problem explicitly happens when there's an L1 cache miss and L2 is relied upon. That's the part that's interesting.

Frankly I'd imagine this is going to be a one-in-a-million bug.

I disagree. Do you realise how many cache operations go on in a processor within 1 physical second of time? Hundreds of thousands. Do the math.

Here's the actual text instead of someone's paraphrasing:

I "paraphrased" for those who aren't familiar with low-level architecture. I come from a pure assembly and machine language background, so I did my best to explain the situation as I understand it.

Honestly I think Intel is just covering their ass as technically the architecture could allow a data hazard like that, but frankly the way things are processed today I doubt you'd ever see C1 trying to reference data in C2's L1 while it is being modified.

Again, I don't think either CPU can access one another's L1 directly. If you have an architecture diagram for the Core 2 Duo, I'd love to see it, as I could be flat-out wrong. But again, this problem happens when there's a L1 cache **miss** (that means the data being fetched is not in the local Core's cache, which relies on L2).

I'll happily admit that I am NOT very familiar with SMP architecture on x86.

EDIT It is funny how quickly the new sheep will turn on their new master

This comment may have been for others... but in my case: i'm a complete and total Intel fanboy, and have been up until the Prescott days (400 watt draw? NO THANKS). I've been aching to switch back to Intel CPUs -- and not because of the CPU, but because of Intel chipsets being reliable (compared to NF4 and AMDs laughing-stock-of-a-chipset). It just so happened that the Core 2 Duos came out, and blew away the competition -- while simultaneously drawing less power than their AMD competitors.

My current system is an X2 3800+. I'm happy with it, but not very thrilled about the NF4 chipset. I don't like the weird SATA2 bugs it has, and nVidia's chipset drivers are atrocious (not to mention, hardly updated, and include no changelog from nVidia).

For now, my GA-965P-DS3 will sit in its box until a newer CPU stepping is available and Intel marks this particular errata as fixed in that stepping.

 

[phile]

Most of this goes over my head, so I prefer to consider this problem in terms of how it will affect my use of the product. All I know is that I've been pounding a E6300 and E6600 for 3 weeks without so much as a hiccup. I've been playing games, using office apps, photoshop, video encoding, benchmarking, etc., and haven't noticed any peculiarities. How could a major problem go unnoticed for several weeks of intense use? I'll remain concerned, but unworried.

-phil

 

[Viditor]

Originally posted by: Henny
Well guess what. Athlon 64 currently has 249 errata items and many of them can also cause data corruption:

AMD Errata

Errata IS, HAS, and ALWAYS will be part of any silicon design.

Comment: 249 is not A64, that's all AMD lines.

Question: which ones can cause corrupted data?

 

[fbrdphreak]

Originally posted by: koitsu

Originally posted by: fbrdphreak
Now let's not make a mountain out of a mole-hill. With modern OOE architecture, it is pretty unlikely for the data needed by Core 1 to be in L1 cache of Core 2.

The way I understand CPU architecture (and admittedly I come from a purely CISC-based single-CPU background), the L1 caches on Core#1 and Core#2 are completely independant of one another.

The way I understand the Errata, what you've described is not what's happening. The problem explicitly happens when there's an L1 cache miss and L2 is relied upon. That's the part that's interesting. What the errate is describing is that C1 undergoes an L1 miss. It goes to the shared L2, and by some miracle (dunno how) it finds out the data it needs is stored in C2's L1. So it fetches from C2-L1 over to C1-L1, but the data is being/has been modified in L1 and while the address is what C1-L1 needs, the data is different. Thus C1-L1 doesn't get the data it needs and you have a bug, a potentially unstable one.

Frankly I'd imagine this is going to be a one-in-a-million bug.

I disagree. Do you realise how many cache operations go on in a processor within 1 physical second of time? Hundreds of thousands. Do the math. I do know how man cache operations go on. I tested dozens of cache configurations tracing numerous different operations (C compiling for example) and measured hits/misses/etc. I also studied cache execution and operation. There are measures in place to prevent data hazards like this and from what I can tell, the only reason this hazard exists is because Conroe can fetch data from another core's L1 and I'd imagine that isn't accounted for in standard architecture.

Here's the actual text instead of someone's paraphrasing:

I "paraphrased" for those who aren't familiar with low-level architecture. I come from a pure assembly and machine language background, so I did my best to explain the situation as I understand it. I wasn't nagging you on that, I was giving the people the straight facts. Stop getting so defensive

Honestly I think Intel is just covering their ass as technically the architecture could allow a data hazard like that, but frankly the way things are processed today I doubt you'd ever see C1 trying to reference data in C2's L1 while it is being modified.

Again, I don't think either CPU can access one another's L1 directly. If you have an architecture diagram for the Core 2 Duo, I'd love to see it, as I could be flat-out wrong. But again, this problem happens when there's a L1 cache **miss** (that means the data being fetched is not in the local Core's cache, which relies on L2).

I'll happily admit that I am NOT very familiar with SMP architecture on x86. I'm not sure how it get's the other core's L1 info either. I'd imagine it is some kind of reverse fetch that can be performed since they share the same L2, but I really don't know for sure. What I do know is that it is implied in the errata that a core can fetch data from the other core's L1.

EDIT It is funny how quickly the new sheep will turn on their new master

This comment may have been for others... but in my case: i'm a complete and total Intel fanboy, and have been up until the Prescott days (400 watt draw? NO THANKS). I've been aching to switch back to Intel CPUs -- and not because of the CPU, but because of Intel chipsets being reliable (compared to NF4 and AMDs laughing-stock-of-a-chipset). It just so happened that the Core 2 Duos came out, and blew away the competition -- while simultaneously drawing less power than their AMD competitors.

My current system is an X2 3800+. I'm happy with it, but not very thrilled about the NF4 chipset. I don't like the weird SATA2 bugs it has, and nVidia's chipset drivers are atrocious (not to mention, hardly updated, and include no changelog from nVidia).

For now, my GA-965P-DS3 will sit in its box until a newer CPU stepping is available and Intel marks this particular errata as fixed in that stepping. Again, the comment was just a remark on how a lot of people here switched to Intel and it is interesting to watch the tides change