cvs commit: src/sys/dev/random probe.c

[Bruce Evans]

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 classes.

Related bugs:
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.

Bruce