From: Steve Underwood <steveu@coppice.org>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Linux Kermel ML <linux-kernel@vger.kernel.org>
Subject: Re: VIA 686 timer bugfix incomplete
Date: Fri, 09 Nov 2001 10:57:52 +0800 [thread overview]
Message-ID: <3BEB4630.6010103@coppice.org> (raw)
In-Reply-To: <E161RcS-0003x8-00@the-village.bc.nu> <3BE98BA9.7090102@coppice.org> <20011108211126.B6266@suse.cz>
Hi,
Vojtech Pavlik wrote:
> On Thu, Nov 08, 2001 at 03:29:45AM +0800, Steve Underwood wrote:
>>If the messages:
>>
>>probable hardware bug: clock timer configuration lost - probably a
>>VIA686a motherboard.
>>probable hardware bug: restoring chip configuration.
>>
>>are really related to a VIA686A bug, why do they erratically appear on
>>Compaq ML370's, which use ServerWorks chip sets? Is there a common bug
>>between these chip sets? Seems unlikely.
>>
>
> Just to make sure: Is on the system the Ftape of any joystick driver in
> use? If not, then:
>
> The ServerWorks chip set has a bug that is shared with old Intel Neptune
> chipset most likely. This is a problem per se, but also triggers the VIA
> bug workaround. The VIA bug test can be enhanced to detect this false
> alarm, but the Neptune-like bug still stays and is dangerous as well.
>
> At least the VIA workaround told us something fishy is happening on
> non-VIA hardware as well.
>
> For example on my VIA686a/cg (late revision), the workaround is never
> triggered.
There are no such devices in use in our machines. This is happening on 3
Compaq servers, and each has a similar configuration. A Compaq ML370,
1G RAM, a Compaq Smart Array 431 RAID controller, and some Dialogic
telephony cards.
I don't have one of these machines running without telephony cards, to
see if that has any significance.The only external interfaces we use are
the LAN, one of the serial ports, and the phone lines connected to the
Dialogic cards. The SCSI controller is idle, as the disks are on the
RAID controller. The IDE interface has a CD-ROM on it..
From what you say, it sounds like the ServerWorks chipset may well have
a timer bug. This machine uses the LE 3.0 chipset.
Regards,
Steve
next prev parent reply other threads:[~2001-11-09 2:54 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
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 [this message]
-- 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=3BEB4630.6010103@coppice.org \
--to=steveu@coppice.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox