In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> > Sep  7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 -> 
>10412, -694583121)y
>> >
>> > this is bad.. right ? :-)
>> Well, at any rate it looks very funny.  If this is a laptop, try
>> building a kernel without apm and see if that helps.
>It only helps "hide" the problem.  There's either *extremely* bogus data 
>coming in, or an arithmetic or sequencing error that's allowing a corrupt 
>timecounter to be seen.
>It might help to see the negative number as hex...

I have collected all the emails I've received and I have identified
at least two different causes:

There is a bogus i8254 implementation on certain Athlon Mobos, this
is a non-brainer since they should not use the i8254 but the TSC.

There are negative numbers coming in from both the i8254 and in a
few cases from the TSC.  NTIMECOUNTER may be too low for certain
systems, I'm still waiting for some feedback on that.

Either way, I have a patch which I need to burn in in my lab, but
right now I have a hard time getting my SMP box to even print out
"Copyright..." when it boots :-(

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]         | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to