linux-avmb1:C4 unexpected reset

Karagiannidis Savvas karagian at dataways.gr
Wed Nov 16 16:55:02 CET 2005


Hi,

We have a fax server based on slackware linux with the following
characteristics :

kernel versions 2.4.26 and 2.4.31
kernel C4 driver revision 1.1.4.1
C4 firmware revision : 3.11-06

The capi configuration file (/etc/capi.conf) is the following:

# card          file    proto   io      irq     mem     cardnr  options
#b1isa          b1.t4   DSS1    0x150   7       -       -       P2P
b1pci           b1.t4   DSS1    -       -       -       -
c4              c4.bin  DSS1    -       -       -       -
#c4             -       DSS1    -       -       -       -
#c4             -       DSS1    -       -       -       -       P2P
#c4             -       DSS1    -       -       -       -       P2P
c2              c2.bin  DSS1    -       -       -       -
#c2             -       DSS1    -       -       -       -
#t1isa          t1.t4   DSS1    0x340   9       -       0
#t1pci          t1.t4   DSS1    -       -       -       -
fcpci           -       -       -       -       -       -
#fcclassic      -       -       0x150   10      -       -
fcdsl           fdslbase.bin DSS1       -       -       -       -

The fax software used is hylafax 4.1.8 and capi4hylafax version 01.03.00

We have tested the fax server with others ISDN cards and works fine. With
the C4 hardware, the following problem occurs quite frequently:

During reception of a fax, the card suddenly stops responding, all leds on
the card turn off and on the system log we get the following messages :

Nov 16 08:52:41 nohostname c4-a000: unexpected reset
Nov 16 08:52:41 nohostname kcapi: card 1 down.
Nov 16 08:52:41 nohostname kcapi: card 2 down.
Nov 16 08:52:41 nohostname kcapi: card 3 down.
Nov 16 08:52:41 nohostname kcapi: card 4 down.
Nov 16 08:52:41 nohostname kcapi: notify down contr 1
Nov 16 08:52:41 nohostname capidrv: controller 1 down
Nov 16 08:52:41 nohostname capidrv-1: now down.
Nov 16 08:52:41 nohostname capi: controller 1 down
Nov 16 08:52:41 nohostname kcapi: notify down contr 2
Nov 16 08:52:41 nohostname capidrv: controller 2 down
Nov 16 08:52:41 nohostname capidrv-2: now down.
Nov 16 08:52:41 nohostname capi: controller 2 down
Nov 16 08:52:41 nohostname kcapi: notify down contr 3
Nov 16 08:52:41 nohostname capidrv: controller 3 down
Nov 16 08:52:41 nohostname capidrv-3: now down.
Nov 16 08:52:41 nohostname capi: controller 3 down
Nov 16 08:52:41 nohostname kcapi: notify down contr 4
Nov 16 08:52:41 nohostname capidrv: controller 4 down
Nov 16 08:52:41 nohostname capidrv-4: now down.
Nov 16 08:52:41 nohostname capi: controller 4 down

The unexpected reset is a message that comes from the C4 driver. After that,
the status of the CAPI controllers is in the detected state :

~# capiinit status
1 c4         detected c4-a000          C4 - 0xa000 11 0xf7042000
2 c4         detected c4-a000          C4 - 0xa000 11 0xf7042000
3 c4         detected c4-a000          C4 - 0xa000 11 0xf7042000
4 c4         detected c4-a000          C4 - 0xa000 11 0xf7042000

As a result, no fax can be received. To restore the problem, the driver has
to be unloaded and reloaded again with capiinit stop and capiinit start.

After that (unloading and reloading the drivers) the problem is usually
resolved, but sometimes, when the driver is reloaded (capiinit start), there
may be a problem while the firmware is uploaded. When this happens, we get
the following message from capiinit :

ERROR: controller 1: timeout while loading "/usr/lib/isdn/c4.bin"
and the state of the controllers is as follows :

~# capiinit status
1 c4         loading  c4-a000          - - 0xa000 11 0xf7042000
2 c4         loading  c4-a000          - - 0xa000 11 0xf7042000
3 c4         detected c4-a000          - - 0xa000 11 0xf7042000
4 c4         detected c4-a000          - - 0xa000 11 0xf7042000

We ran several tests with two C4 cards that seem identical, but one of them
expresses the above symptoms far more frequently than the other, making the
card practically useless.

We also ran tests with different hardware configurations (board, cpu,
memory), but the results were always the same.

I saw on the list that the unexpected reset is a known problem, but it was
supposed to be resolved with the newer version of firmware. The firmware we
use is the latest version available. I also tried the older versions, but
the problem remains...

Besides implementing a script monitoring the system, is there any other
solution to the problem? Is it a firmware problem, a hardware problem
or a driver problem? And if it is not a hardware problem, is this problem
resolved in 2.6 kernel ?


Thanks,
Savvas




More information about the linux-avmb1 mailing list