Summary:ASTERISK-03684: zaptel.ko causes kernel panic when unloading
Reporter:trepalium (trepalium)Labels:
Date Opened:2005-03-15 23:45:59.000-0600Date Closed:2008-06-07 10:50:22
Versions:Frequency of
Environment:Attachments:( 0) CAPTURE.TXT
Description:When rebooting my system, I started running across this kernel panic whenever the system shuts down.  I've included a log from the shutdown process showing the kernel panic.  I am running zaptel 1.0.6 on Fedora Core 3 with Linux kernel 2.6.10-1.770_FC3.


I realize that there's a problem with the shutdown, namely my init scripts are not unloading ztdummy, and not properly killing asterisk before unloading zaptel.  Regardless of that, I don't believe a kernel panic should happen for a configuration problem like this.
Comments:By: trepalium (trepalium) 2005-03-15 23:50:16.000-0600

Oops.  I'm running a release version, not CVS stable.

By: Russell Bryant (russell) 2005-03-16 01:21:50.000-0600

Please pursue this issue through Digium technical support.  support@digium.com

By: trepalium (trepalium) 2005-03-16 23:36:28.000-0600

I believe this is a bug.  I have researched this further and I believe the problem is, under the 2.6 kernel, there appears to be no reference counting for the individual zaptel modules (there certainly isn't any for wcfxo.ko).  This means, a module can be removed while zaptel.ko still has a reference to it, causing the Oops and eventual panic I experienced.  From what I understand, zaptel.ko should be calling try_module_get() and module_put() on the zap drivers to update the modules' reference counts, but frankly, implementing this is probably quite a bit over my head, especially since it would probably require modifying the zt_span struct to pass around a module pointer.  I have no idea what I might break if I try.

I know about my configuration problems, and I will correct them myself.  However, I would like to see refcounting working properly, too, to avoid a silly config problem (like this one) from crashing my system.

This is not an important bug that must be fixed immediately or anything, just something that should be fixed eventually.  Downgrade the bug if you want, but I don't think it should be closed.

By: petersv (petersv) 2005-03-17 01:15:56.000-0600

Problems with the zaptel cards or their drivers are not handled here. Digium technical support handles such problems. The support is included in the price paid for their products. This is not related to the importancce of the problem, but rather with which component is involved.

By: Matt O'Gorman (mogorman) 2005-03-17 07:44:30.000-0600

If he is running ztdummy.... I don't think he purchased Digium hardware. just a hunch

By: trepalium (trepalium) 2005-03-17 21:33:57.000-0600

I used a knock-off X100P in that system, however, I can also reproduce this oops/panic in another system using ztd-eth.  It appears to only affect zap drivers that provide a span to asterisk, so ztdummy doesn't seem to trigger it.  If this is still Digium's responsibility to fix, close the bug, and I'll report it to Digium after I get some hardware purchased.

By: Mark Spencer (markster) 2005-03-20 23:19:23.000-0600

I went ahead and fixed it in zaptel for our currently shipping stuff (yah, it's an ugly fix, i know...  Is it really worth increasing the size of zt_span for though to do it right?) If anyone wants to fix up the rest of the drivers they can and submit a new patch.  Oh yah, and buy something or something...

By: Russell Bryant (russell) 2005-03-31 17:04:00.000-0600

fixed in 1.0

By: Digium Subversion (svnbot) 2008-06-07 10:50:09

Repository: dahdi
Revision: 607

U   trunk/wct4xxp.c
U   trunk/wctdm.c
U   trunk/wcte11xp.c

r607 | markster | 2008-06-07 10:50:08 -0500 (Sat, 07 Jun 2008) | 2 lines

Add use counts to currently shipping stuff (bug ASTERISK-3684):



By: Digium Subversion (svnbot) 2008-06-07 10:50:22

Repository: dahdi
Revision: 610

U   branches/v1-0/wcfxs.c
U   branches/v1-0/wct4xxp.c
U   branches/v1-0/wcte11xp.c

r610 | russell | 2008-06-07 10:50:21 -0500 (Sat, 07 Jun 2008) | 2 lines

add use counts to prevent kernel panics (bug ASTERISK-3684)