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."