[asterisk-users] Problem with dahdi XPP driver?

Matteo matteo.campana at gmail.com
Thu Jun 6 03:12:39 CDT 2013 

On Thu, Jun 6, 2013 at 9:56 AM, Tzafrir Cohen <tzafrir.cohen at xorcom.com>wrote:

> On Thu, Jun 06, 2013 at 09:31:39AM +0200, Matteo wrote:
> > Hi list,
> > I had a problem with the dahdi XPP driver.
> > After this error in syslog, the Xorcom disconnect from the server:
>
> Has it happened once? More then once? Reproducable?
>
> How long has the Astribank been working till then?
>

Hi Tzafrir,
I don't know how many times it happened, this time I was reported  because
they have had problems with HA.
This Astribank has been in production for more than 1 year, some months ago
(maybe in September) I have upgraded the dahdi version to 2.6.1 from an
older one (2.3).



> > (usb-0000:00:1d.7-3) [X1047686]: nonzero write bulk status received: -108
>
> Is X1047686 the serial number of the Astribank? See 'dahdi_hardware -v'
>

Yes it is the serial number of the Astribank.

Regards,
Matteo

>
> >
> >
> > Jun  3 15:03:29  kernel: [361010.637858] *NOTICE-xpp_usb: xusb-0
> > (usb-0000:00:1d.7-3) [X1047686]: Sluggish USB. Dropping next PCM frame
> (p**
> > **ending_writes=5)*
> > Jun  3 15:03:52  kernel: [361033.890575]* ERR-xpp: XBUS-00: Failed to
> send
> > from command_queue (ret=-19)*
> > Jun  3 15:03:52  kernel: [361033.894565] ------------[ cut here
> > ]------------
> > Jun  3 15:03:52  kernel: [361033.894565] WARNING: at kernel/softirq.c:141
> > local_bh_enable+0x2f/0x6a()
> > Jun  3 15:03:52  kernel: [361033.894565] Hardware name:
> > Jun  3 15:03:52  kernel: [361033.894565] Modules linked in:
> > dahdi_echocan_oslec echo xpd_pri xpp_usb xpp dahdi crc_ccitt drbd cn ipv6
> > loop rng_core serio_raw i2c_i801 ehci_hcd uhci_hcd iTCO_wdt i2c_core
> usbcore
> > Jun  3 15:03:52  kernel: [361033.894565] Pid: 0, comm: swapper Not
> tainted
> > 2.6.30.9 #3
> > Jun  3 15:03:52  kernel: [361033.894565] Call Trace:
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c0117d97>] ?
> > warn_slowpath_common+0x5e/0x8a
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c0117dcd>] ?
> > warn_slowpath_null+0xa/0xc
> > Jun  3 15:03:52 kernel: [361033.894565]  [<c011b82d>] ?
> > local_bh_enable+0x2f/0x6a
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c0293c3f>] ?
> sk_filter+0x63/0x6c
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c029d5b4>] ?
> > netlink_broadcast+0x1aa/0x2e7
> > Jun  3 15:03:52 kernel: [361033.894565]  [<c01ea9bd>] ?
> > kobject_uevent_env+0x295/0x340
> > Jun  3 15:03:52  kernel: [361033.894565]  [<f8471990>] ?
> > xbus_setstate+0x155/0x18d [xpp]
> > Jun  3 15:03:52  kernel: [361033.894565]  [<f8472b09>] ?
> > xbus_command_queue_tick+0x15d/0x18c [xpp]
> > Jun  3 15:03:52  kernel: [361033.894565]  [<f8475d6b>] ?
> > xframe_receive_pcm+0x91/0xe28 [xpp]
> > Jun  3 15:03:52 kernel: [361033.894565]  [<c012b256>] ?
> > getnstimeofday+0x4d/0xca
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c012b256>] ?
> > getnstimeofday+0x4d/0xca
> > Jun  3 15:03:52  kernel: [361033.894565]  [<f847a002>] ?
> > xframe_receive+0x118/0x52c [xpp]
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c012b2e2>] ?
> > do_gettimeofday+0xf/0x29
> > Jun  3 15:03:52  kernel: [361033.894565]  [<f84c50ee>] ?
> > xpp_receive_callback+0x117/0x13e [xpp_usb]
> > Jun  3 15:03:52  kernel: [361033.894565]  [<f8065c63>] ?
> > usb_hcd_giveback_urb+0x60/0x8e [usbcore]
> > Jun  3 15:03:52  kernel: [361033.894565]  [<f80f867c>] ?
> > qh_completions+0x91/0x3e9 [ehci_hcd]
> > Jun  3 15:03:52  kernel: [361033.894565]  [<f80fa942>] ?
> > ehci_work+0x93/0x780 [ehci_hcd]
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c01281cd>] ?
> > ktime_get_ts+0x1d/0x3f
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c01281fc>] ?
> ktime_get+0xd/0x2d
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c012b256>] ?
> > getnstimeofday+0x4d/0xca
> > Jun  3 15:03:52  kernel: [361033.894565]  [<f80fbd1c>] ?
> > ehci_irq+0x147/0x197 [ehci_hcd]
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c01281fc>] ?
> ktime_get+0xd/0x2d
> > Jun  3 15:03:52  kernel: [361033.894565]  [<f8065aad>] ?
> > usb_hcd_irq+0x24/0x58 [usbcore]
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c0142365>] ?
> > handle_IRQ_event+0x49/0xf8
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c0143336>] ?
> > handle_level_irq+0x50/0x85
> > Jun  3 15:03:52 kernel: [361033.894565]  [<c0103e0f>] ?
> handle_irq+0x17/0x1c
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c0103bc8>] ? do_IRQ+0x2b/0x63
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c0102da9>] ?
> > common_interrupt+0x29/0x30
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c014007b>] ?
> > audit_log_exit+0xb78/0xc8b
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c0106f93>] ?
> > mwait_idle+0x75/0xa0
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c0101afc>] ?
> cpu_idle+0x23/0x3f
> > Jun  3 15:03:52  kernel: [361033.894565]  [<c03c88d7>] ?
> > start_kernel+0x262/0x265
> > Jun  3 15:03:52 kernel: [361033.894565] ---[ end trace 9422ad58c50dc1ad
> ]---
> > Jun  3 15:03:54  kernel: [361036.107365]* usb 5-3: USB disconnect,
> address 2
> > *
> > Jun  3 15:03:54  kernel: [361036.112475] ERR-xpp_usb: xusb-0
> > (usb-0000:00:1d.7-3) [X1047686]: nonzero write bulk status received: -108
> > (pending_writes=101)
> >
> > So the customer was* *unable to call* *** PSTN numbers.
> >
> > Some info about the server:
> >
> >
> >    - uname -a
> >
> >       Linux 2.6.30.9 #3 Tue Apr 20 10:55:28 CEST 2010 i686 GNU/Linux
> >
> >
> >    - Debian 5.0
> >
> >
> >    -  modinfo dahdi
> >
> > filename:       /lib/modules/2.6.30.9/dahdi/dahdi.ko
> > alias:          dahdi_dummy
> > license:        GPL v2
> > description:    DAHDI Telephony Interface
> > author:         Mark Spencer <markster at digium.com> <markster at digium.com>
> > version:        2.6.1
> > srcversion:     0AFDAE1CD29137EA0FA18FB
> > depends:        crc-ccitt
> > vermagic:       2.6.30.9 mod_unload modversions PENTIUM4
> > parm:           initdir:charp
> > parm:           debug:Sets debugging verbosity as a bitfield, to see
> > general debugging set this to 1. To see RBS debugging set this to 32
> (int)
> > parm:           deftaps:int
> > parm:           max_pseudo_channels:Maximum number of pseudo channels.
> (int)
> > parm:           hwec_overrides_swec:When true, a hardware echo canceller
> is
> > used instead of configured SWEC. (int)
> > parm:           auto_assign_spans:If 1 spans will automatically have
> their
> > children span and channel numbers assigned by the driver. If 0, user
> space
> > will need to assign them via /sys/bus/dahdi_devices. (int)
> >
> > What can be the problem?
> >
> > Thanks,
> > Matteo
>
> > --
> > _____________________________________________________________________
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> > New to Asterisk? Join us for a live introductory webinar every Thurs:
> >                http://www.asterisk.org/hello
> >
> > asterisk-users mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
> --
>                Tzafrir Cohen
> icq#16849755              jabber:tzafrir.cohen at xorcom.com
> +972-50-7952406           mailto:tzafrir.cohen at xorcom.com
> http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130606/45ebac9d/attachment.htm>

More information about the asterisk-users mailing list