Talk:Pentium F00F bug

Title

"F00f" is awkward, but "F00F" would be equally correct as a title. Why not move it? Hairy Dude 04:15, 24 August 2006 (UTC)

Oh, yeah. Anyone against the move? --Ihope127 00:50, 30 August 2006 (UTC)

Meaning and grammar of "possible data loss" statement

I propose changing

if the disk buffers had not been flushed, any drives that were interrupted during a write operation, or some other non-atomic operation was interrupted, it is possible for data loss to occur

to instead read

if the disk buffers had not been flushed, and any drives were interrupted during a write operation or some other non-atomic operation, it would be possible for data loss to occur

so that it's a little more grammatically correct, but I'm not sure if it has the original intended meaning. Can anyone double-check this or explain what the original version is saying? 218.189.243.131 16:59, 26 December 2006 (UTC)

No, its supposed to be a list of possible things that if interrupted could cause damage, eg:

• If the disk buffers had not been flushed
• or A drive is interrupted during a write operation
• or Some other non-atomic operation was interrupted

Any of these could cause data loss to occur.

I think when I originally wrote it, it was "if the disk buffers had not been flushed, a drive was interrupted during a write operation, or some other non-atomic operation was interrupted, it is possible for data loss to occur" but someone modified it. I'm terrible at grammar, so please correct it :-) -- taviso 19:29, 26 December 2006 (UTC)

Add list of affected models?

This entry would be greatly improved by a list of affected models like the list in the Pentium FDIV bug entry. Alas, I haven't been able to find a reliable source listing which models are affected. Some anonymous Usenet posts claim that AMD K5 and K6 processors are not affected but Cyrix (which ones?) are.

And yes, the title should be changed from F00f to F00F. Upper case representations of hexadecimal numbers are quite common; my perception is that F00F is more common than f00f. Guy Macon (talk) 19:28, 18 March 2007 (UTC)

AT&T syntax?

Why not use Intel IA86 syntax?

it's exactly the same, except for the extra % before the register name, i think any intel syntax fans will work it out. -- taviso 17:52, 11 July 2007 (UTC)

And your point is?

This is an Intel IA86 bug.

Historically, this was a MS/Windows crack, at a time when MS/Windows hackers used IA86 syntax in all of their tools.

So, that's two reasons to use Intel IA86 syntax. Conversely, is there any reason to use AT&T syntax?

(FWIW, i think that any AT&T syntax fans would be able to work it out.)150.101.166.15 (talk) 03:06, 22 November 2007 (UTC)

Even if that sentence made any sense, which it doesn't, it would be wrong. Regardless, if that % sign really bothers you that much, go ahead and change it ;) -- taviso (talk) 00:17, 23 November 2007 (UTC)

Workaround

IMHO there should be some information about the workaround in this article. —Preceding unsigned comment added by 62.181.193.162 (talk) 08:38, 18 September 2007 (UTC)

I don't think there are any workarounds other than using softfloat libraries (implementing the affected arithmetic operations with integer arithmetic). -- intgr [talk] 09:21, 18 September 2007 (UTC)

I think you're confusing this (Pentium F00F bug) with the Pentium FDIV bug, there are workarounds for this one, eg [1] - taviso 03:17, 19 September 2007 (UTC)

You're right, I was confusing it with the FDIV bug. :) -- intgr [talk] 07:27, 19 September 2007 (UTC)

help with pronunciation

I wanted to clean up the pronunciation, but can't tell if it's pronounced with the oo of foot or the oo of food. kwami (talk) 11:02, 15 December 2007 (UTC)

It is not pronounced · · · Omnissiahs hierophant (talk) 11:28, 18 August 2021 (UTC)

Is it just me...

Or does this sound like the automonapoea (SP?) "FOOF!"? Maiq the liar (talk) 18:02, 18 January 2008 (UTC) Do you mean onomatopoeia? And, no, I don't think the bug makes any noise. Freddy. — Preceding unsigned comment added by 220.233.71.153 (talk) 00:04, 22 January 2013 (UTC)

New CPU affected

The article states 'No Intel processors since the introduction of the Pentium Pro have been affected by the bug' - but the Intel Quark SoC X1000 (intreduced with the galileo platform) is based on a intel 486/pentium hybrid, which states:

cat /proc/cpuinfo
processor       : 0 

vendor_id       : GenuineIntel

cpu family      : 5

model           : 9

model name      : 05/09

stepping        : 0

cpu MHz         : 399.076

cache size      : 0 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : yes

So, we have more affected cpu's — Preceding unsigned comment added by 46.228.92.142 (talk) 11:48, 29 August 2014 (UTC)

Thanks, but to add this to the article we would need a reliable source supporting this claim. -- intgr [talk] 14:39, 29 August 2014 (UTC)

German wiki cites heise: http://www.heise.de/developer/artikel/Intels-Einplatinen-Computer-Galileo-unter-der-Lupe-2252539.html and confirms it under Intel Quark page — Preceding unsigned comment added by 85.221.130.92 (talk) 17:48, 29 August 2014 (UTC)

Heise cites Wikipedia which cites Heise? Not reputable. Reverted article. Has anyone actually *tested* this? Linux is detecting Quark as Pentium and then assuming Quark has the bug. See See also https://twitter.com/marcan42/status/526559512853889024. — Preceding unsigned comment added by 60.242.88.97 (talk) 08:05, 27 October 2014 (UTC)

I think Heise was linking to Wikipedia for an explanation about what the f00f bug is, not "citing Wikipedia" for the presence of the bug on Quark. The mention of Quark was added after the Heise article was published: [2]. But you're probably right that there's not enough evidence that they tested it, so let's keep it out of the article. -- intgr [talk] 09:34, 27 October 2014 (UTC)

Marking as in need of attention

As is clear, prima facie, the article extensively describes the title subject, and its functioning and implications, in significant technical detail. The presentation is jargon, and unsourced. It is this not encyclopedic, and violates WP:VERIFY, and so attention is called to the article, so that editing by an expert can be done that:

• provides a general introduction that a layman can understand,
• indicates the sources of that introduction, and provides the same for any further technical description—from published secondary sources (thus avoiding doing the OR otherwise required to technically describe it), and
• removes the inline and section and article tags (after the majority of information is sourced per WP:VERIFY).

Please do not try "common knowledge" or other end arounds (this material is not), or that good sources for this subject cannot be found. This bug's description and implications appeared repeatedly in the press, and it made its way into books, non? It is not an encyclopedic article if it remains an editor's (or group of editors') first hand, and original composition—appearing here for the first time, as their description and explanation of the bug. Le prof 71.201.62.200 (talk) 07:59, 27 July 2015 (UTC)

@71.201.62.200: In response to this series of edits: It's not an improvement to the article to slap {{citation needed}} or other templates to almost every sentence. If you find something particularly dubious, then tag or remove that, otherwise to just indicate generally bad sourcing, the top boxes are enough. See WP:POINT.

Wikipedia is a wiki, and you're invited to improve the article yourself. But you can't demand other volunteers to do that work for you. -- intgr [talk] 08:19, 28 July 2015 (UTC)

needs better technical documentation

This article needs some more technical information on the subject. Documentation is needed badly with some example code.

FockeWulf FW 190 (talk) 16:28, 11 March 2016 (UTC)

@FockeWulf FW 190: The code example is already there: lock cmpxchg8b eax in x86 assembly language. -- intgr [talk] 11:07, 15 March 2016 (UTC)

@Intgr:

oops I must have misread it. Thanks for correcting me.

Three Remarks

I have 2 minor & 1 major issue with the article, for which i'd like to receive some comments before attempting any corrections (which might be mistaken, afterall):

First minor issue is where it says that the relevant registers are R0 and R2 in more modern processors. Even in 64-bit architectures there are no such named registers. General purpose registers having numbers in their names are R8 thru R15 only. AFAIK, the text should state RAX and RDX, respectively, unless things have really been renamed this way in very recent hardware, for which reason i withhold editing for now.

Second minor issue is that, since the relevant instruction is cmpxchg8b, which operates on single bytes, the affected register should be AL, not AX, nor EAX, nor RAX (all of which are wider than one byte). I tried confirming this by disassembling the opcodes, but the only disassembler i have available now (objdump) just renders "(bad)", which is only natural, since this is an illegal instruction afterall.

Then the major issue is where it says in the article (unsourced, as far as i can tell) that there were workarounds for this problem issued for operating systems back then. I can't see how this could be, since it is a purely hardware issue which does not depend on privileges or particular CPU configurations; ie, it is unpreventable (unless you stop running native code altogether and emulate everything, which is obviously unfeasible). If there really were workarounds (even partial ones) that could be deployed in software, this would be of immense interest. Anyone has any clue either way? — Preceding unsigned comment added by 79.168.78.24 (talk) 03:27, 11 April 2018 (UTC)

OK. I really need to go through sources more thoroughly in advance. Turns out the Dr.Dobbs reference in the text contained the official workarounds from Intel, plus two others of his own devising, all of which are very interesting as they elucidate the deepest quirks of microprocessors in action. I'll try to summarise them for the article. My second minor issue above was in fact my mistake, i don't know where i got the idea that the cmpxchg8b instruction operated on single bytes, so, nevermind. As for the first minor issue, i'm going for the correction. — Preceding unsigned comment added by 79.168.78.24 (talk) 03:54, 11 April 2018 (UTC)