Jump to content
Toggle sidebar
JookWiki
Search
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Navigation
Main page
Recent changes
Random page
All pages
Help about MediaWiki
Tools
What links here
Related changes
Special pages
Page information
Editing
Nopl
(section)
Page
Discussion
English
Read
Edit
Edit source
View history
More
Read
Edit
Edit source
View history
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Linux fallout == In 2006 [https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1596541188b1a4080ab7bce6578c09626193dfd0 PATCH: Add "nop memory" for i386/x86-64] was committed to the GNU Assembler. It added support for the 'nopl' and 'nopw' assembly instructions that map to multi-byte NOP code. In 2007 [http://lkml.iu.edu/hypermail/linux/kernel/0709.2/2726.html x86: multi-byte single instruction NOPs] was committed to Linux. This added a set of 'P6 NOPs' that used the multi-byte NOP opcodes and used them for i686 or newer x86 CPUs. Which type of NOPs to use were decided at runtime, so running an i686 kernel on an i586 machine would not cause any issues with this. Strangely on 64-bit systems the NOPs were only used if your CPU vendor was Intel. In 2008 the Debian bugs [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463606 Linux 2.6.24 fails to boot on MS Virtual PC 2007] and [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464962 -686 build uses long noops, that are unsupported by Transmeta Crusoe, immediate crash on boot] were reported. After a lot of discussion, the following CPUs were reported to not support multi-byte NOPs: * VIA C3 Nehemiah * Transmeta Crusoe TM5800 * Microsoft Virtual PC 2007 * QEMU 0.9.1 * AMD Geode LX800 Interestingly enough the TM5800 reports its CPUID as family 5 like the LX800 does. But for the TM5800 the kernel promoted its status to i686 by changing the reported family at runtime. The LX800 reports its family as 5, so shouldn't have failed due to the patch. I looked up other reports from the time and found the bug report [https://linux-kernel.vger.kernel.narkive.com/ICAshwKv/2-6-24-rc8-hangs-at-mfgpt-timer 2.6.24-rc8 hangs at mfgpt-timer] which seems to fit better, especially since the reporter didn't post any logs. In parallel [https://linux.kernel.narkive.com/9RuAfy4c/bug-x86-kenel-won-t-boot-under-virtual-pc <nowiki>[BUG] x86 kenel won't boot under Virtual PC</nowiki>] was reported to the Linux mailing list. This has a bit of a more focused discussion about how to address this problem. To summarize the discussion: * GNU Assembler shouldn't generate multi-byte NOPs if not all i686 CPUs support it * This is all too much effort for NOPs A flurry of fixes appeared in Linux 2.6.25 to stop the bleeding: * [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a7ef94e6889186848573a10c5bdb8271405f44de x86: do not promote TM3x00/TM5x00 to i686-class] * [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7343b3b3a627eb30e24e921f004f659c8ebb91c5 x86: require family >= 6 if we are using P6 NOPs] * [https://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=959b3be64cab9160cd74532a49b89cdd918d38e9 x86: don't use P6_NOPs if compiling with CONFIG_X86_GENERIC] This decided Transmeta Crusoe CPUs weren't i686, and limited use of multi-byte NOPs to i686 non-generic kernels. A little while later in Linux 2.6.27 this amazing chain of patches happened: * [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b6734c35af028f06772c0b2c836c7d579e6d4dad x86: add NOPL as a synthetic CPU feature bit] * [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=14469a8dd23677921db5e7354a602c98d9c6300f x86: disable static NOPLs on 32 bits] * [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28f7e66fc1da53997a545684b21b91fb3ca3f321 x86: prevent binutils from being "smart" and generating NOPLs for us] * [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ba0593bf553c450a03dbc5f8c1f0ff58b778a0c8 x86: completely disable NOPL on 32 bits] Instead of only adding multi-byte NOPs to i686 and better machines during the kernel build, the plan was to only use multi-byte NOPs at runtime based on whether the CPU supported running multi-byte NOPs. Unfortunately the developers found the GNU Assembler would add multi-byte NOPs all the time for i686 and Virtual PC would freeze during detection of multi-byte NOP support. In the end they just threw their arms up and said 'no multi-byte NOPs at all on 32-bit x86'. As a result, the 'nopl' flag found in /proc/cpuinfo which would have shown if the CPU supported multi-byte NOPs is always hidden on 32-bit x86 and always shown on 64-bit x86, making it effectively useless.
Summary:
Please note that all contributions to JookWiki are considered to be released under the Creative Commons Zero (Public Domain) (see
JookWiki:Copyrights
for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource.
Do not submit copyrighted work without permission!
To edit this page, please answer the question that appears below (
more info
):
Who owns this wiki?
Cancel
Editing help
(opens in new window)