On Fri, Oct 27, 2000 at 12:58:12PM +0200, Yoann Vandoorselaere wrote:
> > > > So this is not our problem here. Anyway I guess it's time to hunt for
> > > > i8259 accesses in the kernel that lack the necessary spinlock, even when
> > > > they're not probably the cause of the problem we see here.
> > >
> > > BTW what about trying to modify your work-around code to make it
> > > attempt to read the timer again? This way we could test whether it was
> > > a race condition during timer read or really timer jumping to a bogus
> > > value.
> >
> > Actually if I don't reprogram the timer (and just ignore the value for
> > example), the work-around code keeps being called again and again very
> > often (between 1x/minute to 100x/second) after the first failure, even
> > when the system is idle.
> >
> > When reprogramming, next failure happens only after stressing the system
> > again.
> >
> > So it's not just a race, the impact of the failure on the chip is
> > permanent and stays till it's reprogrammed.
>
> Are you sure there is not an error in the way the
> chipset is programmed ?
Which part of the chipset you mean? The PIT (programmable interrupt
timer)? That one is standard since XT times. The rest of the ISA bridge?
Maybe, but that's mostly BIOS work and shouldn't impact the PIT
under sane conditions.
--
Vojtech Pavlik
SuSE Labs