Re: fxp going quiescent in current

Mike Tancsa <mike_at_sentex.net> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        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 <full-duplex>
        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: <Intel 82559 Pro/100 Ethernet> port 0x9800-0x983f mem 0xe2203000-0xe2203fff,0xe2100000-0xe21fffff irq 5 at device 6.0 on pci2
miibus0: <MII bus> on fxp0
fxp0: Ethernet address: 00:30:48:51:c8:5e
fxp1: <Intel 82559 Pro/100 Ethernet> port 0x9c00-0x9c3f mem 0xe2201000-0xe2201fff,0xe2000000-0xe20fffff irq 12 at device 7.0 on pci2
miibus1: <MII bus> 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