Vojtech Pavlik <[email protected]> writes:
> 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.
What is strange is that a number of persons seem to be hit by this
problem... And if VIA didn't corrected it it's probably because
they are not aware of it...
I think that if such problem occured under windows
(thinking to the windows user base), VIA would be already in touch.
--
-- Yoann http://www.mandrakesoft.com/~yoann/
Tiniest "mesures unities?"
- lenght : millimeter
- volume : milliliter
- intelligence : military man