to deal with bad dev->refcnt in unregister_netdevice()

Update on the "unregister_netdevice" bug ...

Arnaldo Carvalho de Melo has been valiantly trying in his scarce free time to find the cause. I haven't been able to hunt effectively because I don't really understand the networking code; however I have been experimenting to see what are the exact conditions under which the failure occurs. I modified my kernel to print dev->refcnt in /proc/net/dev so that I could see what the refcnt of eth0 is at any given moment. One of the more interesting experiment logs is appended below.

Experimentation seems to show
1) It happens when ipx is used, specifically when
auto_interface=on and auto_primary=on
2) It happens only or especially when using DHCP
3) It happens only to PCMCIA ethernet cards

Thomas Hood
jdthood_AT_yahoo.co.uk

Linux 2.4.1-ac10
/etc/pcmcia/network disabled with an 'exit 0'

command                         refcnt  message
-------                         ------  -------
(boot)                               0
(I inserted Xircom card)             1
ifconfig eth0 up                     2
ipx_configure --auto_interface=on --auto_primary=on    2
ifconfig eth0 down                   0  "Freeing alive device c127ac8c, eth0"
cardctl eject                        ?  "unregister_netdevice: waiting for

eth0 to become free. Usage count = 0
Message from syslogd@thanatos at Wed Feb 14 12:51:26 2001 ... thanatos kernel: unregister_netdevice: waiting for eth0 to become free. Usage count = 0"

Hi,

Found it, here's the patch, please apply. Not using auto creation
of interfaces we're using dev_get_by_name, that does a dev_hold, on ipx_auto_create we're not doing it, duh 8) Tested with several combinhations of unpluging pcmcia card, just ifconfig eth0 down, etc

- Arnaldo

@@ -1194,6 +1194,7 @@
 		atomic_set(&intrfc->refcnt, 1);
 		MOD_INC_USE_COUNT;
 		ipxitf_insert(intrfc);
+		dev_hold(dev);
 	}
 
 	return intrfc;

Em Thu, Feb 15, 2001 at 04:13:01PM -0500, Thomas Hood escreveu:

Update on the "unregister_netdevice" bug ...

Arnaldo Carvalho de Melo found one bug but there remains another one that makes the dev->refcnt too high instead of too low.

To be continued ...

Thomas

Hello, l-k.

On my ThinkPad 600, The ThinkPad PnP BIOS configures all PnP devices at boot time.

If I load the isa-pnp.o driver it never detects any ISA PnP
devices: it says "isapnp: No Plug & Play device found". This is unfortunate, because it means that device drivers can't find out from isa-pnp where the devices are.

David Hinds's pcmcia-cs package contains driver code that interfaces with the PnP BIOS. With it, one can list the resource usage of ISA PnP devices (serial and parallel ports, sound chip, etc.) and set them, using the "lspnp" and "setpnp" commands.

Would it not be useful if the isa-pnp driver would fall back to utilizing the PnP BIOS (if possible) in order to read and change ISA PnP device configurations when it can't do this itself? If so, could this perhaps be done by bringing the Hinds PnP BIOS driver into the kernel and interfacing isa-pnp to it?

Thomas Hood
jdthood_AT_yahoo.co.uk <- Change '_AT_' to '@'

I would find this EXTREMELY usefull... my Compaq laptop's hot-dock with power eject will only work if Linux uses PnP BIOS's insert/eject methods.

I saw some code in early 2.3 that would talk to bios, i still have a tarball, but it seems 2.4 only does hardware banging (best in *most* cases...)

There are some desktop m/boards that don't seem to respond to the kernel-mode ISA-PnP at the moment, too. Particularly my Abit KT7 - I have to use user-mode ISA-PnP for it to pick up my nice SB AWE-64. This needs fixing somehow, and maybe looking at the PnP BIOS stuff is the right way.

--------------------------------------------------------------

from:     Jonathan "Chromatix" Morton
mail:     [email protected]  (not for attachments)
big-mail: [email protected]
uni-mail: [email protected]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----

Okay, a couple of people have responded positively to this suggestion. The next question is, how should it be implemented?

How 'bout:

$ cd pcmcia-cs/modules
$ cp pnp_bios.c pnp_proc.c pnp_rsrc.c /usr/src/linux/2.4.2a/drivers/pnp
$ cd ../include/linux
$ cp pnp_bios.h pnp_resource.h /usr/src/linux/2.4.2a/include/linux
Edit makefiles
Edit isapnp.c to include new global flag "isapnp_usepnpbios",
  a MODULE_PARM, which each isapnp function checks at entry.
  If the flag is set then: in the case of "low-level" functions,
  return immediately; in the case of "high-level" functions, call
  appropriate pnp_bios functions to perform the task; in the case
  of isapnp_init(), just check isapnp_disabled and exit.  isapnp's
  /proc interface would not be supported.  Presumably
  inter_module_get_request() would be used to call the isapnp-bios
  routines.

Comments? (Go easy on me; I'm a newbie at kernel hacking.)

Thomas

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

Machine:   ThinkPad 600
Kernel:    2.4.7-ac1

When I resume the machine the apmd_proxy script handles *two* "resume suspend" events. The apm driver ought to filter multiple resume events.

About a year ago I had this and a couple other problems with the apm driver. I submitted patches to the maintainer, Stephen Rothwell, but he was MIA. "Too busy", he said. I see he is still listed as the maintainer. Is there someone else who is acting as the de facto maintainer or should I just post patches to this list?

Thomas Hood
Please cc: jdthood_AT_yahoo.co.uk with "_AT_" -> "@"