[asterisk-users] Asterisk failing when recording calls

[Carlos Chavez]

     We have a server that has been in operation since December of last year.
 Two days ago we started seeing this messages over and over (maybe a couple
thousand in a minute):

[Sep  2 17:46:19] DEBUG[7422] audiohook.c: Write factory 0x2aaad40a0038 was
pretty quick last time, waiting for them.
[Sep  2 17:46:19] DEBUG[7421] chan_dahdi.c: Write returned -1 (Resource
temporarily unavailable) on channel 34

     For the past two days Asterisk seems to fail at random intervals.  It
does not crash but it stops processing calls.  You need to restart Asterisk to
restore service.  We are running Asterisk 1.6.2.11 with Freepbx on a CentOS
5.5 server.  We started with version 1.6.2.4 and upgraded all the way to the
latest just in case it was a bug that has been fixed.  The server has a TE210P
card with only one port in use and 4 USB100 Sangoma dual FXO modules.  We use
DAHDI 2.3.0.1 and Wanpipe 3.5.15 for the cards.

     As far as I can see they problem may happen when a call is being recorded
but I have no definitive proof.  The USB100 seem to be a little unstable at
times.  Sometimes when you reboot the server one of them will not even be
listed by LSUSB or wanrouter.  You need to completely power off the server so
they will show up again.  Everything seems to start fine but I see this message:

BUG: warning at
/usr/src/dahdi-linux-2.3.0.1/drivers/dahdi/dahdi-base.c:5866/dahdi_register()
(Tainted: G     )

Call Trace:
 [<ffffffff883cafe6>] :dahdi:dahdi_register+0x56/0x309
 [<ffffffff88515721>] :wanpipe:wp_usb_tdmv_remora_software_init+0x5ee/0x916
 [<ffffffff8850db5d>] :wanpipe:wp_usb_new_if+0x291/0x5ef
 [<ffffffff800cbbc9>] __kzalloc+0x9/0x21
 [<ffffffff884a7970>] :wanrouter:wan_device_new_if+0x2d0/0x4dd
 [<ffffffff884a870b>] :wanrouter:wanrouter_ioctl+0x3ba/0x936
 [<ffffffff8804c1b6>] :ext3:ext3_file_write+0x16/0x91
 [<ffffffff800182c3>] do_sync_write+0xc7/0x104
 [<ffffffff80066b88>] do_page_fault+0x4fe/0x874
 [<ffffffff800a09d8>] autoremove_wake_function+0x0/0x2e
 [<ffffffff80042181>] do_ioctl+0x55/0x6b
 [<ffffffff80030204>] vfs_ioctl+0x457/0x4b9
 [<ffffffff800b7605>] audit_syscall_entry+0x180/0x1b3
 [<ffffffff8004c633>] sys_ioctl+0x59/0x78
 [<ffffffff8005d28d>] tracesys+0xd5/0xe0

     I do not know if this is normal because Wanpipe patches DAHDI or if this
indicates a problem.  Any ideas or recommendations?

--
Carlos Chavez
Director de Tecnología
Telecomunicaciones Abiertas de México S.A. de C.V.
Tel: +52-55-91169161 Ext 2001