From owner-freebsd-current Mon Oct 23 19:46:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C26E737B479 for ; Mon, 23 Oct 2000 19:46:27 -0700 (PDT) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id WAA14278 for ; Mon, 23 Oct 2000 22:46:26 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.0/8.9.1) id e9O2kQs11122; Mon, 23 Oct 2000 22:46:26 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 23 Oct 2000 22:46:26 -0400 (EDT) To: freebsd-current@freebsd.org Subject: dc0: watchdog timeout X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14836.62663.657129.698427@grasshopper.cs.duke.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anybody else seeing 'dc0: watchdog timeout' since SMPng integration? Just after the removal of SPLs on alpha, my UP1000 started occasionally spewing 'dc0: watchdog timeout' and effectively dropping off the network when linking 23+ MB alpha kernel.debug's over NFSv3 to a reasonably snappy NFS server. This happens on maybe 1 in 5 kernel links. I don't have tulip cards in any PCs, so it is hard for me to tell if this is an alpha issue or an if_dc driver issue.. When it happens, I see the following: Oct 23 17:37:58 thunder /kernel.test: dc0: TX underrun -- increasing TX threshold Oct 23 17:54:44 thunder /kernel.test: dc0: watchdog timeout Oct 23 17:54:59 thunder /kernel.test: nfs server xxx:/export/xxx: not responding Oct 23 17:55:02 thunder /kernel.test: nfs server xxx:/export/xxx: not responding <...> The card in question is a gen-u-ine DEC DE500 of some vintage: # pciconf -l | grep ^dc dc0@pci0:9:0: class=0x020000 card=0x500b1011 chip=0x00191011 rev=0x30 hdr=0x00 It identifies itself as: dc0: port 0x10100-0x1017f mem 0x41353100-0x4135317f irq 10 at device 9.0 on pci0 dc0: interrupting at ISA irq 10 dc0: Ethernet address: 00:00:f8:07:b6:45 miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto <...> I'm running in hardcoded 100baseTX full-duplex mode: dc0: flags=8843 mtu 1500 inet 152.3.x.y netmask 0xffffff00 broadcast 152.3.x.255 ether 00:00:f8:07:b6:45 media: 100baseTX status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX none Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message