Digium released dahdi and dahdi-tools version 2.3.0 on 04/13/2010. The ebuilds shown below are a rebuild from yesterdays release of dahdi-2.2.1.1 ebuild; three patches removed, rest fixed to patch correctly against dahdi-2.3.0. Modifications to ebuild: - SRC_URI of firmwares - patchset set to gentoo-dahdi-patchset-0.2.tar.bz2 (containing the patches posted below) - RDEPEND="" (see bug: http://bugs.gentoo.org/show_bug.cgi?id=315201) Removed patches ('cause already done by Digum): 01-no-autoconf-ktnxbye.diff 04-attr-not-sysfs.diff 05-activate-core-timer.diff Built today and tested on x86_64 with zaphfc - works flawlessy so far. What I observed is that compiling with MAKEOPTS="-j16" on one machine (phenom quad) worked, another machine (sempron) stopped make'in. So I think someone has to optimize parallel-make.diff .
Created attachment 227731 [details] ebuild for dahdi-2.3.0
Created attachment 227733 [details, diff] updated patch for gentoo-dahdi-patchset-0.2
Created attachment 227735 [details, diff] updated patch for gentoo-dahdi-patchset-0.2
Created attachment 227737 [details, diff] updated patch for gentoo-dahdi-patchset-0.2
Created attachment 227739 [details, diff] updated patch for gentoo-dahdi-patchset-0.2
Created attachment 227741 [details, diff] updated patch for gentoo-dahdi-patchset-0.2
Created attachment 227743 [details, diff] updated patch for gentoo-dahdi-patchset-0.2
Created attachment 227745 [details, diff] updated patch for gentoo-dahdi-patchset-0.2
Created attachment 227747 [details, diff] updated patch for gentoo-dahdi-patchset-0.2
Created attachment 227749 [details] ebuild for dahdi-tools-2.3.0
Created attachment 227751 [details, diff] parallel-make patch
Created attachment 227753 [details, diff] ifreq patch
Created attachment 227755 [details, diff] vendorlib patch
Created attachment 227757 [details, diff] no-hardware-fiddling patch
Forgot to mention about changes in dahdi-tools-2.3.0 ebuild: - removed modprobe-suffix.patch (already patched by Digum)
Regarding the build failure on your Sempron system, did it bail out during the src_compile() or the src_install() phase?
(In reply to comment #16) > Regarding the build failure on your Sempron system, did it bail out during the > src_compile() or the src_install() phase? During src_compile() . Re-tried emerging dahdi three times in a row just now but emerge builds fine now. Hell knows why. Sunshine? Laid off icecc? So the following log is from this early morning (GMT+1)
Created attachment 227771 [details] log of dahdi-2.3.0 - ebuild died
I've been bitten by issue 13114 upstream: https://issues.asterisk.org/view.php?id=13114 Attaching three patches to include in the revised gentoo patchset which will hopefully resolve it, although I won't be able to tell until at least a few working days have elapsed. Once I know, I'll post back here and upstream. Note that patch #08 fixes a different bug but affects a common region of code as #09. I determined that it would be easier to simply include the former also as opposed to rolling a new diff for the latter.
Created attachment 230727 [details, diff] SVN r8560
Created attachment 230729 [details, diff] SVN r8575 (drivers/dahdi/voicebus/GpakCust.c)
Created attachment 230731 [details, diff] SVN r8576
Created attachment 230733 [details] Consolidated net-misc/dahdi patchset And here's a patch tarball for net-misc/dahdi-2.3.0 which consolidates everything thus far.
Thanks for your patches. When loading zaphfc on two of my x86_64 machines the kernel Ooopses. Tested with net-misc/dahdi-2.3.0 on 2.6.31-gentoo-r10 and 2.6.32-gentoo-r7. This happens before and again after your patches - so it seems to me that there's a change in dahdi-base.c that breaks compatibility with zaphfc. However, dahdi-2.3.0 with zaphfc works...strange... ------- SNIP ------- vzaphfc 0000:00:0a.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 vzaphfc: card 0: registered ZTHFC1/0/1 vzaphfc: card 0: registered ZTHFC1/0/2 vzaphfc: card 0: registered ZTHFC1/0/3 ------------[ cut here ]------------ WARNING: at /var/tmp/portage/net-misc/dahdi-2.3.0/work/dahdi-linux-2.3.0/drivers/dahdi/dahdi-base.c:5866 dahdi_register+0x3e/0x2fb [dahdi]() Hardware name: ESPRIMO E Modules linked in: floppy(+) ohci_hcd(+) rtc_cmos ppdev k8temp(+) zaphfc(+) snd_intel8x0(+) 8250_pnp 8250 ssb parport_pc serial_core shpchp snd_ac97_codec dahdi ac97_bus Pid: 952, comm: modprobe Not tainted 2.6.32-gentoo-r7 #1 Call Trace: [<ffffffffa0012dd3>] ? dahdi_register+0x3e/0x2fb [dahdi] [<ffffffff81046b9b>] warn_slowpath_common+0x77/0xa4 [<ffffffff81046bd7>] warn_slowpath_null+0xf/0x11 [<ffffffffa0012dd3>] dahdi_register+0x3e/0x2fb [dahdi] [<ffffffffa00bc0bb>] cleanup_module+0xcc7/0xf34 [zaphfc] [<ffffffff81132b2c>] ? sysfs_add_one+0x1c/0x10a [<ffffffff813c355f>] local_pci_probe+0x12/0x16 [<ffffffff813c4225>] pci_device_probe+0x5f/0x89 [<ffffffff8144ad68>] ? driver_sysfs_add+0x4c/0x72 [<ffffffff8144aeb4>] driver_probe_device+0xad/0x15f [<ffffffff8144afbe>] __driver_attach+0x58/0x7b [<ffffffff8144af66>] ? __driver_attach+0x0/0x7b [<ffffffff8144a69d>] bus_for_each_dev+0x4e/0x84 [<ffffffff8144ad1a>] driver_attach+0x1c/0x1e [<ffffffff8144a007>] bus_add_driver+0x11e/0x26f [<ffffffffa00c0000>] ? init_module+0x0/0x43 [zaphfc] [<ffffffff8144b2b2>] driver_register+0xb3/0x121 [<ffffffffa00c0000>] ? init_module+0x0/0x43 [zaphfc] [<ffffffff813c446a>] __pci_register_driver+0x51/0xbc [<ffffffffa00c0000>] ? init_module+0x0/0x43 [zaphfc] [<ffffffffa00c0041>] init_module+0x41/0x43 [zaphfc] [<ffffffff81009060>] do_one_initcall+0x5a/0x14a [<ffffffff810761d6>] sys_init_module+0xd0/0x229 [<ffffffff8100bb2b>] system_call_fastpath+0x16/0x1b ---[ end trace 80acae8327997c5b ]--- vzaphfc: card 0: resetting vzaphfc: card 0 configured for TE mode at mem 0xfc004400 (0xffffc9000007e400) IRQ 17
Created attachment 230767 [details] updated patch-set from http://bugs.gentoo.org/show_bug.cgi?id=315237#c23 As zaphfc-code was in both patches, I merged 98-zaphfc-isdn-bri.diff and 99-non-digium-hardware.diff together and did some cosmetic changes to it.
That's not an oops. Rather, it's a warning triggered by slow path detection code (CONFIG_SLOW_WORK). If you also enable CONFIG_PRINTK_TIME, you'll get an idea of just how slow the path in question is. If you choose to keep this option enabled and the hardware takes some time to initialize then it may well trigger this warning. It is unlikely that it indicates any kind of fault.
Thanks for your explanation. Indeed, CONFIG_SLOW_WORK is enabled, CONFIG_PRINTK_TIME is not. It seems that the first option is hidden or even "hard enabled" as I can't find any switch to disable for tesing purposes (seems to me that it has to be in the /general setup/). Whatever - do you mean that this warning is more a kind of "stupid annoying warning nobody cares of" as it only happens with dahdi-2.3.0 for now (or more precise: a code-fault caused by Digium)?
Search for the option, refer to the "Selected by:" line and you'll find out why it's being forcibly set. I would see it as more of an annoyance than an issue per se and certainly not something that should block this package. On the other hand, if you are encountering this warning only in the current version of dahdi, then I can see no good reason not to mention it upstream. At the very least, it would suggest a minor performance regression during initialisation and, given Digium's track record, who's to say that a bug isn't coming into play? ;) On another note, I'm pleased to say that the most recent three patches I added appear to have resolved the issue with the VPM.
I just realised that I pasted the wrong URL entirely in Comment 19. It should have been: https://issues.asterisk.org/view.php?id=17289
Created attachment 231337 [details, diff] jpah echo canceller needs #include <linux/slab.h> on linux-2.6.34-rcX (and later) drivers/dahdi/dahdi_echocan_jpah.c:79: error: implicit declaration of function 'kzalloc' drivers/dahdi/dahdi_echocan_jpah.c:93: error: implicit declaration of function 'kfree'
Created attachment 231339 [details, diff] jpah and oslec echo cancellers need #include <linux/slab.h> on linux-2.6.34-rcX (and later) rename patch, and fix the same problem in oslec too (now that it is working again). successfully emerged on 2.6.34-rc7 (x86_64)
Created attachment 231455 [details] gentoo-dahdi-patchset-0.2.tar.bz2 Consolidation of all existing patch submissions.
*** Bug 316009 has been marked as a duplicate of this bug. ***
Created attachment 231457 [details] build.log And here is the result of trying to actually build this. Jon reported a similar bug in 2.2.1.1 which never triggered for me; this however fails reproducably even on my dual-core laptop.
(In reply to comment #32) > Consolidation of all existing patch submissions. I do not undertood where the ebuild know about the gentoo-dahdi-patchset-0.2.tar.bz2, but it have problems with the names: * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /mnt/auto/portage/overlays/nicronom.net-testing/net-misc/dahdi-tools/files/dahdi-tools-2.3.0-parallel-make.patch * ( dahdi-tools-2.3.0-parallel-make.patch ) * ERROR: net-misc/dahdi-tools-2.3.0 failed: * Cannot find $EPATCH_SOURCE! In the tar.bz2 is only 06-parallel-make.diff. :-/
(In reply to comment #35) > > Consolidation of all existing patch submissions. > I do not undertood where the ebuild know about the > gentoo-dahdi-patchset-0.2.tar.bz2, but it have problems with the names: gentoo-dahdi-patchset-0.2.tar.bz2 is referenced on lines #21: mirror://gentoo/gentoo-dahdi-patchset-0.2.tar.bz2" #32: PATCHES=( "${WORKDIR}/dahdi-patchset" ) As this ebuild is not in the official portage yet you've to download gentoo-dahdi-patchset-0.2.tar.bz2 manually and to stick it up to the distfiles directory. > * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: > /mnt/auto/portage/overlays/nicronom.net-testing/net-misc/dahdi-tools/files/dahdi-tools-2.3.0-parallel-make.patch > * ( dahdi-tools-2.3.0-parallel-make.patch ) > > * ERROR: net-misc/dahdi-tools-2.3.0 failed: > * Cannot find $EPATCH_SOURCE! > > In the tar.bz2 is only 06-parallel-make.diff. :-/ Gotcha! Chainsaw set the patches to obsolete. I think it was a mistake by him as these patches are still required by dahdi-tools-2.3.0.ebuild for now. At a closer look it was a fault by me to open this bug for two ebuilds - I vow to improve next time... So you'll need to download the following patches to your dahdi-tools/files directory. http://bugs.gentoo.org/attachment.cgi?id=227751 http://bugs.gentoo.org/attachment.cgi?id=227753 http://bugs.gentoo.org/attachment.cgi?id=227755 http://bugs.gentoo.org/attachment.cgi?id=227757 Rebuild the digest for the appropriate ebuild after then and give it a new try.
(In reply to comment #34) > And here is the result of trying to actually build this. > Jon reported a similar bug in 2.2.1.1 which never triggered for me; this > however fails reproducably even on my dual-core laptop. Yeah, this is a weired cryptic thing, really. I've a icecc-cluster with different ARCHs for monts, even for years now, but similar things happens very very rarely. I compiled dahdi-2.2.1.1 many times on this cluster but none unexpected happened 'til now. My 'lab-master' where I build the ebuilds and test them for the very first time is a AMD phenom quad set to MAKEOPTS="-j16" (sometimes set to -j32) and there is a 50:50 chance to compile dahdi-2.3.0 successfully. Today my thought was that the problem has to be found in parallel-make.diff, so I did some very small changes to it (more +$(MAKE) ) and tried it on different machines with MAKEOPTS respectively set to -j16, -j32 and -j64 - and it did it too 100%. Fluke or not? Please give it a try.
Created attachment 232319 [details, diff] new parallel-make patch Hopefully this will fix it
10-echocan-jpah-oslec-add-slab_h-include.patch is currently ignored by epatch, needs to be renamed to ".diff"
jfyi: There's another issue with 2.6.34 (vanilla, amd64): CC [M] /var/tmp/portage/net-misc/dahdi-2.3.0/work/dahdi-linux-2.3.0/drivers/dahdi/voicebus/voicebus.o ERROR: __mcount_loc already in /var/tmp/portage/net-misc/dahdi-2.3.0/work/dahdi-linux-2.3.0/drivers/dahdi/../staging/echo/echo.o This may be an indication that your build is corrupted. Delete /var/tmp/portage/net-misc/dahdi-2.3.0/work/dahdi-linux-2.3.0/drivers/dahdi/../staging/echo/echo.o and try again. If the same object file still causes an issue, then disable CONFIG_DYNAMIC_FTRACE. make[3]: *** [/var/tmp/portage/net-misc/dahdi-2.3.0/work/dahdi-linux-2.3.0/drivers/dahdi/../staging/echo/echo.o] Error 255 make[2]: *** [/var/tmp/portage/net-misc/dahdi-2.3.0/work/dahdi-linux-2.3.0/drivers/dahdi/../staging/echo] Error 2 make[2]: *** Waiting for unfinished jobs.... This happens with CONFIG_DYNAMIC_FTRACE=y and <binutils-2.20 (tried different versions of gcc (4.3.3-r2/4.4.3-r2) and binutils (2.18-r3/.19.1-r1/.20.1-r1)).
ok, ignore the last part, i tried a few more times and it still breaks with newest binutils. MAKEOPTS="-j1" fixes it, so it's just another incarnation of the parallel make error (and the latest 06-parallel-make.diff doesn't help). digging a bit deeper: 04-enable-oslec-in-kbuild.diff adds (to drivers/dahdi/Kbuild): +obj-m += dahdi_echocan_oslec.o +obj-m += ../staging/echo/echo.o 99-non-digium-hardware.diff adds (to drivers/dahdi/Kbuild): +obj-$(DAHDI_BUILD_ALL)$(CONFIG_ECHO) += ../staging/echo/ +obj-$(DAHDI_BUILD_ALL)$(CONFIG_DAHDI_ECHOCAN_OSLEC) += dahdi_echocan_oslec.o which results in ... CC [M] /var/tmp/portage/net-misc/dahdi-2.3.0/work/dahdi-linux-2.3.0/drivers/dahdi/../staging/echo/echo.o LD [M] /var/tmp/portage/net-misc/dahdi-2.3.0/work/dahdi-linux-2.3.0/drivers/dahdi/dahdi_vpmadt032_loader.o CC [M] /var/tmp/portage/net-misc/dahdi-2.3.0/work/dahdi-linux-2.3.0/drivers/dahdi/../staging/echo/echo.o ... for -jX (X > 1) we seem to have two processes entering the same directory and overwriting each other's files. i've disabled the two lines in the 99*.diff and managed to successfully emerge the package a couple of times without errors, with -j5 set.
Created attachment 232713 [details] updated patchset changes: dropped 04-enable-oslec-in-kbuild.diff (see below) latest parallel-make patch patches < 99 renumbered 99-non-digium-hardware.diff renamed and "echo.o" appended to "obj-$(DAHDI_BUILD_ALL)$(CONFIG_ECHO)", to match 04-enable-oslec-in-kbuild.diff survived five rounds of MAKEOPTS="-j5" emerging on my 2.6.34 box
Created attachment 232739 [details] gentoo-dahdi-patchset-0.2.tar.bz2 Updated for compatibility with 2.6.35-rc0. Filed upstream bug reports: https://issues.asterisk.org/view.php?id=17382 https://issues.asterisk.org/view.php?id=17383 Please test & confirm that I have not broken your older kernels; I will commit once I receive two positive reports.
compile tested on (amd64): 2.6.34 2.6.32.9 2.6.31.2 2.6.29.2(-grsec)
Basic operational tests conducted with a Wildcard TE122 + VPMADT032 module without issue. As far as I'm concerned, chocks away!
+*dahdi-2.3.0 (24 May 2010) + + 24 May 2010; <chainsaw@gentoo.org> +dahdi-2.3.0.ebuild: + Version bump. With many thanks to Oliver Jaksch, Stefan Knoblich, Jaco + Kroon & Kerin Millar for research, patches & testing. Closes bug #315237. Could we please keep to one bug per package gentlemen; your work on dahdi-tools is appreciated but should be in a separate report.
Created attachment 232765 [details, diff] add non-digium modules to dahdi.blacklist.conf too Add zaphfc and wcopenpci to the modprobe.d/dahdi.blacklist.conf file that prevents udev module coldplugging from messing up the span order (or in my case: mISDN and zaphfc trying to use the same card)
