From: Jeff Garzik <jeff@garzik.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Luis R. Rodriguez" <mcgrof@gmail.com>,
linux kernel <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@kernel.org>,
Ivan Seskar <Seskar@winlab.rutgers.edu>,
jfm3 <jfm3@winlab.rutgers.edu>, Sujith <m.sujith@gmail.com>
Subject: Re: Bug on 2.6.26 - x86 VIA Nehemiah CentaurHauls processor cannot boot
Date: Tue, 22 Jul 2008 19:28:16 -0400 [thread overview]
Message-ID: <48866D10.3020907@garzik.org> (raw)
In-Reply-To: <488629D5.4050603@zytor.com>
H. Peter Anvin wrote:
> Jeff Garzik wrote:
>>
>>> We're only referring specifically to the family == 6 VIA processors
>>> here.
>>
>> To be specific, I was merely saying that VIA processors where
>> c->x86_model==6 may lack CMOV.
>>
>> I have not kept track of what current Kconfig options will set, but in
>> the past it was quite easy to build a "generic 686 kernel" that
>> required CMOV and thus excluded these VIA processors.
>>
>> Distros in the past often wound up intentionally -not- supporting some
>> of these VIA processors, because they did not want to create a
>> non-CMOV kernel. (This policy obviously excluded older x86 as well)
>>
>> If these things have been addressed recently (< 12-18 months) then all
>> good.
>>
>
> I am pretty sure CONFIG_X86_GENERIC doesn't disable CMOV, and since CMOV
> is a separate CPUID flag it's all good (if the chip doesn't have it,
> it'll trap.)
It's generally more an issue of making sure the compiler is not
instructed to issue cmov (-march=i686).
> Unfortunately Intel didn't assign a CPUID flag for the long NOPs, and
> then didn't document them (I think partially because they were a
> retcon), but yet it reflected a serious hole in Centaur's
> characterization effort that they bumped family to 6 without following
> P6 behaviour for a massive range of opcodes.
>
> The main reason for disabling P6 NOPs for CONFIG_X86_GENERIC is that the
> win is so small, and that a number of vendors got it wrong.
Yeah.
Jeff
next prev parent reply other threads:[~2008-07-22 23:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-21 13:14 Bug on 2.6.26 - x86 VIA Nehemiah CentaurHauls processor cannot boot Luis R. Rodriguez
2008-07-21 13:23 ` H. Peter Anvin
2008-07-21 14:01 ` Luis R. Rodriguez
2008-07-21 23:24 ` H. Peter Anvin
2008-07-22 4:47 ` Luis R. Rodriguez
2008-07-22 13:10 ` H. Peter Anvin
2008-07-22 17:10 ` Jeff Garzik
2008-07-22 18:21 ` H. Peter Anvin
2008-07-22 18:33 ` Jeff Garzik
2008-07-22 18:41 ` H. Peter Anvin
2008-07-22 23:28 ` Jeff Garzik [this message]
2008-07-23 0:31 ` H. Peter Anvin
2008-07-22 13:14 ` Ingo Molnar
2008-07-22 13:24 ` H. Peter Anvin
2008-07-22 13:46 ` Ingo Molnar
2008-07-22 13:54 ` H. Peter Anvin
2008-07-26 18:31 ` Andi Kleen
2008-07-26 18:35 ` H. Peter Anvin
2008-07-26 18:44 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48866D10.3020907@garzik.org \
--to=jeff@garzik.org \
--cc=Seskar@winlab.rutgers.edu \
--cc=hpa@kernel.org \
--cc=hpa@zytor.com \
--cc=jfm3@winlab.rutgers.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=m.sujith@gmail.com \
--cc=mcgrof@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.