From owner-freebsd-net@FreeBSD.ORG Tue Nov 14 23:43:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68D8916A415; Tue, 14 Nov 2006 23:43:41 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB48243D53; Tue, 14 Nov 2006 23:43:40 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gk7wK-00056s-1u; Tue, 14 Nov 2006 23:43:40 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gk7pu-0001h2-BM; Tue, 14 Nov 2006 13:37:02 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17754.21277.210338.175055@roam.psg.com> Date: Tue, 14 Nov 2006 13:37:01 -1000 To: Robert Watson References: <17752.41644.706579.902238@roam.psg.com> <17753.64161.965166.601002@roam.psg.com> <20061114181823.K87081@fledge.watson.org> Cc: freebsd-net@freebsd.org, FreeBSD Current Subject: Re: fxp going quiescent in current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 23:43:41 -0000 Mike Tancsa suggested i try ifconfig fxp0 media 10baseT/UTP ifconfig fxp0 media autoselect this worked! i will next reboot with in_fxp.c reverted to pre 2006.10.06. but first i did the suggested analysis, which follows. > (1) When it's "dead", do interrupts still fire for the interface when packets > go near by? See vmstat -i. nope > (2) Does the driver think the link is still negotiated? What are the > interface flags set to? See ifconfig. same as in first post on this whine # ifconfig fxp0 fxp0: flags=8843 mtu 1500 options=8 inet 147.28.0.39 netmask 0xffffff00 broadcast 147.28.0.255 inet 147.28.0.40 netmask 0xffffffff broadcast 147.28.0.40 ether 00:30:48:51:c8:5e media: Ethernet 100baseTX status: active > (3) When you run tcpdump on the interace, does it see packets from the > outside world? nope. only this interface issuing arp requests etc. > (4) If you ping out the interface, does tcpdump see packets? Do you get > ENOBUFS? Have ping send at least 256 packets. Do you get errors? Send > to the broadcast address so that arp doesn't need to be working to > transmit. fun one as, when it is in this state, i have only serial access through the craft port. this machine is 4000km away in a rack. so i nohupped and backgrounded the pinger, and watched tcpdump. nohup.out showed zero response ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down PING 147.28.0.35 (147.28.0.35): 56 data bytes --- 147.28.0.35 ping statistics --- 325 packets transmitted, 0 packets received, 100.0% packet loss tcpdump showed only the arp requests 23:32:41.459630 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:42.460575 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:43.461486 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:44.462426 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:45.463347 arp who-has 147.28.0.35 tell 147.28.0.39 23:32:46.464279 arp who-has 147.28.0.35 tell 147.28.0.39 > (5) What does netstat -m show? # netstat -m 132/693/825 mbufs in use (current/cache/total) 128/262/390/17088 mbuf clusters in use (current/cache/total/max) 128/256 mbuf+clusters out of packet secondary zone in use (current/cache) 0/28/28/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 289K/809K/1098K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/22/4528 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 30 requests for I/O initiated by sendfile 0 calls to protocol drain routines > (6) Any unusual dmesg output? In particular, any mention of fxp state > changes or watchdogs firing? nope # dmesg | grep fxp fxp0: port 0x9800-0x983f mem 0xe2203000-0xe2203fff,0xe2100000-0xe21fffff irq 5 at device 6.0 on pci2 miibus0: on fxp0 fxp0: Ethernet address: 00:30:48:51:c8:5e fxp1: port 0x9c00-0x9c3f mem 0xe2201000-0xe2201fff,0xe2000000-0xe20fffff irq 12 at device 7.0 on pci2 miibus1: on fxp1 fxp1: Ethernet address: 00:30:48:51:c8:5f fxp0: link state changed to UP fxp0: promiscuous mode enabled fxp0: promiscuous mode disabled > (7) Does lowering the interface, waiting ten seconds, then raising it > help? nope > Notice that these are all much easier if you have a serial console. well, most of them are :). > If not, you might want to do the above using cron and a temporary file > followed by a reboot. :-) i hope to do better than that :) randy