Ok, here is a patch that executes a brute-force solution to the
asynchronous counter problem.
Basically it figures out a mask and then the timer code loops until two
masked reads yield the same value, guarenteeing that we haven't caught
the timer during a carry.
On my system, the mask I got was: 0xFFFC which means I lost only 2
bits of accuracy in order to be able to retrieve accurate counter values.
This gives my particular box an approximately 1uS accuracy.
I think this may be the only safe way to do it. It looks like it is
possible to catch the ripple and/or fast-carry on *any* bit, with the
statistical chance of it occuring on higher bits dropping by 2x per bit.
My proposed (tested) patch is below. Mike?
I have some reservations about this, because I'm not sure that 10
successive reads will catch the ripple-counter problem that the old PIIX4s
have.
I think that if this code detects a need for the mask technique, it
should set the handler to a function that will deal with the mask. If it
doesn't, it should assume that we need the 'safe' function as it
currently exists (I'm not sure why it's not the default, unless there's a
log message to explain it, it must have been a mistake on my part).
I'd also like to see the description include the number of bits, rather
than the mask, if we are using a mask.
Thanks for taking the time to track this one down.
--
To announce that there must be no criticism of the president,
or that we are to stand by the president, right or wrong, is not
only unpatriotic and servile, but is morally treasonable to
the American public. - Theodore Roosevelt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
