From owner-freebsd-stable Fri Dec 28 14:23:34 2001 Delivered-To: freebsd-stable@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 0078137B41A; Fri, 28 Dec 2001 14:23:26 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.11.6/8.11.6) id fBSMN2c39286; Fri, 28 Dec 2001 23:23:02 +0100 (CET) (envelope-from sos) From: Søren Schmidt Message-Id: <200112282223.fBSMN2c39286@freebsd.dk> Subject: Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers In-Reply-To: <200112282125.fBSLPeE94616@apollo.backplane.com> To: Matthew Dillon Date: Fri, 28 Dec 2001 23:23:01 +0100 (CET) Cc: "Brandon S. Allbery KF8NH" , ian j hart , Matthew Gilbert , freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 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 It seems Matthew Dillon wrote: > 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. Hmm, did the second change I posted change anything ? > 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. If the BIOS has the option to disable "page mode" access to RAM try to switch that off, it has shown problems here (as I mentioned in another mail) > 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. My patch is based on the info from VIA and from various other sources plus lots of testing here in the lab. > 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. The 686B data corruption bug is isolated to that chip *only*, the older 686A doesn't have that problem, the even older 686 has problems with the ATA66 clock generation but luckily only few of those exist. There is no offcial problems with the older chips of this sort, but some has varius minor problems/"features", which is unrelated here... > 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? Sure, this one turns off ATA100 support (note its for -current, but should be easily applied to -stable) in the same fashion ATA66 can be turned off etc. However under -current you can just use atacontrol to set the wanted transfermode, no patch is needed there. --- ata-dma.c 25 Dec 2001 14:44:26 -0000 1.80 +++ ata-dma.c 28 Dec 2001 22:14:01 -0000 @@ -407,6 +407,7 @@ if (ata_find_dev(parent, 0x06861106, 0x40) || ata_find_dev(parent, 0x82311106, 0) || ata_find_dev(parent, 0x30741106, 0)) { /* 82C686b */ +#if 0 if (udmamode >= 5) { error = ata_command(scp, device, ATA_C_SETFEATURES, 0, ATA_UDMA5, ATA_C_F_SETXFER, ATA_WAIT_READY); @@ -419,6 +420,7 @@ return; } } +#endif if (udmamode >= 4) { error = ata_command(scp, device, ATA_C_SETFEATURES, 0, ATA_UDMA4, ATA_C_F_SETXFER, ATA_WAIT_READY); -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message