Upgraded to dahdi-2.4.0 this morning and noticed that dahdi does'nt like zaphfc anymore. zaphfc module loads and init the card as usual but dahdi complains about invalid spans. A look at the codebase of zaphfc (the URL) showed me that they've enhanced and splitted the zaphfc code to dahdi version 2.2, 2.3 and 2.4 yesterday. As the zaphfc code ist jailed in '99-non-digium-hardware-and-oslec.diff' in Gentoo's dahdi-ebuilds I removed the zaphfc codeparts (Kbuild, Makefile, base.c, fifo.c, fifo.h and zaphfc.h) from there, built a new ebuild and a separate patch for zaphfc based on the new zaphfc branch. The new ebuild compiles and works fine. And as a reward zaphfc is working again. My suggestion is to remove the zaphfc codeparts from '99-non-digium-hardware-and-oslec.diff' and to put them into separate patches. Afterwards the dahdi-ebuilds, which contains the zaphfc code, needs to be rewritten. As a quick'n'dirty example I appended the new patches for zaphfc, separated for dahdi 2.2, 2.3 and 2.4, together with a updated ebuild for dahdi-2.4. Don't wonder about the PATCHES section in the ebuild as I used the unpacked patchset for easier testing there.
Created attachment 247549 [details] updated ebuild for dahdi-2.4.0 with working zaphfc module
Created attachment 247551 [details, diff] zaphfc code for dahdi-2.2 series
Created attachment 247553 [details, diff] zaphfc code for dahdi-2.3 series
Created attachment 247555 [details, diff] zaphfc code for dahdi-2.4 series
Oliver - may I please ask WHERE you got those patches from? The changes from 2.3 here to 2.4 is similar to those I've made. A few questions: 1. Does the spans show in /proc/dahdi? 2. Does dahdi_scan pick them up? 3. Does dmesg report anything strange? Tony - I have no problem with following the suggestion of moving zaphfc into a separate patch permitting we can obtain a reliable upstream to get these patches from. Oliver - can you confirm that if you follow the following procedure: 1. ebuild /path/to/dahdi-2.4.0.ebuild unpack; then 2. remove the 99-non-digium-hardware-and-oslec.diff (presumably in /var/tmp/portage/net-misc/dahdi-2.4.0/work/dahdi-patchset); then 3. Place the 2.4.0 patch into 99-zaphfc in that same folder; then 4. ebuild /usr/portage/net-misc/dahdi/dahdi-2.4.0.ebuild prepare compile merge And then restart the system that it works as expected then?
(In reply to comment #5) > Oliver - may I please ask WHERE you got those patches from? As I mentioned at the beginning: http://code.google.com/p/zaphfc/updates/list This is the official project page. You can get the complete branch via 'svn co http://zaphfc.googlecode.com/svn/' Last update was on 9/15/10 - the day before I was trapped. > The changes from 2.3 here to 2.4 is similar to those I've made. > > A few questions: > > 1. Does the spans show in /proc/dahdi? As I'm working with my patched dahdi-2.4.0, 'cat /proc/dahdi/1' throws out Span 1: ZTHFC1 "HFC-S PCI A ISDN card 0 [TE] " (MASTER) AMI/CCS 1 ZTHFC1/0/1 Clear (In use) (SWEC: OSLEC) 2 ZTHFC1/0/2 Clear (In use) (SWEC: OSLEC) 3 ZTHFC1/0/3 Hardware-assisted HDLC (In use) > 2. Does dahdi_scan pick them up? Yes: [1] active=yes alarms=OK description=HFC-S PCI A ISDN card 0 [TE] name=ZTHFC1 manufacturer=Cologne Chips devicetype=HFC-S PCI-A ISDN location=PCI Bus 04 Slot 06 basechan=1 totchans=3 irq=20 type=digital-TE syncsrc=0 lbo=0 db (CSU)/0-133 feet (DSX-1) coding_opts=AMI framing_opts=CCS coding=AMI framing=CCS > 3. Does dmesg report anything strange? No, clean as a blank white paper: dahdi: Telephony Interface Registered on major 196 dahdi: Version: 2.4.0 vzaphfc: HFC-S PCI A ISDN (V1.42) loading alloc irq_desc for 20 on node -1 alloc kstat_irqs on node -1 vzaphfc 0000:04:05.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 vzaphfc: card 0: registered ZTHFC1/0/1 vzaphfc: card 0: registered ZTHFC1/0/2 vzaphfc: card 0: registered ZTHFC1/0/3 unable to register zaptel device! vzaphfc: card 0: resetting vzaphfc: card 0 configured for TE mode at mem 0xfdcff000 (0xf8468000) IRQ 20 > Oliver - can you confirm that if you follow the following procedure: > > 1. ebuild /path/to/dahdi-2.4.0.ebuild unpack; then > 2. remove the 99-non-digium-hardware-and-oslec.diff (presumably in > /var/tmp/portage/net-misc/dahdi-2.4.0/work/dahdi-patchset); then > 3. Place the 2.4.0 patch into 99-zaphfc in that same folder; then > 4. ebuild /usr/portage/net-misc/dahdi/dahdi-2.4.0.ebuild prepare compile merge > > And then restart the system that it works as expected then? Well, let me check and report this later this day - I've to visit a customer now. When I'm back to home I'll check/update my test-pc as the pc with my patched dahdi-2.4.0 is working in productive environment - stable since opening this bug-request.
(In reply to comment #5) > Oliver - may I please ask WHERE you got those patches from? Oh, wait, maybe you ment where my posted diffs are coming from? They're handmade by me. Diffed manually. Yeah! Could'nt wait as I saw that my test-pc is more or less up-to-date... > 1. ebuild /path/to/dahdi-2.4.0.ebuild unpack; then > 2. remove the 99-non-digium-hardware-and-oslec.diff (presumably in > /var/tmp/portage/net-misc/dahdi-2.4.0/work/dahdi-patchset); then > 3. Place the 2.4.0 patch into 99-zaphfc in that same folder; then > 4. ebuild /usr/portage/net-misc/dahdi/dahdi-2.4.0.ebuild prepare compile merge > And then restart the system that it works as expected then? This isn't working as some things from 99-non-digium-hardware-and-oslec.diff are missing then, i.E. 'obj-$(DAHDI_BUILD_ALL)$(CONFIG_DAHDI_ZAPHFC) += zaphfc/' for dahdi-linux-2.4.0/drivers/dahdi/Kbuild. zaphfc builds and can be loaded but dahdi_scan can't find anything and a (re)start of /etc/init.d/dahdi (or 'dahdi_cfg -s') fails with 'DAHDI_SPANCONFIG failed on span 1: No such device or address (6)'. As I wrote in my 1st post someone needs a 'hfc-free' 99-non-digium-hardware-and-oslec.diff , therefore I enclosed my version of this file as it is missing from my bug-request. The next thing is, that when going through your steps (completed with 98-non-digium-hardware-and-oslec.diff (hfc-free'd) and 99-zaphfc.diff) the patch 99-zaphfc.diff fails as it creates 'dahdi-linux-2.4.0/drivers/dahdi/zaphfc' within '/var/tmp/portage/net-misc/dahdi-2.4.0/work/dahdi-linux-2.4.0' - 'compile' fails then. But when moving things to the right place 'prepare compile merge' works properly, dahdi_scan works, dahdi_cfg inits the card correctly and the sun is shining again :)
Created attachment 249633 [details, diff] hfc-free'd patch
works for me at amd64. Thank you.
> But when moving things to the right place 'prepare compile merge' works > properly, dahdi_scan works, dahdi_cfg inits the card correctly and the sun is > shining again :) can you explain please, which patches i need now, to get dahdi 2.4.0 working again with hfc-hardware? I'm a little bit confued, now :)
(In reply to comment #10) > can you explain please, which patches i need now, to get dahdi 2.4.0 working > again with hfc-hardware? > I'm a little bit confued, now :) Yeah, this is a lil' bit weired. But have a look at http://code.google.com/p/zaphfc/updates/list . There they're sayin' to "take a look at branches 2.3 or 2.4 2.2 doesn't compile on new kernels > 2.6.33 without changes. Status: Fixed". Whatever "Status: Fixed" exactly means ;) But at the end it's easy: If you're using a recent kernel with dahdi-2.3, you should use my dahdi-2.3.0-zaphfc.patch - for dahdi-2.4 use the dahdi-2.4.0-zaphfc.patch . For my needs on 2.6.34 with dahdi-2.4.0 I'm using the appropriate patch from above. It's working stable in production environment on my site 'til now.
Also for me the ebuild in the portage tree does not work. I get 2 times "unable to register zaptel device!" (2 hfc cards installed) kernel: 2.6.35-gentoo-r12, linux-headers-2.6.35, glibc-2.11.2-r3, gcc-4.4.4 After building dahdi-2.4.0 manually by: # tar -xzf /usr/portage/distfiles/dahdi-linux-2.4.0.tar.gz -C /usr/local/src # cd /usr/local/src/dahdi-linux-2.4.0 # wget http://bugs.gentoo.org/attachment.cgi?id=249633 -O 98-non-digium-hardware-and-oslec.diff # wget http://bugs.gentoo.org/attachment.cgi?id=247555 -O dahdi-2.4.0-zaphfc.patch # patch -p1 <98-non-digium-hardware-and-oslec.diff # patch -p1 <dahdi-2.4.0-zaphfc.patch # make && make install rebuilding asterisk by: # emerge =net-misc/asterisk-1.6.2.13-r2 merging /etc/asterisk/dahdi-channels.conf into /etc/asterisk/chan-dahdi.conf remove my first try with an include statement After all of this it seems to work for me. It could certainly be easier with a corrected dahdi-2.4.0.ebuild, but unfortunately I don't know yet how to implement these changes.
Created attachment 255313 [details] updated ebuild for dahdi-2.4.0 Well, new try against the problem about the non-working zaphfc-code. The only things I did are a lil' bit of re-diffing/combining the patches 99-non-digium-hardware-and-oslec.diff and dahdi-2.4.0-zaphfc.patch and putting all the stuff together into gentoo-dahdi-patchset-0.5.tar.bz2 Ebuild compiles fine, zaphfc module loads cleanly and dahdi doesn't complain anything about that. Tested under lab-conditions with hfc-card - but should work in real-life as the previous patches described in this bug 're still working here under daily workload.
Created attachment 255315 [details] patchset #5 for dahdi-2.4.0 ebuild
+*dahdi-2.4.0-r1 (03 Dec 2010) + + 03 Dec 2010; <chainsaw@gentoo.org> +dahdi-2.4.0-r1.ebuild, metadata.xml: + Add USE-flag to enable FXS flash support, closes bug #324879 by Olivier + Voortman. zaphfc fixups by Oliver Jaksch, closes bug #337589.
