Date: Fri, 28 Dec 2001 13:25:40 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Søren Schmidt <sos@freebsd.dk> Cc: "Brandon S. Allbery KF8NH" <allbery@ece.cmu.edu>, ian j hart <ianjhart@ntlworld.com>, Matthew Gilbert <agilbertm@earthlink.net>, freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers Message-ID: <200112282125.fBSLPeE94616@apollo.backplane.com> References: <200112272203.fBRM3ep79889@freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:...
:> >
:> > There is also the "only supports 16MxN RAM" feature.
:>
:> Maybe I should toss in that I've had spontaneous reboots during heavy
:> IDE activity both on my desktop (VIA 82C686) and my laptop (Intel
:> 82443BX). And before that, random disk corruption during heavy SCSI
:> activity on my old desktop machine (seen with Tekram and Acer
:> 83C575-based host adapters and a borrowed Adaptec 2940).
:
:Guys guys, we are talking about known HW issues that causes known
:bad behavior, having a system that is flaky can have all kinds of
:reasons, I'd risk saying that genuine HW bugs like the 686B bug
:is one of the least likely problems...
:
:The most likely reasons are probably bad/subspec'd RAM, lousy PSU,
:bad/subspec'd cabeling, too many "performance features" enabled,
:generally crappy hardware (there are *tons* of that out there),
:bad/insufficient cooling, overclocking (even the motherboard makers
:overclock pr default nowadays to gain a litte over the competition),
:
:And do *not* forget bugs/bogons/mistakes in your favorite OS :)
:
:-Søren
Ok, I have more information on Nils problem. First of all, Soren's
patch greatly reduced the rate of corruption. It took 25 loops of
Nils 'cp' test to generate the corruption.
However, Soren's patch did not fiix the corruption. The same exact
corruption is occuring. In Nils case it is always the same exact
location in VM -- a certain bit (or byte) in the middle of the nfsnode
hash table. Hardware watch points indicate that the cpu is NOT modifying
this location, so I really doubt that it is a kernel bug.
From this and from reading a number of other postings about VIA chipsets
I believe that Soren's original patch (which I guess is the official
VIA chipset patch) does not completely solve the VIA chipset's problems.
I also believe, from reading some of the reference material that has
been posted, that this corruption is not limited to the 686[A/B] but
may also occur in earlier VIA chipsets.
What I would like to do is try forcing the DMA transfer rate to 66 MHz,
i.e. UDMA66 or UDMA33, to see if that solves the problem. Soren,
could you supply a patch that universally turns off higher UDMA modes?
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112282125.fBSLPeE94616>