On Fri, Oct 27, 2000 at 12:02:20PM +0200, Martin Mares 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.
--
Vojtech Pavlik
SuSE Labs