Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Feb 2006 21:27:55 +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:  <20060207182755.GB32998@comp.chem.msu.su>
In-Reply-To: <200602071806.k17I6WQc007602@cwsys.cwsent.com>
References:  <20060207173154.GE19674@comp.chem.msu.su> <200602071806.k17I6WQc007602@cwsys.cwsent.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 07, 2006 at 10:06:32AM -0800, Cy Schubert wrote:
> In message <20060207173154.GE19674@comp.chem.msu.su>, Yar Tikhiy writes:
> > 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.
> 
> Mine is Family 5 Model 2 Stepping 12. All of my doc is for Pentium-Pro and 
> newer so you are probably correct.

Do you know what CPUID function 0x00 returns in EAX for your CPU?
Hint: just run misc/cpuid once and show its output here.  I've just
fixed the port so that it has no bogus dependencies and is very
light-weight.

> > Dealing with "rounds" equal to -1 can be a good idea anyway to catch
> > braid dead CPUs instead of hanging the system on them.
> 
> Well, with rounds = -1 [actually (unsigned int)0xffffffff], the CPU will 
> "appear" to hang as it "rounds" or loops virtually forever -- counting back 
> from 0xffffffff on a 120 MHz machine and performing get TLB info a number 
> of times each iteration takes hours to do just a few iterations. I've seen 
> mine go through "rounds", decrementing rounds-- each time, for hours at a 
> time, though initially before digging into it using DDB it did appear that 
> the CPU was hung, it was just starting to loop for 4,294,967,295 times. On 
> older and slower machines, if it took hours to iterate through a few 
> iterations, my guess is that it would take days to loop through this code. 
> My patch allows it to take the defaults and finally boot. If the CPU 
> doesn't support AL = 0x02, what's the point of looping? It appears to run 
> nicely with the patch.

I do see that rounds = -1 is causing trouble.
I just meant that we should not call do_cpuid(0x02) at all if
(cpu_high < 2) because it can result in undefined behavior.
Your patch still makes sense because it deals with possible
brain-dead CPUs.  I'd implement it in a slightly different
way though -- stay tuned! :-)

-- 
Yar



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