Hi!
> 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.
Have a nice fortnight
--
Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/
"This line is umop apisdn."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
- Re: Possible critical VIA vt82c686a chip bug (pr... Richard B. Johnson
- Re: Possible critical VIA vt82c686a chip bug... Vojtech Pavlik
- Re: Possible critical VIA vt82c686a chip... Richard B. Johnson
- Re: Possible critical VIA vt82c686a ... Vojtech Pavlik
- Re: Possible critical VIA vt82c... Yoann Vandoorselaere
- Re: Possible critical VIA v... Vojtech Pavlik
- Re: Possible critical VIA v... Yoann Vandoorselaere
- Re: Possible critical VIA v... Vojtech Pavlik
- Re: Possible critical VIA v... Yoann Vandoorselaere
- Re: Possible critical VIA v... Vojtech Pavlik
- Re: Possible critical VIA vt82c686a chip... Martin Mares
- Re: Possible critical VIA vt82c686a ... Vojtech Pavlik
- Re: Possible critical VIA vt82c... Yoann Vandoorselaere
- Re: Possible critical VIA v... Vojtech Pavlik
- Re: Possible critical VIA v... Yoann Vandoorselaere
- Re: Possible critical VIA v... Vojtech Pavlik
- Re: Possible critical VIA vt82c686a chip bug (private... bart

