fxp deafness

[Bob Vaughan]

I have also noticed periodic freezes with my various intel nics, using the 
fxp driver. So far they haven't happened enough to be able to discern a 
real pattern, but here are a few datapoints:

1. the problem has been randomly occuring since at least 5.0.

	I first noticed the problem when the onboard nic on a i815 based mb
	went deaf a few years ago.. I finally had the mb replaced under 
	warranty, thinking it was a hardware problem, but now i'm not so
	sure.. At the time, the system was running -current in the pre 5.0
	days, doing a twice daily buildworld, and nothing else. One day it
	just went deaf. I left it in the rack for a year or so, and finally
	got it replaced just as the warranty on the mb was running out.

	After replacement, the same problem popped up during install, where
	the onboard nic went deaf during the install process (this would
	have been 5.0 or 5.1), but worked fine after the os was installed. 

2. something in the install process triggers the problem. 

	This is the one area where I am consistently able to reproduce the 
	problem. The install sees the nic, uses dhcp to sucessfully grab an
	address, but when the time comes to use the nic for the install,
	the nic is deaf. I have seen this with both 5-stable and 6-stable.

3. the problem occurs in both onboard and add-on nics.

	I've seen the problem in at least 4 different machines, not 
	including the original i815 mb mentioned above. Two of these systems
	use onboard nics, and the other two use pci nics.

4. the nic goes deaf.

	tcpdump on both ends confirm that packets are being transmitted,
	but not received. This occurs no matter what networking devices are
	used. Testing has included switches, hubs, and crossover cables.

5. a reboot is necessary to restore connectivity.

	taking the interface down and up does not clear the problem,
	nor does unplugging and replugging the cable.

6. the only errors reported are: fxp0: device timeout

7. the problem does not appear to be related to network load.

	I have had the problem occur under moderate/heavy nfs traffic,
	as well as under no/light load conditions.




All of these machines are running 6.1-beta3 or 6.1-rc (#2). The problem
has most recently been observed in #1 and #2.

#1
onboard: intel D815EEAL mb

fxp0: <Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet> port 0xdf00-0xdf3f 
mem 0xfc9fe000-0xfc9fefff irq 7 at device 8.0 on pci1
miibus0: <MII bus> on fxp0
inphy0: <i82562ET 10/100 media interface> on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:03:47:9f:eb:3b


#2
pci card:

fxp0: <Intel 82550 Pro/100 Ethernet> port 0xd400-0xd43f 
mem 0xf1000000-0xf1000fff,0xf0800000-0xf081ffff irq 16 at device 8.0 on pci0
miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:02:b3:9c:ce:01


#3
pci card:

fxp0: <Intel 82558 Pro/100 Ethernet> port 0x7000-0x701f 
mem 0x80300000-0x80300fff,0x80100000-0x801fffff irq 10 at device 16.0 on pci0
miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:a0:c9:de:89:6a


#4
onboard: intel 815 chipset.

fxp0: <Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet> port 0xac00-0xac3f 
mem 0xefdee000-0xefdeefff irq 11 at device 8.0 on pci1
miibus0: <MII bus> on fxp0
inphy0: <i82562ET 10/100 media interface> on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:40:ca:28:10:7d






               -- Welcome My Son, Welcome To The Machine --
Bob Vaughan  | techie @ tantivy.net 		  |
	     | P.O. Box 19792, Stanford, Ca 94309 |
-- I am Me, I am only Me, And no one else is Me, What could be simpler? --