Date: Wed, 26 Dec 2001 22:41:25 +0100 (CET) From: Søren Schmidt <sos@freebsd.dk> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Need PCI/VIA chipset help (was Re: 4.4-STABLE crashes - suspects new ata-driver over wd-drivers) Message-ID: <200112262141.fBQLfP319423@freebsd.dk> In-Reply-To: <200112262015.fBQKFHi47418@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Matthew Dillon wrote: > I am trying to determine if our ATA/VIA setup code may have issues. I > did a google search and came up with a linux-quirks patch which may > apply to the random corruption problems people have been reporting. > Here is the URL: > > http://www.linuxhq.com/kernel/v2.4/patch/patch-2.4.8/linux/drivers/pci/quirks.c.html > > My question is: Does any of this apply to our ATA driver code? The > problem they are solving looks fairly serious. That patch ONLY applies to VIA chipsets containing the VIA82C686B southbridge, and a semilar fix has been in -current for quite some time, and I have asked for permission to commit it to 4.5 as well. Now of the two systems you list below, only the second has a VIA82C686B southbridge, the first is an older '586 suthbridge which doesn't have that problem. > I would also like to know if there is any sort of generic 'safe' pci > configuration that we can set for thet ATA driver to try to rule-in > or rule-out the driver as the cause of the memory corruption. The patch in -current is belived to fix the problem. That is according to info from VIA, and significant testing on about a dozen different boards by me. There is no such thing as a safe setup other than that. > So far nearly everyone reporting these weird panics is running under > heavy IDE drive loads. I've received about 5 kernel core's from one > person and a core from another and investigated them. The corruption > appears to occur 'out of the blue', during heavy IDE drive loads. > There are no warnings or errors in the dmesg output prior to the > crash. I do not believe the kernel code itself is causing the > memory corruption. Again if we are talking about the '686B data corruption bug, this is well known, and the fix has been in place for quite some time. However if you are talking about other chipsets I have no idea... The '686B data corruption problem is not an ATA/IDE problem alone, it is a problem when PCI activity raises above a certain limit, the wind is in the right direction, and your BIOS has setup the chipset with the wrong combination of features. I'm in doubt who I would blaim, VIA for not telling which options go together safely, or BIOS writers for not giving a hoot and just turn on every feature they can find.... But one thing I can tell, I think it is the BIOS writers damn problem to fix things like this (and luckily most vendors have), it is not something that we as an OS vendor should tinker with, since we dont have all the info and docs, that can show us exactly what features a given motherboard has implemented and supports. Anyhow since this is not always the case I did the fix for -current, granted it should not be in the ATA driver, but since nobody else really cared at the time.... -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?200112262141.fBQLfP319423>