Debian Bug report logs - #601034
dahdi vzaphfc: system freezes during longer calls (after approximately one minute)

version graph

Package: dahdi-source; Maintainer for dahdi-source is Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>; Source for dahdi-source is src:dahdi-linux.

Reported by: karl156 <karl156@abwesend.de>

Date: Sat, 2 Oct 2010 19:30:01 UTC

Severity: important

Tags: jessie, sid, squeeze, wheezy

Found in version dahdi-linux/1:2.3.0.1+dfsg-1

Fixed in version 1:2.3.0.1+dfsg-2

Done: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>:
Bug#598886; Package dahdi-source. (Sat, 02 Oct 2010 19:30:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to karl156 <karl156@abwesend.de>:
New Bug report received and forwarded. Copy sent to Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>. (Sat, 02 Oct 2010 19:30:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: karl156 <karl156@abwesend.de>
To: submit@bugs.debian.org
Subject: dahdi-source: vzaphfc does not work: "Unable to receive TEI from network"
Date: Sat, 02 Oct 2010 21:26:33 +0200
Package: dahdi-source
Version: 1:2.3.0.1+dfsg-1
Severity: important
Tags: squeeze sid

This occurs even after a fresh Debian Squeeze installation on new
(=other) hardware. I have also tried Linux kernel 2.6.32, 2.6.34,
2.6.35. State in Asterisk is always "Provisioned, Down, Active".

Looks like other users are having the same problem:
http://lists.digium.com/pipermail/asterisk-users/2010-October/254351.html


When loading the vzaphfc kernel module:
[ 6064.533280] dahdi: Telephony Interface Registered on major 196
[ 6064.533288] dahdi: Version: 2.3.0.1
[ 6064.544846] vzaphfc: HFC-S PCI A ISDN (V1.42) loading
[ 6064.545139] vzaphfc: card 0: registered ZTHFC1/0/1
[ 6064.545147] vzaphfc: card 0: registered ZTHFC1/0/2
[ 6064.545154] vzaphfc: card 0: registered ZTHFC1/0/3
[ 6064.545160] ------------[ cut here ]------------
[ 6064.545181] WARNING: at
/usr/src/modules/dahdi/drivers/dahdi/dahdi-base.c:5866
dahdi_register+0x39/0x299 [dahdi]()
[ 6064.545189] Hardware name: System Name
[ 6064.545193] Modules linked in: zaphfc(+) dahdi crc_ccitt isofs udf
crc_itu_t speedstep_lib cpufreq_userspace cpufreq_conservative
cpufreq_powersave cpufreq_stats parport_pc ppdev lp parport fuse loop
snd_ens1370 gameport snd_seq_midi snd_seq_midi_event snd_rawmidi snd_pcm
snd_seq nouveau snd_timer ttm snd_seq_device drm_kms_helper snd drm
intel_rng i2c_algo_bit rng_core soundcore pcspkr snd_page_alloc i2c_i801
i2c_core serio_raw evdev button processor psmouse shpchp pci_hotplug
ext4 mbcache jbd2 crc16 sg sr_mod sd_mod crc_t10dif cdrom ata_generic
ata_piix uhci_hcd libata ehci_hcd thermal floppy usbcore skge nls_base
scsi_mod thermal_sys [last unloaded: mISDN_core]
[ 6064.545320] Pid: 10371, comm: modprobe Not tainted 2.6.32-5-686 #1
[ 6064.545326] Call Trace:
[ 6064.545348]  [<c103014d>] ? warn_slowpath_common+0x5e/0x8a
[ 6064.545358]  [<c1030183>] ? warn_slowpath_null+0xa/0xc
[ 6064.545370]  [<e4ac8d78>] ? dahdi_register+0x39/0x299 [dahdi]
[ 6064.545390]  [<c126b4e3>] ? printk+0xe/0x13
[ 6064.545410]  [<e09acc34>] ? hfc_probe+0x8db/0xb64 [zaphfc]
[ 6064.545423]  [<e09acd1c>] ? hfc_probe+0x9c3/0xb64 [zaphfc]
[ 6064.545445]  [<c1145895>] ? local_pci_probe+0xb/0xc
[ 6064.545454]  [<c11461df>] ? pci_device_probe+0x41/0x63
[ 6064.545470]  [<c11b2306>] ? driver_probe_device+0x8a/0x11e
[ 6064.545480]  [<c11b23da>] ? __driver_attach+0x40/0x5b
[ 6064.545490]  [<c11b1d49>] ? bus_for_each_dev+0x37/0x5f
[ 6064.545499]  [<c11b21d9>] ? driver_attach+0x11/0x13
[ 6064.545508]  [<c11b239a>] ? __driver_attach+0x0/0x5b
[ 6064.545517]  [<c11b1811>] ? bus_add_driver+0x99/0x1c5
[ 6064.545527]  [<c11b260b>] ? driver_register+0x87/0xe0
[ 6064.545537]  [<c10e8e5f>] ? proc_register+0xf8/0x142
[ 6064.545546]  [<c11463b0>] ? __pci_register_driver+0x33/0x89
[ 6064.545558]  [<e0975000>] ? hfc_init_module+0x0/0x30 [zaphfc]
[ 6064.545568]  [<c100113e>] ? do_one_initcall+0x55/0x155
[ 6064.545578]  [<c1057135>] ? sys_init_module+0xa7/0x1d7
[ 6064.545591]  [<c10030fb>] ? sysenter_do_call+0x12/0x28
[ 6064.545598] ---[ end trace 48ca2bdcff2ea5ef ]---


Immediately after starting Asterisk:
root@debian:/# asterisk -rvvvvvvvvv
Asterisk 1.6.2.9-2, Copyright (C) 1999 - 2010 Digium, Inc. and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty'
for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it
under
certain conditions. Type 'core show license' for details.
=========================================================================
  == Parsing '/etc/asterisk/asterisk.conf':   == Found
  == Parsing '/etc/asterisk/extconfig.conf':   == Found
Connected to Asterisk 1.6.2.9-2 currently running on debian (pid = 10833)
Verbosity was 0 and is now 9
debian*CLI> pri set debug 2 span 1
Enabled debugging on span 1
1 Sending TEI management message 1, TEI=127
1 TEI: 0 State 2
1 V(S) 0 V(A) 0 V(R) 0
1 K 1, RC 0, l3initiated 0, reject_except 0 ack_pend 0
1 T200 0, N200 3, T203 0
1
1 > [ fc ff 03 0f 07 c5 01 ff ]
1
1 > Unnumbered frame:
1 > SAPI: 63  C/R: 0 EA: 0
1 >  TEI: 127        EA: 1
1 >   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
1 > 5 bytes of data
1 > MDL Message: TEI Identity Request (1)
1 > RI: 1989
1 > Ai: 127 E:1
1 Sending TEI management message 1, TEI=127
1 TEI: 0 State 2
1 V(S) 0 V(A) 0 V(R) 0
1 K 1, RC 0, l3initiated 0, reject_except 0 ack_pend 0
1 T200 0, N200 3, T203 0
1
1 > [ fc ff 03 0f 21 6d 01 ff ]
1
1 > Unnumbered frame:
1 > SAPI: 63  C/R: 0 EA: 0
1 >  TEI: 127        EA: 1
1 >   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
1 > 5 bytes of data
1 > MDL Message: TEI Identity Request (1)
1 > RI: 8557
1 > Ai: 127 E:1
[Oct  2 17:17:36] ERROR[10870]: chan_dahdi.c:12393 dahdi_pri_error: 1
Unable to receive TEI from network!
debian*CLI>



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dahdi-source depends on:
ii  bzip2                         1.0.5-6    high-quality block-sorting
file co
ii  debhelper                     8.0.0      helper programs for
debian/rules
ii  module-assistant              0.11.3     tool to make module package
creati

Versions of packages dahdi-source recommends:
ii  dahdi-linux             1:2.3.0.1+dfsg-1 DAHDI telephony interface -
Linux

dahdi-source suggests no packages.

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>:
Bug#598886; Package dahdi-source. (Sun, 03 Oct 2010 10:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to karl156 <karl156@abwesend.de>:
Extra info received and forwarded to list. Copy sent to Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>. (Sun, 03 Oct 2010 10:33:03 GMT) Full text and rfc822 format available.

Message #10 received at 598886@bugs.debian.org (full text, mbox):

From: karl156 <karl156@abwesend.de>
To: Tzafrir Cohen <tzafrir.cohen@xorcom.com>, 598886@bugs.debian.org
Subject: Re: Bug#598886: dahdi-source: vzaphfc does not work: "Unable to receive TEI from network"
Date: Sun, 03 Oct 2010 12:29:21 +0200
> I suspect this is the making of mISDN. Is this reproducable when mISDN
> is blacklisted?

It also happens when mISDN_core and hfcpci are blacklisted and the dadhi
drivers are started during system startup. The kernel warning then
occurs 4 - 5 seconds after system start.

I could solve the TEI problem with a newer upstream version of vzaphfc.
There is a version specially for dahdi 2.3.0. (A version for 2.4.0 is
also available).

But the kernel warning problem remains. Maybe dahdi 2.4.0 can solve that
problem?




Information forwarded to debian-bugs-dist@lists.debian.org, Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>:
Bug#598886; Package dahdi-source. (Mon, 04 Oct 2010 17:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alex <alex@massive.ch>:
Extra info received and forwarded to list. Copy sent to Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>. (Mon, 04 Oct 2010 17:42:03 GMT) Full text and rfc822 format available.

Message #15 received at 598886@bugs.debian.org (full text, mbox):

From: Alex <alex@massive.ch>
To: karl156 <karl156@abwesend.de>, 598886@bugs.debian.org
Cc: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Subject: Re: Bug#598886: dahdi-source: vzaphfc does not work: "Unable to receive TEI from network"
Date: Mon, 04 Oct 2010 19:30:28 +0200
karl156 wrote:
>> I suspect this is the making of mISDN. Is this reproducable when mISDN
>> is blacklisted?

main suspect is zaphfc!

> It also happens when mISDN_core and hfcpci are blacklisted and the dadhi
> drivers are started during system startup. The kernel warning then
> occurs 4 - 5 seconds after system start.

I only blacklisted hfcpci, thus mISDN doesn't get loaded.

> I could solve the TEI problem with a newer upstream version of vzaphfc.
> There is a version specially for dahdi 2.3.0. (A version for 2.4.0 is
> also available).

Nice!
I can also confirm that the TEI problem can be solved by patching
dahdi-source 2.3.0.1+dfsg-1 zaphfc/base.c with upstream's r8=r9 branch
2.3 (http://zaphfc.googlecode.com/svn).

> But the kernel warning problem remains. Maybe dahdi 2.4.0 can solve that
> problem?

In my case, it is even better than karl's report, as it also got rid of
the warn_slowpath_common. This has been tested on 2 different machines
(w/ and w/o shared irq), although with the same HFC card. I'm using
stock squeeze kernel package (linux-image-2.6.32-5-686 2.6.32-23).

I can make & receive calls over the dahdi channels, so everything looks
good to me. I can even see the callerid being received properly in the
logs (although my dialplan needs more tweaking to handle the callerid
changes occurred since asterisk 1.2, but you don't care).

I didn't try dahdi 2.4 or any other kernel version. I just want a
standard system I can forget and update without thinking too much...

Smallish changes:

$ diff /usr/src/modules/dahdi/drivers/dahdi/zaphfc/base.c
/usr/src/zaphfc-googlecode/branches/2.3/zaphfc/base.c
34a35
> #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 32))
35a37
> #endif
659a662
>       hfccard->span.owner = THIS_MODULE;
701c704
<                       hfccard->sigchan = &hfccard->chans[D];
---
>                       hfccard->sigchan = &hfccard->chans[DAHDI_D];





Information forwarded to debian-bugs-dist@lists.debian.org, Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>:
Bug#598886; Package dahdi-source. (Mon, 04 Oct 2010 17:55:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to karl156 <karl156@abwesend.de>:
Extra info received and forwarded to list. Copy sent to Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>. (Mon, 04 Oct 2010 17:55:07 GMT) Full text and rfc822 format available.

Message #20 received at 598886@bugs.debian.org (full text, mbox):

From: karl156 <karl156@abwesend.de>
To: Alex <alex@massive.ch>
Cc: 598886@bugs.debian.org, Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Subject: Re: Bug#598886: dahdi-source: vzaphfc does not work: "Unable to receive TEI from network"
Date: Mon, 04 Oct 2010 19:53:28 +0200
Alex, can you test long calls?

On my side everything looks good too, but after approximately one minute
of phoning (sometimes more sometimes less) my system freezes.

I could not solve that problem yet, but I think I should file a separate
bug for that.

>> I could solve the TEI problem with a newer upstream version of vzaphfc.
>> There is a version specially for dahdi 2.3.0. (A version for 2.4.0 is
>> also available).
> 
> Nice!
> I can also confirm that the TEI problem can be solved by patching
> dahdi-source 2.3.0.1+dfsg-1 zaphfc/base.c with upstream's r8=r9 branch
> 2.3 (http://zaphfc.googlecode.com/svn).
> 
>> But the kernel warning problem remains. Maybe dahdi 2.4.0 can solve that
>> problem?
> 
> In my case, it is even better than karl's report, as it also got rid of
> the warn_slowpath_common. This has been tested on 2 different machines
> (w/ and w/o shared irq), although with the same HFC card. I'm using
> stock squeeze kernel package (linux-image-2.6.32-5-686 2.6.32-23).
> 
> I can make & receive calls over the dahdi channels, so everything looks
> good to me. I can even see the callerid being received properly in the
> logs (although my dialplan needs more tweaking to handle the callerid
> changes occurred since asterisk 1.2, but you don't care).
> 
> I didn't try dahdi 2.4 or any other kernel version. I just want a
> standard system I can forget and update without thinking too much...
> 
> Smallish changes:
> 
> $ diff /usr/src/modules/dahdi/drivers/dahdi/zaphfc/base.c
> /usr/src/zaphfc-googlecode/branches/2.3/zaphfc/base.c
> 34a35
>> #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 32))
> 35a37
>> #endif
> 659a662
>>       hfccard->span.owner = THIS_MODULE;
> 701c704
> <                       hfccard->sigchan = &hfccard->chans[D];
> ---
>>                       hfccard->sigchan = &hfccard->chans[DAHDI_D];
> 
> 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>:
Bug#598886; Package dahdi-source. (Mon, 04 Oct 2010 23:54:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alex <alex@massive.ch>:
Extra info received and forwarded to list. Copy sent to Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>. (Mon, 04 Oct 2010 23:54:05 GMT) Full text and rfc822 format available.

Message #25 received at 598886@bugs.debian.org (full text, mbox):

From: Alex <alex@massive.ch>
To: karl156 <karl156@abwesend.de>
Cc: 598886@bugs.debian.org, Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Subject: Re: Bug#598886: dahdi-source: vzaphfc does not work: "Unable to receive TEI from network"
Date: Tue, 05 Oct 2010 01:52:56 +0200
karl156 wrote:
> Alex, can you test long calls?
> 
> On my side everything looks good too, but after approximately one minute
> of phoning (sometimes more sometimes less) my system freezes.

Same behaviour here. Kernel panic after calling for a few seconds.
In my case, disabling echo cancellation seems to prevent crashes.

I booted with a serial console after a few worthless crashes (no
capture). I didn't see any solid recurring pattern after 10 crashes.
However, hfc_interrupt is often in the loop (but not always) and oslec
is also often there. See below for one such report.

After looking at those panic calltraces, I disabled echo cancellation
(echocancel=no in /etc/asterisk/chan_dahdi.conf) and my system no longer
crashes during calls. Multiple successive calls of many minutes (tested
up to 10 minutes) can be conducted properly.

Testing other echo cancellers would be next logical step, but I wanted
to share this and see if it can reproduced by someone else.

Seeing quirk_piix4_acpi in the calltrace raises some interrogations
about whether this could be platform specific, maybe caused by pci or
interrupt handling bugs. I just don't know. My test system is an old P3
deskpro EN. Testing other slots in this machine and testing other
machines lying around is on my todo list...

Karl, can you make stable calls if you disable echo cancellation? What
about the hardware you are using? is it also having such "quirks"?

> I could not solve that problem yet, but I think I should file a separate
> bug for that.

I don't know if it's wise to file a debian bug for this, as we're not
using debian-only code to go "that far". Any advice, Tzafrir?

----------

Most crashes were very verbose, so I'll only include one that look
interesting:

[   42.793942] BUG: unable to handle kernel NULL pointer dereference at
000001ff
[   42.797247] IP: [<c1003ec4>] __math_state_restore+0x30/0x67
[   42.797247] *pde = 00000000
[   42.797247] Oops: 0000 [#1] SMP
[   42.797247] last sysfs file: /sys/devices/virtual/vc/vcs3/uevent
[   42.797247] Modules linked in: dahdi_echocan_oslec echo
dahdi_transcode nfsd lockd nfs_acl auth_rpcgss ]
[   42.797247]
[   42.797247] Pid: 1724, comm: check_load Not tainted (2.6.32-5-686 #1)
Deskpro
[   42.797247] EIP: 0060:[<c1003ec4>] EFLAGS: 00210046 CPU: 0
[   42.797247] EIP is at __math_state_restore+0x30/0x67
[   42.797247] EAX: de9d4000 EBX: de9d4000 ECX: de8c0440 EDX: ffffffff
[   42.797247] ESI: de8c0440 EDI: 00000000 EBP: de06a600 ESP: de9d5de4
[   42.797247]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   42.797247] Process check_load (pid: 1724, ti=de9d4000 task=de8c0440
task.ti=de9d4000)
[   42.797247] Stack:
[   42.797247]  00000001 00000000 de9d5e10 00000007 c126d418 de06a600
c126d455 00000000
[   42.797247] <0> c13b323c de06a660 c126d123 de06a660 00000080 de06a700
00000007 00000000
[   42.797247] <0> de06a600 de91900e de9d007b de9d007b de0100d8 000000e0
ffffffff e125d029
[   42.797247] Call Trace:
[   42.797247]  [<c126d418>] ? do_device_not_available+0x0/0x4d
[   42.797247]  [<c126d455>] ? do_device_not_available+0x3d/0x4d
[   42.797247]  [<c126d123>] ? error_code+0x73/0x78
[   42.797247]  [<e125d029>] ? fir16+0x29/0x7c [echo]
[   42.797247]  [<e125d1dc>] ? oslec_update+0x105/0x3a4 [echo]
[   42.797247]  [<e1267025>] ? echo_can_process+0x1f/0x2f
[dahdi_echocan_oslec]
[   42.797247]  [<e0cb8764>] ? __dahdi_ec_chunk+0x181/0x2cb [dahdi]
[   42.797247]  [<e0cfeb12>] ? hfc_interrupt+0x46f/0x565 [zaphfc]
[   42.797247]  [<c106beb5>] ? handle_IRQ_event+0x4e/0x101
[   42.797247]  [<c106d35b>] ? handle_fasteoi_irq+0x66/0x97
[   42.797247]  [<c1004dd7>] ? handle_irq+0x17/0x1b
[   42.797247]  [<c1004659>] ? do_IRQ+0x38/0x89
[   42.797247]  [<c10037f0>] ? common_interrupt+0x30/0x38
[   42.797247]  [<c126007b>] ? quirk_piix4_acpi+0xe9/0x13c
[   42.797247]  [<c126eba2>] ? do_page_fault+0x2d3/0x307
[   42.797247]  [<c126e8cf>] ? do_page_fault+0x0/0x307
[   42.797247]  [<c126d123>] ? error_code+0x73/0x78
[   42.797247] Code: ec 08 89 e3 81 e3 00 e0 ff ff 8b 33 8b 46 04 8b be
94 02 00 00 f6 40 0c 10 74 10 83 c
[   42.797247] EIP: [<c1003ec4>] __math_state_restore+0x30/0x67 SS:ESP
0068:de9d5de4
[   42.797247] CR2: 00000000000001ff
[   42.797247] ---[ end trace 08d004051235b5ca ]---
[   42.797247] Kernel panic - not syncing: Fatal exception in interrupt
[   42.797247] Pid: 1724, comm: check_load Tainted: G      D
2.6.32-5-686 #1
[   42.797247] Call Trace:
[   42.797247]  [<c126b429>] ? panic+0x38/0xe4
[   42.797247]  [<c126da31>] ? oops_end+0x91/0x9d
[   42.797247]  [<c101b5db>] ? no_context+0x105/0x10e
[   42.797247]  [<c101b6f9>] ? __bad_area_nosemaphore+0x115/0x11d
[   42.797247]  [<c126e8cf>] ? do_page_fault+0x0/0x307
[   42.797247]  [<c101b70b>] ? bad_area_nosemaphore+0xa/0xc
[   42.797247]  [<c126d123>] ? error_code+0x73/0x78
[   42.797247]  [<c10800d8>] ? ftrace_format_power_frequency+0x21/0x51
[   42.797247]  [<c1003ec4>] ? __math_state_restore+0x30/0x67
[   42.797247]  [<c126d418>] ? do_device_not_available+0x0/0x4d
[   42.797247]  [<c126d455>] ? do_device_not_available+0x3d/0x4d
[   42.797247]  [<c126d123>] ? error_code+0x73/0x78
[   42.797247]  [<e125d029>] ? fir16+0x29/0x7c [echo]
[   42.797247]  [<e125d1dc>] ? oslec_update+0x105/0x3a4 [echo]
[   42.797247]  [<e1267025>] ? echo_can_process+0x1f/0x2f
[dahdi_echocan_oslec]
[   42.797247]  [<e0cb8764>] ? __dahdi_ec_chunk+0x181/0x2cb [dahdi]
[   42.797247]  [<e0cfeb12>] ? hfc_interrupt+0x46f/0x565 [zaphfc]
[   42.797247]  [<c106beb5>] ? handle_IRQ_event+0x4e/0x101
[   42.797247]  [<c106d35b>] ? handle_fasteoi_irq+0x66/0x97
[   42.797247]  [<c1004dd7>] ? handle_irq+0x17/0x1b
[   42.797247]  [<c1004659>] ? do_IRQ+0x38/0x89
[   42.797247]  [<c10037f0>] ? common_interrupt+0x30/0x38
[   42.797247]  [<c126007b>] ? quirk_piix4_acpi+0xe9/0x13c
[   42.797247]  [<c126eba2>] ? do_page_fault+0x2d3/0x307
[   42.797247]  [<c126e8cf>] ? do_page_fault+0x0/0x307
[   42.797247]  [<c126d123>] ? error_code+0x73/0x78

Two of the crashes had very terse output (single line!):
occurence 1)
BUG: scheduling while atomic: rs:main Q:Reg/1708/0x10010100
occurence 2)
BUG: scheduling while atomic: sh/2443/0x10010000





Added tag(s) pending. Request was from Tzafrir Cohen <tzafrir@debian.org> to control@bugs.debian.org. (Wed, 20 Oct 2010 05:39:05 GMT) Full text and rfc822 format available.

Bug 598886 cloned as bug 601034. Request was from martin.stern@jpberlin.de to control@bugs.debian.org. (Fri, 22 Oct 2010 18:51:01 GMT) Full text and rfc822 format available.

Changed Bug title to 'dahdi vzaphfc: system freezes during longer calls (after approximately one minute)' from 'dahdi-source: vzaphfc does not work: "Unable to receive TEI from network"' Request was from martin.stern@jpberlin.de to control@bugs.debian.org. (Fri, 22 Oct 2010 18:51:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>:
Bug#601034; Package dahdi-source. (Fri, 22 Oct 2010 19:36:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to martin.stern@jpberlin.de:
Extra info received and forwarded to list. Copy sent to Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>. (Fri, 22 Oct 2010 19:36:04 GMT) Full text and rfc822 format available.

Message #36 received at 601034@bugs.debian.org (full text, mbox):

From: martin.stern@jpberlin.de
To: 601034@bugs.debian.org
Subject: Same behaviour here
Date: Fri, 22 Oct 2010 21:33:48 +0200
Hello,

i use cheap HFC-Cards with dahdi and zaphfc here.

andrew:/etc/dahdi# lsdahdi
### Span  1: ZTHFC1 "HFC-S PCI A ISDN card 0 [TE] " (MASTER) AMI/CCS
  1 BRI        Clear       (In use) (SWEC: OSLEC)
  2 BRI        Clear       (In use) (SWEC: OSLEC)
  3 BRI        Hardware-assisted HDLC  (In use)

andrew:/etc/dahdi# lsmod | egrep "dahdi|hfc|echo"
dahdi_echocan_oslec     1038  4
echo                    2988  1 dahdi_echocan_oslec
dahdi_transcode         3802  0
zaphfc                 11961  3
dahdi                 174416  9 dahdi_echocan_oslec,dahdi_transcode,zaphfc
crc_ccitt               1039  1 dahdi


If I set "echocancel=yes" in /etc/asterisk/chan_dahdi.conf my system 
freezes every time after one to two minutes of calling.
After setting "echocancel=no" this problem disappears.

I am not shure if this has really disabled echo cancellation, because, 
even after reboot:
- lsdahdi still shows OSLEC
- Kernelmodules dahdi_echocan_oslec is still in use
- I hear no echo


Regards,
Martin







Added tag(s) wheezy. Request was from Kurt Roeckx <kurt@roeckx.be> to control@bugs.debian.org. (Wed, 16 Feb 2011 19:04:51 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>:
Bug#601034; Package dahdi-source. (Mon, 25 Apr 2011 16:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Teanlorg Chan <alias-bts-5pzpj0srowdc@airsource.co.uk>:
Extra info received and forwarded to list. Copy sent to Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>. (Mon, 25 Apr 2011 16:03:09 GMT) Full text and rfc822 format available.

Message #43 received at 601034@bugs.debian.org (full text, mbox):

From: Teanlorg Chan <alias-bts-5pzpj0srowdc@airsource.co.uk>
To: 601034@bugs.debian.org
Subject: This subject is intentionally left blank.
Date: Mon, 25 Apr 2011 16:29:49 +0100
A little digging reveals a thread [1] reporting similar behaviour (crashes which go away when echo cancellation is disabled). The explanation [2] goes something like this:

> Therefore, oslec most likely is killing the FPU registers since it believes that dahdi-base.c is taking care of saving and restoring them by hand.

The fix is pretty simple:

diff -U3 -r dahdi/drivers/dahdi/Kbuild dahdi.fixed/drivers/dahdi/Kbuild
--- dahdi/drivers/dahdi/Kbuild	2010-08-02 12:09:15.000000000 +0100
+++ dahdi.fixed/drivers/dahdi/Kbuild	2011-04-08 16:27:35.000000000 +0100
@@ -157,7 +157,7 @@
 ifneq (,$(DAHDI_MMX_AUTO))
   ifneq (,$(DAHDI_MMX_CONFIG_VALS))
     DAHDI_USE_MMX=yes
-    CFLAGS_zaptel-base.o += -DCONFIG_DAHDI_MMX
+    CFLAGS_dahdi-base.o += -DCONFIG_DAHDI_MMX
   endif
 endif

It passes the obvious sanity check (there's no reference to "zaptel-base" anywhere else in Kbuild).

Testing this fix is also pretty simple:

1. Get the source and unpack it (you can skip this if it's already been built)
  # m-a unpack dahdi
2. Edit /usr/src/modules/dahdi/drivers/dahdi/Kbuild and replace CFLAGS_zaptel-base.o with CFLAGS_dahdi-base.o
3. Stop asterisk and unload dahdi modules.
4. Rebuild dahdi
  # m-a a-i --not-unpack -f dahdi
5. If things are still broken, reboot. (This might be related to omitting step 3; oops.)

It probably has nothing to do with zaphfc other than that the code happens to run at around the same time; the only crash log I have handy is in "imap-login" which didn't manage to print a backtrace (the other crashes seemed equally unhelpful).

- Teanlorg

[1] http://lists.digium.com/pipermail/asterisk-users/2010-October/thread.html#254817
[2] http://lists.digium.com/pipermail/asterisk-users/2010-October/254890.html




Added tag(s) jessie. Request was from Julien Cristau <jcristau@debian.org> to control@bugs.debian.org. (Thu, 18 Apr 2013 17:41:56 GMT) Full text and rfc822 format available.

Reply sent to Tzafrir Cohen <tzafrir.cohen@xorcom.com>:
You have taken responsibility. (Wed, 28 Aug 2013 14:21:04 GMT) Full text and rfc822 format available.

Notification sent to karl156 <karl156@abwesend.de>:
Bug acknowledged by developer. (Wed, 28 Aug 2013 14:21:04 GMT) Full text and rfc822 format available.

Message #50 received at 601034-done@bugs.debian.org (full text, mbox):

From: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
To: 601034-done@bugs.debian.org
Subject: Re: Bug#601034: zaphfc crashes: it's the MMX issue of OSLEC
Date: Wed, 28 Aug 2013 17:09:57 +0300
Version: 1:2.3.0.1+dfsg-2

On Mon, Apr 25, 2011 at 04:29:49PM +0100, Teanlorg Chan wrote:
> A little digging reveals a thread [1] reporting similar behaviour (crashes which go away when echo cancellation is disabled). The explanation [2] goes something like this:
> 
> >Therefore, oslec most likely is killing the FPU registers since it believes that dahdi-base.c is taking care of saving and restoring them by hand.

See http://bugs.debian.org/593438

This has been fixed in 1:2.3.0.1+dfsg-2 by removing the patch auto_mmx.

I believe that this issue is fixed. Please reopen if necessary.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen@xorcom.com
+972-50-7952406           mailto:tzafrir.cohen@xorcom.com
http://www.xorcom.com



Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 26 Sep 2013 07:28:31 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 07:21:13 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.