fxp0: device timeout

/dev/null null at dnswatch.com
Mon Apr 25 12:33:44 PDT 2005


I don't want to sound like a smart a$$, or know-it-all. But could this not
also be a simple case of Induction? Is it possible that something has
changed in the environment that might interfere with the NIC or cabling?
I mean it wouldn't have to completely clobber the connection, but simply
impeed it slightly, which would make it crap out under any type of load.
Just thought I'd mention it FWIW.

-Chris

> My server in the attic was recently reinstalled from scratch with
> FreeBSD 5.stable (actually: RC2, and now upgraded to 5-stable), see the
> attached dmesg.boot for the dmesg info.
>
> This machine in the exact hardware configuration was running fine in its
> 6-current days. The reason for 'down'grading was the fact that overtime
> it seems that a subtle filesystem problem arose, that lead to random
> crashes (well, random... take a lot of vm activity and at some point
> vnlru would lead to a kernel panic), but the network was perfectly fine.
>
> Now, with the 5.x install, I have regular problems with fxp0.
>
> In /var/log/messages and dmesg I get this:
> (The last line comes from ifconfig fxp0 link0, which I added yesterday
> to see if it would solve problems, the same symptoms occur without that
> option)
>
> Apr 25 18:15:08 eeyore kernel: fxp0: device timeout
> Apr 25 18:15:08 eeyore kernel: fxp0: Microcode loaded, int_delay: 1000
> usec  bundle_max: 0
>
> The symptoms:
> * network freezes for 30 seconds or something like that, after a while
> pings start to work again and everything moves on.
>
> When:
> * combinations of network activity and/or disk activity. Starting bacula
> will guarantee device timeouts, as will browsing from a workstation
> combined
> with e.g. using a samba share
>
> The interface:
>
> fxp0: <Intel 82558 Pro/100 Ethernet> port 0xe000-0xe01f mem
> 0xe3000000-0xe30fffff,0xe3101000-0xe3101fff irq 5 at device 17.0 on pci0
> miibus1: <MII bus> on fxp0
>
> fxp0: flags=9843<UP,BROADCAST,RUNNING,SIMPLEX,LINK0,MULTICAST> mtu 1500
> 	options=8<VLAN_MTU>
> 	inet6 fe80::208:c7ff:fe25:7560%fxp0 prefixlen 64 scopeid 0x2
> 	ether 00:50:da:3d:d7:f6
> 	media: Ethernet autoselect (100baseTX <full-duplex>)
> 	status: active
>
> There are 2 'special' things with this interface:
> * the mac address is changed from /etc/start_if.fxp0
> * it is used with VLAN's (802.1q tagging)
>
> I looked in the mail archives, and of course it is clearly an interrupt
> problem. I did the usual stuff: put the card in different PCI slots,
> force it to different IRQ in the BIOS, but still no improvement.
> Furthermore I don't believe that hardware should change that much just
> by reinstalling FreeBSD, so I tend to believe that something is
> different between 5.x and 6.x.
>
> Does anyone recognize these symptoms and have a nice solution for me?
> Or if people decide I should PR this: what kind of info would make
> debugging easy? vmstat 1 info would take a little work to collect for
> these kind of outages, but I can do some scripting to fix that of course
> :-)
>
> Greetings,
>
> Mark
> --
> Nice testing in little China...
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>


////////////////////////////////////////////////////
 If only Western Electric had found a way to offer
binary licenses for the UNIX system back in 1974,
the UNIX system would be running on all PC's today
rather than DOS/Windows.
////////////////////////////////////////////////////


More information about the freebsd-current mailing list