OK, I now understand the problem is with the chip (finally got that oneAs I said before, this is a problem with the NE2000 chip and not the driver.
The driver has no way of knowing whether there is a link or not with this
chipset. The newer 10/100 chipsets have a PHY that you can probe to tell
whether there is a link or not. There is no way with the NE2000 chipset that
you can probe the link status before transmitting a packet.
into my head). My solution of slaying the Net.ether1000 driver on a
connection failure and restarting it seems to do the trick, with the
exception of only being able to do this a certain number of times. I
have now found out the reason for the limited number of restarts. Every
time I slay / restart the Net.ether1000 driver the Net process is
creating a timer. These timers are building up, until the system limit
is reached and then bingo no more restarts are possible and all system
timers are used.
Now I would slay the entire network and restart it, but this takes way
too much time to perform (3 network drivers, detecting which one is
being used for the main network connection...). The simple slaying and
restarting of the Net.ether1000 driver is much quicker and more
desirable. So is there a way to cleanly unregister a driver from the Net
process. I have taken out the code that attempts a connection to the
un-powered device, and these times are still created so I guess the
drivers are not being unregistered from the Net process.
If it is not possible to cleanly unregister with the Net process then
would it be possible for me to write an app that resets the card upon a
connection failure. And would doing this while the Net.ether1000 driver
is running upset the driver in any way?