TLB bug still present in B3 rev Phenoms

[alfaunits]

Coooper, what in da world is wrong with my post, except for the fact that it wasn't pro-AMD?
HP selling stuff at Wal-mart deserves a ridicule!

[v0dka]

Frankly it seems Intel is already operating as a monoploy and has been since Core 2's introduction. They are releasing new product to their own schedule and setting compelling pricing without the slightest threat from AMD. They can't arbitrarily set prices and let the market stagnate as this would both impact on their revenue and allow other competitors in. Would most people really need a PC if a net enable, keyboard equipped games console bundle with Linux and an applications suite were available?

I'm not denying competative pressure plays a role in pricing, but I think it's current importance is overstated.

Just keep telling yourself that.

AMD was eating away Intel's market share for years in a row, and you think the agressive pricing, marketing and development plan of Intel is just a coincidence? The tick-tock model didnt just fall out of the sky around 2005.

We can already see them taking some pressure off as AMD keeps failing.

Intel will cut down to what they think is an optimum between cost and production, as soon as they feel safe. Even someone with a moderate economical education can udnerstand that. And looking at the past, it's safe to say that what they have done with Core 2 and Quad is far above that optimum - especially in the light of the agressive pricing.

[Cooper]

Coooper, what in da world is wrong with my post, except for the fact that it wasn't pro-AMD?
HP selling stuff at Wal-mart deserves a ridicule!

maybe in yr mind. I find this to be trolling

[justapost]

The bug is very critical for servers.
Here is the problem:
http://www.x86-64.org/pipermail/disc...er/010281.html
Here is the answer:
http://www.x86-64.org/pipermail/disc...er/010282.html

Thank you for those links, this is the first time i see the bug in action.
The guy who answerd is working for AMD according to his sig, so it seems to be no BS this time.

I could not make the bug occure with xen and differen guest osses all running prime95 or other benchmarks.
It would be interesting what software he ran.

[Shintai]

Thank you for those links, this is the first time i see the bug in action.
The guy who answerd is working for AMD according to his sig, so it seems to be no BS this time.

I could not make the bug occure with xen and differen guest osses all running prime95 or other benchmarks.
It would be interesting what software he ran.

It is not as easy as such. The guess is its due to hot spots. Thats also one reason it could be safe at under 2.4Ghz. So Its abit like OC and chips. Random picks. Maybe only 5% of all chips have this bug at stock speed. And with an increased chance with higher frequency.

if it was a fixed bug so to say. I am pretty sure AMD would have caught it in their QA process.

We have a few people here with 0 bugs, and we have an example of a person in WCG forum where it crashes.

[justapost]

It is not as easy as such. The guess is its due to hot spots. Thats also one reason it could be safe at under 2.4Ghz. So Its abit like OC and chips. Random picks. Maybe only 5% of all chips have this bug at stock speed. And with an increased chance with higher frequency.

There is a detailed description of the TLB-thing at LostCircuit here.

if it was a fixed bug so to say. I am pretty sure AMD would have caught it in their QA process.

I dont want to say the bug does not exist, but i experienced it is pretty hard to trigger it.

We have a few people here with 0 bugs, and we have an example of a person in WCG forum where it crashes.

Thx, gona try to trigger the bug with WCG. Do you remeber when the crash was reported in the WCG forum.
According to LostCircuit the bug can only occure with hardware enabled virtualisation. What did the person at WCG use?

[Shintai]

There is a detailed description of the TLB-thing at LostCircuit here.

I dont want to say the bug does not exist, but i experienced it is pretty hard to trigger it.

Thx, gona try to trigger the bug with WCG. Do you remeber when the crash was reported in the WCG forum.
According to LostCircuit the bug can only occure with hardware enabled virtualisation. What did the person at WCG use?

He just ran WCG and it crashed a few times.

Also i think you misunderstood my post. Its not hard to trigger as such. It just depends on your luck of CPU. If there is a hot thermal spot or not and if so, at what frequencies. I do not believe it s a virtualization only bug. Its a pretty lame excuse. Also you would just have the BIOS setting where you disable or enable virtualization to enable or disable the fix aswell. I call it a smoke screen

[Cooper]

I don't think WCG can trigger this bug. I've been running Phenom 9600 at stock on WCG for 4 days non stop - not a single crash. I beleive there are few more ppl that run WCG or any other F@H app on Phenom even on higher clock speeds. this is just not that kind of load. Though if you running something elsevery CPU intensive...don't know. This guy at x86-64...there is no explanation of what exactly he was doing to get this error

[SEA]

[TLB bug still present in B3 rev Phenoms]
http://www.erenumerique.fr/ces_2008_...ews-11723.html
[...]
AMD got its first chips using the B3 rev, the bug is not addressed still, a new spin is needed which could postponed Phenoms till May.

I tried to translate that French site and i cannot see where it sais that the bug not fixed is the TLB bug (there are quite a few bugs can remain normally from revision to revision). Is it the reason why they pushed to 2nd quarter those 9650 and 9550?

[Zytek_Fan]

What type of calculations set off the bug though? Surely something cache and CPU intensive...

[justapost]

He just ran WCG and it crashed a few times.

Also i think you misunderstood my post. Its not hard to trigger as such. It just depends on your luck of CPU. If there is a hot thermal spot or not and if so, at what frequencies. I do not believe it s a virtualization only bug. Its a pretty lame excuse. Also you would just have the BIOS setting where you disable or enable virtualization to enable or disable the fix aswell. I call it a smoke screen

NP I wrote a mail to x86-64 with a link to the description, waiting for feedback now. The reviewer seems to be an amd-fan so i do not trust that guy.

The hotspot thing is speculation atm. No phenom user in the AMD section could find a relation between stability and temps or between stability and the tlb-fix.

Maybe you are right and not all cpu's are affected. But that whould be something AMD-marketing whould have mentioned.

Here is an success report for the linux tlb-patch.

[AMDDeathstar]

How do you know that a crash or data corruption problem was caused by the TLB bug ? Do you have advanced debugging tools ?

Best answer I can give you is it not crashing under full load at all. The stock one is running Boinc 24/7. The OC'ed one, the only time it's not running Boinc is when I'm gaming or benchin'

The bug is very critical for servers.

True. Especially if your running virtualization on that Server

The thread title is about Phenoms not Barcelonas.
I don't think you'll see too many using a Phenom for virtualized mission critical servers.

Is TLB bug on Phenom going to crash Average Joes(sinlge OS Windows machine) multithreaded game...No

The TLB bug doesn't prevent you from overclocking but overclocking should increase your chances of tripping the bug

Can anybody show me that somebody actually tripped the TLB bug on Phenom(not Bacelona) running a single OS. Please, because I want to try too.

The crashing on WCG probably has more to do with ram compatibility.

[Shintai]

Maybe you are right and not all cpu's are affected. But that whould be something AMD-marketing whould have mentioned.

You cant do that as a company. Just imagine it. "Only some of our CPUs are faulthy, we dont know which ones".

It would be a PR suicide.

Also patching agains 1 or a few possible bugs is not a fix really in what we usually see.

[hollo]

what is the argument for, or technical details behind, an overclocked phenom being more likely to trip the bug? or is that just people's experience?

[Jamesrt2004]

what is the argument for, or technical details behind, an overclocked phenom being more likely to trip the bug? or is that just people's experience?

I think it's not the fact it's overclocked I think its tied that with the higher bus speed when you upp the fsb it gets more... common say if a BE I think.... just higher multi ther'd be normal chance ?

please correct if im wrong

[Shintai]

I think it's not the fact it's overclocked I think its tied that with the higher bus speed when you upp the fsb it gets more... common say if a BE I think.... just higher multi ther'd be normal chance ?

please correct if im wrong

The speed sould be the same. Its only the Core speed that change. Even the bugged L3 is at same speed.

[justapost]

You cant do that as a company. Just imagine it. "Only some of our CPUs are faulthy, we dont know which ones".

It would be a PR suicide.

Also patching agains 1 or a few possible bugs is not a fix really in what we usually see.

The whole launch was PR suicide.
They know in what circumstnaces the bug occures, there is a good decription from amd here.
I guess it should be possible to write a test case for the errata.
Such a test whould be no option for tier1's but for desktop users it whould be a nice stability test.
So if you are right that whould be actualy good news for phenom/b2 users.

The NB and the L3 cache runs at ref HT (FSB) * NB multi (max 9 for locked phenoms). The multi can be modified with wprcedit.
The NB speed is independant from the memory speed (ref HT * mem multi/mem divider).
NB speed becomes an issue above ~2100MHz, ref HT at ~260MHz.

[savantu]

Paul Demone's view on the bug :

It probably isn't a straight forward logic bug in synchronous
logic. The four cores and the L3/IMC can all run at different
frequencies and thus there is asynchronous interfaces between
them. AMD might have tried something a bit more aggressive
than straight out double sampling in both directions to reduce
latency crossing clock boundaries. And when two CPUs running
at different frequency and/or phase hit their L3 interfaces at
nearly the same time under some rare set of circumstances
some condition that should never happen, happens. You know,
like the brown stuff. It just happens and now AMD is up that
particular creek.

This is the reason why AMD locked the NB speed , they tried to get rid of at least one variable.No wonder that the bug is hard to fix ; it's non-deterministic.
In other words you can't really try to replicate it.Even with code known to cause the bug , it might not happen all the time.

Montecito experienced a similar problem with different clock domains for the cores and the L3 which was asynchronous.Foxton which modified frequency in real time depending on power consumption made this a real nightmare.The fix : Foxton disabled and L3 locked at 1600MHz.

It will be interesting to see how Nehalem will handle this problem since it also has independent clocks for each core , NB and IMC.Knowing Intel , the caches are also far more aggressive in terms of latency and BW.Add to that HT ; you have 8 threads per device , all targeting a shared l2.

[gdogg]

Because of what history? When in history has Intel charged $1000 for a low end cpu and $2000 for mainstream? I don't recall that happening; even in the early pentium pro days (the time when intels prices were highest).

In the pre-k8 days, Intel's prices weren't as high as people think they remember them to be. In the pentium 1 through pentium 3 days Intel always priced thier processors the same. $200-300 for the low-end and $800 or $900 for the high-end.

Even if Intel was a true monopoly, they could not sell cpu's at very high prices because not enough people would buy them to cover the cost to make the cpu's. The market is what determines prices. If AMD were to die right now I doubt Intel would raise their prices much at all. The problem we would face with Intel being a monopoly is lack of inovation not pricing.

That is why when someone says that Intel would price thier low-end processors at $1000 if they were a monopoly or when someone says that nehalem cpu's would cost $2000 if they were a monopoly, they are either stupid fanboys or are just plain ignorant. (too many people)

Never said low end cpu would cost $1000, said the PC itself.

Since amd is now both video and proc, its safe to say, if they go bottoms up, that the price of a low end pc could rise from $400 to more around $1000 again.

This is because, intel won't need to produce such a large line of processors to compete, and their can just be like 5, 2 low end , 2 mid range, and a EE.

Anyway, wasn't trying to imply anything in my post, was just saying what I have seen over the years since 1995 in computer prices, and how that could go in reverse w/o competition.

Not a fan boy or whatever, only really 1 company I don't like with good reason and its not amd or intel ,love them both, amd I still use for low end cheaper gaming machines, that can just focus on the video card, then rest of system is done for under $300

[Psycho_eddie]

Just wondering if anyone noticed the early silicone in brackets, possible early samples of B3 still contain the bug and possible later ones wont. But still doesnt make any different as this bug hasnt really happended to any one has it..

Its like the chances perhaps of a CPU HSF falling off, its a possibility but never really happens to anyone.. well unless your god dam unlucky


If it doesnt effect you why worry...

[Shintai]

The NB and the L3 cache runs at ref HT (FSB) * NB multi (max 9 for locked phenoms). The multi can be modified with wprcedit.
The NB speed is independant from the memory speed (ref HT * mem multi/mem divider).
NB speed becomes an issue above ~2100MHz, ref HT at ~260MHz.

Who cares above 2100Mhz right now? It doesnt even work at 1800 or 2000Mhz. The only thing that matters is the core speed for the bug.

Also they can not test it as such.

And if AMD had actually told the truth. It wouldnt even be an issue for desktops users. In short they lied about the impact as so many other companies.

The simple most straightforward fix for a hardware virtualization issue is DISABLE IT. Yet AMD choose to default have the TLB patch on with or without virtualization.

[LowRun]

I tried to translate that French site and i cannot see where it sais that the bug not fixed is the TLB bug (there are quite a few bugs can remain normally from revision to revision). Is it the reason why they pushed to 2nd quarter those 9650 and 9550?

They don't mention the TLB bug specifically but this is the one they're talking about anyway.

Don't know about 9550 and 9650 being pushed back.

Now there is another French site saying they contacted AMD France to clarify the matter and have been officially told that there actually were no problem and that 9700 and 9900 had started to get in big OEMs hands, that they were ramping up the delivery and that everything was still on track for a worlwide launch at the end of this quarter.

http://www.presence-pc.com/actualite...-retard-27203/

.

[tictac]

inq confirmed NO TLB BUG ON B3!

[Shintai]

inq confirmed NO TLB BUG ON B3!

Theinq also confirmed it to be 50% faster than Core 2 and doing 30K 3Dmark06. Not even to mention the "dancing in the aisle".

[JumpingJack]

inq confirmed NO TLB BUG ON B3!

How ironic, the King Rumor-Monger himself squelching a rumor.... how quaint.