Age | Commit message (Collapse) | Author |
|
* Change refcount_xpd(): instead of returning a pointer to the atomic
counter, return directly its value (just like refcount_xbus())
* Add a refcount_xbus and refcount_xpd attributes to sysfs (for debugging)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8878 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
This changeset should have no functional changes.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8877 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
When initializing registers for the "PRI" (E1/T1) module, in the case the
user has not explicitly asked for E1/T1 settings in xpp.conf (pri_protocol)
fall back to the current value, which is the build-time fall-back.
The value is read from sysfs.
Previously we implicitly assumed this value is E1.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8873 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8872 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
As best as I can tell, when CONFIG_NO_HZ is set along with CONFIG_HZ < 250, it
is possible for the system timer to exceed MAX_SOFTIRQ_RESTART. Tony
Mountifield alluded that this might be a problem in the below mailing list
posting, but when I was originally testing, I wasn't using CONFIG_NO_HZ and HZ
< 250.
http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg37384.html
(closes issue #17620)
Reported by: seanbright
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8868 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8853 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8849 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8841 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
gcc 4.5.0 generates a warning on the changed lines and
http://gcc.gnu.org/ml/gcc/2004-10/msg00032.html explains why.
Essentially, the only thing guaranteed with the preincrement operator is that
the value will be incremented before the assignment. It's undefined where in
the sequence the mask will be applied.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8832 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
gcc 4.5.0 was generating a warning on the changed line, and the
discussion at http://gcc.gnu.org/ml/gcc/2004-10/msg00024.html explains
why.
Essentially, the only thing guaranteed with the preincrement operator is
that the value will be incremented before the assignment. It's
undefined where in the sequence the mask will be applied.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8831 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
suggestion)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8805 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
RBS modes to be broken when using AMI coding. DAHDI-647.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8801 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
latency - the default number of ms of buffering to start off with
ms_per_irq - how often the card interrupts
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8768 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
usb_buffer_alloc has been replaced with usb_alloc_coherent , and likewise
usb_buffer_free has been replaced with usb_free_coherent. in kernels 2.6.34
the older names are proxies for the new ones, and in 2.6.35 the older names are gone.
This patch defines the new names for the old ones, for older kernel versions.
(closes issue #17383)
Reported by: Chainsaw
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8762 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
With kernel version >= 2.6.35-rc1, building failed with:
drivers/dahdi/voicebus/GpakCust.h:114: error: field ‘sem’ has incomplete type
(closes issue #17382)
Reported by: Chainsaw
Patches:
07-semaphore-include-not-optional.diff uploaded by Chainsaw (license 723)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8758 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8689 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Fix the same issue as in r8550 , for dahdi_echocan_hpec.c:
With kernel 2.6.34 an explicit '#include <slab.h>' is required for
using kzalloc() and friends.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8680 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Fix the same issue as in r8550 , for dahdi_echocan_oslec.c:
With kernel 2.6.34-rc5 an explicit '#include <slab.h>' is required for using
kzalloc() and friends.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8674 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8673 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8653 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Modules that aren't installed should show at the same level as
modules that are installed. It could be confusing if the console
log level is set to 3 and only messages about which ports do not
have any modules installed show up on the console.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8642 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
CentOS4 has this backported in their 2.6.9 kernel.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8641 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Over-verbose instrumentation snuck in, on commit r8594
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8600 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
(part 3) Fixes DAHDI-449 where dahdi_cfg would need to be run multiple times
in order to properly set the rbs or clear mode of a channel. The prior
logic was calling set_clear in the context of setting all channels to
clear mode, even if the channel was intended to be in bit robbed mode.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8594 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
CheckDspReset can return -1 if the DSP is not ready to process any new
commands. In this case we should retry a few times to give the DSP a chance
to become ready. While I'm not ready to say this definitely fixes recently
reported cases when the wcte12xp driver constantly resets, it eliminated
communication failures to the DSP module when under stress (via the
vpm_firmware_version sysfs attribute). However, I haven't let it run long
enough to say that the issue is resolved. DAHDI-603.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8576 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
If the sleep is ever interrupted, 'up' will still be called in the GpakApi,
essentially making the lock useless after that point.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8575 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Currently only exported if CONFIG_VOICEBUS_SYSFS is defined in
drivers/dahdi/voicebus.h. Reading from the 'vpm_firmware_version' attribute
will poll the firmware on the VPMADT032 for it's current version.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8574 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
'voicebus_current_latency' is only exported when CONFIG_VOICEBUS_SYSFS is
defined in voicebus.h. This is a debugging aide which enables determing the
board specific latency without parsing through the kernel logs.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8573 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Removed a change to dahdi-base from last patch which might have caused
compatibility with drivers other than the wcte12xp.
wcte12xp: The channel clear/rbs function no longer reads the register first.
It now uses the span's channel flags to determine each channels clear state.
Also added various minor readability improvements.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8569 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Fixes DAHDI-449 where chanconfig was failing on the first call. It needed
to be called twice in a row. This was due to the channel configuration using
a non-relative channel number in its loop.
Also re-added the register dumping ioctl for inspecting the framer's state.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8564 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
In revision 8176 I changed register access from I/O space to memory mapped
registers. Unfortunately, when I made that change, I didn't account for
posted writes. This change makes sure all the registers are read back to
ensure that they are posted through any intermediate bridges.
The most readily observable symptom were cards that were taking 2000
interrupts/second. The card reported that it handled an interrupt but the
write to silence the card wasn't flushed through until the second time the
interrupt handler run. DAHDI-602.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8560 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
(closes issue #16339)
Reported by: alecdavis
Patches:
20091129__issue16339.diff.txt uploaded by tilghman (license 14)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8556 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
With kernel 2.6.34-rc5 an explicit '#include <slab.h>' is required for using
kzalloc() and friends.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8550 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8539 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
WARN_ON_ONCE is not defined in 2.6.9, and this condition would be catastrophic
anyway if it were to occur.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8494 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8489 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8488 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8487 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8482 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
If we try to unload the driver soon after a high latency event, it is possible
to get stuck for several seconds reloading the firmware. DAHDI-573.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8481 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8480 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8479 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Only program the VPM in spanconfig if it either is not setup, or if it fails a
ping test. Also, if the channel config fails (but ping would otherwise work),
force a reset / reconfiguration if the VPM module. DAHDI-573.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8478 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Also, fall back to any software echocan configured for this channel for new
calls while we're in the middle of a recovery.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8473 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
When the transmit descriptor runs out completely, there (appears to be) a
chance for a random command to be sent that results in the VPMADT032 to no
longer respond, typically resulting in one way audio. This change introduces
a poll of the VPM. If it fails the poll, it will be bypassed temporarily
while the driver resets and reprograms it. Also, the VPM is initially
programmed in the spanconfig callback instead of at driver load. This moves
the potential for underruns until later in the boot process. DAHDI-573.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8468 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
This will make us two behind, which is fine, and eliminates a busy loop in
atomic context.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8467 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8466 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
r8454 and r8460 introduced a change where writes are not retried when other
module/framer commands are retried. This was an error and wasn't what was
actually under test. This commit restores the behavior in wctdm24xxp and
makes sure the vpm writes are retried in the wcte12xp.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8461 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Closes a memory leak when processing the VPM write commands introduced in
r8454.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8460 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
When the latency is large and register reads can take 100s of milliseconds, the
alarm polling function could tie up one of the global workqueue threads long
enough to interfere with other system operations. Most noticeably the console.
DAHDI-573
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@8455 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|