>Search http://mail-index.netbsd.org/port-i386/2004/04/ for "NetBSD ruined 
>my NIC??"
>Quite a long thread, but there is some kind of fix/repair mentioned for 
>your (probably) damaged EEPROM.

I managed to finally reconstruct my EEPROM and get the NIC working again 
(on NetBSD 1.6.2_Stable).

I had an interesting situation where I had tried to reconstruct the eeprom 
as best I could - based on a working systems eeprom as an example - but 
still had the following problem:

- I was able to ping other nics from the fxp and be successfully pinged.

- when I tried to telnet into the machine with the fxp I could see the 
incoming traffic using tcpdump on the fxp card. However I could not see any 
response generated by the card either on the local tcpdump or on the 
originators tcpdump. So the telnet failed. I found by reprogramming some of 
the registers to ffff the full functionality of the nic returned. I havent 
really go to the bottom of this. If anyone has an explanation for this 
based on the information given so far I would be grateful.

I have two 865BFs here with the same problem (lucky me). On the second 
motherboard I simply changed address 0x23 - to 0x1050 - which is the device 
ID number read by the 82801 (and left the majority of the registers set to 
ffff : the corrupted values) and the controller worked albeit with a mac 
address of 0:0:ff:ff:ff:ff.

Based on http://mail-index.netbsd.org/port-i386/2004/04/ it seems that the 
cause of the problem is the rewriting of the EEPROM ID to ensure that 
the  dynamic standby mode is disabled.

The code for netbsd-2-0 seems identical to that of 1.6.2_Stable in this 
regard so if this is indeed the cause it will manifest in netbsd 2 as well.

Is there no better mechanism for implementing a solution for this  problem? 
Intel have not fixed the firmware problem and do not seem to intend doing 
so (according to the may specification update). Does this mean that we 
cannot safely install NetBSD on a system with an onboard fxp0 device ?

Thanks
Mark