This saves ~300K of kernel memory for each quad or dual span VPM. Due
to the fact that this change disables caching of the NLP words (among
other things), the time to disable the echocans appears to have
increased by ~1ms.
Before this change:
=======================================================================
0) ! 356.498 us | vpm450m_setecmode(); <--- disable
0) ! 387.762 us | vpm450m_setecmode(); <--- enable
0) ! 429.839 us | vpm450m_setecmode(); <--- disable
]# echo 1 > /proc/sys/vm/drop_caches && free -k
total used free shared buffers cached
Mem: 2005352 228368 1776984 0 132
5540
-/+ buffers/cache: 222696 1782656
Swap: 983036 0 983036
After this change:
=======================================================================
0) ! 1109.515 us | vpm450m_setecmode(); <--- disable
0) ! 339.017 us | vpm450m_setecmode(); <--- enable
0) ! 1431.460 us | vpm450m_setecmode(); <--- disable
]# echo 1 > /proc/sys/vm/drop_caches && free -k
total used free shared buffers cached
Mem: 2005352 228080 1777272 0 112
5484
-/+ buffers/cache: 222484 1782868
Swap: 983036 0 983036
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9750
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9753 a0bf4364-ded3-4de4-8d8a-66a801d63aff
With the release of Linux 2.6.37, the Big Kernel Lock is now a compile
time option. This change adds a mutex around the one place in the code
that we already knew was dependent on the lock_kernel/unlock_kernel
calls for serialization and drops the other calls to
lock_kernel/unlock_kernel if CONFIG_BKL is not defined.
This is *mostly* the dahdi-no-bkl.patch with a few minor whitespace
changes, the global_dialparmslock made static, and a warning added to
let people know they are running an experimental configuration.
(issue #18604)
Reported by: jkroon
Patches:
dahdi-no-bkl.patch uploaded by jkroon (license 714)
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9721
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9725 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Extended reset is needed primarily with the PCI express version of the
dual and quad-span cards. Enable it by default for those cards and
allow it to be forced on or off globally for the driver as a compile
time option.
The options to force it should be able to come out if there aren't any
further reports that the compile time option needs to be set.
DAHDI-773
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9635
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9695 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi/wcb4xxp driver used with Digium Wildcard B410 quad-BRI PCI card
unable to communicate with another ISDN device (ISDN phone, another port
of B410). It appears that B-channels are capable to transport data, but
D-channel is not.
Debug output added into the driver shows that packets are transmitted to
the D-channel, but no packets are received. Further investigation shows
that no interrupts received from Rx FIFO associated with D-channel,
although packets are delivered to the FIFO. I've found that problem is
in improper usage of chan->chanpos while indexing the fifo index
(bspan->fifos): chanpos starts from 1 and fifos starts from 0.
Therefore, garbage read instead of fifo number.
(closes issue #14834)
Reported by: vvv
Patches:
dahdi-linux-complete-2.2.0-rc1.patch uploaded by vvv (license 741)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9555
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9689 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Instead of using pci_set_drvdata embed the 'struct voicebus_operations'
directly in the context so we can use container_of to find the context.
This resolves a problem where the 'remove_one' callback gets an invalid
pointer to 'struct t1' if the VPMADT032 is in the middle of a reload
when the module is unloading. DAHDI-783.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9554
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9688 a0bf4364-ded3-4de4-8d8a-66a801d63aff
There are some platforms where the read-line multiple transaction causes
packets to be dropped in the voicebus pipeline. The only observable
behavior is that packets just go "missing" in the pipeline. This also
only appears to affect PCI cards.
A typical 'symptom' of this problem is you may see IRQ misses increasing
without any corresponding "bumps" in latency in the kernel message log.
Normally, IRQ misses are correlated to latency bumps since that is an
indication that the host was not able to service the card interrupt in a
timely fashion. DAHDI-510 DAHDI-774
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9542
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9687 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The wcte12xp does all the checking for alarm in a user space workqueue.
Most of this time is spent sleeping waiting for reads from the framer to
complete. Tasks in uninterruptible sleeps are added to running tasks
for the purposes of calculating load average. This change makes the
sleeps interruptible so as to not affect the load average as much.
For example, the following command will load and configure the driver and
then print the load average every 10 seconds.
]# modprobe wcte12xp && dahdi_cfg && ((x=12)); while [[ $x -gt 0 ]]; do cat
/proc/loadavg; sleep 10; let x=$x-1; done
With this change:
0.29 0.10 0.02 1/101 29945
0.24 0.10 0.02 1/101 29967
0.20 0.09 0.02 1/101 30019
0.17 0.09 0.02 1/101 30041
0.15 0.09 0.02 1/101 30062
0.12 0.08 0.02 1/101 30085
0.10 0.08 0.02 1/101 30107
0.09 0.08 0.02 1/101 30129
0.07 0.08 0.02 1/101 30151
0.14 0.09 0.02 1/101 30173
0.12 0.09 0.02 1/101 30195
0.10 0.08 0.02 1/101 30217
(and I've seen it get down to 0.0)
Before this change:
0.57 0.22 0.07 1/101 31920
0.48 0.21 0.07 1/101 31942
0.48 0.22 0.07 1/101 31964
0.48 0.23 0.08 1/101 31986
0.41 0.22 0.07 1/101 32008
0.42 0.23 0.08 1/101 32030
0.43 0.24 0.08 1/101 32054
0.45 0.25 0.09 1/101 32076
0.45 0.25 0.09 1/101 32098
0.46 0.26 0.10 1/101 32120
0.47 0.27 0.10 1/101 32172
0.39 0.26 0.10 1/101 32194
(closes issue #18142)
Reported by: foxfire
Tested by: foxfire
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9512
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9683 a0bf4364-ded3-4de4-8d8a-66a801d63aff
There were some routes through the failure paths in __voicebus_init() where a
registered memory region was not subsequently released. This change closes
those paths.
The result would be on subsequent loads of the driver after hitting the
failure condition you would see "IO Registers are in use by another module."
in dmesg.
request_mem_region/release_mem_region should most likely be converted to
devm_request_region and devm_release_region introduced in 2.6.20
(commit 9ac7849e35f705830f7b016ff272b0ff1f7ff759) which was introduced for
reasons just such as this.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9503
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9678 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The voicebus library by default configures the PCI interface to poll the
descriptor ring for available buffers. There are some platforms like
the Intel SG3420P motherboard where this does not appear to be
sufficient. Writing to the transmit demand poll register resolves this
problem on these troublesome platforms. DAHDI-700 DAHDI-702.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9397
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.4@9672 a0bf4364-ded3-4de4-8d8a-66a801d63aff
