Summary:	ASTERISK-03899: [patch] Don't abort reconfiguration of other channels if we encounter a connected HDLC device
Reporter:	Tilghman Lesher (tilghman)	Labels:
Date Opened:	2005-04-08 15:57:46	Date Closed:	2005-09-28 22:35:18
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20050408__dont_abort_nethdlc.diff.txt
Description:	Currently, on any machine which uses HDLC for its network device, we cannot reconfigure other channels (like adding PRI voice channels) without rebooting the machine.  This patch allows us to continue to configure other Zaptel channels, even when there's a nethdlc device on the span.
Comments:	By: Mark Spencer (markster) 2005-04-09 14:09:56 Presumably ztcfg should at least spit our a warning that it didn't recover the interface.  Why couldn't you just take down the nethdlc before running ztcfg anyway? By: Tilghman Lesher (tilghman) 2005-04-09 15:45:30 Because taking down the hdlc0 device results in a kernel NULL pointer dereference, which panics the machine. By: Mark Spencer (markster) 2005-04-10 01:06:59 That would appear to me to be the more significant bug, what kernel are you using?  Are you doing "ifdown hdlc0" ? By: Tilghman Lesher (tilghman) 2005-04-10 10:27:26 2.6.8.1, and 'ifdown hdlc0' is exactly the command that causes the panic.  Yes, 'ifdown pvc0' is done immediately beforehand. On the particular machine on which this is a problem, we've gotten away at shutdown with aliasing out these two commands, such that a reboot does not produce a kernel panic. By: Mark Spencer (markster) 2005-04-10 11:26:24 Does the panic hard lock (i.e. it's within an interrupt handler)? By: Tilghman Lesher (tilghman) 2005-04-10 12:55:52 It hardlocks that console, but other consoles still respond. By: Mark Spencer (markster) 2005-04-10 21:19:41 Have you done any diagnostic to see where the problem might occur? By: Tilghman Lesher (tilghman) 2005-04-10 21:22:06 No, I don't have an understanding of the HDLC kernel API enough to perform any diagnosis. By: Michael Jerris (mikej) 2005-05-03 07:54:46 Is there anything else that can be done on this?  Are we holding up a useful patch due to the root cause issue?  Isn't this a useful patch regardless? By: rephorm (rephorm) 2005-06-17 14:07:16 I have this same issue on a centos 4 box. The kernel is RHEL-2.6.9-i686 recompiled with wan support (all modules under wan enabled). is there any other information i can provide to aid in debugging? By: Tilghman Lesher (tilghman) 2005-06-17 14:38:12 There is another scenario that would make this patch helpful.  Consider a machine configured at a remote site with X channels configured as PRI and Y channels configured for HDLC, where X + Y is less than 23.  As a remote admin, you are connected into the machine via the HDLC device, and you want to increase the number of PRI channels.  This cannot be done without rebooting the machine. Hence, this patch has application OUTSIDE of the kernel panic issue and is therefore still useful, even if/when that bug is fixed.  What may even be more useful, if it could happen, would be the ability to configure or reconfigure channels which are currently not in use.  However, since HDLC is pretty much the only channel which may be important to keep up (either because of the kernel panic or because you're connected via the hdlc device), this patch should be an acceptable first step. By: Kevin P. Fleming (kpfleming) 2005-09-28 22:34:53 This has been fixed by modifying ztcfg to only reconfigure channels that have changed since their last configuration was done (unless a force parameter is specified). This won't cure the kernel panic on HDLC shutdown problem (which Mark is working on), but it will take care of the posted issue.