Date: Sun, 29 Oct 1995 05:39:01 +1100 From: Bruce Evans <bde@zeta.org.au> To: stable@freebsd.org, swallace@ece.uci.edu Cc: bugs@freebsd.org Subject: Re: probs with latest stable snap Message-ID: <199510281839.FAA05152@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Ahh! I have traced it to line 180 of microtime.s: > divl %ecx # get value in usec >Hmmm, it appears the code checks for pentium_mhz != 0, so it could not >be div by 0. However, I looked up div, and it says, "If the >dividend is 0 or if the quotient is too large to fit in the result accumulator, a divide error fault (interrupt 0) occurs. >So, if the pentium cycle count is > 2^59, then on my 90 MHz pentium >(correctly reported), the fault will occur. I do not know what originally >caused the first panic, but it appears it put the pentium clock count >to a large number. Then it rebooted and gets into a panic div 0 loop. >I noticed that after I hit reset, then it booted up just fine (resetting >the counter?). >I noticed in -current code it has a i586_ctr_bias long long which >gets initialized and subtracts the cycle count before the division >in microtime.s. I think something like this should be put into -stable >to prevent this panic. Normally the counter gets set every clock tick. This reduces the dividend in much the same way as subtracting i586_ctr_bias, so there should be no problem dividing. However, microtime() is apparently sometimes called before the counter has been reset after booting. -current initializes i586_ctr_bias early so there should be no problem. The equivalent in -stable would be resetting the counter early. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510281839.FAA05152>