From: Vojtech Pavlik <vojtech@suse.cz>
To: Jonas Diemer <diemer@gmx.de>
Cc: Linux Kermel ML <linux-kernel@vger.kernel.org>
Subject: Re: VIA 686 timer bugfix incomplete
Date: Wed, 7 Nov 2001 21:14:45 +0100 [thread overview]
Message-ID: <20011107211445.A2286@suse.cz> (raw)
In-Reply-To: <20011107125012.6b1fbdc3.diemer@gmx.de> <E161RcS-0003x8-00@the-village.bc.nu> <20011107202546.A1939@suse.cz> <20011107204800.70b91985.diemer@gmx.de>
In-Reply-To: <20011107204800.70b91985.diemer@gmx.de>; from diemer@gmx.de on Wed, Nov 07, 2001 at 08:48:00PM +0100
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
next prev parent reply other threads:[~2001-11-07 20:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-07 11:50 VIA 686 timer bugfix incomplete Jonas Diemer
2001-11-07 12:15 ` Alan Cox
2001-11-07 19:25 ` Vojtech Pavlik
2001-11-07 19:48 ` Jonas Diemer
2001-11-07 20:14 ` Vojtech Pavlik [this message]
2001-11-07 22:32 ` Neale Banks
2001-11-08 8:02 ` Vojtech Pavlik
2001-11-08 9:21 ` Jonas Diemer
2001-11-08 20:08 ` Vojtech Pavlik
[not found] ` <20011108221751.5273484e.diemer@gmx.de>
2001-11-08 21:22 ` Vojtech Pavlik
2001-11-08 21:30 ` george anzinger
2001-11-08 23:30 ` Alan Cox
2001-11-09 8:34 ` Vojtech Pavlik
2001-11-09 17:21 ` george anzinger
2001-11-07 19:29 ` Steve Underwood
2001-11-08 20:11 ` Vojtech Pavlik
2001-11-09 2:57 ` Steve Underwood
-- strict thread matches above, loose matches on Subject: below --
2001-11-09 19:19 Grover, Andrew
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011107211445.A2286@suse.cz \
--to=vojtech@suse.cz \
--cc=diemer@gmx.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox