Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()

Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()

[Thomas Hood]

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"

[PATCH] fix bad dev->refcnt in unregister_netdevice was Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()

[Arnaldo Carvalho de Melo]

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

--- linux-2.4.2-pre4/net/ipx/af_ipx.c	Mon Feb 19 06:00:21 2001
+++ linux-2.4.2-pre4.acme/net/ipx/af_ipx.c	Mon Feb 19 12:15:27 2001
@@ -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 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"
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()

[Thomas Hood]

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

Should isa-pnp utilize the PnP BIOS?

[Thomas Hood]

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 '@'

Re: Should isa-pnp utilize the PnP BIOS?

[Jeremy Jackson]

Thomas Hood wrote:

> 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

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...)

>
> 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?

Re: Should isa-pnp utilize the PnP BIOS?

[Jonathan Morton]

>> 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
>
>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:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

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-----

Re: Should isa-pnp utilize the PnP BIOS?

[Thomas Hood]

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

> 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 '@'

[BUG] "unregister_netdevice: waiting for eth0 to become free. Usage count = 2"

[Thomas Hood]

>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

Multiple apm resume events

[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_" -> "@"