On Wed, Nov 07, 2001 at 08:48:00PM +0100, Jonas Diemer wrote:
> On Wed, 7 Nov 2001 20:25:46 +0100
> Vojtech Pavlik <vojtech@suse.cz> wrote:
>
> ...
> > The bug #2 can trigger the test for #1, because the timer is read just
> > after the timer interrupt happens and thus the value is usually around
> > 11920, which, plus 256 is larger than 11920.
> >
>
> so why don't you simply add a new option to the config file, that says "work
> around Via 686a bug"? that way, only ppl who have the bug need the fix.
>
> ...
> > Only timer.c and apic.c do proper locking.
> >
>
> well, but as I said, the workaround in arch/i386/kernel/time.c is incomplete, at
> least in linus' kernel tree!
>
> > The problem is how to work around the bugs 1) and 2) reliably and
> > without too much performance impact. I haven't found a feasible way to
> > do that yet.
>
> well, just use the option described above. that way, ppl that need the fix can
> choose to use it (at a cost of performance), others simply don't need checking.
>
> -jonas
>
> PS: CC me in your answers plz, I am not subscribed to the list.
The VIA bug isn't a problem: The fix doesn't cause performance problems
to people unaffected by the bug, it just prints an annoying message to
people who see it triggered by bug #2 (Neptune).
The Neptune bug (which seems much more widespread than expected) is a
much larger problem - it's hard to detect without performance
degradation and currently it isn't known which chipsets are affected. It
is known that Intel Mercury and Intel Neptune (old P6 chipsets) are. But
how about others ... ?
-- 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 More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:36 EST