From: Vojtech Pavlik <vojtech@suse.cz>
To: Martin Mares <mj@suse.cz>
Cc: "Richard B. Johnson" <root@chaos.analogic.com>,
Yoann Vandoorselaere <yoann@mandrakesoft.com>,
linux-kernel@vger.kernel.org
Subject: Re: Possible critical VIA vt82c686a chip bug (private question)
Date: Fri, 27 Oct 2000 12:49:47 +0200 [thread overview]
Message-ID: <20001027124947.A476@suse.cz> (raw)
In-Reply-To: <m3d7gnd31m.fsf@test1.mandrakesoft.com> <Pine.LNX.3.95.1001026115039.12337A-100000@chaos.analogic.com> <20001026190309.A372@suse.cz> <20001027120220.A5741@atrey.karlin.mff.cuni.cz>
In-Reply-To: <20001027120220.A5741@atrey.karlin.mff.cuni.cz>; from mj@suse.cz on Fri, Oct 27, 2000 at 12:02:20PM +0200
On Fri, Oct 27, 2000 at 12:02:20PM +0200, Martin Mares wrote:
> > 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.
Actually if I don't reprogram the timer (and just ignore the value for
example), the work-around code keeps being called again and again very
often (between 1x/minute to 100x/second) after the first failure, even
when the system is idle.
When reprogramming, next failure happens only after stressing the system
again.
So it's not just a race, the impact of the failure on the chip is
permanent and stays till it's reprogrammed.
--
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
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-10-27 10:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m3d7gnd31m.fsf@test1.mandrakesoft.com>
[not found] ` <Pine.LNX.3.95.1001026115039.12337A-100000@chaos.analogic.com>
2000-10-26 17:03 ` Possible critical VIA vt82c686a chip bug (private question) Vojtech Pavlik
2000-10-26 17:42 ` Richard B. Johnson
2000-10-26 18:02 ` Vojtech Pavlik
2000-10-26 20:11 ` Yoann Vandoorselaere
2000-10-26 20:16 ` Vojtech Pavlik
2000-10-26 21:05 ` Yoann Vandoorselaere
2000-10-26 21:15 ` Vojtech Pavlik
2000-10-26 21:24 ` Yoann Vandoorselaere
2000-10-26 21:25 ` Vojtech Pavlik
2000-10-27 10:02 ` Martin Mares
2000-10-27 10:49 ` Vojtech Pavlik [this message]
2000-10-27 10:58 ` Yoann Vandoorselaere
2000-10-27 11:01 ` Vojtech Pavlik
2000-10-27 11:16 ` Yoann Vandoorselaere
2000-10-27 11:15 ` Vojtech Pavlik
[not found] <20001026173244.B8290@suse.cz>
2000-10-27 12:04 ` bart
2000-10-27 13:41 ` Vojtech Pavlik
2000-10-28 5:39 ` TimO
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=20001027124947.A476@suse.cz \
--to=vojtech@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mj@suse.cz \
--cc=root@chaos.analogic.com \
--cc=yoann@mandrakesoft.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.