In 2.6.2 I introduced an error in (41639330a "wctdm24xxp: Eliminate chance for
channel to be stuck in RED alarm.") which would get an FXO stuck in detecting an
ONHOOK event from the remote side. An FXO port could go into the
BATTERY_DEBOUNCING_LOST_ALARM state and then back to the BATTERY_PRESENT state
without sending the dahdi_hooksig up to Asterisk. Therefore, Asterisk would
never detect the state changes needed for a remote side disconnect.
This change adds two more states, BATTERY_DEBOUNCING_PRESENT_FROM_LOST_ALARM and
BATTERY_DEBOUNCING_LOST_FROM_PRESENT_ALARM so that the state machine does not
miss any needed transitions when going back to BATTERY_PRESENT or BATTERY_LOST
regardless of why the debounce was started.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
(cherry picked from commit 244f621eb1)
If a user switches linemode with sysfs, the VPM would never switch the
companding mode to alaw, and the result would be extreme static on all channels
of the span when the VPM is enabeld.
Now if the deflaw of the span has changed when an echocan is created, the
companding mode of the VPM channel is changed.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Conflicts:
drivers/dahdi/wct4xxp/base.c
Not configuring all the spans on an octal card can result in some of the
spans not working in clear channel modes.
Now ensure that all spans receive a default configuration regardless how
they are configured from user space.
Internal-Issue-ID: DAHLIN-289
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10728 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Fixes up the kbuild to work with compiling OSLEC from the kernel source. See
HOWTO here: http://forums.digium.com/viewtopic.php?t=67164
Internal-Issue-ID: DAHLIN-317
Reported-By: Vladimir Mikhelson
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
(cherry picked from commit f09daed735)
Do not want to accidentally change the tag "very_cool" to "ery_cool".
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit 7714d5d94e)
Quote: "It's a change. People hate change"
Make the version string say something like 2.6.2 instead of v2.6.2.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit 9b0d19c054)
Also, if there is no other version information use the directory name. Downloads
from gitweb will include the sha information in the build and otherwise a user
could locate the source directory via the embedded version information. I
believe this is better than an empty string.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit 37371f19e9)
The __dev* directives and functions were removed in 3.8, as they
are no-ops. We still have use of them for older versions, thus
we should define them (as noops) if they don't exist.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
There was a code patch where it was possible to get stuck in RED ALARM on a
channel when debouncing the battery states. The state transitions would look
like this:
BATTERY_PRESENT -> BATTERY_DEBOUNCING_LOST -> BATTERY_DEBOUNCING_LOST_ALARM --
(send alarm up to asterisk) --> BATTERY_LOST -> BATTERY_DEBOUNCING_PRESENT ->
BATTERY_DEBOUNCING_PRESENT_ALARM -> BATTERY_DEBOUNCING_LOST -> BATTERY_PRESENT
In the above sequence there was never any transition from
BATTERY_DEBOUNCING_PRESENT_ALARM to BATTERY_PRESENT so the alarm to Asterisk was
never cleared and the channel stayed stuck.
Now when you loose battery when in the BATTERY_DEBOUNCING_PRESENT_ALARM go all
the way back to the BATTERY_LOST state instead of the BATTERY_DEBOUNCING_LOST
state so that all the events are properly sent up.
This fixes a regression introduced in 2.6.0 with commit (r10169 "wctdm24xxp: Use
interval for debouncing FXO battery." 874b76bd22).
Internal-Issue-ID: DAHDI-1019
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit 8bf0434896)
The logic to check for battery lost and battery present were using different
time bases. One was using jiffies and the other was using framecount. Since
framecount is always in milliseconds, let's use that to stay consistent.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit a6be603590)
hfc_decode_st_state() will be called from interrupt context when the debug flag
is set to 32. Therefore, must use GFP_ATOMIC when allocating memory.
Only affects the wcb4xxp driver when called with particular debug flags set.
Internal-Issue-ID: DAHLIN-314
Reported-by: Gerald Schnabel
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit 85e6cdde83)
The driver iterates through all the spans on a given device during assignment,
checking for unassigned spans, but it was erroneously testing the span on which
assigned was called.
This just removes some unexpected behavior and provides a slight performance
increase on load and does not impact the functionality of the driver as far as
I'm aware.
Reported-by: Doug Bailey <dbailey@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit 9de213b104)
Since r10290 "wct4xxp: Add support for TE820 and VPMOCT256." [1],
the TONEDETECT ioctl was not calculating the VPM channel correctly
on non TE820 cards. This fixes a regression first introduced in
2.6.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10290
Internal-Issue-ID: DAHLIN-302
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10733 a0bf4364-ded3-4de4-8d8a-66a801d63aff
(cherry picked from commit abad4b4479)
This fixes a regression introduced in commit r10186 "wctdm24xxp: Use time
interval for debouncing FXO ring detect." [1] which was first released in
DAHDI-Linux 2.6.0. This only affects users with analog trunks whose providers do
not present 4 polarity reversals on the ring signals. The reporter of this issue
is based in South Africa.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10168
In prior versions, the ring detector did not check for polarity reversals, only
the presence of ringing voltage unless fwringdetect or neonmwi_monitor mode was
set, and even when one of those modes were set, the driver only needed two
reversals to validate a ring. This commit allows the driver to always stay in
fwringdetect mode but restores the requirement for only two reversals.
Also included in this commit is a change to ensure that ringing is not reported
when debouncing lost battery which can happen when voltage is swinging through
0.
Reported-and-Tested-by: Jaco Kroon <jaco@uls.co.za>
Internal-Issue-ID: DAHLIN-298
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10719 a0bf4364-ded3-4de4-8d8a-66a801d63aff
(cherry picked from commit 84e70cdac5)
Without digging into the specifics, it looks like Red Hat Linux 5.9
removed the hex_asc definition that was previously used to determine
if the bool definition was backported.
We can simply use the RHEL_RELEASE_CODE now since we do not support any
releases before the 5 series now.
Reported-By: Vladimir Mikhelson
Internal-Issue-ID: DAHLIN-312
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
(cherry picked from commit da0aa6f231)
Conflicts:
drivers/dahdi/xpp/xdefs.h
Allows 'git status' command to better show untracked files which one may be
interested in.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
(cherry picked from commit d889fb39d3)
This fixes an (embarrassing) error in t1_check_sigbits in the previous commit
where I was writing pass the end of an array on the stack.
Now instead of using an array on the stack, of which all elements were not used,
the pending commands are now stored on a list. I also removed the automatic free
of commands from __t1_getresults and now the function that allocated the command
now frees them.
I believe this will be less error-prone going forward.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10700
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10707 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The frequency that the RBS registers were polled was too slow to catch the pulse
dialing digits. The result was that often times dahdi would generate WINK events
instead of PULSEDIGIT events.
This speeds up the rate at which the registers are checked from 100ms to 33ms
and also makes the process of checking the registers quicker by queing up all
the reads at once.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10699
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10706 a0bf4364-ded3-4de4-8d8a-66a801d63aff
To enable J1 mode previously one would configure the card in T1 mode and then
set the j1mode module parameter. Now "modprobe wcte12xp default_linemode=j1"
will work like the other linemodes globally for all cards manged by this driver.
J1 can also be set on a card-by-card basis in sysfs.
Also move pr_fmt to top of file so pr_xxx macros print the module name as
intended.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10696
Conflicts:
drivers/dahdi/wcte12xp/base.c
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10698 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* UMH_WAIT_PROC semantics (and value) was changed from enum to
a bitmask (via #define)
* This constant was missing from kernels older than 2.6.23
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10694 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Previous commit (r10651) included an incorrect version. Including full message
from that commit for the description.
rev. 10502 of the FPGA firmware for the new E-Main rev. 4 fixes a potential
issue when used on Xorcom XR1000 systems: an issue with the power supply may
cause the unit to reset.
Note that there is no issue with previous models, with a normal setup of an
Astribank, or other XRx000 systems.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10652
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10654 a0bf4364-ded3-4de4-8d8a-66a801d63aff
rev. 10502 of the FPGA firmware for the new E-Main rev. 4 fixes a potential
issue when used on Xorcom XR1000 systems: an issue with the power supply may
cause the unit to reset.
Note that there is no issue with previous models, with a normal setup of an
Astribank, or other XRx000 systems.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10649
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10651 a0bf4364-ded3-4de4-8d8a-66a801d63aff
It appears that some kernel configurations do not include timer.h in any of
the include files that are included by dahdi_dummy. The timer_structs are
defined in timer.h and not time.h, so this change is correct even though I
never could find a configuation myself that actually failed to compile.
This has negligible impact since dahdi_dummy is not compiled by default.
Internal-Issue-ID: DAHLIN-185
Reported-by: Steve Murphy
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10640
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10644 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Minor change to follow generally recommended practice. Prevents new packets
from being queued up for devices when they are about to be cleaned up. Also
clean up any skbs that may still be on the queue after unloading.
Also closes anoter potential kernel oops on module unload. It was possible to
delete the private structure while the master span process was running. The
result was an attempt to page memory from interrupt context.
Make sure that the pvt function is set and cleared under the zlock. Also do
not assume that the pvt pointer is valid in ztdeth_transmit.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10626
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10631 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The board drivers are the ones calling the unregister function, and
therefore we do not need to worry about them unloading while calling the
destroy callback.
When destroying spans with the ioctl, replace __module_get() with
try_module_get. This avoids hitting a BUG in module_get on kernel versions <
2.6.29.
ALSO move the call to try_module_get out of the dahdi_dynamic_release function
and into destroy. This way if the destroy callback isn't called because the
dynamic driver is unloading the dynamic device can be left on the list to be
cleaned up by the dahdi_dynamic_unregister_driver function().
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10624
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10629 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Instead of registering a function pointer, register a dahdi_dynamic_ops
structure that contains the owner as well as the ioctl callback. This way
dahdi.ko can bump up the reference count on dahdi_dynamic.ko before calling
the ioctl callback.
Also, use the registration mutex to guard against the module being unloaded
between the time the structure pointer was checked, and the module reference
is taken.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10623
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10628 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Enables the driver to update firmware on systems that do not have the firmware
loader configured / enabled (Linux config option CONFIG_FW_LOADER). Compiling
the firmware into the driver increase the memory footprint by around ~440K.
Internal-Issue-ID: DAHDI-963
Reported-and-Tested-by: Guenther Kelleter
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10618
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10620 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The driver makes the assumption that interrupts are disabled but this cannot
be guaranteed. We'll explicity disable interrupts on the local processor while
the interrupt handler is running.
This eliminates the "IRQF_DISABLED is not guaranteed on shared IRQs" warning
when loading the driver.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10589
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10593 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Resolves the follwing build error:
drivers/dahdi/dahdi_dynamic_eth.c: In function ‘ztdeth_exit’:
drivers/dahdi/dahdi_dynamic_eth.c:448: error: implicit declaration of function ‘cancel_work_sync’
RHEL kernel versions 2.6.18-238 (5.6) and greater had cancel_work_sync()
backported which is what I did my original smoke test on.
Reported-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10588
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10592 a0bf4364-ded3-4de4-8d8a-66a801d63aff
It was possible after a dynamic ethernet span was created for a packet to come
in before the dahdi_span was fully initialized. The result would be a NULL
pointer dereference. Now just discard any packets that might come in during
this time window.
Internal-Issue-ID: DAHLIN-280
Reported-by: Pavel Selivanov
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10587
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10591 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Adds a new parameter, 'lower_ringing_noise', to module xpd_fxs.
* Makes the "power-down" behaviour that was added
in upstream svn r10478, switchable in runtime.
* By default (false), makes the vbat_h behave like it did
before the power-down change.
- I.e: vbat_h is held throughout the ringing period (during
both ring-up/ring-down)
- So this patch revert part of r10478
* When switched to true, activate the "power-down" behaviour.
- I.e: vbat_h follows the ring-up/ring-down.
- This behaviour lowers the noise caused by group ringing of
FXS channels in the same unit, but causes problems with CallerID.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10574
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10576 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* In do_chan_power() make vbat_h changes atomic.
* As a result we can ignore duplicate requests.
This will allow cleaner logic in the next commit.
* Added proper debug messages.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10573
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10575 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This in conjunction with r10449 "A parent-less device should not crash dahdi",
this allows dahdi_dynamic spans to work post the dahdi_devices changes in
2.6.0.
The full address of the device is not used since kernels prior to 2.6.31 limit
the length of a devicename to 20 characters. The full address of the device
can be pulled out of the "hardware_id" and "type" fields of the span.
This patch is just to get things working again. dahdi_dynamic devices *may*
still have issues if the auto_assign_spans module parameter is 0.
Internal-Issue-ID: DAHLIN-280
Reported-by: Pavel Selivanov
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10563
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10571 a0bf4364-ded3-4de4-8d8a-66a801d63aff
