From owner-aic7xxx Tue May 19 10:11:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA28549 for aic7xxx-outgoing; Tue, 19 May 1998 10:11:00 -0700 (PDT) (envelope-from owner-aic7xxx@FreeBSD.ORG) Received: from dledford.dialnet.net (root@dledford.dialnet.net [206.65.249.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA28489 for ; Tue, 19 May 1998 10:10:49 -0700 (PDT) (envelope-from dledford@dialnet.net) Received: from dialnet.net (localhost [127.0.0.1]) by dledford.dialnet.net (8.8.5/8.8.4) with ESMTP id MAA00392; Tue, 19 May 1998 12:10:22 -0500 Message-ID: <3561BCFD.6801F896@dialnet.net> Date: Tue, 19 May 1998 12:10:21 -0500 From: Doug Ledford X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.102 i686) MIME-Version: 1.0 To: "Justin T. Gibbs" CC: aic7xxx@FreeBSD.ORG Subject: Re: linux: the tag that wouldn't die? References: <199805191642.KAA09672@narnia.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk Justin T. Gibbs wrote: > Are you sure this isn't caused by using I/O instructions instead memory > mapped I/O. I'm positive that isn't the cause because it doesn't happen :) There is only one place in the current 5.0.x driver where we don't use the aic_inb and aic_outb instructions, and that's the aic7xxx_probe() function that looks for the 284x and 274x cards. Obviously, I don't probe on the PCI cards. For the PCI cards, we use the pci_read_config_* functions to get the IO and MMAP addresses and to configure those before we ever even go so far as to do the initial pause of the chip. If we configure the MMAP IO address, then we never once touch that chip in PIO mode. However, that isn't to say I don't have an idea what else could be causing it, but if I'm right, that problem is beyond the scope of this driver... > This was a common problem on a few steppings of the P6 and > was one of the main reasons I initially added memory mapped I/O support. > > I've never had anyone report PCI parity errors like this with the FreeBSD > driver when using memory mapped I/O. There are a few situations that I know of that are "bad" under linux with regards to this option. One, some motherboards are shipping with a BIOS option to change the cacheline size on the motherboard. If this cache line size is not set to 8, then it can cause all kinds of problems, including PCI interrupts for PCI errors. Two, there are certain motherboards that will generate a continuous stream of interrupts when this is enabled. One of these that has been tested for me is the Intel Alder Quad PPro motherboard based on the GX chipset. On my own development motherboard, I can't force a PCI error interrupt even when the error bits are active, it simply never occurs. Mine is an Intel DK440LX based on the LX chipset. So, the general issue is that under linux it's unreliable whether or not the PCI parity error checking is actually checking anything worth checking. Therefore, it's disabled by default. Now, I mentioned that I thought I might know what's causing this. It could be one of the FreeBSD/Linux difference things, I'm not sure. But, certain motherboards that generate these continuous streams of errors also seem to have SERR and PARITY enabled in the command register for the primary bus chipset, and that tends to be active at the time. Motherboards that don't ever generate anything tend to have the SERR and PARITY bits of PCI_COMMAND disabled on the primary chipset. So, I'm theorizing that possibly there are differences in the PCI setup code on linux and FreeBSD that result in this. Possibly that the primary PCI chipset (the 440LX or 440GX or whatever) are not having their PCI_COMMAND register set to sane values at boot up and as a result we either get no checking, or bogus interrupts when we enable the checking. To my knowledge, the linux PCI code doesn't touch those bits in the PCI chipset, and so we rely on the BIOS to set things up in a sane and useable manner. If we instead forced it to whatever it needed to be and cleaned out any stale error information, then that might get things working, but that's really in the PCI chipset code, not in the driver. -- Doug Ledford Opinions expressed are my own, but they should be everybody's. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message