All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yoann Vandoorselaere <yoann@mandrakesoft.com>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Martin Mares <mj@suse.cz>,
	"Richard B. Johnson" <root@chaos.analogic.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Possible critical VIA vt82c686a chip bug (private question)
Date: 27 Oct 2000 13:16:34 +0200	[thread overview]
Message-ID: <m3y9zaa60d.fsf@test1.mandrakesoft.com> (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> <20001027124947.A476@suse.cz> <m38zrablff.fsf@test1.mandrakesoft.com> <20001027130151.A607@suse.cz>
In-Reply-To: Vojtech Pavlik's message of "Fri, 27 Oct 2000 13:01:51 +0200"

Vojtech Pavlik <vojtech@suse.cz> writes:

> On Fri, Oct 27, 2000 at 12:58:12PM +0200, Yoann Vandoorselaere 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.
> > 
> > Are you sure there is not an error in the way the 
> > chipset is programmed ?
> 
> Which part of the chipset you mean? The PIT (programmable interrupt
> timer)? That one is standard since XT times. The rest of the ISA bridge?
> Maybe, but that's mostly BIOS work and shouldn't impact the PIT
> under sane conditions.

What is strange is that a number of persons seem to be hit by this
problem... And if VIA didn't corrected it it's probably because
they are not aware of it...

I think that if such problem occured under windows 
(thinking to the windows user base), VIA would be already in touch.

-- 
		-- Yoann http://www.mandrakesoft.com/~yoann/
Tiniest "mesures unities?"
- lenght : millimeter
- volume : milliliter
- intelligence : military man
-
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/

  reply	other threads:[~2000-10-27 11:12 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
2000-10-27 10:58         ` Yoann Vandoorselaere
2000-10-27 11:01           ` Vojtech Pavlik
2000-10-27 11:16             ` Yoann Vandoorselaere [this message]
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=m3y9zaa60d.fsf@test1.mandrakesoft.com \
    --to=yoann@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mj@suse.cz \
    --cc=root@chaos.analogic.com \
    --cc=vojtech@suse.cz \
    /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.