Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Feb 2006 20:31:54 +0300
From:      Yar Tikhiy <yar@comp.chem.msu.su>
To:        Cy Schubert <Cy.Schubert@spqr.komquats.com>
Cc:        freebsd-current@freebsd.org, netchild@freebsd.org
Subject:   Re: 7.0-CURRENT Hang
Message-ID:  <20060207173154.GE19674@comp.chem.msu.su>
In-Reply-To: <200602070429.k174TZ6v009581@cwsys.cwsent.com>
References:  <200602070429.k174TZ6v009581@cwsys.cwsent.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 06, 2006 at 08:29:35PM -0800, Cy Schubert wrote:
> 
> On the Pentium P54C model (that's an old 120 MHz Pentium I use as a 4.x, 
> 5.x, and 7.x ports build testbed) the CPUID instruction when called with AL 
> = 0x02, CPUID returns EAX = EBX = ECX = EDX = 0. The code fragment in 
> identcpu.c below results in "rounds" becoming 0xffffffff.
> 
> 	do_cpuid(0x2, regs);
> 	rounds = (regs[0] & 0xff) - 1;
> 
> The subsequent loop of the following will loop virtually for ever (it takes 
> forever tor this machine to count down from 0xffffffff performing a very 
> great many calls to get_INTEL_TLB in the process, virtually hanging the 
> machine in the process.
> 
> 	while (rounds > 0) {
> 		[... code ...]
> 		rounds--;
> 	}

FWIW, my presumably P54C machine (Family 5 Model 2 Stepping 6)
doesn't indicate it has the CPUID 0x02 function.  That is, CPUID
0x00 returns EAX = 0x01, which is the highest function supported.
Could you try to run the misc/cpuid port on your Pentium and show
its output?  It might appear that the code around CPUID 0x02 shouldn't
be reached at all in your case.  Zero values from CPUID 0x02 are
pretty indicative of that.

Dealing with "rounds" equal to -1 can be a good idea anyway to catch
braid dead CPUs instead of hanging the system on them.

-- 
Yar



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060207173154.GE19674>