From owner-freebsd-stable Wed Jun 27 0:51: 6 2001 Delivered-To: freebsd-stable@freebsd.org Received: from root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id A6F3137B401 for ; Wed, 27 Jun 2001 00:51:00 -0700 (PDT) (envelope-from dg@root.com) Received: (from dg@localhost) by root.com (8.11.2/8.11.2) id f5R7fQ553271; Wed, 27 Jun 2001 00:41:26 -0700 (PDT) (envelope-from dg) Date: Wed, 27 Jun 2001 00:41:26 -0700 From: David Greenman To: Mike Tancsa Cc: freebsd-stable@freebsd.org Subject: Re: More fxp problems (Different ?) Message-ID: <20010627004126.A53263@nexus.root.com> References: <5.1.0.14.0.20010626132049.04048e40@marble.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20010626132049.04048e40@marble.sentex.ca>; from mike@sentex.net on Tue, Jun 26, 2001 at 01:32:51PM -0400 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 >This is a stange one. It seems like a hardware issue as the same two nics >on a 815 or 440BX chipset did have these problems. ^ NOT? ...in any case, try this patch and let me know if the problem goes away: Index: if_fxp.c =================================================================== RCS file: /home/ncvs/src/sys/dev/fxp/if_fxp.c,v retrieving revision 1.110.2.4 diff -c -r1.110.2.4 if_fxp.c *** if_fxp.c 2001/06/08 20:36:57 1.110.2.4 --- if_fxp.c 2001/06/27 07:48:29 *************** *** 490,501 **** --- 490,503 ---- * If we are not a 82557 chip, we can enable extended features. */ if (sc->chip != FXP_CHIP_82557) { + #if 0 /* * If there is a valid cacheline size (8 or 16 dwords), * then turn on MWI. */ if (pci_read_config(dev, PCIR_CACHELNSZ, 1) != 0) sc->flags |= FXP_FLAG_MWI_ENABLE; + #endif /* turn on the extended TxCB feature */ sc->flags |= FXP_FLAG_EXT_TXCB; -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. >MB is an Asus CUV-4x-e Via82ct chipset 686b. Cards are >1 2940U >1 3Ware 2 port RAID-1 config (6x000 series) >2 Intel nics, both show inphy1: on miib >inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >and both are from the same box. In short, all these parts do not play well >together. If I pull the two nics and put in cheap old RealTeks the box >works fine enough. But with the Intels (I have tried manual IRQs, auto, >changing the slot order etc), I still get the nics locking up on a >consistent basis. I even tried a card that was made a few years ago, but >same results. > > >Jun 26 08:52:02 granite /kernel: Timecounter "i8254" frequency 1193182 Hz >Jun 26 08:52:02 granite /kernel: CPU: Pentium III/Pentium III Xeon/Celeron >(870.58-MHz 686-class CPU) >Jun 26 08:52:02 granite /kernel: Origin = >"GenuineIntel" Id = 0x68a Stepping = 10 >Jun 26 08:52:02 granite /kernel: >Features=0x383f9ffSR,SSE> >un 26 08:52:02 granite /kernel: npx0: INT 16 interface >Jun 26 08:52:02 granite /kernel: pcib0: on motherboard >Jun 26 08:52:02 granite /kernel: pci0: on pcib0 >Jun 26 08:52:02 granite /kernel: pcib2: PCI-PCI (AGP) bridge> at device 1.0 on pci0 >Jun 26 08:52:02 granite /kernel: pci1: on pcib2 >Jun 26 08:52:02 granite /kernel: isab0: at >device 4.0 on pci0 >Jun 26 08:52:02 granite /kernel: isa0: on isab0 >Jun 26 08:52:02 granite /kernel: atapci0: >port 0xd800-0xd80f at device 4.1 on pci0 >Jun 26 08:52:02 granite /kernel: ata0: at 0x1f0 irq 14 on atapci0 >Jun 26 08:52:02 granite /kernel: ata1: at 0x170 irq 15 on atapci0 >Jun 26 08:52:02 granite /kernel: pci0: at 4.2 >irq 10 >Jun 26 08:52:02 granite /kernel: pci0: at 4.3 >irq 10 > >I have a very similar mix of parts in my news server and I have never seen >this happen on the 440BX chipset. Is it something specific to the Via or >this combo ? The errors were happening at 100 and 10Mb with various duplex >settings. A few times the NIC totally locked up and I had to reboot the >machine to recover. > > >Jun 26 06:25:11 granite /kernel: fxp1: device timeout >Jun 26 06:25:11 granite /kernel: fxp1: SCB timeout: 0x60, 0x0, 0x0 0x0 >Jun 26 06:25:11 granite /kernel: fxp1: SCB timeout: 0x6, 0x0, 0x0 0x0 >Jun 26 06:25:11 granite /kernel: fxp1: SCB timeout: 0x40, 0x0, 0x0 0x0 >Jun 26 06:25:11 granite /kernel: fxp1: DMA timeout >Jun 26 06:25:12 granite /kernel: fxp1: SCB timeout: 0x10, 0x0, 0x0 0x0 >Jun 26 06:25:12 granite /kernel: fxp1: DMA timeout >Jun 26 06:25:12 granite /kernel: fxp1: SCB timeout: 0x10, 0x0, 0x0 0x0 >Jun 26 06:25:12 granite /kernel: fxp1: SCB timeout: 0x10, 0x0, 0x0 0x0 >Jun 26 06:25:17 granite /kernel: fxp1: SCB timeout: 0x1, 0x0, 0x0 0x400 >Jun 26 06:25:19 granite /kernel: fxp1: SCB timeout: 0x81, 0x0, 0x0 0x400 >Jun 26 06:25:31 granite /kernel: fxp1: device timeout >Jun 26 06:25:31 granite /kernel: fxp1: SCB timeout: 0x60, 0x0, 0x0 0x0 >Jun 26 06:25:31 granite /kernel: fxp1: SCB timeout: 0x6, 0x0, 0x0 0x0 >Jun 26 06:25:31 granite /kernel: fxp1: SCB timeout: 0x40, 0x0, 0x0 0x0 >Jun 26 06:25:31 granite /kernel: fxp1: DMA timeout >Jun 26 06:25:31 granite /kernel: fxp1: SCB timeout: 0x10, 0x0, 0x0 0x0 >Jun 26 06:25:31 granite /kernel: fxp1: DMA timeout >Jun 26 06:25:31 granite /kernel: fxp1: SCB timeout: 0x10, 0x0, 0x0 0x0 >Jun 26 06:25:31 granite /kernel: fxp1: SCB timeout: 0x10, 0x0, 0x0 0x0 >Jun 26 08:39:46 granite /kernel: fxp1: Ethernet address 00:d0:b7:92:32:b4 >Jun 26 08:40:09 granite /kernel: fxp1: device timeout >Jun 26 08:40:24 granite /kernel: arp: 199.212.134.2 is on fxp1 but got >reply from 00:90:27:b0:35:21 on fxp0 >Jun 26 08:40:32 granite /kernel: fxp1: device timeout >Jun 26 08:41:04 granite /kernel: fxp1: device timeout >Jun 26 08:47:04 granite /kernel: fxp0: >port 0xb400-0xb43f mem 0xfa000000-0xfa0fffff,0xfa800000-0xfa800fff irq 7 at >device 9.0 on pci0 >Jun 26 08:47:04 granite /kernel: fxp0: Ethernet address 00:d0:b7:92:32:b4 >Jun 26 08:47:27 granite /kernel: fxp0: device timeout >Jun 26 08:47:51 granite /kernel: fxp0: device timeout >Jun 26 08:48:14 granite /kernel: fxp0: device timeout > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message