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