svn commit: r219646 - head/sys/x86/isa

[Bruce Evans]

On Tue, 15 Mar 2011, Jung-uk Kim wrote:

> On Tuesday 15 March 2011 02:13 pm, Bruce Evans wrote:
>> On Tue, 15 Mar 2011, Jung-uk Kim wrote:
>>> ...
>>> I disagree.  I think we should keep away from i8254 as much as
>>> possible.
>>
>> It is adequate for DELAY(), and is the only timer that is available
>> on all x86.  You need large complications in DELAY() to make it
>> work as well as the old code using the i8254, for no gain until
>> there is an x86 without an i8254.
>
> Intel started killing off i8254 (and other "legacy" ISA devices),
> starting from "Mobile Internet Device" platforms.  Even for other
> so-called "legacy-free" platforms, it isn't adequate any more because
> of unpredictable SMI# interference.

I thought of getting a SandyBridge system and decided not to since it
it kills too much of my hardware.

Lengthening the delay due to SMI# interference doesn't matter in DELAY(),
since normal interrupts also lengthen it.  SMI# would have to corrupt
the i8254 state to cause larger problems.  (This is too easy to do
since the i8254 cannot be used without clobbering its current state
by more than advancing its countdown.)

>>>> Even in this patch, it isn't clear that the low level
>>>> timecounters are initialized before they are used.
>>>
>>> The timecounter is always initialized first, then set.
>>
>> It is still unclear whether they are initialized enough before they
>> are used since their setting is neither locked nor atomic.
>> ...
>> accessing it.  In fact, I can now see a reproducible bug in
>> DELAY(): - find an x86 that can run at 4GHz
>> - run it in 386 mode
>> - start it so that tsc_freq is 0x10000000ULL
>> - use the machdep.tsc_freq sysctl to tune tsc_freq to 0xFFFFFFFF
>
> machdep.tsc_freq should never have modified tsc_freq in the first
> place.  I am going to remove that soon.

No, changing tsc_freq is what machdep.tsc_freq is for.  Breaking this
would be backed out :-).  You can fix it using a generation count or
something.

>> [More examples of races.]
>
> Now don't you think we should really kill delay by TSC? ;-)

I always said that it should never have existed.  This leaves similar
bugs in timecounter intiialization, but there is some protection from
generation counts and time-domain locking there.

The sysctl is hackish in writing directly to the timecounter freqquency
variable instead of calling a tc function like tc_setclock().  I forget
why it does that.  (I said tc_init() before.  tc_init() is only for
initial initialization and tc_setclock() is intended only for adjustments
to the time.)

Bruce