svn commit: r330780 - in head/sys: amd64/include isa x86/isa

[Ian Lepore]

On Mon, 2018-03-12 at 13:03 -0600, Ian Lepore wrote:
> On Mon, 2018-03-12 at 17:56 +0200, Konstantin Belousov wrote:
> > 
> > On Mon, Mar 12, 2018 at 09:34:51AM -0600, Ian Lepore wrote:
> > > 
> > > [...]
> > > 
> > > Does anybody really need an eventtimer that runs only at a fixed
> > > periodic rate of 32khz in 2018?
> > Problem is that atrtc is what old machines use. If we have HPET or
> > better LAPIC timers, then we do not need atrtc at all, of course.
> > But e.g. 486 do not have them. I am not even sure about early amd64
> > machines.
> I think not unless someone has manually configured it that way.  The
> i8254 timer should be used as both timecounter and eventtimer if there
> is no lapic or hpet.  i8254 has an ET priority of 100 compared to
> atrtc's 0.  That's by code inspection...  I might still have some
> industrial SBCs around here old enough to not have hpet or lapic, I'll
> see if I can get one running.
> 

I found a nice old (2001 vintage) SBC based on a 586-class cyrix chip
that has no lapic or hpet timers.  It had a copy of freebsd 11-current
from Nov 2015 already installed and it booted right up.  It was using
the i8254 hardware as both timecounter and eventtimer.  I rebooted it
from a drive that had a copy of 12-current from yesterday and it
behaved the same.

Then I rebooted and set hint.attimer.0.clock=0 to prevent the i8254
driver from attaching an eventtimer.  That left only the atrtc
eventimer, and the result of that was that the system just becomes
comatose after saying "Timecounters tick every 0.967 msec".  So I
booted the old 11-current image with i8254 disabled, and that behaved
just the same.

So, the eventtimer code in the atrtc driver doesn't even work, and has
been broken (and unreported) since at least Nov 2015.  That sounds to
me like even more evidence that we should just remove eventtimer stuff
from the atrtc driver.

-- Ian