From owner-freebsd-stable Fri Dec 28 15:19:56 2001 Delivered-To: freebsd-stable@freebsd.org Received: from pc1-cove4-0-cust214.bir.cable.ntl.com (pc1-cove4-0-cust214.bir.cable.ntl.com [213.105.93.214]) by hub.freebsd.org (Postfix) with ESMTP id ADEA137B420 for ; Fri, 28 Dec 2001 15:19:50 -0800 (PST) Received: (from root@localhost) by pc1-cove4-0-cust214.bir.cable.ntl.com (8.11.6/8.11.6) id fBSNJPJ05558; Fri, 28 Dec 2001 23:19:25 GMT (envelope-from ianjhart@ntlworld.com) Received: from ntlworld.com (alpha.private.net [192.168.0.2]) (authenticated) by pc1-cove4-0-cust214.bir.cable.ntl.com (8.11.6/8.11.6av) with ESMTP id fBSNJC405551 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Fri, 28 Dec 2001 23:19:15 GMT (envelope-from ianjhart@ntlworld.com) Message-ID: <3C2CFDF0.4FF8489D@ntlworld.com> Date: Fri, 28 Dec 2001 23:19:12 +0000 From: ian j hart X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: "stable@FreeBSD.ORG" Cc: Matthew Dillon , SXren Schmidt Subject: Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers References: <200112272203.fBRM3ep79889@freebsd.dk> <200112282125.fBSLPeE94616@apollo.backplane.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Filter-Version: 1.7 (pc1-cove4-0-cust214.bir.cable.ntl.com) X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > :... > :> > > :> > 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 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message I'm out of the loop on this one. I have been unable to reproduce the error for two weeks. I'll try backtracking to see if I can break it again. Summary: System VIA ATA33 (82C586) with UDMA66 drives. 4 disks RAID10 (vinum). Softupdates ON, DMA ON. 1 Upgraded BIOS. Side effect - factory default (safe) settings. 2 This revealed the memory addressing feature, so I swapped the 8chip X 1side SDRAM for an 8cX2s to match the other RAM present. This will wrap - sorry. http://www.azza.com.tw/ftp/specs/MTB-0109-01-00%20'Using%20more%20then%2064Mb%20memory%20with%20VIA%20MVP3%20chipset%20boards'.htm 3 The new BIOS doesn't like the ISA SCSI card and I get a panic on boot. BIOS settings which work put the SB128 on the same IRQ as the network card (rl). 4 Swapped the ISA SCSI card (adv) for a PCI (sym) one. [Only a CDRW on this] 5 Full build (Dec 11). I've thrashed the living daylights out of the drives without so much as a twitch. I enabled the memory performance features - still okay. If I can force an IRQ conflict I'll try that next, followed by the old SCSI card. I'd have to downgrade the BIOS to try the old memory, and anyway it's in another M/C. -- ian j hart To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message