I only generally test on RHEL 4 when testing against kernels older
than 2.6.18. Apparently OpenSUSE 10.1 runs with 2.6.16 and doesn't
have WARN_ON_ONCE backported. I took the patch Richard Miller
originally attached to the issue and moved it to
include/dahdi/kernel.h so it would be available for all the board
drivers in the future.
Internal-Issue-ID: DAHLIN-260
Reported-by: Richard Miller
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10252
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10254 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r10082 "wctc4xxp: Cleanup in-flight commands when halting due to
hardware error." introduced a lock imblance on the error path where the
cmd_list_lock would be unlocked twice when the board is halted due to a
hardware error. Thanks sparse.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10138
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10139 a0bf4364-ded3-4de4-8d8a-66a801d63aff
On one system I was seeing the board reset in the middle of a
transaction. Any commands that were on the response list when this would
happen would never be completed and the process would then be stuck in
an uninterruptible sleep. This change also prevents the driver from
sleeping in timer context, which would result in a kernel panic.
This change at least lets an error message propogate back to the user.
DAHDI-880
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10082 a0bf4364-ded3-4de4-8d8a-66a801d63aff
gcc-4.6 now warns about variables that are set but never used. Clean up
unused variables everywhere except the oct612x subdirectory.
The oct612x should go in a separate patch in case that needs to be
pulled out into a separate project again.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9929 a0bf4364-ded3-4de4-8d8a-66a801d63aff
These drivers (all DAHDI drivers) should explicitly block suspend if they are
loaded.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9882 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2.6.25 added the DEFINE_PCI_DEVICE_TABLE macro to make sure that the
pci_device_id tables are put into the correct section in the binary.
Convert all the places where the tables were defined to use them.
This is linux-2.6 commit where the change went in along with the
rationale: 90a1ba0c5e39eeea278f263c28ae02166c5911c8
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9584 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The mode module parameter is only acted on during module initialization.
We shouldn't allow anyone to change it after the driver is already
loaded.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-By: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9537 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Using semaphores as mutexes was removed from the kernel in 4882720b267b.
Just use straight semaphores now. 'DECLARE_MUTEX()' -> 'DEFINE_SEMAPHORE()'
and 'init_MUTEX()' -> 'sema_init()'.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
LKML-Reference: <20100907125057.562399240@linutronix.de>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9464 a0bf4364-ded3-4de4-8d8a-66a801d63aff
If the DSP ever finds it's way into a bad state it can be possible for a
timeslot to get 'wedged'. All attempts to create a channel in a wedged
timeslot will fail and the WARN_ON macro can quickly fill the logs.
This change adds some more debugging information (which timeslot is wedged)
along with the result code from the DSP and puts it all behind a
printk_ratelimit.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9437 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Just use the standard way to print messages associated with a particular
device. Also dropped the "Attached to device at" message since that
information is now printed on every print.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9436 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'service_dte' was only called in one place and is only two lines. I do
not think it is adding much anymore. Also, let compiler should decide if
'service_rx_ring' and 'service_tx_ring' should be inlined.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9435 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This needs some more testing before it's on by default. If the card is
otherwise functioning, these messages may be confusing to the user. If
the card is not functioning, the driver can be reloaded with debug to
check for this condition.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9205 a0bf4364-ded3-4de4-8d8a-66a801d63aff
