lkml.org 
[lkml]   [2003]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Requested FAQ addition - Mandrake and partial-i686 platforms
Date
On Tuesday 12 August 2003 17:48, Brandon Stewart wrote:
> Apparently, there is an issue with glibc on versions less than 2.3.1-15
> (and maybe others), where it mistakenly treats CPUs as full i686
> compliant when they only execute a subset of the i686 instructions. For
> example, the VIA C3 supports pretty much everything i686 except CMOV,
> yet the broken versions of glibc will detect it as fully i686 compliant.
>
> From someone who emailed me privately, this apparently affects K6-III
> as well. Possibly other Cyrix or AMD CPUs are affected, though I don't
> have a complete list.
>
> The problem is that Mandrake 9.1 ships with a broken glibc. So you would
> expect that the incorrectly detected CPUs just wouldn't work. But
> apparently, Mandrake added a CMOV instruction emulator patch to their
> kernel, both the one that ships precompiled and the source rpm.
>
> So people will find that compiling the Mandrake version works fine, yet
> any kernel downloaded from kernel.org, 2.6 or other, will not work at
> all. The symptom is that booting the shiny new kernel will hang after
> "Freeing unused kernel memory". Doing a magic sysreq will reveal that
> /sbin/init is executing do_invalid_op(). You can keep pressing the magic
> sysreq stack dump key, and you will keep getting a new stack trace.
> Caps-lock works, and CTRL-ALT-DEL will reboot the machine.

Hm. I was right. ;)

> There are three possible workarounds:
> 1) Upgrade glibc to a working version. I haven't done this myself, so I
> don't know if the bug has been fixed yet. But it would be the best
> solution. 2) Remove i686 libraries from glibc. This can be done by 'mv
> /lib/i686 /lib/i686.invalid'. This is what I did, and it works. While some
> performance is lost, it's not noticeable, especially given that the
> stock Mandrake kernel is i386 compatible, and so has limited optimization.
> 3) Reapply the CMOV emulation patch to your downloaded kernel. Not
> recommended since it turns one CPU cycle into 400.

4) Never never never never NEVER compile for 586+

You lost several days debugging this. It's $days*24*60*60=$days*86400 seconds
~= $days * 86400000000000 CPU cycles. A bit high price for using optimized
binaries, eh?

IMHO:
Speed optimizations make sense in heavy CPU bound tasks like bzip2.
CPU-heavy part of code is usually small, can be hand-optimized.
The remaining 99,999% of code is best optimized for size.
At least you will save on pagein and icache footprint.

After you happily compiled a piece of code with all bells and
whistles for your new shiny 986+ processor, do take a look at
generated assembly. There might be surprizes.

BTW, will anyone bet that gcc generates better code with cmov's
than without? ;)
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.095 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site