K8 Bug List ... Is Your Opteron or A64 Safe?

[slvr_phoenix]

While browsing around AMD's site for some information I ran across <A HREF="http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf" target="_new">this PDF file</A> that lists 'Errata'. Let me list a few of the items detailed:

<font color=green><b>60 Single Machine Check Error May Report Overflow</b>

<b>Description</b>
A single parity error encountered in the data cache tag array may incorrectly report the detection of
multiple errors, as indicated by the overflow bit of the DC Machine Check Status register (bit 62 of
MSR 0x401).

<b>Potential Effect on System</b>
System software may be informed of a machine check overflow when only a single error was actually
encountered.</font color=green>

<font color=green><b>62 Task Gates With Breakpoints Enabled May Cause Unexpected Faults</b>

<b>Description</b>
When a task gate is used by a CALL or JMP instruction and any debug breakpoint is enabled through
the DR7.LE or GE bits, the processor may incorrectly use the new TSS base [15:0] contained in the
new TSS as a selector. This will most likely lead to a GP fault with an error code of the new TSS base.

<b>Potential Effect on System</b>
Unexpected faults leading to unpredictable system failure.</font color=green>

<font color=green><b>63 TLB Flush Filter Causes Coherency Problem in Multiprocessor Systems</b>

<b>Description</b>
If the TLB flush filter is enabled in a multiprocessor configuration, coherency problems may arise
between the page tables in memory and the translations stored in the on-chip TLBs. This can result in
the possible use of stale translations even after software has performed a TLB flush.

<b>Potential Effect on System</b>
Unpredictable system failure.</font color=green>

<font color=green><b>66 Upstream Read Response Delayed by Downstream Posted Writes</b>

<b>Description</b>
An upstream read to main memory can be delayed when the following sequence occurs:
1. The processor issues one or more posted writes downstream.
2. The processor evicts a line from its cache.
3. The chipset performs an upstream read to memory with the PassPW bit set in the HyperTransport
packet.
In this case, the read should pass the downstream posted writes but due to a resource conflict in the
internal request queues, the read is delayed until the processor’s cache line is written and all
previously enqueued posted writes have completed.

<b>Potential Effect on System</b>
Unexpectedly large latencies may be experienced during upstream memory reads, potentially
resulting in performance anomolies or functional failures, depending on the buffering capabilities of
external devices.</font color=green>

<font color=green><b>69 Multiprocessor Coherency Problem with Hardware Prefetch Mechanism</b>

<b>Description</b>
If the on-chip hardware prefetch mechansim generates a prefetch with write intent for a cache line
that is also found to be present in the instruction cache, then the eventual prefetch response from the
system is incorrectly discarded by the processor.
In the event the prefetched line was transferred in the modified state from another processor’s cache,
that processor’s modified data is lost.

<b>Potential Effect on System</b>
Multiprocessor memory coherency issues leading to unpredictable system failure.</font color=green>

<font color=green><b>74 Registered DIMM Exit-Self-Refresh Requirements Not Met</b>

<b>Description</b>
When sequencing registered DIMMs out of self refresh state at the completion of an S1, S3 or
LDTSTOP_L initiated HyperTransport link width/frequency change, certain sequencing
requirements of the registered DIMMs are not met.

<b>Potential Effect on System</b>
Memory system failure leading to unpredictable system failure.</font color=green>

<font color=green><b>80 Registered DIMM Initialization Requirements Not Met</b>

<b>Description</b>
When initializing registered DIMMs after a powerup or warm reset assertion, the time interval
between the deassertion of MEMRESET_L and the assertion of CKE is not sufficient for some
DIMMs.

<b>Potential Effect on System</b>
The memory system may fail to initialize, leading to boot failure.</font color=green>

<font color=green><b>86 DRAM Data Masking Feature Can Cause ECC Failures</b>

<b>Description</b>
Under certain conditions, the memory controller fails to generate a DRAM read request when
performing partial writes to an already allocated write combining buffer. Because the DRAM is not
read for these subsequent write requests, the generated ECC bits are incorrect.

<b>Potential Effect on System</b>
Incorrect data can be read back from DRAM.</font color=green>

<font color=green><b>89 Potential Deadlock With Locked Transactions</b>

<b>Description</b>
Downstream non-posted requests to devices that are dependent on the completion of an upstream
non-posted request can cause a deadlock in the presence of transactions resulting in bus locks, as
shown in the following two scenarios:
1. A downstream non-posted read to the LPC bus occurs while an LPC bus DMA is in progress. The
legacy LPC DMA blocks downstream traffic until it completes its upstream reads.
2. A downstream non-posted read is sent to a device that must first send an upstream non-posted
read before it can complete the downstream read.
In both cases, a locked transaction causes the upstream channel to be blocked, causing the deadlock
condition.

<b>Potential Effect on System</b>
The system fails due to a bus deadlock.</font color=green>

<font color=green><b>94 Sequential Prefetch Feature May Cause Incorrect Processor Operation</b>

<b>Description</b>
On an instruction cache miss, the sequential prefetch mechanism may enable the early prefetch of the
next sequential cache line. Under a highly specific set of internal pipeline conditions this mechanism
may cause the processor to hang or execute incorrect code in 64-bit systems running 32-bit
compatibility mode applications.

<b>Potential Effect on System</b>
Processor may deadlock or execute incorrect code.</font color=green>

<font color=green><b>97 128-Bit Streaming Stores May Cause Coherency Failure</b>

<b>Description</b>
Under a specific set of internal pipeline conditions, stale data may be left in the L1 cache when a 128-
bit streaming store (MOVNT*) to a writeback (WB) memory type misses in the L1 data cache and
both L1 and L2 TLBs.

<b>Potential Effect on System</b>
Memory coherence failures leading to unpredictable operation.</font color=green>

Don't shoot the messenger. This is all straight out of AMD's documentation. If you own an Opteron or Athlon 64 I would highly suggest that you look up what bugs you are potentially affected by and see about trying to implement any of AMD's suggested workarounds. Better safe than sorry.

<A HREF="http://ars.userfriendly.org/cartoons/?id=20031017" target="_new">Then what's your poison of choice?
Soymilk. I was raised on the stuff.
Ah. What's it made of?
Soy.
Is that soy as in soylent green?</A>

 

[Kelledin]

<A HREF="http://www.xbitlabs.com/news/mobile/display/20030407062442.html" target="_new">Pentium M has "only" 14 errata.</A>

Errata are a fact of life with complex processors. Some get corrected (or worked around) later, some don't. Almost all of them take the engineering equivalent of a virgin goat sacrifice under a harvest moon to trip over, which is why they slip through the cracks at all.

This is why most CISC kit (including AMD and Intel CPUs) are largely microcode-based. Microcode can be tweaked without entire new tapeouts or the like.

<i>I can love my fellow man...but I'm damned if I'll love yours.</i>

 

[slvr_phoenix]

Easy Kelledin. I know that processors have 'errata'. I know how it works. I'm not your typical troll trying to prove something. I didn't say "AMD sucks and Intel rocks!" You don't have to get defensive.

Primarily all that I am saying that some of these are rather interesting bugs and the more aware that people are about them the better chance they have of mitigating the occurance of these problems. So far I hadn't seen any threads or articles about the 'errata' so I thought that it would be useful information for people to read.

Secondarily I think that some of them are interesting enough to discuss. Some of them are rather applicable to servers. Some of them are intriguing from a software engineer's point of view.

That's all.

<A HREF="http://ars.userfriendly.org/cartoons/?id=20031017" target="_new">Then what's your poison of choice?
Soymilk. I was raised on the stuff.
Ah. What's it made of?
Soy.
Is that soy as in soylent green?</A>

 

[Kelledin]

Easy Kelledin. I know that processors have 'errata'. I know how it works.

Oh, I know. I'm just putting a little extra perspective on things.

This goes beyond processors, by the way. Goes beyond x86 platforms well. The core logic (fancy term for chipset) on my PC164LX motherboard has this crazy little bug in scatter-gather DMA handling. Later revisions of the board just had an extra chip tacked on to handle that instead of the buggy part of the core logic. The bug itself was never "fixed", just...masked.

(I was lucky enough to get a board with the tacked-on workaround in place.)

If you spend most of your time working with this stuff, you start getting the attitude that the computer world is nothing but a morass of buggy hardware waiting to blow up in your face.

<i>I can love my fellow man...but I'm damned if I'll love yours.</i>

 

[slvr_phoenix]

If you spend most of your time working with this stuff, you start getting the attitude that the computer world is nothing but a morass of buggy hardware waiting to blow up in your face.

No kidding. I'm one of the few unfortunates to have a P3 running on a VIA chipset using Win2K for my work PC. More so than the buggy hardware is the buggy firmware! It took VIA ages to finally release drivers that didn't cause my system to crash at least once a day. Grrrr.

(My only consolation is that the hardware was not my choice. I even suggested a 440BX or an 815 for a mobo, but noooooooo, they had to go VIA.)

And then there are all of the poor saps who have WinME but are forced to use the 16-bit drivers from Win9x. I've helped an awful lot of people 'downgrade' to Win98SE just to make their PC stable.

And of course there are actual software bugs too. MS has released so many critical updates that I dread doing a clean OS install because I <i>know</i> just how long it'll take to run Windows Update afterwords.

Which is exactly why I like to help bring awareness of known bugs to people so that they can mitigate the influence of those bugs in their systems and purchases.

<A HREF="http://ars.userfriendly.org/cartoons/?id=20031017" target="_new">Then what's your poison of choice?
Soymilk. I was raised on the stuff.
Ah. What's it made of?
Soy.
Is that soy as in soylent green?</A>

 

[juin]

Good news at lease they make testing now most of this errata dont affect stability just performance P4 was having more that 500 errata most been solve and they still find some.

I dont like french test

 

[Guest]

> I'm not your typical troll trying to prove something.

Then why didnt you include the workarounds in your quotes ? Pretty much every issue you raised there only affects BIOS developpers, and they all have very straightforward fixes. Known errata is not what one should fear, they are known and either they can be worked around, or the chip wouldnt ship, that simple. Its unknown errata like the FDIV bug one should fear

Also, if not for trolling, why would you use a FUD title like "is you Opteron or A64 Safe ?"

= The views stated herein are my personal views, and not necessarily the views of my wife. =

 

[TknD]

Easy Kelledin. I know that processors have 'errata'. I know how it works. I'm not your typical troll trying to prove something. I didn't say "AMD sucks and Intel rocks!" You don't have to get defensive.

I have to disagree, the original title and post has connotations that make it seem like there is something bad with AMD64/Opteron.

If you really wanted to be neutral or not "prove something" then the post title should have been "opteron errata" not "is your opteron or A64 safe?"

Either you're trying to draw attention to yourself like a newspaper headline or you're trying to hype something up.

 

[whittak]

There is nothing wrong with constructive advice on things to be aware of. The original post was very miss leading even for a laymen like myself.

I am only new here and seeing slvr_phoenix's other posts lead me to believe he is trolling (IMO).

 

[slvr_phoenix]

Then why didnt you include the workarounds in your quotes ?

There are a number of reasons actually. Initially I did. The post however was a mile long. So I trimmed it up as well as I could. In case you weren't reading the post itself, I did finish with the statement "<font color=blue>If you own an Opteron or Athlon 64 I would highly suggest that you look up what bugs you are potentially affected by and see about trying to implement any of AMD's suggested workarounds.</font color=blue>" So in the end I decided to use the quotes to get people's attention to the problems at hand so that they would have a reason to go and look up the workarounds.

Pretty much every issue you raised there only affects BIOS developpers, and they all have very straightforward fixes.

Straightforward workarounds you mean. And that's my point. If you own these chips then check into it. Pester your mobo's manu for those BIOS updates. Change settings in BIOS if you can. Fix your system. Make it stable. Make your data safe. That's what I'm saying.

Known errata is not what one should fear, they are known and either they can be worked around, or the chip wouldnt ship, that simple.

Actually, when purchasing new hardware known errata is <i>exactly</i> what one should fear and research. An existing customer is already knee-deep into the errata, but a future customer can either watch for the fixes and workarounds to be implemented before they purchase or can decide upon a different product if they decide that the problems are a concern to them. An educated consumer is a happy consumer.

Its unknown errata like the FDIV bug one should fear

To fear the unknown to the point of acting upon it is to become a slave to infinite worries. bbaeyens, you have a rather paranoid point of view.

Also, if not for trolling, why would you use a FUD title like "is you Opteron or A64 Safe ?"

Because until you implement fixes and workarounds your data <i>isn't</i> safe. No one buys the best because they enjoy having their PC crash on them while working on a highly important project. They buy the best because they expect to get what they pay for, and usually because they <i>need</i> that stability. There are fixes. But have you implemented them yet? Is your data safe? <i>That</i> was my point.

And if you can't see the simplicity of that and have to go and twist that into some trollish monstrosity because that's how you get your jollies then you can go f yourself because I'm not playing that game.

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

 

[slvr_phoenix]

I have to disagree, the original title and post has connotations that make it seem like there is something bad with AMD64/Opteron.

Duh. What do you think errata is? There <i>is</i> something bad. <i>AND</i> you can fix it and/or pester your manu to fix it. <i>That's</i> the point.

If you really wanted to be neutral or not "prove something" then the post title should have been "opteron errata" not "is your opteron or A64 safe?"

Either you're trying to draw attention to yourself like a newspaper headline or you're trying to hype something up.

Exactly! Do you honestly think people would be phased at all to see "Opteron errata"? No! The way to get them to look, to get them interested in the problems enough to fix their PC is to get their attention. There are plenty of errata that I cut out of the post. There are plenty of workarounds. No one has to suffer from these errata. They can make their PC and the data on it safe. But if they aren't interested in even looking then you have to <i>make</i> it interesting enough for them to look or else they'll never bother making their data safe.

Why do you think so few people run Windows Update? It's not because it's hard. It's not because it's confusing. It's because it really doesn't seem all that important. But if you <i>make</i> it seem important, then people will do it.

Did I dramatize the errata? Hell yes! And for good reason, so that it would <i>become interesting enough for people to be concerned enough to implement the workarounds</i>. If the definition of trolling has become "<i>trying to get customers to make their PCs more stable and more safe</i>" then things have gotten really f-ing out of hand.

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

 

[slvr_phoenix]

I am only new here and seeing slvr_phoenix's other posts lead me to believe he is trolling (IMO).

Other posts led you to believe that I'm trolling? What the hell are you talking about?

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

 

[Guest]

> If you own these chips then check into it. Pester your
>mobo's manu for those BIOS updates. Change settings in BIOS
>if you can. Fix your system. Make it stable. Make your data
>safe.

Good grief, none of these errata affect end users ! You really think something like <font color=blue>"setting the DisDatMsk bit (Northbridge Configuration Register - MSR C001_001F, bit 36" </font color=blue>is something you or me should do in the BIOS ?? That stuff is 99% for chipset and BIOS developpers, not end users. The remaining 1% is perhaps relevant to OS kernel developpers. It has zero relevance to customers/ end users. Seriously, do you have any idea what do with a published workaround like <font color=blue>"clear the NBLowPwrEn bit in SMAF code 011 of the Power Mangement control Registers (i.e., clear Dev:3x80[25])." </font color=blue>? To nVidia engineers or AMI developpers this could mean something, but it means nothing to me. I haven't even got a clue what it is about.

>Actually, when purchasing new hardware known errata is
>exactly what one should fear and research

Allright, then enlighten me, and explain 2 of those errata; tell what it means, how it would impact me, and what I should do to avoid any issues. Pick just 2. This list is utterly meaningless to me.

= The views stated herein are my personal views, and not necessarily the views of my wife. =

 

[Guest]

>Did I dramatize the errata? Hell yes! And for good reason,
>so that it would become interesting enough for people to be
>concerned enough to implement the workarounds.

People don't have the faintest idea what these errata mean, (at least I don't) nor can they either fix any of them even with the printed errata list printed on their desk, they can't even check if they are fixed without reverse engineering the BIOS or OS kernel and knowing a LOT more than you or me. If it werent for open source operating systems, there wouldnt even be any reason at all to publish this list. Are you concerned with the errata in your GPU ? in your RAID controller ? Rest assured there are plenty of bugs in those chips as well, and they are known to the people that should know about them, and that doesnt include you or me. Its pointless

= The views stated herein are my personal views, and not necessarily the views of my wife. =

 

[slvr_phoenix]

Good grief, none of these errata affect end users !

What, end users are just magically safe from these somehow? Yeah, whatever. End users are the <i>exact</i> people <i>affected</i> by these.

You really think something like "setting the DisDatMsk bit (Northbridge Configuration Register - MSR C001_001F, bit 36" is something you or me should do in the BIOS ??

No, I think it's something that an end user should demand of their manu to fix in the next patch of their BIOS, <i>as I stated</i>. If a customer contacts the manu and expresses a desire for an exact fix then the manu will be much more likely to make that fix a priority. If however you just sit back and wait for it to happen it may <i>never</i> happen. End users who make themselves an active part of the product refinement process are much more likely to see results that they need than end users who sit on their duff. Most companies <i>like</i> customer feedback. So get active! Express concerns. Make your needs for a fix known.

Allright, then enlighten me, and explain 2 of those errata; tell what it means, how it would impact me, and what I should do to avoid any issues. Pick just 2.

Talk about easy as pie. You want two, here's two:

<font color=green><b>58 Memory Latency with Processor Power States</b>

<b>Description</b>
If CPU Low Power mode is enabled in the C1, C2, or throttling processor power states, then
externally generated sequences of memory references may experience unexpectedly large latencies
through the memory controller.

<b>Potential Effect on System</b>
Long memory latencies may lead to performance anomolies or functional failures, depending on the
buffering capabilities of external devices.

<b>Suggested Workaround</b>
Do not enable CPU Low Power mode in the C1, C2, or throttling processor power states. Specifically,
disable the CPULowPwrEn bits for System Management Action Field (SMAF) codes 000, 101, and
111 by clearing Dev:3x80[0] for C2, Dev:3x84[24] for C1, and Dev:3x84[8] for throttling.
</font color=green>

<b>Translation:</b>
If you drop your Opteron into a power saving mode (or it gets throttled) then your memory may be run at much worse latencies which will kill your performance.

<b>Workaround:</b>
Until proper workarounds have been implemented in BIOS or fixed in the CPU itself you shouldn't allow your CPU to throttle and you should avoid running your CPU in a power saving mode.

<font color=green><b>80 Registered DIMM Initialization Requirements Not Met</b>

<b>Description</b>
When initializing registered DIMMs after a powerup or warm reset assertion, the time interval
between the deassertion of MEMRESET_L and the assertion of CKE is not sufficient for some
DIMMs.

<b>Potential Effect on System</b>
The memory system may fail to initialize, leading to boot failure.

<b>Suggested Workaround</b>
A board level workaround is available for this problem, see Methodologies for Using Registered
DIMMs with AMD Athlon™ 64 and AMD Opteron™ Processors, order #27510, for details.</font color=green>

<b>Translation:</b>
Some memory won't work with your CPU because AMD stuffed up the initialization requirements in their ondie memory controller. A motherboard fix is available.

<b>Workaround:</b>
If you have a motherboard before it was fixed and your memory doesn't work in it this is why and either replace your memory with better RAM, demand that your mobo manu replace your mobo with a fixed mobo, or replace your mobo with a fixed mobo at your own cost.

If you're looking to purchase new hardware then be sure to get a mobo that contains the fix unless you want to take a chance.

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

 

[jihiggs]

damn, its getting to the point where a guy cant talk about something without the a$$holes nitpicking it to death and twisting it around so bad. you should all be politicians.

wpdclan.com cs game server - 69.12.5.119:27015

 

[slvr_phoenix]

People don't have the faintest idea what these errata mean, (at least I don't)

And you wonder why I called you clueless? Just because you don't understand doesn't mean that no one does or that my trying to bring awareness and end-user action is useless. It only means that you personally are clueless, as you even <i>just</i> admitted.

nor can they either fix any of them even with the printed errata list printed on their desk, they can't even check if they are fixed without reverse engineering the BIOS or OS kernel and knowing a LOT more than you or me

No, but they <i>can</i> make themselves part of the process to get then fixed if they complain to their motherboard manufacturer and to AMD. And they <i>can</i> contact their motherboard manufacturer to find out what workarounds have been implemented into the current hardware and BIOS releases if they plan on purchasing new hardware so that they can make an educated decision that will minimize their problems with their purchases and thus maximize their data's safety.

Are you concerned with the errata in your GPU ? in your RAID controller ? Rest assured there are plenty of bugs in those chips as well

I know that there are and yes I am. I am very much concerned with these errata, <i>especially</i> when making new purchases.

and they are known to the people that should know about them

Just because they are known does not mean that they are being fixed. Companies will often let fixes slide if they believe that there is something else of higher priority. Only when the customer gets involved do companies know what is really a priority to their customers.

and that doesnt include you or me. Its pointless

That's a damn pathetic stance to take. You can't fix it personally so it's not worth even knowing about. You'd rather instead just live in blissful ignorance of why your product is failing and take it up the arse. Well congrats. Whenever your PC crashes, whenever <i>any</i> of your products fail, <b>YOU</b> are the one to blame for them because <b>YOU</b> refuse to take the responsability to become part of the solution. Refusing to take action is just as much of a choice as actually taking action and it's <i>your</i> choices which help determine <i>your</i> situation.

But I can't make you chose to become active in the process. All that I can do is sensationalize and dramatize the information in an attempt to get you to understand the problem and appreciate what <i>you can do</i> to be a part of the solution. I can make the information interesting but I can't force you to act upon it. I've done my part. It's up to you to do yours.

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

 

[eden]

Dude, maybe he is overdramatizing, but have you ANY idea whatsoever what trolling is?

Do you know what a troll is?

Slvr doesn't beging to fit any of the criteria. Switch your naming man!

--
<A HREF="http://www.lochel.com/THGC/album.html" target="_new"><font color=blue><b>This just in, over 56 no-lifers have their pics up on THGC's Photo Album! </b></font color=blue></A> :lol:

 

[whittak]

Sorry I did not mean to offend. IMO Slvr's posts seem very negative and confusing even for a newby like myself.

I like reading technical discussions especially when both sides offer constructrive facts/advice/opinions.

Bbaeyens comments seem to favour AMD and Slvr seems to favour Intel. The difference I notice is that Bbaeyens are a lot more constructive and positive over Slvr's.

I suppose it is just in the tone of the comments that I am noticing this.

Just my two cents

 

[slvr_phoenix]

IMO Slvr's posts seem very negative and confusing even for a newby like myself.

No offense, but that could be exactly why they seem confusing, don't you think?

I like reading technical discussions especially when both sides offer constructrive facts/advice/opinions.

I'm curious. I have to ask. What part of <i>these are bugs that you want to be aware of and make sure that your manufacturers implements the workarounds for</i> isn't constructive advice?

If it's just the list of bugs that seems negative or confusing then blame AMD. They came right straight out of a PDF file from AMD. I just copied and pasted.

Bbaeyens comments seem to favour AMD and Slvr seems to favour Intel.

Mine only seem to favor Intel because lately AMD has been obfuscating the facts. What little can be found often either contradicts what they've released before or is lacking all of the tiny little details that should be there. I still haven't even seen a thermal/electrical spec sheet for the A64FX. That seems rather odd to me.

Further if you've been watching AMD's marketing lately you'll notice a strong tend there to duplicate Apple's extremely 'creative' truths. Until AMD learns to be more factual I have to say that I'm not inclined to take any of AMD's words at face value. That's why I seem so anti-AMD and why I lean heavily upon independant sources for information.

The truth is that from a technical standpoint I currently like the Opteron 1xx the most out of any CPU. It's fast. It's flexible. And it's on a platform that's the most likely to stay out of all of the platforms available at the moment. It's only real fault is its price and it's requirement of registered RAM which not everyone would want to pay for.

The Athlon64 isn't half bad either, but it really hasn't been made clear if that product line will continue to exist once AMD implements Socket939. That makes it hard to know if it is safe to recommend to anyone. Not that Intel and the possible but unclear future of a Prescott that may or may not work on current motherboards is any better of a suggestion. :\

But basically I only seem pro Intel because right now I have more to complain about from AMD than I do from Intel. It's not that I like either company more or less or either product line more or less. (And as I said, I actually prefer the Opteron line at the moment.)

The difference I notice is that Bbaeyens are a lot more constructive and positive over Slvr's.

I'm intrigued. It's entirely possible. There's not too much for me to be very constructive about lately. AMD and Intel both are keeping a little too much information in the dark for me to appreciate. It's got me in a bit of a bad mood. Care to give any specific examples though?

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

 

[whittak]

Sorry it is not your facts which are the problem, it is the way you infer them and the tone.

I suppose it goes back to what you intention is when you post.

Is your intention to make people aware of a problem or are you mad at a company for deceiving?

You could probably call it semantics but is very noticiable in your posts.

 

[slvr_phoenix]

Sorry it is not your facts which are the problem, it is the way you infer them and the tone.

I suppose it goes back to what you intention is when you post.

Is your intention to make people aware of a problem or are you mad at a company for deceiving?

In this particular thread I'm just trying to make people aware and get them involved. There's nothing really deceptive in this thread. Errata are if anything too much information, which makes them boring. Hence my effort at dramatizing.

<pre><b><font color=red>I've always wondered why people liken the taste of blood to copper.
It tastes much more like iron to me.
<- - - - - -></font color=red></b></pre><p>

 

[Guest]

>What, end users are just magically safe from these somehow?
>Yeah, whatever. End users are the exact people affected by
>these

They are not if the BIOS guys do their homework. If they don't, they are f*cked anyhow, they may well implement these workarounds, and introduce other bugs. Same applies to the OS kernel developpers. You really plan on calling MS, and ask if their 64 bit windows XP implemented a "synchronizing operation between all MOV/POP SWAPGS ?" Get real man ! Did you call MS before you bought your P4 and asked them if they implemented a fix for "Simultaneous Page Faults at Similar Page Offsets on Both Logical Processors of a Hyper-Threading Technology Enabled Processor" and all of the <A HREF="http://ftp://download.intel.com/design/pentium4/specupdt/24919942.pdf" target="_new"> other 83 documented errata of the pentium 4</A> ??

>No, I think it's something that an end user should demand
>of their manu to fix in the next patch of their BIOS, as I
>stated.

Oh gimme a break man.. or do me a favor, and send those 83 P4 errata to your favourite BIOS/MB supplier, to microsoft and Linus Torvalds, ask them to comment and say which fixes they implemented, and which ones they didnt know about yet *cough*, and please post their response here. It will help us all ! *cough*. Oh, and when you're done with P4, please do the same with the 850 chipset, the 865, the 875 and all their variants. i'm sure that will be sooo usefull.

>Translation:
>If you drop your Opteron into a power saving mode (or it
>gets throttled) then your memory may be run at much worse
>latencies which will kill your performance.

translation: Im just completely guessing here since I have no clue where to set the "CPULowPwrEn bits for System Management Action Field (SMAF)", nor what it does, but I recognise a few words, so who knows, maybe disabling throtteling will actually help. Maybe its not necessary. Maybe I have no f*cking idea.

You're hilarious really.. almost like my mother demanding the sourcecode of the electronic engine management system for her next car, or taking the errata list of the Xscale processor with her when she goes shopping for a PDA.

= The views stated herein are my personal views, and not necessarily the views of my wife. =

 

[SJJM]

You look at what bbaeyen posts you will see that he whole heartly believes in amd. I think that bbaeyen is very knowledgeable, but I think that his feelings are getting in the way of his judgement. I think that the a64 will be a great product, but like any other product I will not buy it when it comes out. I want to let them fix most of the bugs before I get something. In the next 6 months or so the a64 seems to be stable, then I might get it for my next system, but who knows what will happen.

<font color=blue>"You know, that my backstab attack does double the damage. I can make an off button for him." </font color=blue>

 

[ImpPatience]

I have weigh in with Slvr Phoenix on this one. When I worked for a manufacturer if someone outside the company complained, things happened. In my experience management makes the decisions and management understands complaints a lot better then they do engineers. In other words if an engineer complains that something doesn't work management may or may not allocate time to fix the bug. If a customer, ie the one with the money, complains management will definitely allocate time to fix the bug.

<font color=blue><b>Purchase object A, install object A, curse object A, repeat...</b></font color=blue>