This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing Low‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Low This article has been rated as Low-importance on the project's importance scale.

A simple fix is to insert another instruction in the loop, the nop instruction being a good candidate.

This is not really a fix for the problem. The problem is that any program can lock up the cpu, without giving the os the chance to do something about it. Unless the above statement implies scanning all programs for suspect opcodes, patching them, taking into jump targets and self-modifying code, that is to say, effectively running all programs in an emulator, it is not a fix. Shinobu 22:52, 1 June 2007 (UTC)[reply]

The point is that if your program runs similar code, and it's causing the computer to lock, even though it was not your intention, adding a nop will avoid the lock. However, you're right that in an intentional attempt to trigger the bug and cause a DoS, it's not a solution at all. 201.212.126.164 14:02, 6 September 2007 (UTC)[reply]

What's the significance of

0x36, 0x78, 0x38, 0x36

and

movl %eax, %edx

? —Preceding unsigned comment added by 82.139.87.74 (talk) 06:01, 8 July 2010 (UTC)[reply]

0x36, 0x78, 0x38, 0x36 

that is "6x86" in ascii, it could be anything. --46.64.28.128 (talk) —Preceding undated comment added 13:05, 3 December 2010 (UTC).[reply]

Hello fellow Wikipedians,

I have just modified one external link on Cyrix coma bug. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20090928041114/http://grafi.ii.pw.edu.pl:80/grafi1/gbm/x86/6x86reg.html to http://grafi.ii.pw.edu.pl/grafi1/gbm/x86/6x86reg.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:19, 4 December 2016 (UTC)[reply]

Regarding "One way to prevent this bug is to enable bit 0x10 in the configuration register CCR1 …": Isn’t it possible for the attacker to disable the named bit? -- Pemu (talk) 02:40, 10 August 2019 (UTC)[reply]