Date: Fri, 28 Dec 2001 23:19:12 +0000 From: ian j hart <ianjhart@ntlworld.com> To: "stable@FreeBSD.ORG" <stable@freebsd.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, SXren Schmidt <sos@freebsd.dk> Subject: Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers Message-ID: <3C2CFDF0.4FF8489D@ntlworld.com> References: <200112272203.fBRM3ep79889@freebsd.dk> <200112282125.fBSLPeE94616@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > <dillon@backplane.com> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C2CFDF0.4FF8489D>