Capisuite (net-dialup/capisuite-0.4.5) appears to work properly but crashes without any kind of error message after receiving its first fax or voice call of the session. The kernel (dmesg) seems to mention it simply disappeared. Reproducible: Always Steps to Reproduce: 1. Install, configure and start Capisuite 0.4.5 as normal. 2. Send a fax or dial and wait for the answering machine and finish the fax or voice call as normal. 3. Check if capisuite is still running ('pgrep capisuite' ought to do it) or try to call/fax again Actual Results: Capisuite stops without writing anything to its logs. See further at "Additional Information". Expected Results: Keep running, for one thing, but also deliver the generated fax/voice file (PDF/ wav) to the appropriate user through local e-mail. I (and at least one other user) did however notice it didn't write descriptive . txt files for every fax or voice file in the user directory (/var/spool/ capisuite/users/<user>/received), which it does even before it mails the generated voice/fax file. Interestingly, when I call the answering machine and type in the PIN number, Capisuite hangs up and does produce useful information in its <capisuite.log> (though oddly not in <capisuite.error>). I will submit redacted log excerpts as attachments to this bug report shortly. Re. Severity: Capisuite doesn't appear to lose data, but prevents me from receiving (fax) data.
As a workaround I recommend you to use capi4hylafax in the meantime. I do not knwo what the issue is caused by, do you have any idea? Also is there an upstream(as in capisuite website) bug about this?
Created attachment 57621 [details] Excerpt from </var/log/capisuite.error>. This </var/log/capisuite.error> log excerpt show what happens when I call the answering machine and then dial the PIN number: it fails to find </var/spool/capisuite/users/<user>/received/voice-4.txt> while trying to play back that particular voice message.
Created attachment 57622 [details] Excerpt from </var/log/capisuite.log> According to isdncause, "Reason 0x301" translates to: Location: (unknown location 33) Cause: Invalid Call reference value. After that last entry, Capisuite dies.
Created attachment 57623 [details] Excerpt from </var/log/messages> Apparently shows that Capisuite never got round to detaching itself from the CAPI driver.
Re comment #1: This is already being discussed by two *Gentoo* users on the capisuite-users mailing list (and we both brought up the issue independently of one another) but as yet no users of other operating systems have come forward with similar experiences. The absence of the .txt files describing received voice/fax files made it rather clear the problem is in Gentoo specifically and not in Capisuite in general. I may be wrong, but by all current indications, I may as well not be. (I may look into capi4hylafax, but I'd rather have Capisuite fixed.)
Well, there was a patch for the new capi20 V3 (20050322). The API/ABI has changed a little, but the patch is straight forward. Ok, please try to emerge the old capi4k-utils (capi4k-utils-20041006-r5) and re-emerge capisuite. Then test it again. If it works, then emerge the latest capi4k-utils-20050322-r1 and re-emerge capisuite once again. If you can now reproduce the error, then we know where to seek. Unfortunately, capisuite is unmaintained right now. So an upstream-patch for the new capi20 V3 will not be available anytime soon, at least until there's a new maintainer. So we have to get this working somehow... :-/
I have tried with capi4k-utils-20041006-r5 now, and I am seeing the exact same problem with this *stable* package. I will post more local system info shortly.
Created attachment 57674 [details] Current `emerge info' output from the system on which the problem occurs.
which ISDN card do you use and which driver?
furthermore: what's the output of 'capiinfo'
Created attachment 57680 [details] Output of 'capiinfo'
The controller is an AVM B1 ISA, properly configured.
'capiinit status' says: 1 b1isa running b1isa-150 B1 3.09-10 0x150 4 r255 'capiinit show' says: driver firmware proto io irq mem cardnr options b1isa b1.t4 DSS1 0x150 4 - - P2P
B1 is ok. T.30 Fax support is available. ;) But: > b1isa b1.t4 DSS1 0x150 4 - - P2P P2P? Leased-Line (Point-to-Point)? Is this correct? I have a B1 PCI V3, so I will test it ASAP (gimme some time, I have to setup anything first). But I don't have a leased-line...
Yes, indeed the problem is with Capisuite and NOT with the hardware. I could install the other B1 ISA I borrowed for testing, but I am pretty sure all the kernel / driver output points to the fact that Capisuite inexplicably quits. The controller, on the other hand, just keeps running and (for instance) keeps reporting incoming and outgoing calls occurring on the local S0 bus. The features you saw are options. Using P2P is optional, and so is the leased line functionality.
I know what P2P means. But I wonder, that you need that option at all. ;) I live in Germany and P2P is very uncommon, at least for regular BRI installations at home. You need a leased-line to use this. But I trust you, that this option is OK for your installation in Holland. But I can't use it here, it just won't work. ;) Tommorrow is sunday and with my ISDN XXL tariff, I can test it tomorrow for free. No matter how much calls I have to do. :-D So I will give you feedback tomorrow. But another question: did it worked already in the past? if, with which version of capisuite and capi4k-utils?
The optional P2P functionality is in the proprietary firmware that runs on the controller, provided by AVM. It's the file <b1.t4> that comes in the (current) Gentoo package net-dialup/isdn-firmware-2004.4.5-r1. AFAIK there is no other firmware available for the AVM B1 ISA. I have downloaded ftp://ftp.avm.de/cardware/b1/linux/suse.81/b1-suse8.1-03.10.02.tar.gz and I will give the firmware file in there a try now. Which reminds me -- unloading the capi service (</etc/init.d/capi>) gives very ugly results: capiinit crashes and it's generally a mess. Should I open another bug for that or is this to be considered cosmetic?
I get the same problem with Capisuite using firmware: Manufacturer Version: 3.100-02 (49.2) which incidentally also has the P2P option. BTW, AFAIK P2P is just another way of writing PPP, which is very much something you'd want to have if you dial in to the 'Net using an ISDN controller.
No, you're totally wrong. P2P has *nothing* to do with PPP and is also not a special "feature" of the b1.t4 firmware. It's a different protocol variant spoken on the D-Channel. If you don't have a leased-line, you *have* *to* disable it. On a regular BRI ISDN-line you can have Point-to-Multipoint (default, regular dialup to any other phone line) *or* Point-to-Point (P2P, two fixed end-points), but not both. For the other problem with capiinit: I can not reproduce it here. All my AVM cards (not just B1, but also C2, Fritz!Card PCI, Fritz!Card USB V2.0 and BlueFRITZ!) are working properly and capiinit doesn't segfaults, even on amd64 (for supported card on this platform). The old capi4k-utils-20041006-r5 had a problem with capiinfo, which segfaulted if you had more than one controller. But this issue is fixed with capi4k-utils-20050322-r1.
I still don't get what the firmware has to do with it. AFAICT I am using the latest version (Can I get some feedback on this?) and I have not set any special features myself, so I am at a loss as to how this ended up in </etc/capi.conf> (where I found it now that you mentioned it). Apparently it's a default for just the b1isa: ------------------- ### AVM B1 (you also have to install the firmware) b1isa b1.t4 DSS1 0x150 4 - - P2P ------------------- I will remove that feature and then check if Capisuite still has problems.
Removing "P2P" from the b1isa line in </etc/capi.conf> did not solve the problem.
I test capisuite in a few hours (after sleep). But: what is the "ugly" output of capiinit you talked about? capiinit should not segfault at all, no matter if you use the old or the new version. I've never seen that neither on x86 nor on amd64. Which platform do you use? And what are your CFLAGS?
btw: the firmware b1.t4 is the *whole* CAPI-implementation for the B1. The kernel-driver 'b1pci' or 'b1isa' just routes the CAPI-Mesages to the B1-card. The B1 is an active controller with its own CPU. This is totally different compared to passive cards, where the kernel-driver implements the CAPI-stuff. btw^2: the entries in /etc/capi.conf are an *example*. You always have to setup it correctly. The P2P option is available for most AVM cards, even the passive ones. You are the first I've met, who were fooled by this. ;) So I will add a hint to /etc/capi.conf, that P2P should only used on leased-lines. And I'm quite sure, that 99,9% of the users don't have an ISDN leased-line (which you have to order from your Telco).
Re #22: The 4th attachment I posted contains my emerge info, which should tell you all about the platform and CFLAGS. The suspicious bits I see are -funroll-loops in CFLAGS and USE="nptl nptlonly" (the latter ones may have an effect on Capisuite itself). The ugly output is not just a very good segfault that seemingly occurs in either a module (capidrv is being unloaded) or in capiinit, but it also shows that the service unload order is wrong. For instance, Gentoo tries to unload capi before it unloads isdnlog. Or maybe the isdn service hasn't done its job properly. I am attaching another excerpt from </var/log/messages> with part of the ugly output, quickly generated by stopping the capi service while dependent services are also running, using the command '/etc/init.d/capi stop'. AFAIK, it should stop dependent services on its own. Re #23, btw1: Er, I know all that. I think I have establish that the firmware is not at fault here, and that is the end of that matter. Re #23, btw1: IMHO sane defaults should be used as (commented out) examples. If the sane default is not to switch on the P2P option, then the P2P option has no place in a config file with (commented out) defaults. Whoever needs such an extra option to be switched on can find all the necessary information on the 'Net or acquire this information from the hardware vendor.
Created attachment 57697 [details] Excerpt from </var/log/messages> showing what happens when the 'capi' service is normally stopped when dependencies are running
OK, with a little sleep behind me, I now see it very clearly: Gentoo stops the services in this order: capisuite CAPI (/etc/init.d/capi) ... isdnlog isdn Both pairs of services are dependent among themselves, but since isdn is dependent upon capi, it should be stopped / unloaded first. General question: I guess capisuite has capi in its dependencies and isdnlog has isdn in its dependencies. So 1) should I remove capi and isdn using rc-update and let the system figure that out by itself? 2) How do I fix any dependency problems myself?
1. your CFLAGS looks sane (though I wouldn't use -funroll-loops). Also 'ntpl ntplonly' is no problem, I use that also. 2. segfault in capiinit shoudn't happen at all and I've never seen that before 3. stopping order problem is solved yet (since 2 weeks) in my upcoming isdn4k-utils (will be released ASAP), so next version in portage will stop anything in the right order. For now, you can add a 'need capi' to /etc/init.d/isdn, that should solve it immediately for you. 4. the examples in /etc/capi.conf are taken 1:1 from the example file included in the capi4k-utils packages. The installed version is just a little bit expanded by us to also have the passive cards from fritzcapi and fcdsl in. btw: capi4k-utils is written and maintained by AVM, the same vendor as of your ISDN-card. But we will add some hints and explainations in capi.conf, so the issue should be solved then. 5. The firmware should be ok, since I used it also (until I switched to Fritz!Card USB v2.0 on my server becaue I needed the PCI-slot otherwise) 6. capisuite test report follows...
ok, now my capisuite test report. All tests are done with a Fritz!Card USB V2.0, using the fritzcapi driver 'fcusb2' and the firmware 'fus2base.frm'. This driver is AVM propritary closed-source, but offers the same functionality as the AVM B1 (T.30 Fax G3, etc.). If needed, I can repeat the tests with an AVM B1 PCI V3.0, an AVM C2 and an AVM Fritz!Card PCI. But I think my tests are absolutely significant, so I'm sure the results would be 100% the same. I installed latest (means ~x86) capi4k-utils in portage, latest capisuite, latest fritzcapi, latest hylafax and latest capi4hylafax. All packages are setup correctly. capi4hylafax/hylafax were working properly already, so I can be sure that all drivers and hardware-installation are correctly working. 1. capisuite voicebox: works perfectly, I got an email with a WAV file, which could be played w/o any problems. 2. capisuite fax: First I sent a fax via my Windows-PC. No problems at all, I got the fax via email as a PDF which could be viewed with i.e. KPDF. 3. capisuite fax: Now I sent a fax via 'c2faxsend' from the capi4hylafax package to capisuite. Same result as in 2. 4. capisuite fax: I sent a fax via 'capisuitefax' to capisuite. Same Result as in 2. 5. capi4hylafax: I sent a fax via 'capisuitefax' to hylafax. Fax was received properly. 6. capi4hylafax: I sent a fax via 'c2faxsend' to hylafax. Fax was received properly. So all I can say is: 1. capisuite voicebox works 2. capisuite fax receiving works 3. capisuite fax sending works 4. capi4hylafax fax receiving works 5. capi4hylafax fax sending works 6. capi4hylafax and capisuite are working smoothly together, even on the same machine. 7. I have no segfaults at all That proves that all packages in portage are perfect and don't have any problems if installed and configured properly. You should do the following: 1. revdep-rebuild 2. emerge --update --deep --newuse world 3. emerge again isdn-firmware, capi4k-utils, capisuite, isdn4k-utils 4. setup all packages *correctly* There's nothing we can do else for you. Beside the corrections mentioned above in comment #27 of course.
So you have proven that it *can* work. That's wonderful, but it does not solve my problem. I am currently running revdep-rebuild and it found four broken dependencies that are irrelevant to Capisuite: broken /usr/bin/c2faxrecv (requires libcapi20.so.2) broken /usr/bin/c2faxsend (requires libcapi20.so.2) broken /usr/X11R6/bin/c2faxrecv (requires libcapi20.so.2) broken /usr/X11R6/bin/c2faxsend (requires libcapi20.so.2) These belong to capi4hylafax, which is installed but which I haven't used up to this point. They don't belong to Capisuite, and are not used by Capisuite. I'll let revdep-rebuild remerge capi4hylafax for now, but I don't think that will help the Capisuite problem. What I still think might be going wrong is that a binary in Capisuite fails to use some system function that your system has but my system does not have. Capisuite doesn't show any Python-related errors, so it must be somewhere within a Capisuite binary.
Btw, I don't really understand the sudden "we" (being you) as opposed to myself (JeR). I think we are both working on this problem with one or more packages in Gentoo Linux. Solving my particular problem (which at least one other Gentoo user experiences as well) would be just a very lucky side effect for me. You (singular) seem to be giving up, which I frankly cannot begin to understand. I don't need this fixed for my own purposes, as running a fax/answering server isn't even something I really need. I'm just having fun. Are you? And in fact there is a lot you could do, like telling me what kernel, glibc, gcc, boost, python, sfftobmp, ... versions *you* use. In order to compare a working Capisuite with a non-working Capisuite properly, it would be beneficial for me to know more about the relevant environment Capisuite *does* work properly in. There may be telling differences, and it would at least allow me to recreate the relevant parts of your system to see if that solves my problem and in the process sheds light on the requirements for Capisuite to work, which would help develop Capisuite and the capisuite packages in Gentoo Linux. Re configuration: I have gone over and over all relevant configuration files and I haven't found anything that might indicate a problem. In fact everything works, even recording a new answering machine response message </var/spool/capisuite/users/jeroen/announcement-tmp.la>, up to the point of actually putting it in place. Also we already know Capisuite doesn't write .txt files for otherwise properly received fax and voice messages, and that it doesn't write the appropriate PDF and WAV files either. There are lots of clues there and they occured on two distinct Gentoo Linux systems in distinct locations (NL and Germany) using distinct CAPI-capable ISDN controllers. FYI, I here reproduce Bernd Wurst's message to the capisuite-users mailing list: ----------------------------------------------------------- Hallo. Ich nutze Capisuite schon l
Btw, I don't really understand the sudden "we" (being you) as opposed to myself (JeR). I think we are both working on this problem with one or more packages in Gentoo Linux. Solving my particular problem (which at least one other Gentoo user experiences as well) would be just a very lucky side effect for me. You (singular) seem to be giving up, which I frankly cannot begin to understand. I don't need this fixed for my own purposes, as running a fax/answering server isn't even something I really need. I'm just having fun. Are you? And in fact there is a lot you could do, like telling me what kernel, glibc, gcc, boost, python, sfftobmp, ... versions *you* use. In order to compare a working Capisuite with a non-working Capisuite properly, it would be beneficial for me to know more about the relevant environment Capisuite *does* work properly in. There may be telling differences, and it would at least allow me to recreate the relevant parts of your system to see if that solves my problem and in the process sheds light on the requirements for Capisuite to work, which would help develop Capisuite and the capisuite packages in Gentoo Linux. Re configuration: I have gone over and over all relevant configuration files and I haven't found anything that might indicate a problem. In fact everything works, even recording a new answering machine response message </var/spool/capisuite/users/jeroen/announcement-tmp.la>, up to the point of actually putting it in place. Also we already know Capisuite doesn't write .txt files for otherwise properly received fax and voice messages, and that it doesn't write the appropriate PDF and WAV files either. There are lots of clues there and they occured on two distinct Gentoo Linux systems in distinct locations (NL and Germany) using distinct CAPI-capable ISDN controllers. FYI, I here reproduce Bernd Wurst's message to the capisuite-users mailing list: ----------------------------------------------------------- Hallo. Ich nutze Capisuite schon länger und hatte schon manchmal Probleme mit dem FritzCard-Binärtreiber, aber so wie jetz twar es noch nie. ;-) Also, seit etwa einer Woche kann mein Capisuite kein Fax mehr annehmen. Wenn ein Fax reinkommt, wird das ordnungsgemäß angenommen und als SFF gespeichert. Beim Empfänger wird die Übertragung als "Ok" eingestuft. Die SFF-Datei kann danach problemlos nach TIFF und PDF konvertiert werden. Danach ist der Capisuite-Prozess aber weg, in der Logfile kein weiterer Kommentar. Die .txt-Datei mit den Infos wird *nicht* erstellt, daher glaube ich, dass der Fehler noch vor dem Konvertieren auftritt. Was ich zu dem Zeitpunkt getan habe, seit das Fax nicht mehr geht, war, dass ich vom capisuite 0.4.4 auf 0.4.5 geupdated habe. Ein Downgrade hat aber nichts geholfen. Zum Test habe ich bereits die FritzCard USB durch eine FritzCard PCI ersetzt, das hat aber nichts geändert (bis auf das Problem, dass dann der PPPd nicht mehr per DSL einwählen wollte) (!). Kernel habe ich auch geändert und neu kompiliert (2.6.11 => 2.6.11.7), kein Erfolg, Capi-Treiber-Module habe ich alle neu erstellt, ebenfalls nichts geändert. Jetzt bin ich mit meinem Latein am Ende. Anrufbeantworter funktioniert einwandfrei. Hat jemand ne Idee, wo ich da weiter suchen kann? Im Anhang ein Ausschnitt der Log-Datei mit exzessiv-Logging. Danach ist sofort Ende, ohne weitere Meldungen. In der capisuite.error wird nichts geloggt ausser "Capisuite started". cu, Bernd -----------------------------------------------------------
Created attachment 57743 [details] Bernd Wurst's capisuite.log excerpt as sent to the capisuite-users mailing list
Bernd Wurst: Have you solved the problem already? I suggest you to try commenting out the patches in capisuite, to see if they are the culprits .. I suspect capisuite-fax-compatibility.patch of making problems..
I can leave a comment for myself if this helps solving this issue. ;-) Ok, for short: I have two gentoo linux boxes acting as home-servers, both have ISDN connectivity and one of them works and one doesn't. Both systems are up-to-date. The one that shows the mentioned problem has a FritzCard USB (v1) and I also tried a FC-PCI without success. I'm sorry to say that the one box I have physical access to is the one that works, the other one is only controllable via ssh, so experimenting with the (very unstable!) AVM capi crap is very risky. My current workaround for this problem is, that I run capisuite in an endless loop via DJB's daemontools and send me a message with tail /var/log/capisuite.log every time it crashes. Faxes are saved to SFF correctly, so I can convert this manually if the last log entries shows an incoming fax. :-(
Stefan Schweizer: No, I did not solve the issue yet. :( > I suggest you to try commenting out the patches in capisuite, to see if they are > the culprits .. I suspect capisuite-fax-compatibility.patch of making problems.. Tried that, no success. I tried commenting out a single one (3 tries) and I tried commenting out all 3 patches. No success, the very same behaviour.
ok, folks. Lets try to analyse the problem. Since I used ebuilds already in portage w/o any modifications for my successful tests, it's not clever to disable any patches. I proved, that all ebuilds and packages are working properly. And I don't see a general Gentoo problem, it looks like a special problem in some particular machines. So we should try to get every single part working, before we patch anything. AVM B1 is an active card, so the driver is nothing more than a router for the CAPI messages from userland via kernelcapi to the card. The CAPI itself is fully implemented in the 'b1.t4' firmware and running on the controller board. Crappy drivers are really NOT the problem at all, because the driver is working on *many* installations w/o any problem. Maybe a 'crappy' firmware, but this can be easily solved, if you try a different one: ftp://ftp.in-berlin.de/pub/capi4linux/firmware/b1/ First of all, capiinit should not segfault. That's not Ok. If CAPI is not running properly, you will have problems with any CAPI based application. Running /etc/init.d/capi stop and then start *should* work w/o any segfaults. If it segfaults, then you should check your BIOS, Hardware and Kernel first. Perhaps you have some kind of ressource problem. But since you use an ISA card, your kernel should be configured properly for ISA and PNP and all that stuff. It's also a good idea to select *all* ISDN/CAPI stuff and use modules instead of static, at least for testing. My kernel is 'gentoo-sources' 2.6.11-gentoo-r6 Following Options should be enabled: CONFIG_ISDN_CAPI=m CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_CAPIFS_BOOL=y CONFIG_ISDN_CAPI_CAPIFS=m CONFIG_ISDN_CAPI_CAPIDRV=m where CAPIDRV is optional. But if you use it, you should enable: CONFIG_ISDN=m CONFIG_ISDN_I4L=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y CONFIG_IPPP_FILTER=y CONFIG_ISDN_PPP_BSDCOMP=m CONFIG_ISDN_AUDIO=y CONFIG_ISDN_TTY_FAX=y and of course the AVM B1 stuff: CONFIG_CAPI_AVM=y <- B1 generic CONFIG_ISDN_DRV_AVMB1_B1PCI=m <- B1 PCI CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y <- B1 PCI V4.0 in /etc/conf.d/capi you can disable the loading of 'capidrv', which is not needed, if you only want to use CAPI based applications. 'capidrv' is the bridge to the old I4L subsystem. I only have a AVM B1 PCI V3.0, but friend of mine is using an B1 ISA card and capi4hylafax works perfectly on his system. So I don't think, that we have a general problem. Once again: before you complain about not running software, it's essential that your HW is working properly. Segfaults should give you an unambiguous sign, that there are indeed problems. Check your BIOS, your Kernel. /etc/init.d/capi start/stop should tell you via /var/log/messages and 'dmesg' if your card was initialized properly. There shouldn't be any Oops and Segfaults. cat /proc/capi/controller should tell you 'running'. next step: capiinfo. Does it shows correct informations? then: check /dev/capi20. Does it exist? What are the permissions? You can setup correct permissions in /etc/udev/rules.d/50-udev.rules if your're using UDEV (which is recommended!). # capi devices KERNEL="capi", NAME="capi20", SYMLINK="isdn/capi20", GROUP="dialout" KERNEL="capi*", NAME="capi/%n", GROUP="dialout" I added 'GROUP' to the defaults, because hylafax needs it (Furthermore I had to add 'uucp' to the 'dialout' group for this). Now you should check basic functionality of your card. I would try a PPP dialup for this purpose. So emerge net-dialup/ppp and setup a simple CAPI connection in /etc/ppp/peers (select any cheap ISDN dialup provider in your country): [/etc/ppp/peers/capitest] sync noauth -chap defaultroute plugin userpass.so plugin capiplugin.so #controller 1 protocol hdlc #numberprefix 0 user <username_here> number <phonenumber_here> password <password_here> /dev/null Now test it with 'pon capitest' and check with 'ifconfig' and in /var/log/messages if it works. 'poff capitest' hangs up the line. if this is working, then we can go further and check other CAPI services and applications. So I stop here for the time beeing and wait for your input. If you solved this, then I try to help you with capisuite and/or capi4hylafax. but I still don't believe that it is gentoo/capisuite problem at this point.
I've run another test on my AMD64. With my AVM C2. This is also an active controller with its own firmware. The only difference to the B1 is, that it has two S0 ports (=2x2 B-channels). I'm using latest capi4k-utils in portage. capisuite hasn't the ~amd64 keyword right now, but I managed to compile it w/o any problems on AMD64 (just adding the ~amd64 keyword to boost, sfftobmp and capisuite ebuild). There's a BugZilla for this already. But since it is not fully tested, I'm expecting problems here or there. Ok, I tested voicebox and fax receiveing. Both is working. Fax sending via 'capisuitefax' gives me a problem with permissions (traceback). But only on commandline, the capisuite server is still running. I have to check this in detail, but it's proven again, that capisuite should work.
Thanks for your information. I apparently use the exact same kernel you do. As a preliminary note regarding unloading drivers, I found this interesting comment from Karsten Keil at <http://lists.suse.com/archive/suse-isdn/2005-Feb/0063.html> : > >> Nein, das Entladen von Modulen ist mit den 2.6 kernel Versionen sehr > >> racy und problematisch geworden. > >> Ein workaround waer es beim runterfahren nicht zu tun, es schadet nicht, > >> da der Rechner eh rebootet wird. > >> Dazu in /etc/init.d/isdn direkt hinter stop) ein exit einbauen. A couple more things: 1) I can successfully *send* faxes without Capisuite crashing like it does when receiving faxes / voice messages. Works like a charm. (I really don't want to test Internet connections unless I really have to, and currently I don't see what PPP connections should add to the mix except a whole bunch of extra variables.) 2) I have set CAPI_UNLOAD_CARDS="no" in </etc/conf.d/capi> and this way, I prevent the segfault. modprobe complains about capidrv and b1isa being busy/used, but at least I don't see any oops anymore. IIRC SuSE does that with some ISDN controllers too.
3) My kernel configuration mirrors yours exactly (including the bits about ISA and PNP), except I have CONFIG_ISDN_DRV_AVMB1_B1ISA=m where you have CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y 4) Re hardware/ BIOS: The entirely unchanged hardware worked flawlessly using whatever Capisuite version was distributed with SuSE Linux 9.2, which ran on this machine for years (well, in different versions of course) without flaws.
you can fix the shutdown order, if you add 'need capi' to depend() in /etc/init.d/isdn (don't forget to run 'depscan.sh' after). this is fixed in an upcoming isdn4k-utils ebuild since 3 weeks now. I still have some work on it, so I don't release it yet. But you can fix it as described above. Unloading modules is indeed tricky, but /etc/init.d/capi solved it mostly (means 98%). And I'd never had any problems with B1 or C2. But I had unloading problems with some AVM USB devices. The mentioned SuSE advice is for the Fritz!Card PCMCIA, where the PCMCIA stack is involved additionally. The CAPI_UNLOAD_CARDS was introduced to make it possible to restart capi w/o un/re-plugging USB cards. But if this solves your problem, then it's ok to use it. But it *should* also work w/o, at least with your B1. Oh well, 'etc-update' is mandantory if you re-emerged capi4k-utils, because some init-scripts etc. change a lot. I just tell you this, because it's often forgotten. For the PPP advice: it's cheap, it's simple, it's easy to test. It doesn't need any special CAPI features like DTMF or T.30 Fax. Just HDLC. So even mISDN works with it. And it's very easy to setup. I wanted to be sure, that your card is working properly, before we look for other application bugs. How do you send faxes? With which program? There're only 3 I know about for CAPI: capifax (capi4k-utils), c2sendfax (capi4hylafax) and of course capisuitefax. And now to capisuite. First thing to test is the voicebox. edit: /etc/capisuite/answering_machine.conf go to the end and add: [<your_unix_username>] voice_numbers="<your_msn>" voice_action="SaveOnly" voice_delay="10" record_length="60" voice_email="" pin="1234" run "/etc/init.d/capisuite start" Open another shell as root and type: tail -f /var/log/capisuite.log Now try to call your MSN. Wait some seconds and you should hear a voice. If this is working, then it just works. Watch the output of the tail command. Next step is fax, but I wait for your answer first.
I used capisuitefax to send a fax tonight; it worked well and Capisuite did not crash. I don't know why you want me to perform a test that I have been routinely running for a couple of days now after every remerge or change to the configuration. Even with SaveOnly instead of MailAndSave (to prevent mail problems) no descriptive .txt files are produced in the <received> directory, and no .wav file is produced. The .la files play OK using 'play'. I think the problem has been described very well now. Everything works, except Capisuite crashes right after the voice/fax connection is finished. The output files (sff and la) are not corrupt, but the .txt files are never written and the la and sff files are not converted to WAV/PDF. After restarting Capisuite, everything works until reception of a fax / voice message completes.
can you strace the capisuited? My problem is, that I can not reproduce it here. And I've tested it on two different machines with two different cards and even on two different platforms. So it is almost impossible, that the capisuite ebuild has a problem or any other gentoo involved part. At least not with my minimal configuration. Furthermore, there wasn't any bugreport before... But Stefan Schweizer found a Debian-Patch for capisuite-0.4.5. We can test, if this patch helps with your configuration. But then, it's an upstream bug. I try to include that patch: http://ftp.debian.org/debian/pool/main/c/capisuite/capisuite_0.4.5-3.diff.gz I'll be back, when it's done.
I have tested a case I hadn't thought of before: Test: Call the answering machine and hang up before the announcement is finished playing. Result: CapiSuite writes ----------------------------------------- Mon May 2 00:26:56 2005 Capi 0x81aa6b0: ** Mon May 2 00:26:56 2005 Capi 0x81aa6b0: * Mon May 2 00:26:56 2005 Capi 0x81aa6b0: <INFO_IND: Controller/PLCI 0x101, InfoN umber 1e (ignoring) Mon May 2 00:26:56 2005 Capi 0x81aa6b0: >INFO_RESP ApplId 0x2, MsgNr 0x2b, Addr ess 0x101 Mon May 2 00:26:56 2005 Capi 0x81aa6b0: info: 0 Mon May 2 00:26:56 2005 Capi 0x81aa6b0: ** Mon May 2 00:26:56 2005 Capi 0x81aa6b0: * Mon May 2 00:26:56 2005 Capi 0x81aa6b0: <DISCONNECT_B3_IND NCCI 0x10101 Reason 0x3301 Mon May 2 00:26:56 2005 Connection 0x8222b38: stop_file_transmission initiated Mon May 2 00:26:56 2005 Connection 0x8222b38: stop_file_transmission finished Mon May 2 00:26:56 2005 Connection 0x8222b38: stop_file_reception finished Mon May 2 00:26:56 2005 Capi 0x81aa6b0: >DISCONNECT_B3_RESP ApplId 0x2 MsgNum 0 x2c NCCI 0x10101 Mon May 2 00:26:56 2005 Capi 0x81aa6b0: info: 0 Mon May 2 00:26:56 2005 Capi 0x81aa6b0: ** Mon May 2 00:26:56 2005 Connection 0x8222b38: stop_file_transmission finished Mon May 2 00:26:56 2005 Connection 0x8222b38: start_file_transmission /usr/shar e/capisuite/5.la ----------------------------------------- to the log (apparently <5.la> was the last sound it produced. Earlier I tested recording a new announcement through the phone and it produced an undamaged </var/spool/capisuite/users/jeroen/announcement-tmp.la> which I can play with 'play'. In that case, Capisuite crashed as well.
Created attachment 57776 [details] capisuite-0.4.5.ebuild added: debian patch removed: other patches, but not the CAPI V3 patch
please test this ebuild. I disabled the gentoo and fax-compatibility patch for the time beeing. I don't know who added them, but I think it's better to use only the debian patch, which is quite huge.
Created attachment 57777 [details] Output from 'strace -f -o capisuite.trace capisuite -d' Again, I called the answering machine, spoke a short voice message ("This is number 22") and hung up.
Oh and the output from strace in the terminal window accompanying the output produced in the <capisuite.trace> attachment was: PANIC: handle_group_exit: 20563 leader 20561 PANIC: handle_group_exit: 20562 leader 20561
please test the attached ebuild. It seems, that capisuite has *many* bugs. At least debian made a *huge* patch. I don't know why this isn't fixed upstream yet.
I am merging the test ebuild now. I guess the patches hasn't gone upstream very far because Capisuite is more or less unmaintained currently, or at least without a maintainer.
if this patch works, then I would use the patch version as the ebuild version, so we can bump it easily when Debian releases another patch.
I don't know what the patch is supposed to fix, but the new build gives me the exact same problem. I not only tested voice this time, but also sent a fax from a neighbouring machine. Same result: the content gets saved properly but then capisuite crashes. Here's the last output before the crash: ----------------------------------------------- Mon May 2 01:29:13 2005 Capi 0x81aa6b0: <DATA_B3_IND: NCCI 0x10101, DataLength 1190, DataHandle 0xc, Flags 0x0 Mon May 2 01:29:13 2005 Capi 0x81aa6b0: >DATA_B3_RESP, ApplId 0x2, msgNum 0x2ae , NCCI 0x10101, DataHandle 0xc Mon May 2 01:29:13 2005 Capi 0x81aa6b0: info: 0 Mon May 2 01:29:13 2005 Capi 0x81aa6b0: ** Mon May 2 01:29:16 2005 Capi 0x81aa6b0: * Mon May 2 01:29:16 2005 Capi 0x81aa6b0: <DISCONNECT_B3_IND NCCI 0x10101 Reason 0x0 Mon May 2 01:29:16 2005 Connection 0x82222e8: fax finished with rate 7200, hiRe s, ID: Fax , 1 pages Mon May 2 01:29:16 2005 Connection 0x82222e8: stop_file_transmission initiated Mon May 2 01:29:16 2005 Connection 0x82222e8: stop_file_transmission finished Mon May 2 01:29:16 2005 Connection 0x82222e8: stop_file_reception finished Mon May 2 01:29:16 2005 Capi 0x81aa6b0: >DISCONNECT_B3_RESP ApplId 0x2 MsgNum 0 x2af NCCI 0x10101 Mon May 2 01:29:16 2005 Capi 0x81aa6b0: info: 0 Mon May 2 01:29:16 2005 Capi 0x81aa6b0: ** -----------------------------------------------
what does crashing means? The daemon is still running? Or not?
Created attachment 57780 [details] Another strace, for the '-r99' ebuild
It means it's gone from memory, no process left, no daemon running where there previously was, a late process, an ex-daemon. Dead. To be zapped and started as a services again. :)
ok, lets analyse it again. 1. CAPI is working and capi4k-utils is also ok 2. capi4k-utils-20050322-r1 has CAPI 2.0 V3 3. capisuite-0.4.5 is compiled/installed straight forward 4. we apply latest debian patches and my CAPI V3 patch. So we should have the same binaries as Debian. 5. capisuite uses 'sox' and 'sfftobmp' for audio/fax converting to wav/pdf. sox is called after voice-recording, sfftobmp is called after fax-receiving. voice-recording seems to work, but *after* this, it "crashes". IMHO 'sox' is called then. conclusion: 1. are you using capi4k-utils-20050322-r1 and is the CAPI V3 patch applied to capisuite? Check the output. The old version of capi4k-utils should prevent the patch, otherwise it has to be applied. 2. is 'sox' and 'sfftobmp' working properly? I'm using this: media-sound/sox-12.17.7-r1 +alsa -debug +encode +mad +oggvorbis media-gfx/sfftobmp-3.0
another possibility is, that something is wrong with your python installation. Perhaps it "crashes" with a traceback. I did this for testing: 1. /etc/init.d/capisuite stop 2. /usr/sbin/capisuite I got these message while making a voice-call: sys:1: DeprecationWarning: Non-ASCII character '\xfc' in file /usr/lib/capisuite/incoming.py on line 421, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details sox: Do not support inversed A-law with 16-bit data. Forcing to Signed.
net-dialup/capi4k-utils-20050322-r1 -- working properly (I think) net-dialup/capisuite-0.4.5-r99 media-gfx/sfftobmp-3.0 -- working properly media-sound/sox-12.17.5-r1 -- working properly, same USE flags you use
Interesting. Running capisuite like that and speaking to the answering machine a bit gives me this output: ------------------------------------------------------- sys:1: DeprecationWarning: Non-ASCII character '\xfc' in file /usr/lib/capisuite/incoming.py on line 421, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details Aborted ------------------------------------------------------- Not very informative...
Created attachment 57781 [details] Finally a slightly more interesting tidbit from <capisuite.error>
Btw, sox reported that warning when I tried it on a .la file. That I get "Aborted" instead of what sox writes to stderr confirms (again) that sox never gets around to starting the .la file conversion or (rather more likely) that capisuite never calls sox. I still don't rule out the possibility that it's one of the python scripts that goes wrong and (Python) throws some exception that capisuite doesn't handle. I appear to be using dev-lang/python-2.3.5 (which according to http://bugs.gentoo.org/show_bug.cgi?id=91024 has at least one flaw).
re.match("voice-([0-9]+)\.la",s) returns None in your case. And then .group() can't work. Dirty, dirty code. But this log is from 0:35h. It's quite old?
my python: dev-lang/python-2.3.5 +X +berkdb -bootstrap -build -debug -doc +gdbm +ipv6 +ncurses +readline +ssl +tcltk -ucs2 perhaps you should re-emerge it, just for the case that there was an error while you emerged it and that is now fixed.
Created attachment 57782 [details] Files in </var/spool/capisuite/users/jeroen/received> But I do have voice*.la files there.
There is a fix for #91024 in Portage, and I am currently syncing (or actually regenerating the metadata db). I hope the fix has made it to whatever mirror I just synced with. And maybe it has a solution too.
nonetheless, I facelift the current ebuild and will provide a better init-script. The current one is crap. ;)
Created attachment 57788 [details] capisuite-0.4.5.3.ebuild updated ebuild, reactivate all patches since they're needed. Now with new versioning.
Created attachment 57789 [details] capisuite.initd updated and renamed init-script. Put it into $FILESDIR. new name, so old ebuild can install old init-script.
I'll test it.
No success for me. I used the attached 0.4.5.3 ebuild and initd-File. :-( My strace-Log seems to be quite similar to the one attached here, after receiving a fax file (I tested with fax) and closing the data file, all processes receive a SIGABRT and crash. capisuite's C++-source seems not to contain any signal-emiting code, so this seems to come from the python stuff. I'll look at this later...
Same result here with the .3 ebuild. I have glanced through the documentation and it looks like it's possible to compile a debug build. The current ebuilds don't seem to output useful messages at all. I still think it's a Python problem, but the capisuite binary simply doesn't report (enough of) them. I have tested nice -n -10 strace -f -o capisuite-0.4.5.3.trace capisuite -d too, just to see if some kind of critical timing error occurs, but it gives me the same results: </usr/sbin/capisuite> crashes and the strace output is rather inconclusive.
Created attachment 57808 [details] strace output from 'nice -n -10 strace -f -o capisuite-0.4.5.3.trace capisuite -d'
perhaps the python herd can help a little. I've done all *I* can do to solve this problem. At this point we need python geeks ;) If there is any patch or fix I can put into the capisuite ebuild, I will do it. But since I can not reproduce the problem here on my machines, it's almost impossible for me to help other than that.
Hmmm... 14127 select(7, [6], NULL, NULL, NULL <unfinished ...> 14128 <... nanosleep resumed> NULL) = 0 14128 nanosleep({0, 100000000}, <unfinished ...> 14131 <... nanosleep resumed> NULL) = 0 14131 futex(0xb7fb2c54, FUTEX_WAKE, 2147483647) = 0 14131 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 14131 tgkill(14126, 14131, SIGABRT) = 0 14131 --- SIGABRT (Aborted) @ 0 (0) --- 14127 <... select resumed> ) = ? ERESTARTNOHAND (To be restarted) 14128 <... nanosleep resumed> 0) = ? ERESTART_RESTARTBLOCK (To be restarted) 14127 +++ killed by SIGABRT +++ 14128 +++ killed by SIGABRT +++ tgkill? thread-group kill. Who is sendig tgkill with SIGABORT? This syscall is not included anywhere neither in the capisuite-code nor in capi4k-utils. Even in python 2.3.5 there isn't that call. man tgkill [..] tkill and tgkill are Linux specific and should not be used in programs that are intended to be portable. tkill is supported since Linux 2.4.19 / 2.5.4. tgkill was added in Linux 2.5.75.
tgkill() appears to be called by rt_sigprocmask(). Something in the kernel, perhaps? I will build a kernel with all the (spin)lock checking features disabled and see if that solves it.
Specifically, I didn't appear to have any of the spinlock debugging hacks enabled, but I did set # CONFIG_PREEMPT_BKL is not set
I don't think it will help, though. The process that issues the rt_sigprocmask and tgkill is 14131, and the first thing that this process writes to the log (judging from the combined capisuite.log and the second trace output is Mon May 2 12:30:40 2005 Pythonscript /usr/lib/capisuite/incoming.py,callIncomin g,0x81f3210: PythonScript created. So it calls the callIncoming function in incoming.py and in the end wants to abort the entire enterprise when the phone is hung up on the other end. What happens near the end is important. callIncoming calls voiceIncoming or faxIncoming, and both use [from line 231 in </usr/lib/capisuite/incoming.py>] except capisuite.CallGoneError: # catch this here to get the cause info in the mail (cause,causeB3)=capisuite.disconnect(call) capisuite.log("connection lost with cause 0x%x,0x%x" % (cause,causeB3),1,call) "to get the cause info in the mail". Maybe disabling this will solve the problem entirely, but I am no Python wizard either.
Two more comments: 1) While compiling the kernel, the following message is shown: drivers/isdn/capi/capidrv.c:2108:10: warning: #warning FIXME: maybe a race condition the card should be removed here from global list /kkeil I have no idea what that means. :) 2) I have just run another test. I called the answering machine and entered a voice message, and then I did not hang up, but I waited the 5 seconds in order to have capisuite disconnect by itself. That worked, capisuite kept running, and I even got the wav file in the mail. I don't know the innards of sending faxes, but I assume from this experiences that the sending fax machines disconnects when it is done, and that this makes capisuite choke for the very same reason it doesn't handle callers hanging up on it "unexpectedly". This again seems to point to capisuite.CallGoneError: either capisuite receives a disconnect cause it doesn't expect, or in a format it doesn't understand. I'd rather have capisuite not telling me what the disconnect reason was than crashing because it does want to tell me so dearly.
Ok, I did a little bit of python debugging and I think the problem is not inside the python code. I placed some checkpoints in the python code, one message between every siginificant command and the last command executed from within python is capisuite.fax_receive(call,filename) My print statement after this one is not executed. The module capisuite is the C one, but I am still looking for some hint how this is implemented at all, I did not yet find out how they implemented this binary module...
This is a session recorded from my capisuite: Mon May 2 09:32:05 2005 Connection 0x801e6b18: Connection object created for incoming call PLCI 102 from XXXXXXXXXX to XXXXXX CIP 0x10 Mon May 2 09:32:05 2005 Connection 0x80208f80: Connection object created for incoming call PLCI 101 from XXXXXXXXXX to XXXXXX CIP 0x10 Mon May 2 09:32:06 2005 Connection 0x801e6b18: call from XXXXXXXXXX to XXXXXX for stefan connecting with voice Mon May 2 09:32:06 2005 Connection 0x80208f80: call from XXXXXXXXXX to XXXXXX for stefan connecting with voice Mon May 2 09:32:16 2005 Connection 0x801e6b18: accepting with service 0 Mon May 2 09:32:16 2005 Connection 0x80208f80: accepting with service 0 Mon May 2 09:32:16 2005 Connection 0x80208f80: connection lost with cause 0x349a,0x0 Mon May 2 09:32:16 2005 Connection 0x80208f80: Connection object deleted Mon May 2 09:32:23 2005 Connection 0x801e6b18: disconnect initiated Mon May 2 09:32:23 2005 Connection 0x801e6b18: connection lost with cause 0x3490,0x0 Mon May 2 09:32:23 2005 Connection 0x801e6b18: Connection object deleted
@Bernd (sorry, the B...Wurst lets me read your name always as 'Bratwurst' ;-)): Please test the 2004 capi4k-utils + re-emerging the capisuite-0.4.5.3 ebuild. The capiv3 patch shouldn't be applied then. I want to be sure, that there isn't a problem with my capiv3 patch and CAPI V3 at all. But here it works and using CAPI V3 is prefered, because it fixes some ugly bugs. The main difference between V2 and V3 is, that some functions have one or two parameters added, which can be NULL if not needed. So the patch is straight forward and very simple (just adding NULLs).
@Comment #76: capidrv is irrelevant, it's the brigde driver to the OLD I4l world. You can disable it, if you don't need neither old ipppX- and AT-Commandset-support nor isdnlog.
Another test: When I call the answering machine, enter my PIN and press 1, capisuite tells me the number of waiting messages (26! :-), and then disconnects, but keeps running. Nothing noteworthy appears in capisuite.log or capisuite.error, apart from Mon May 2 15:31:08 2005 Pythonscript 0x81f3210: Traceback: IOError: [Errno 2] N o such file or directory: '/var/spool/capisuite/users/jeroen/received/voice-0.tx t' which is to be expected because those files are never written. I guess that still means the problem is somewhere with the capisuite.* interface to the Python scripts.
> @Bernd (sorry, the B...Wurst lets me read your name always as 'Bratwurst' Omg, you're so funny. :-/ > Please test the 2004 capi4k-utils + re-emerging the capisuite-0.4.5.3 ebuild. # emerge -pv capi4k-utils [ebuild R ] net-dialup/capi4k-utils-20041006-r5 0 kB I think I use the 2004-capi4k-utils. :) > The capiv3 patch shouldn't be applied then. I want to be sure, that there > isn't a problem with my capiv3 patch and CAPI V3 at all. I already tested to leave patches out, that was with those capi4k-utils, so I think this cannot be the point. But I'm a littel further. As mentioned above, the python code calls a C-coded module before it crashes. The function called seems to be this one: static PyObject* capisuite_fax_receive(PyObject *, PyObject *args) { Connection *conn; char *filename; PyThreadState *_save; if (!PyArg_ParseTuple(args,"O&s:fax_receive",convertConnRef,&conn,&filename)) return NULL; try { Py_UNBLOCK_THREADS FaxReceive active(conn,filename); active.mainLoop(); Py_BLOCK_THREADS } catch (CapiWrongState e) { Py_BLOCK_THREADS PyErr_SetString(CallGoneError,"Call was finished from partner."); return NULL; } catch (CapiExternalError e) { Py_BLOCK_THREADS PyErr_SetString(BackendError,(e.message()).c_str()); return NULL; } Py_XINCREF(Py_None); return (Py_None); } You wrote about those thread-kill-functions, This code here uses threads! Perhaps there's something wrong with Python's thread management here? I use following flags: # emerge -pv glibc python [ebuild R ] sys-libs/glibc-2.3.4.20041102-r1 -build -debug -erandom -hardened (-multilib) +nls -nomalloccheck +nptl -nptlonly -pic +userlocales 0 kB [ebuild R ] dev-lang/python-2.3.5 -X -berkdb -bootstrap -build -debug -doc -gdbm +ipv6 +ncurses +readline +ssl -tcltk -ucs2 0 kB And the server that does not have this problem has these flags: # emerge -pv glibc python [ebuild R ] sys-libs/glibc-2.3.4.20041102-r1 -build -debug -erandom -hardened (-multilib) +nls -nomalloccheck -nptl -nptlonly +pic -userlocales 0 kB [ebuild R ] dev-lang/python-2.4-r3 -X +berkdb -bootstrap -build -debug -doc +gdbm +ipv6 +ncurses +readline +ssl -tcltk -ucs2 0 kB @JeR: Do you have NPTL in your USE-Flags? I think it is not really possible to turn NPTL off in a running system, isn't it?
I have: [ebuild R ] sys-libs/glibc-2.3.4.20041102-r1 -build -debug -erandom -hardened (-multilib) +nls -nomalloccheck +nptl +nptlonly +pic +userlocales 0 kB [ebuild R ] dev-lang/python-2.3.5 +X +berkdb -bootstrap -build -debug -doc +gdbm +ipv6 +ncurses +readline +ssl -tcltk -ucs2 0 kB To sum up all the differences in glibc on all systems: Doesn't work (JeR): +nptl +pic +userlocales Doesn't work (Bernd): +nptl -pic +userlocales Does work (Bernd): -nptl +pic -userlocales That's three variables, not one. :-\
Stefan Briesenick, what are your USE flags for glibc? (I think we can count out python or the Capisuite python scripts as the direct cause of the problem and instead focus on the capisuite binary.)
I would think Capisuite requires linuxthreads but I am a bit reluctant to rebuild the entire toolchain on an AMD K6-2 @ 400 MHz just to test this theory. Bernd, do you have a faster machine that's available for testing this and that has the problem? Testing this by rebuilding glibc, etc, would probably cost about a day (at least 18 hours for twice rebuilding the tc alone).
@JeR: Partly. The non-working machine is a P3-800, but I don't have physical access to it, so rebuilding system core would be kind of dangerous. At weekend, I am there for a few days, if this isn't solved then, I can try. Cause the woking machine is in my flat, I can try turning on NPTL there and do the test the other way. Dangerous but this box (and it's fax functionality) is not needed, it's just a testing machine and my internet router. :) emerge glibc runs. :)
@ #86: Thanks. Hopefully we'll know soon. Do you think emerging only glibc and only once will be enough? That would be only 5 hours merge time for me...
on my server where I tested it first: sys-libs/glibc-2.3.5 -build -debug +erandom +hardened (-multilib) +nls +nomalloccheck +nptl +nptlonly +pic +userlocales
I recompiled glibc with NPTL & NPTLONLY Flags set but no changem capisuite works like a charme on that box. But I thought that it's not really possible to switch a system over to nptl by just re-merging glibc... However, executing /lib/libc.so.6 shows NPTL as supported feature. Any further suggestions?
Bernd Wurst / Stefan Briesenick: Could you please post your log_level="3" output to <capisuite.log> from a working Capisuite? I am particularly interest in connections ending with this sequence: ------------------------------------- Capi ... DISCONNECT_B3_IND ... [ perhaps something like this here: ] [ ... fax finished with rate 14400, lowRes, ID: + xxxxxxxx, 1 pages ... ] ... stop_file_transmission initiated ... ... stop_file_transmission finished ... ... stop_file_reception finished ... Capi ... DISCONNECT_B3_RESP ... [ perhaps something like this here: ] [ Capi ... info: 0 ] [ Capi ... ** ] ------------------------------------- Based on the assumption that Capisuite is choking on some CAPI message it doesn't expect, this could be important (at least for my point of view, with no working Capisuite to judge from what it ought to look like).
I wasn't at home today. But I will test it with log_level="3" now.
Created attachment 57958 [details] capisuite.log complete session voice call. recorded with loglevel 3.
ooops ;) both controllers were connected to the S0, so the log looks a little bit strange. I'm not sure which controller got the call. If needed, I can repeat it with only one controller.
Interesting. It looks like my capisuite gets only as far as ----------------------------------------------- 11:27:54 2005 Capi 0x81ac6b0: <DISCONNECT_B3_IND NCCI 0x10101 Reason 0x3301 11:27:54 2005 Connection 0x821e180: stop_file_transmission initiated 11:27:54 2005 Connection 0x821e180: stop_file_transmission finished 11:27:54 2005 Connection 0x821e180: stop_file_reception finished 11:27:54 2005 Capi 0x81ac6b0: >DISCONNECT_B3_RESP ApplId 0x2 MsgNum 0x277 NCCI 0x10101 11:27:54 2005 Capi 0x81ac6b0: info: 0 11:27:54 2005 Capi 0x81ac6b0: ** ----------------------------------------------- while yours seems to continue further from that point with ----------------------------------------------- 22:11:17 2005 Connection 0x801eb840: disconnect initiated 22:11:17 2005 Capi 0x801728c8: >DISCONNECT_REQ ApplId 0x4 MsgNum 0x2e PLCI 0x101 22:11:17 2005 Capi 0x801728c8: info: 0 22:11:17 2005 Capi 0x801728c8: * 22:11:17 2005 Capi 0x801728c8: <DISCONNECT_CONF PLCI 0x101 Info 0x0 22:11:17 2005 Capi 0x801728c8: ** 22:11:17 2005 Capi 0x801728c8: * 22:11:17 2005 Capi 0x801728c8: <DISCONNECT_IND PLCI 0x101 Reason 0x3490 22:11:17 2005 Capi 0x801728c8: >DISCONNECT_RESP ApplId 0x4 MsgNum 0xdd PLCI 0x101 22:11:17 2005 Capi 0x801728c8: info: 0 22:11:17 2005 Capi 0x801728c8: ** 22:11:17 2005 Connection 0x801eb840: connection lost with cause 0x3490,0x3301 22:11:17 2005 CapiSuite 0xbfffeea0: mail sent successful 22:11:17 2005 Connection 0x801eb840: Python: deleting connection object 22:11:17 2005 Connection 0x801eb840: stop_file_transmission initiated 22:11:17 2005 Connection 0x801eb840: stop_file_transmission finished 22:11:17 2005 Connection 0x801eb840: stop_file_reception finished 22:11:17 2005 Connection 0x801eb840: Connection object deleted 22:11:17 2005 Pythonscript /usr/lib/capisuite/incoming.py,callIncoming,0x801913c0: IncomingScript deleted 22:11:17 2005 Pythonscript /usr/lib/capisuite/incoming.py,callIncoming,0x801913c0: PythonScript deleted. 22:11:28 2005 Pythonscript /usr/lib/capisuite/idle.py,idle,0x801a16e8: executing idlescript... 22:11:28 2005 Pythonscript /usr/lib/capisuite/idle.py,idle,0x801a16e8: idlescript finished... ----------------------------------------------- Is it possible to get a -debug USE flag working easily for capisuite? Judging from the documentation it seems like capisuite has such options and code built in.
just add the debug option to the 'econf' in src_compile(). Should be enough.
Created attachment 58052 [details] capisuite.log (with AVM Fritz!Card USB v2.0)
Just for a laugh I tried out (CAPI4)Hylafax and it works flawlessly (though I do miss the answering machine and haven't found a replacement for it yet).
On my system x86, gcc 3.3.6, kernel 2.6.12 capisuite always terminated if capisuite was called by another party at the moment when the other party disconnected the call. - This matches the descriptions above. Chrooting into a SUSE 9.3 system did not show this behaviour; thus, hardware and kernel modules are ok. Finally I compiled capisuite manually and it worked without terminating. Solution, at least in my case: emerging capisuite-0.4.5-r2 in my setup used gcc-flag -fomit-frame-pointer which caused the crash; so two changes in the ebuild solved my problem: adding flag-o-matic to inherit ... calling strip-flags in function src_compile() Christian my modified ebuild will be attached below
Created attachment 65193 [details] patched ebuild for capisuite-0.4.5-r2 this ebuild solves the bug on my system (see comment #98) Christian
'strip-flags' removes all flags. Isn't it enough to remove just -fomit-frame-pointer from CFLAGS? I don't like the idea to strip all flags just to be on the safe side. Please test it with: "filter-flags -fomit-frame-pointer" instead of "strip-flags". and tell us, if it helps. thanks!
(In reply to comment #98) > emerging capisuite-0.4.5-r2 in my setup used gcc-flag > -fomit-frame-pointer which caused the crash; I think I removed -fomit-frame-pointer a long time ago, before a complete rebuild of the system. I might be OK if -fomit-frame-pointer was to blame, so I'll try and remerge and see if it helps. In the mean time, could you please post your emerge info?
Eureka. It works!??! Capisuite now stays up and running, even after receiving and sending a couple of voicemails and faxes (even in rapid succession). Now, as for my former CFLAGS: CFLAGS="-O2 -march=k6-2 -fomit-frame-pointer -pipe -funroll-loops" I changed these to CFLAGS="-Os -march=i586 -pipe" quite a while ago, without taking much more notice of this Capisuite bug, so I'm afraid I can't tell if this change is what solved the problem. It could have been some library dependency instead. So it may not be such a wild idea to keep these as sane as possible. Besides the argument of sanity, Capisuite is not a time-critical application in and of itself AFAIK (even though the capi drivers and utils are, especially if you use a passive CAPI-capable ISDN controller). Last but not least, better CFLAGS won't make faxes and particularly voicemails come in any faster. Ergo, using strip-flags or stripping quite heavily may not be such a bad idea at all.
(In reply to comment #100) > 'strip-flags' removes all flags. Isn't it enough to remove just > -fomit-frame-pointer from CFLAGS? I did test both, so in my case filtering -fomit-frame-pointer is ok as well Christian
ok, this seems to be one of the nasty apps with some dirty code. ;-) though I'm not a friend of strip-flags, in this case I will add it. I commit the fixed ebuild tomorrow (want to do some other checks and maybe some ebuild cleanups first).
capisuite-0.4.5-r3 committed with 'strip-flags'. Please test!
(In reply to comment #104) > ok, this seems to be one of the nasty apps with some dirty code. ;-) No, except c++ in general is considered as dirty. - It has to do with c++ exception handling and seems to be a well known bug since at least gcc 3.1 (http://gcc.gnu.org/ml/gcc-bugs/2002-05/msg00852.html) **** capisuite-0.4.5-r3.ebuild runs correctly and produces the working binary. I think this bug can be closed. - Thanks for quickly providing a new ebuild.
> capisuite-0.4.5-r3.ebuild runs correctly and produces the working binary. > I think this bug can be closed. - Thanks for quickly providing a new ebuild. The new capisuite-0.4.5-r3.ebuild runs well here too, as (ultimately) expected. I am back to capisuite and stopped using hylafax and ivam2. :) Thanks, *everyone*! :-)
@comment #106: huh, this is a terrible bug! This affects *many* programs, since -fomit-frame-pointer is more or less frequently used by so many users (including me). does this mean *all* C++ apps should use "filter-flags -fomit-frame-pointer" to be on the safe side?
