Date: Mon, 10 Aug 1998 20:40:12 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: se@FreeBSD.ORG (Stefan Esser) Cc: hackers@FreeBSD.ORG Subject: Re: Yet another XL driver update Message-ID: <199808110040.UAA23576@skynet.ctr.columbia.edu> In-Reply-To: <19980810233610.A1555@mi.uni-koeln.de> from "Stefan Esser" at Aug 10, 98 11:36:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Stefan Esser had to walk into mine and say: > On 1998-08-09 18:05 -0400, Bill Paul <wpaul@skynet.ctr.columbia.edu> wrote: > > - I haven't yet been able to fix the problem with one particular > > 3c900 COMBO card. This card appears to initialize correctly > > but refuses to do DMA. The 3c900 card that I have works properly > > This could be due to the MASTER_ENABLE bit not being > set in the PCI configuration space COMMAND register. > The PCI code in 2.2.x used to set that bit whenever > a port or memory map was registered, but the code in > 3.0 doesn't, since the bus-master functionality should > be enabled last. The PCI BIOS will often set the master > enable bit, but may leave the board alone, on that > particular system ... > > To check out that possibility, have the owner of that > failing card do a "pciconf -r" of the COMMAND register > and check bit 2 (value 4): it should be set to 1 to > have DMA support enabled. I thought about that; the xl_attach() routine explicitly sets the bus master enable, port enable and memory map enable bits in the PCI command register, and checks to make sure they were turned on successfully, otherwise it prints an error. The card is this guy: pci0:14:0: class=0x020000 card=0x00000000 chip=0x900110b7 rev=0x00 hdr=0x00 The PCI command register should be at offset 4 according to /sys/pci/pcireg.h. pciconf says: snarf# pciconf -r pci0:14:0 4 0x02000107 Looks like everything's turned on to me. This is really a case of "nothing's wrong, but nothing works." I can't find anything in the diag or status registers to indicate why DMA might not be working. This machine has two other bus master ethernet adapters in it, a 3c905B and a ThunderLAN-based card, and both of those seem to be doing DMA correctly. My understanding, which is somewhat limited, is that you can have both PCI bus master and PCI slave slots in a machine; a card that has to do bus master DMA must be placed in a bus master slot in order to work correctly. At first I thought that maybe the user had put the card in a slave slot, but he swears to me that the 3c905B card worked perfectly in the same slot earlier. Like I said, I'm tempted to blame this on a defective card. I've gotten one other report today on a 3c900-TP and 3c900-COMBO that both seem to work fine. It's just very curious because the card will work with the vx driver, which is only different in this case in that it doesn't use the DMA packet transfer mechanism. The engineer in me is having a hard time figuring out how just that one part of the adapter could fail, particularly when the DMA engine is inside the ASIC along with the transmit and receive circuitry and other pieces that that seem to be working fine. I usually think of a chip failure as something that would wipe out the whole ASIC, not just part of it. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= 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?199808110040.UAA23576>