linux-kernel - Re: Bug on 2.6.26 - x86 VIA Nehemiah CentaurHauls processor cannot boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Jul 2008 19:28:16 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	"Luis R. Rodriguez" <mcgrof@...il.com>,
	linux kernel <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...nel.org>,
	Ivan Seskar <Seskar@...lab.rutgers.edu>,
	jfm3 <jfm3@...lab.rutgers.edu>, Sujith <m.sujith@...il.com>
Subject: Re: Bug on 2.6.26 - x86 VIA Nehemiah CentaurHauls processor cannot
 boot

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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/