cvs commit: src/sys/dev/random probe.c
bde at zeta.org.au
Tue Feb 8 05:27:25 GMT 2005
On Mon, 7 Feb 2005, John Baldwin wrote:
> On Sunday 06 February 2005 11:55 am, Ian Dowse wrote:
> > iedowse 2005-02-06 16:55:52 UTC
> > FreeBSD src repository
> > Modified files:
> > sys/dev/random probe.c
> > Log:
> > Check that we have at least a 586-class CPU before calling do_cpuid().
> > This fixes booting on a number of 486 processors.
> This is wrong. Some 486's do have cpuid, notable the dx4's (I used to have
> one.) The correct test is to see if you can flip a bit in %eflags (can't
> remember which one). If that flag stays at zero then you don't have cpuid,
> if the bit follows the value written to it then you do have cpuid.
Actually, the correct test is to see if the CPUID_CPUID bit is set in
the cpu_feature word. locore.s has already done the %eflags test and
repeating it in "MD" code would be even uglier than calling do_cpuid().
Since the cpuid instuction doesn't set a self-referential bit, CPUID_CPUID
doesn't exist yet and it needs to be put in cpu_feature as a software
bit. Since cpu_feature has no space to spare, it needs to be extended.
It should be extended for other reasons: to avoid the almost useless
cpu_feature actually has negative space to spare. The CPUID_XMM and
CPUID_SSE bits in it are aliased. This amplifies the bug that testing
the CPU_SSE bit in cpu_feature is an invalid test for SSE instructions
being available. enable_sse() only enables CR4_XMM if both CPUID_FXSR
and CPUID_XMM are set. Testing just CPUID_SSE is also invalid if
CPU_ENABLE_SSE is not configured. CPUID_SSE should be the preferred
name, since it is better known and is what printcpuinfo() prints, and
the CPUID_SSE bit should be cleared in cpu_feature if the software
decides not to support SSE, so that the tangled logic in enable_sse()
doesn't need to be repeated.
More information about the cvs-src