Date: Fri, 28 Dec 2001 23:23:01 +0100 (CET) From: Søren Schmidt <sos@freebsd.dk> To: Matthew Dillon <dillon@apollo.backplane.com> 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: <200112282223.fBSMN2c39286@freebsd.dk> In-Reply-To: <200112282125.fBSLPeE94616@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112282223.fBSMN2c39286>