It was reported that for VLAN interfaces, failing to release this reference
count will prevent a system from rebooting properly, resulting in the need to
power cycle.
Reported-by: Assen Totin
Internal-Issue-ID: DAHLIN-343
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Latest Astribank firmware (as of Rev. 11426 also supports some newer
hardware types, which will have the ID 203. Anyone installing this newer
version will now have 203 as an alias, but older versions will not have
it.
New firmware that includes a better way to identify hardware modules
type that does not require multiplexers.
This is firmware file FPGA_1161.201.hex rev. 11426.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Kernel version 3.16+, since upstream commit (7f7f25e82d54870d "replace checking
for ->read/->aio_read presence with check in ->f_mode" )[1], does not like it
when dahdi changes the set of allowed file operations on a file descriptor
outside of the context of an open() system call.
DAHDI changes the available file operations when a channel is opened by first
opening /dev/dahdi/channel and then calling the DAHDI_SPECIFY ioctl to bind it
to a particular DAHDI channel. Until DAHDI_SPECIFY is called there weren't any
read()/write() callbacks implemented and therefore after the initial open, the
kernel was setting not setting FMODE_CAN_{WRITE,READ} on the file descriptor
indicating that those operations were not allowed.
Now define empty shell functions on the general dahdi_fops so the vfs layer will
not mark a file descriptor as unwritteable or unreadable on open.
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f7f25e82d54870df24d415a7007fbd327da027b
Internal-Issue-ID: DAHLIN-340
Reported-and-tested-by: Thomas B. Clark
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The logic on ENABLE_TASKELETS compiler flag was inverted causing an oops on
normal dahdi_cfg of a dynamic span.
Issue-id: https://issues.asterisk.org/jira/browse/DAHLIN-328
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
A fresh modprobe and dahdi_cfg would cause a temporary green alarm state on the
spans for a second while the alarm debounced into RED. New logic keeps the
spans alarm state as NONE during the unconfigured state, but sets the alarm
state to RED after the framer reset in the startup logic.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
A fresh modprobe and dahdi_cfg would cause a temporary green alarm state on the
driver for a second while the alarm debounced into RED. New logic keeps the
spans alarm state as NONE during the unconfigured state, but sets the alarm
state to RED after the framer reset in the startup logic.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
The firmware/Makefile missed a line that added the firmware for the TE436 to the
download list.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Adds driver support for Digium's new te436 and te236 quad and dual span T1/E1 cards.
[removed whitespace at end of line]
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
If dahdi_span_ops.spanconfig is called multiple times in a row (like when
running dahdi_cfg; dahdi_cfg ) the tx signaling bits would go through a spurious
state that some far side devices would respond to.
Now, if the dahdi_span_ops.spanconfig callback is called, and the configuration
matches the existing configuration, we will not touch the framer.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If dahdi_span_ops.spanconfig is called multiple times in a row (like when
running dahdi_cfg; dahdi_cfg ) the tx signaling bits would go through a spurious
state that some far side devices would respond to.
Now, if the dahdi_span_ops.spanconfig callback is called, and the configuration
matches the existing configuration, we will not touch the framer.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If a channel is currently playing a tone when the tone zone is updated, the
existing tone zone could be freed while the channel keeps a reference to the
current tone (curtone) that points into the freed zone.
If the newly freed tone is then modified, there was a window where it was
possible to corrupt 'struct dahdi_chan' (by overrunning swritechunk[])
resulting in a "BUG: unable to handle kernel paging request at virtual address"
panic in the context of __dahdi_transmit_chunk().
Reported-and-Tested-by: Matt Behrens <matt@zigg.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This fixes a long standing issue where, for CAS signaling, the RX bits were
sometimes misreported after span configuration before the first detected state
change.
The logic in the wct4xxp driver now matches that in the wcte43x driver and
wcte13xp drivers. The wcte12xp driver always polls the sigbits due to how
voicebus works and is not affected by this.
Internal-Issue-ID: DAHDI-1081
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This is the same change for the wcte13xp driver but applied to the other
xbus-based digital card.
If dahdi_cfg set the DAHDI_CONFIG_NOTOPEN setting on the span, which it does
when the "yellow" flag is added to the span config line, then it was possible
for the span to get stuck with DAHDI_ALARM_NOTOPEN (NOP).
This is because the driver only updates the alarm state when the framer reports
that the span alarm has changed. Therefore, unless the framer goes through an
alarm transition, the fact that channels are opened was never noticed by alarm
handling routine.
Now check the alarm state directly when the first channel is opened, and the
last channel is closed.
Internal-Issue-ID: DAHDI-1103
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This will facilitate adding another flag for open channels on a span without
needing to add a lock on the span, or taking the global lock. Currently the span
flags are protected by the global reglock. This is not longer required.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If dahdi_cfg set the DAHDI_CONFIG_NOTOPEN setting on the span, which it does
when the "yellow" flag is added to the span config line, then it was possible
for the span to get stuck with DAHDI_ALARM_NOTOPEN (NOP).
This is because the wcte13xp driver only updates the alarm state when the framer
reports that the span alarm has changed. Therefore, unless the framer goes
through an alarm transition, the fact that channels are opened was never noticed
by alarm handling routine.
Now check the alarm state directly when the first channel is opened, and the
last channel is closed.
Internal-Issue-ID: DAHDI-1103
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This makes the open symmetrical with the close. It is also considered good
practice to not call through callbacks with spinlocks held.
I modified all the drivers where I could not tell whether it was necessary to
hold the chan->lock with interrupts disabled to simply take the lock inside the
callback.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixes inability to reliably get CAS (robbed-bits) when using AMI line encoding
on the TE820 card.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
When originally implemented, the octasic calls where protected by the big kernel
lock. This change now allows the octasic library to control it's synchronization
as originally intended.
It would still be worthwhile to completely make the oct612x library
kernel-compliant.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
I am primarily making this change in order that the oct612x API can use a mutex as
a synchronization primitive. Mutexes can only be aquired in process context and
the wct4xxp driver calls the Oct61000InterruptServiceRoutine (which grabs a
serialization object) when tone detection is enabled.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This is never accessed or modified in interrupt context. This closes a potential
race if the echocan is being changed on a channel while enabling disabling is
hapening on another thread.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This closes a reference and memory leak when multiple CPUs are enabling echocan
on a single channel in parallel.
The essential problem is that the call to try_module_get() is not serialized.
Two separate threads can come into ioctl_echocan() on the same channel, they
coordinate via the dahdi_chan.lock to release any current echocan, but then both
create a new echocan state, bump the reference on the module, and the last one
through will actually attach the new state to the channel. The earlier reference
/ memory is leaked.
I tried to conceive of a way to fix this leak without adding a new lock, but the
choices where calling throught the function pointers with dahdi_chan.lock.
Otherwise I needed to change the semantics of echocan_create /free which would
ripple through the hardware echocan modules.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Since commit (e10f740 "wctc4xxp: Service tx ring in interrupt handler."), it
was possible to deadlock the system if the interrupt fires while the
watchdog function is running in the context of the system timer.
This was reported by lockdep.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Now use a continue after the check for cmd->timeout. This change is because I
need to make another change but the deep indentation level would make it hard to
stay within the 80 column limit.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
These were left over from recent developments and are not used by the driver.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This is a limitation of the DTE firmware that normally would result in dropped
packets on the firmware. If the driver knows it is going to be dropped it should
drop it.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The driver will now automatically reload the firmware when there are no open
channels if the firmware reports a fatal error. If the firmware reports an
error, but it was not fatal, it will leave things running and try to reload when
all channels are shut down. The driver will also halt channel processing and
reload the firmware if a channel ever failed to be created.
The thought is that if the DTE reports a non-fatal error, I cannot be certain
what the state is, and it should be reset when possible without impacting
otherwise functioning card. If there are problems, presumably all users would
hang up and the driver will then reload the firmware.
If the error is fatal, then all processing is halted to encourage everyone to
hang up. The card is probably not working at this point anyway, so there is no
point in trying to communicate with it.
Also included in this change is a compile-time selectable debug sysfs attribute
that will allow forcing an alert condition for testing the recovery.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The interrupt handler was not schedulding the deferred processing routine when
there was packets to process. I did not test the actual master branch after
editing for checkpatch compliance. Sorry.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
If the host system sends to many packets to the DTE to process, the on-card
memory can be exhausted which will result in an out of memory alert. In commit
2ac2338247, the driver will halt all communication
with the card and request a reload if any alert is received.
Now the driver will silently drop any "burst" traffic that was sent to the
transcoder as opposed to expecting the firmware to do it. There is currently a
limit of 640 samples (80ms of audio) in flight to the firmware at any one time
allowed.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This helps to keep the tx descriptor ring at max capacity when the system is
otherwise loaded. Now ready packets are moved from cmd_list to the transmit
descriptor ring directly in the interrupt handler and not when the deferred
function runs.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
I do not have any evidence that this made a difference, but hopefully it will
clear things up for people in the future who might be wondering why the
timestamp does not increase with the number of samples actually sent.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The polling interval was not fast enough to keep the tx ring full on a loaded
card. This fixes a regression introduced in commits
ba05e31c8a and
354d88cd41.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
When switching to polling mode it was possible that we would mask off the
receive complete interrupt until the next timer fired. Now go ahead and handle
anything we know how to handle regardless of the current mask.
Also, no need to update the reg local anymore since it isn't used to ack any
interrupts. We now always ack all the interrupts first and inspect them all.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
re-organize calls so worker_reset() isn't called twice
(was called from xbus_disconnect() and worker_destroy())
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* Maintain a "shutting_down" flag per-xbus
* Use it to prevent xbus dereferencing (via xbus_get()/xbus_put())
during an xbus shutdown.
* Also, remove xbus from global array earlier.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
waitfor_xpds xbus sysfs file should not take an xbus refcount:
* It is called from sysfs which maintain its own device refcount.
* If put_xbus() calls xbus_destroy() than down the call chain it will
try to release an object that is held by sysfs.
* This will create a deadlock.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
1) Enabling multiple csm_encaps channel commands in a single packet.
2) Sending commands to separate channels in parallel.
This reduces the time waiting for the responses to the commands and brings in
the channel setup from 50ms to under 10ms.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
interruptible_sleep_on_timeout() has been deprecated for awhile and was finally
removed in Linux 3.15. Since interruptible_sleep_on_timeout() uses jiffies for
the delay, I assumed that each jiffy equated to 10ms given the age of the
driver.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Some architectures, like arm, do not automatically pull in the definitions for
kzalloc and friends. This allows DAHDI to build on those platforms.
Originally reported to the asterisk-users mailing list here
http://lists.digium.com/pipermail/asterisk-users/2014-February/282338.html
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This patch does a couple of things. It adds a new DEBUG mode where packet
statistics are printed when channels are closed which can be used to track where
packets might be lost in the transcoding chain.
This patch will also print to the kernel log if the AN983 has detected any
errored received packets. Problems of this type are typically system problems,
like when the card is having trouble DMAing packets.
Internal-Issue-ID: DAHDI-1071
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Keeping the transmit descriptor ring shorter reduces the time it takes to send
CSM_ENCAP commands to the transcoding engine when the card is otherwise busy.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
It is only modified under the chanlock anyway.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Simplifies the logic when polling is enabled. No need to worry about any system
factors when scheduling the default kernel timer.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Otherwise, if there are many RTP commands queued on the command list, some of
the CSM_ENCAP packets, like ACKS, weren't being sent to the firmware within the
timeout value.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Not only does this make it atomic when moving commands from the
waiting_for_response_list to the command_list if the descriptor is full, it will
also make the entire process of submitting a packet the packet transmission
logic atomic.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This was more a holdover when the AN983 interface was brought over from the
voicebus driver.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
When we start the shutdown sequence for a channel, there is no need to submit
any RTP packets that are queued on the command list. Under extreme load with
many backed up RTP packets it was possible to have RTP packets submitted after
the channel shutdown process started.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
A small percentage of the total packets sent to the DTE ever wait for
completions. This will save on the need to keep the completion around in all the
packets.
Also, since we can use the presence of the completion as the flag whether we
intend to auto free, we can simplify the flags as well.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
While not required by the protocol to the DTE, this does help when debugging the
trace files.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Furthermore, do it as soon as we know we should to prevent the ack from
potentially going out after another CSM_ENCAPS packet on another CPU.
Previously, we would not send ACKS to responses we believed we already responded
to.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Eliminates some cases where there are duplicated packets in the capture if the
hardware descriptor ring was already full.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Makes the channels themselves behave like the supervisor channel. This only
protects the driver in the case the commands were severly backed up, like when
there was high packet loss.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
They are sufficiently protected by the list locks. This also cleans up a case
where the tcp was unlocked after already completing it, which was corrupting the
list.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
In case we missed an alert, this will allow for rapid shutdown of Asterisk.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Even if it is duplicated or we don't have an outbound message waiting, we should
ack it so that the firmware does not keep trying to send it to the host.
Otherwise the firmware could get into situations where it was constantly
retrying to send packets for which it did not receive our previous ACK and
exhaust memory.
I was only seeing this on platforms were packets were going missing in the
stream, increasing the probability that the driver would miss early responses.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The kernel log will now contain reports if there are bus errors.
This is a troubleshooting aide on systems with bus issues.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Clarifies that the semaphore was being used as a mutex. Mutexes are also more
efficient and allow better debugging checks.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The ioctls for the debug network interface on the tc400b0 has not been used for
a long time. It is now gone.
This will also allow the sempahore set in the ioctl to be changed into a mutex
which provides enhanced debugging checks.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
When an unsolicited alert is received, we'll flag the card as halted so that
commands will not be retried. This is because often times the firmware will no
longer process any commands in this state and the driver will hold processes in
the dstate while waiting to retry the commands.
This is a debugging aide in that it simplies unloading the driver if the card /
driver is currently in a failed state.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The read-line-multiple command was already disabled on the voicebus cards, which
use the same interface, in commit 4de462c3e0. This
does the same thing for the transcoder card and also disables the read line
command.
I've seen this change directly correlated to problems with the AN983 receiving
packets from the onboard DSP on some platforms.
Internal-Issue-ID: DAHDI-1071
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
I've not seen this directly tied to any issue, but it's enabled on the voicebus
cards and so brings the wctc4xxp driver in line.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixes regression from bb63d03bba (before
v2.7.0). This failed to set the PCM mask on a CAS span when
DAHDI_AUDIO_NOTIFY was not set.
As the first channel of each xbus would be enabled (for
synchronization), a single call may still have passed.
This patch sets the PCM mask on any CAS channel explicitly.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* It's currently harmless (just re-run the pre/post XPD registrations)
* But it's cleaner this way (as with xbus_register_dahdi_device())
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
XPP devices have implicit support for device registration and
unregistration. Even though it is only used for the legacy (non-hotplug)
configuration case, we still prefer to make it explicit.
This attribute would later allow a simpler implementation of the user
space (xpp-specific) tool dahdi_registration.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
In an Astribank with >= 2 PRI ports, switching from E1 to T1 at run-time
may fail at the DAHDI_CHANCONFIG ioctl on the first channel in a span,
That is, on first run of dahdi_cfg, it fails on second span, on second:
it fails on third span, etc.
The code clears the D-channel information on the DAHDI_CHANCONFIG call
for the first channel in the span.
However The code tested for the global "channo" rather than the per-span
"chanpos" to check for the first channel in the span. This the test
failed.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
This is to support users who are unable to update to the lastest CentOS 5.x.
There is no change for most users on the latest releases of their distribution.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The timer_list member of the transcoder buffer has not been used for a long
time. Saves some space in the buffer in addition to removing any future
curiosity about what it is for.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
If the memory allocation for the new channel array fails, it would be possible
to call enable_irq() without the corresponding call to disable_irq().
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This fixes a regression introduced first in release 2.9.1 with commit
(7ce8498465 "firmware: Refactor by using build_tools/install_firmware.")
which prevents from installing the firmware in a location other than the system
root.
Bug: https://issues.asterisk.org/jira/browse/DAHLIN-337
Reported-by: Anthony Messina <amessina@messinet.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
[edited the commit message]
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* dahdi_registration writes multiple times to:
/sys/bus/astribanks/devices/*/*/span
* In some race cases this resulted in corruption and eventual kernel
panic.
* Until migration to "assigned-spans" is complete:
- Accept and ignore multiple "dahdi registrations" from user-space.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
When the card goes through a reset the PCIe link will be brought down. Some
slots will report this change upstream to the root port which will believe that
the card has been hotplugged out of the system.
This fixes cases on some systems where, during a firmware update, the card gets
removed from the system's logical PCI tree with messages like the following in
the kernel log:
pciehp 0000:00:1c.0:pcie04: Card not present on Slot(259)
pciehp 0000:00:1c.0:pcie04: Card present on Slot(259)
Internal-Issue-ID: DAHDI-1091
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This firmware image is able to handle system conditions that would result in
spans internmittenly going down and recovering.
Internal-Issue-ID: DAHDI-1087
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
These firmware images can handle system conditions that would previously result
in transmitted audio being intermittently silenced and then unsilenced.
Internal-Issue-ID: DAHDI-1087
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This firmware image is able to handle system conditions that would result in
spans going down and then coming back intermittently.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
There are some platforms where the DMA operation to the host does not complete
within the required 50us. When this happens some versions of the firmware will
issue a retry and increment the retry field in the descriptor status word.
Now if this driver is configured in DEBUG mode, the presence of these retries
will be printed to the kernel log as a potential troubleshooting aide.
Internal-Issue-ID: DAHDI-1087
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
There are error conditions that the firmware can detect but cannot recover from
without help from the driver. When firmware detects these conditions the
DESC_IO_ERROR bit will be set in the descriptor header to signal that the driver
should reset the TDM engine on the card. Since this is not due to failure of the
host to service the interrupt in time, it does not make sense to increase
latency when these conditions are detected.
Internal-Issue-ID: DAHDI-1087
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Without this change it's hard to see what is actually running on the card when
the firmware in the flash doesn't match the reported version. This is a
debugging aide.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This allows a .tar.gz file that is normally downloaded from the server to be
checked directly into a test branch. Now when the firmware is being installed,
it can be extracted from any present .tar.gz. Again, this is primarily to
simplify testing.
A nice side effect is that when going from a newer version to an older version,
any stale .bin files in the firmware directory will not be installed into
/lib/firmware, but instead the bin file from the *versioned* .tar.gz will always
be installed. This should reduce problems where you have to run "make
dist-clean" when reverting to an older version that has a firmware change.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This is intended to simplify the Makefile and move a large common part into a
subscript. The behavior is the same as it was before.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* We didn't handle proper E1/T1 transitions after device registration.
* Fix SPAN_REGISTERED(xpd):
It now checks for DAHDI_FLAGBIT_REGISTERED as well, as this flag is
set/clear by assign/unassign.
* From set_pri_proto():
- Always free/allocate channels
- Always call dahdi_init_span()
* Improve phonedev_cleanup() safety:
- NULL pointers after free.
- Zero number of channels at the end.
* Refactor channel allocation out of phonedev_init():
- Into phonedev_alloc_channels()
- Also called from xpd_init_span() to prevent duplicated logic.
- And called from set_pri_proto() to prevent our bug.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Commit 74e949c33a exported the module
variable dahdi.auto_assigned_spans. However this is not a good name.
This commit reverts the export and replaces it with a new function to
get the value of the variable.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
A fix to 03b3ce1a10: use ktime_get_ts
instead of getnstimeofday to better handle system time changes.
(Shaun Ruffell)
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Add a new sysfs attribute to dahdi_device: registration_time
* Records the time of the device's registration with DAHDI.
* Used by dahdi_auto_assign_compat to assign spans by device
registration order when backward compatibility needed.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
* Set it to 0 by default (as we use dahdi.auto_assign_spans now)
* Make it readonly (no runtime changes)
* Warn during startup if it was forced to 1
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Instead, use the inverse of dahdi.auto_assign_spans value.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Allow certain older firmwares to delay the hard reset until a full power cycle.
This way we can "preload" newer firmware images, without requiring the user to
physically power off/on their machine.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
This makes the behavior of IRQ misses for these drivers behave the same as the
wcte12xp, wctdm24xxp, and wct4xxp drivers.
Previously irqmisses would never increase. The presence of underruns would still
show up in dmesg as latency bumps.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
These were left over from when the VPM callbacks depended on the different VPM
installed. On the wcte43x this is unnecessary.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
These were left over from when the VPM callbacks depended on the different VPM
installed. On the wcte43x this is unnecessary.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This was a legacy compile time option that is no longer necessary with the new
series of cards.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
struct dahdi_device.devicetype was set incorrectly in both drivers. This caused
the vpm module to not show up after the device name when reading this field
from a spanstat.
Reported-by: Charles Moye <cmoye@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This fixes potential kernel panic due to accessing invalid memory if passing
invalid local span number to 'spantype' attribute via sysfs.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
It was an oversight to prevent the wcte43x and wcte13xp drivers from using
Message Signaled interrupts during the switch to the wcxb library.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wcte13xp now has a max_latency module parameter like the wcaxx and wcte43x
drivers.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The wcxb library did not do actually use the max_latency member to limit the
maximum latency of the DMA engine.
Now it does.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The infrastructure has been put in place in 2.8.0 for fully dynamic device and
span configuration. This will be the default mode in DAHDI-Linux 2.9.0.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>
Previously this was in __dahdi_init_span(). The problem was that
__dahdi_init_span() was only called when a spans' line mode was being changed.
Therefore it was possible to unassign and resassign an analog span and leave it
stuck in the 'NOP' alarm state.
It also make the setting / clearing of DAHDI_ALARM_NOTOPEN symetrical about span
unassignment / assignment in addition to updating the alarm states on all the
channels on the span via the dahdi_alarm_notify() function.
This is a better version of commit 496f817773.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This fixes an issue that affects TDM410 modules when there is not a module
installed in the first port, but there is an FXO module installed in the third
port.
When scaning for QRV modules in the first port, the 3rd port will have the
'hook' struct.qrv set to 0xff. When a QRV module is not detected, that value
will be left, which then maps to an invalid state for both fxo.ring_state and
fxo.battery_state.
The result would be that FXO ports would fail to run the ring detector state
machine since it did not know what the current state was.
Now we'll just reset all the values in struct fxo or struct fxs to the expected
init state.
Internal-Issue-ID: DAHLIN-332
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
A bug introduced in v2.8.0 prevented the recover timing configuration from
being set properly on the hardware. This caused the card to never go into
recovered timing mode.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
drv_attrs was fully removed from the bus structure in upstream commit
e18945b159a1cdbc031f1d3b0b7e515a33bdcbf7 which was merged into 3.13.
This is necessary to compile against linux kernel version 3.13.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
drv_attrs was fully removed from the bus structure in upstream commit
e18945b159a1cdbc031f1d3b0b7e515a33bdcbf7 which was merged into 3.13.
This is necessary to compile dahdi against linux version 3.13.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This resolves issues where, when using internal timing, the first channel of
span 3 has occassional corrupted data in transmit stream.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This extra read eliminates some problems with detecting certain S100M modules.
It is unclear at this time why it is necessary.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The spi master cur_transfer and cur_msg should only be changed under the
spin_lock for the master. The result is that if running user space tools, like
fxstest, that check registers on the modules, it's possible to have a message
that was not yet complete flagged as completed which would result in a bad read.
This does not affect "normal" operation of the wcaxx driver since interrupts are
not enabled during module detection, and during normal operation all access to
the resgisters is done in the context of the interrupt handler. This would only
be an issue if the interrupt handler was running and register accesses are tried
in user space context on an SMP system.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
For the spans exported by the wctdm24xxp, the channels are not going to change
after they are already registered.
This eliminates a problem when analog spans are unassigned/reassigned and the
not_ready goes negative, thereby causing many warnings in the kernel.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Fixes the following warning when loading the driver:
dahdi: Warning: Span DYN/eth/eth1/00:50:c2:97:92:1d/1 didn't specify a spantype. Please fix driver!
The spantype is intended to be used by the auto configuration tools
(dahdi_genconf, pinned spans, etc..) but dynamic spans, since they are created
directly by dahdi_cfg, never take part in the pre-registration auto
configuration, therefore the span type was never used.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This change will ensure that the oct612x module is unloaded automatically when
/etc/init.d/dahdi stop is run.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* This changeset adds master_span as an attribute of the span's driver:
/sys/bus/dahdi_spans/drivers/generic_lowlevel/master_span
* This is mainly used for debugging.
* Reading from it the master span number (or 0 if there is no master
span).
* Writing a number to it, force specified span to be master
* Existing Alternatives:
- grep "MASTER" from /proc/dahdi/*
- cat /sys/bus/dahdi_spans/devices/span-*/is_sync_master
(Note: commit d8fe2af23d is also Acked-By
Tzafrir Cohen <tzafrir.cohen@xorcom.com>)
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Rename as terminology has changed. No change in kernel interface.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* No functional changes.
* Rename the span 'master' to 'master_span' to avoid ambiguity with the
'master' channel.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Create a "ddev" symlink from span's sysfs node to the one of its dahdi
device.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Send the new DAHDI_TOOLS_ROOTDIR and existing DAHDI_INIT_DIR with udev
device events as well.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* Passed to udev as DAHDI_TOOLS_ROOTDIR environment variable
* Default is "/"
* Deprecates the parameter initdir:
- Defaults to $DAHDI_TOOLS_ROOTDIR/usr/share/dahdi
- If specified: taken relative to $DAHDI_TOOLS_ROOTDIR
- Setting both parameters explicitly is prohibited.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If the driver is loaded with vpmsupport=0, then it was possible to create a
deadlock situation since the call into __dahdi_ec_chunk might then try to grab
the channel lock while already holding the reglock.
The purpose of grabbing reglock in the DMA routines was to protect the channel
array, which can be changed when linemode is changing. So instead, we'll
completely mask off that interrupt line from all CPUs when potentially changing
the channel array.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The meta block contains specific version and checksum information and allows the
test tools to validate the image in the flash.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Wendell Thompson <wthompson@digium.com>
These new cards are based on a common architecture with the TE133/TE134 as well
as the new analog cards, A4A/A4B/A8A/A8B.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Rus Meyerriecks <rmeyerriecks@digium.com>
* Removed work queue for maint interface as it is not needed in this driver
* Error counters are now accessible through the maint interface
* Consolidated and revised the big maint switch case
* Added loopup/loopdown code transmit logic to E1
* Now supports error/defect insersion
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Russ Meyerriecks <rmeyerriecks@digium.com>
The framer appears to continue transmitting a signal after modprobe -r. This
patch will leave the physical framer reset pin asserted to force the chip to
stop transmitting a signal when there is no driver attached.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Russ Meyerriecks <rmeyerriecks@digium.com>
Removed all the custom logic and replaced with the common platform wcxb stuff.
There are also changes in here to standardize the function prefix in this
driver to t13x_.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Wendell Thompson <wthompson@digium.com>
Now uses framer interrupt vector polling (in the FPGA interrupt) for
alarm, loopcode, and signaling events eliminating continuous polling.
Now uses timer function for alarm and loopcode debouce, which only
executes during exception conditions.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This is a driver for the new line of analog cards that shares a common interface
with the TE133/TE134 and the TE435.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The octasic library is relatively large and is currently separately linked into
both the wcte13xp and wct4xxp libraries. This change moves it out into a
separate loadable module.
The bigest change from the drivers perspectives is that they must provide a
table of callbacks instead of using statically linked Oct6100UserXxxxx functions
to allow the library to communicate with actual parts on the cards.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This works around some issues with older versions of the firmware not
working properly after the linemode is changed via sysfs. Basically the
intent is to simulate redoing a complete driver reload with a new
linemode.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This print happened when the linemode was changed via sysfs, but it didn't
really add much extra information that a user could act on.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
