>Groan< The "unregister_netdevice" bug is back. I haven't been able to do extensive testing, but I have just encountered the message unregister_netdevice: waiting for eth0 to become free. Usage count = 2 again. Once it starts, it repeats ad infinitum, once per second. The message starts spewing when I do a "cardctl eject" on a Xircom CEM56 modem/ethernet card (driven by xirc2ps_cs.o, serial.o) which was previously configured using DHCP with IPX enabled. The cardctl eject never completes and the OS will not shut down completely; it hangs at the point where it tries to de-configure network interfaces. Disabling IPX cured the problem for me the next time I tried. I am running 2.4.6-ac2, but the bug could have been reintroduced a while back. I haven't been using Ethernet for a couple of months. Well, I'm no expert on the networking code, so I'll just suggest some things that look odd to me. I'm looking in net/ipx/af_ipx.c, tracing through ipxitf_create(). This function exits with dev->refcnt incremented ... unless something goes wrong, in which case the function exits through via a goto to "out_dev" which decrements the refcnt again. Likewise, ipxitf_auto_create() increments the dev refcnt (by doing a dev_hold(dev)) if all goes well. However when I look at ipxitf_delete(), which I presume ought to undo what the *_create() functions do, I see nothing that decrements the refcnt. If this is where the bug lies then I would suggest that the functions be documented to say that "this function exits with the refcnt incremented if blah blah blah", etc. As an aside, I notice that __dev_get_by_name() is called from ipxitf_delete(). A comment preceding __dev_get_by_name() in net/core/dev.c says that this function should be called "under RTNL semaphore or @dev_base_lock", but it is actually called under the ipx_interfaces_lock. Is this okay? __dev_get_by_name() is also called from within ipxitf_ioctl(), seemingly under no locks at all. Also okay? Thomas Hood - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
