net-misc/dahdi-2.4.0-r1 does not support all junghanns.net *BRI ISDN adapters out of the box. junghanns.net has published a driver package which can be included in net-misc/dahdi's build process. The patch I am going to add allows to select these drivers using the bri USE flag. The driver works well for my junghanns.net duoBRI on hardened AMD64 with net-misc/dahdi-2.4.0 and hardened-sources-2.6.36-r9. Reproducible: Always Steps to Reproduce:
Created attachment 262001 [details, diff] Include junghanns.net drivers for their *BRI cards in net-misc/dahdi-2.4.0-r1
Thanks for submitting your patch for additional driver support -- assigning to dahdi maintainers
Created attachment 267741 [details, diff] dahdi-2.4.0-r1.ebuild-jnet.patch alternative patch eliminating the USE flag which Tony (and I have to agree) doesn't like (and USE=bri is misleading anyway, to say the least, USE=jnet would be better but we prefer either providing a driver or not). This patch will cause the jnet drivers to be added unconditionally, however, at least on a 2.6.38 kernel this fails to compile with: CC [M] /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/qozap.o /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/cwain.c: In function 'cwain_isr_sync': /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/cwain.c:1206:5: warning: suggest parentheses around operand of '!' or change '&' to '&&' or '!' to '~' /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/cwain.c: In function 'cwain_dfifo_tx': /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/cwain.c:505:1: warning: the frame size of 4112 bytes is larger than 2048 bytes /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/cwain.c: In function 'cwain_dfifo_rx': /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/cwain.c:643:1: warning: the frame size of 4112 bytes is larger than 2048 bytes /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/qozap.c: In function 'ztqoz_startup': /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/qozap.c:1324:2: error: implicit declaration of function 'set_current_state' /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/qozap.c:1324:20: error: 'TASK_UNINTERRUPTIBLE' undeclared (first use in this function) /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/qozap.c:1324:20: note: each undeclared identifier is reported only once for each function it appears in /var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/qozap.c:1325:2: error: implicit declaration of function 'schedule_timeout' make[2]: *** [/var/tmp/portage/net-misc/dahdi-2.4.0-r2/work/dahdi-linux-2.4.0/drivers/dahdi/qozap.o] Error 1 Which for me personally is a killer. The following comment in the jnet installer.sh also worries me: # make sure that qozap is the only driver for the hfc chipsets It then proceeds to blacklist other modules which I use, including the wcb4xxp module which is a known good module (ie, I would prefer the wcb4xxp module over anything anybody else provides). Note that we don't actually call the script, but still, the above implies that if qozap gets loaded before wcb4xxp it will "steal" devices normally supported by wcb4xxp. Lastly, would you mind testing the above patch on the same kernel that you used to build the other ebuild with? And then please post the output of the "dahdi_hardware" command after merging it please. This needs to be on a box that has a jnet supported card in it, that is not supported by wcb4xxp at all please. Looking at the code this still looks like a zaptel aged driver that is just being kept together with duct tape in order to compile with newer dahdi and kernel versions. I guess the same goes for most other not in tree drivers though. Tony: If we do end up merging this we need to remember to add cwain, qozap and ztgsm to dahdi.blacklist.conf in dahdi-tools.
Well Tony, You're not going to believe what I just found in the office here: 04:04.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller [HFC-4S] (rev 01) Which has a nice big junghanns sticker on it :). Also have a single port zaphfc card here, both in a box so I'll be able to QA this for you permitting I can get the junghanns code to compile. The test box in this case has a 2.6.35-uls (vanilla + a few basic patches for fbconndecor), so may just work. Should be able to at least do compile-tests on 2.6.38 kernels if that's OK with you? Jaco
OK, compile failure against 2.3.36 too. Will be able to cook up a patch later hopefully, however, if we're aiming at dahdi-2.4.1 we might just as well use the newer code for jnet too (dahdi 2.4.1 support) which may avoid having to cook the patch altogether. Please advice the direction you'd like me to take on this.
I aim to release a 2.4.1 as opposed to another 2.4.0; and my compile target is 2.6.38 or newer. If this can be made to work in that environment, excellent. It may have to miss the initial 2.4.1 ebuild based on the amount of love it needs though.
Felix - could you please post the output of the dahdi_hardware command? My junghanns quad port card works with the wcb4xxp driver in dahdi-2.4.0 as it is in Gentoo (it didn't previously work with dahdi 2.2 and 2.3 which is why I was actually looking towards this bug as a resolution for me on that card). I still need to do a cabled test to make sure I can make/receive calls using the card, but so far my experience has been that if I actually get a span from loading the drivers it tends to "just work". From my dahdi-autoconf startup script: * Found Junghanns QuadBRI ISDN card at pci:0000:04:04.0 (module: wcb4xxp) Hopefully I'll get round to doing a cable-test before or on Wednesday but I'll first need to figure out and test a bug I've got in my auto configuration script (seems to be generating illegal configs at the moment).
Additional information is needed about the hardware in question which has not been provided. Please reopen the bug once you have answered Jaco's queries.
My junghanns.net duoBRI reports as follows: # dahdi_hardware pci:0000:05:04.0 qozap- 1397:08b4 Generic Cologne ISDN card
Felix, Looking at the dahdi-linux-2.4.1 source for wcb4xxp (Module typically used for Digium B410P cards) the PCI id is included in the supported pci id list for the module - can you please test whether the wcb4xxp module as currently included with dahdi-2.4.1?
Using wcb4xxp module does not start the adapter. /proc/dahdi remains empty, so does dahdi_tool. Restarting /etc/init.d/dahdi reports "No such device or address (6)". Loading qozap module works.
Felix - is this with dahdi 2.4.1 or 2.4.0? I only checked the 2.4.1 source. If with 2.4.1 can you please provide an updated patch for patching dahdi 2.4.1 instead of 2.4.0?
Jaco - yes, this is with dahdi-2.4.1, patch using jnet USE flag instead of bri follows. This patch applies, compiles and installs cleanly.
Created attachment 279707 [details, diff] dahdi-2.4.1.ebuild-jnet.patch Patch including junghanns.net drivers 1.0,4 into dahdi-2.4.1 using jnet USE flag.
Created attachment 283097 [details, diff] Includes junghanns.net *BRI drivers into net-misc/dahdi Since the older patches obviously did not make it into main portage tree I make another attempt by supplying a patch for the latest stable net-misc/dahdi ebuild (2.4.1-r1 at this time). It also includes latest published junghanns.net driver package 1.0.11. It compiles and installs at hardened amd64 without problems.
(In reply to comment #15) > Created attachment 283097 [details, diff] > Includes junghanns.net *BRI drivers into net-misc/dahdi Thank you, this is looking much easier to integrate. I am working on 2.5.0-r1 which will have this.
+*dahdi-2.5.0-r1 (02 Sep 2011) + + 02 Sep 2011; Tony Vroon <chainsaw@gentoo.org> +dahdi-2.5.0-r1.ebuild: + Add support for junghanns.net BRI adapters, ebuild work by Felix Tiede closes + bug #354321. Stop calling CC/LD directly, closes bug #376705 by Agostino + "ago" Sarubbo. Drop unnecessary patch from set, as per Erik Wallin in bug + #381335. I have not added a USE-flag, I much prefer unconditional patching. It is nice to offer people the Just Works(TM) experience.
