TR-Adapter does not come back into the ring

[Paul Norton <pnorton@ccnvhi.com>]

That's bizarre. But the system must still be able to fork. Otherwise
you'd never be able to fire off the ifconfig command, right?

I have experienced some situations where a wedged network
adapter/driver caused other processes to hang as well. But then it
never allowed the ifconfig command to complete, and it sounds like
this isn't the case on your system. Are you getting any tr0 messages
in syslog? 

As far as being able to bring the adapter back into the ring, yes, it
should work. I did a fair amount of work on this problem when I added
multiple adapter support and got it to work consistantly for
me. However, multiple adapter support didn't go into the kernel until
the early 2.1.x kernels, so this is still a problem for 2.0.x. Even in
2.1.x it's not perfect. 

One of my current front burner projects is to add the capability to
set a locally administered mac address. This requires a reorganization
of the initialization and open code (nothing is ever as simple as it
looks), which is where the source of the problem lies. I'll see if I
can't work all of the bugs out of it when I rework that code. In the
meantime, Mike's suggestion is a good one. You'll probably get better
results if you can unload and reload the driver as a module.  

Paul

Dieter Raith writes:
 > I have a problem, which I suspect to a Novell FS attached
 > via TR. I get plenty of cron jobs hanging around an the
 > system is unacessible as it cannot fork anymore. Only
 > the console terminal is functional. The DF command does
 > never return. When I did a ifconfig tr0 down all problems
 > vanished. Unfortunately the TR does not come back to the
 > ring on on an ifconfig tr0 up. So I have to reboot the
 > system. I compiled the TR driver into the kernel! I cannot
 > believe that this works as designed. Can anybody comment
 > this behaviour? Should I use module technique to assure
 > that I can bring the TR adapter back into the ring?
 > 
 > Thanks
 > 
 > Dieter