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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:20 EST