From owner-freebsd-net Sat Dec 8 11:11:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 6721B37B426; Sat, 8 Dec 2001 11:10:47 -0800 (PST) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.11.6/8.10.2) with ESMTP id fB8JAlV05522; Sat, 8 Dec 2001 19:10:47 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Sat, 8 Dec 2001 19:10:46 +0000 (GMT) From: "E.B. Dreger" To: net@freebsd.org, smp@freebsd.org Subject: dc watchdog timeout on 4.4-R Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Greetings all, Sorry for the hefty cross-post... I've been digging through archives, and it seems that there was talk of this on -current late October of 2000, including speculation that this was an SMPng issue. I'm running a D-Link DFE570TX four-port dc (21143xx, where xx is TD if memory serves) on a dual-PII Micronics PTSAM motherboard. See /var/run/dmesg.boot following .signature for details. After my machine runs successfully for some while, I receive continuous "watchdog timeout" messages on a 10baseT/UTP HDX dc port. It doesn't seem to happen on 100baseTX FDX ports; however, being an infrequent event, I cannot vouch for the statistical validity of this claim. Once I receive these timeouts, "netstat -I dc3 -w 1" shows an output error each time I try to send traffic. A reboot is the only "cure" that I have found... i.e., it's not a cable issue. I don't recall experiencing this 4.3-R; I believe that I used the same motherboard for three months under 4.3-R, and that this is a new event since upgrading to 4.4-R. However, I'm a bit fuzzy on this, too. Anyone have any ideas? Please keep me CCed. I'm not currently subscribed. My email address is valid. However, please un-CC lists as appropriate -- if this is an SMP issue, I don't want to chew up -net, or vice versa. Again, I apologize for the large crosspost, but it's unclear to me which avenue is the correct one... TIA, Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.4-RELEASE #1: Wed Oct 31 14:19:51 GMT 2001 root@kaetzchen.brotsman.test:/usr/src/sys/compile/KAETZCHEN Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80fbff real memory = 134217728 (131072K bytes) avail memory = 127569920 (124580K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc0305000. Pentium Pro MTRR support enabled Using $PIR table, 6 entries at 0xc00f6380 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #0 intpin 19 -> irq 2 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0xfcd0-0xfcdf at device 1.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 1.2 irq 2 Timecounter "PIIX" frequency 3579545 Hz chip0: port 0x2180-0x218f at device 1.3 on pci0 sym0: <875> port 0xf800-0xf8ff mem 0xfebfe000-0xfebfefff,0xfebff800-0xfebff8ff irq 16 at device 17.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: SCAN AT BOOT disabled for targets 1 2 3 4 5 6 8 9 10 11 12 13 14 15. sym0: SCAN FOR LUNS disabled for targets 0 1 2 3 4 5 6 8 9 10 11 12 13 14 15. pci0: at 18.0 irq 17 pcib2: at device 19.0 on pci0 pci1: on pcib2 dc0: port 0xec00-0xec7f mem 0xfdfff800-0xfdfffbff irq 2 at device 4.0 on pci1 dc0: Ethernet address: 00:80:c8:f8:7b:50 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: port 0xe880-0xe8ff mem 0xfdfff400-0xfdfff7ff irq 18 at device 5.0 on pci1 dc1: Ethernet address: 00:80:c8:f8:7b:51 miibus1: on dc1 ukphy1: on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc2: port 0xe800-0xe87f mem 0xfdfff000-0xfdfff3ff irq 17 at device 6.0 on pci1 dc2: Ethernet address: 00:80:c8:f8:7b:52 miibus2: on dc2 ukphy2: on miibus2 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc3: port 0xe480-0xe4ff mem 0xfdffec00-0xfdffefff irq 16 at device 7.0 on pci1 dc3: Ethernet address: 00:80:c8:f8:7b:53 miibus3: on dc3 ukphy3: on miibus3 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: irq 0 at device 25.1 on pci0 atapci1: Busmastering DMA not supported pci0: (vendor=0xffff, dev=0x0000) at 25.2 pci0: (vendor=0xffff, dev=0x0000) at 25.3 pci0: (vendor=0xffff, dev=0x0000) at 25.4 pci0: (vendor=0xffff, dev=0x0000) at 25.5 pci0: (vendor=0xffff, dev=0x0000) at 25.6 pci0: (vendor=0xffff, dev=0x0000) at 25.7 pcib1: on motherboard pci2: on pcib1 orm0: