From owner-freebsd-isdn@FreeBSD.ORG Thu Jul 19 16:48:19 2012 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1300C106564A for ; Thu, 19 Jul 2012 16:48:19 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 66E568FC14 for ; Thu, 19 Jul 2012 16:48:18 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [84.49.175.101] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 300050219; Thu, 19 Jul 2012 18:48:15 +0200 From: Hans Petter Selasky To: Andreas Longwitz Date: Thu, 19 Jul 2012 18:48:31 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <4FFDB2DE.6010107@incore.de> <201207161801.46422.hselasky@c2i.net> <500833F5.2050205@incore.de> In-Reply-To: <500833F5.2050205@incore.de> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201207191848.31049.hselasky@c2i.net> Cc: freebsd-isdn@freebsd.org Subject: Re: ISDN4BSD (HPS version) is going into ports X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:48:19 -0000 On Thursday 19 July 2012 18:21:09 Andreas Longwitz wrote: > Hi Hans, Hi Andreas, > > >> 1. example: Default options + SPPP + RBCH, crash on kldload i4b, test PC > > > >> without isdn hardware: > > I cannot reproduce this crash over here. I think it is not a bug in I4B, > > but rather some hardware generating spurious interrupts when probing! > > Loading I4B will cause a re-probe of existing devices with no driver > > attached. > > OK, the re-probe of the existing devices is done by the kernel because a > DRIVER_MODULE is loaded via kldload, or did you some special programming > for this ? No, this is done by generic PNP/PCI code when the module is loaded as far as I'm aware. > > > The I4B module as a whole cannot be unloaded, it requires a reboot. Some > > parts of I4B supports unload, but others not. A crash at this point is > > like expected. However it is possible in theory to split I4B into > > separate modules, which can be loaded/unloaded, but not the core itself > > currently. > > So it seems a little bit safer to load i4b - or any other DRIVER_MODULE > - via loader.conf, because the re-probe must not be done. Right. > > > I believe the SPPP functionality has not been tested for a while. > > In the meantime I found the reason for my troubles with i4b + sppp on > incoming calls: > > There was a commit for if_spppsubr.c (Revision 1.222) with the text: > Use monotonic time_uptime instead of 'time_second' as timebase for > timeouts. After changing in i4b_global.h from > #define SECOND time_second > to #define SECOND time_uptime > the problem was gone. I4B also uses SECOND for other purpose. I think your change is OK and have committed it. > > One bagatelle is left: On every incoming call I see in /var/log/messages > kernel: i4b-L3 dss1_decode_q931_cs0_ie_cd: IEI_BEARERCAP - Unsupported > B-Sub-Protocol 0x00 > kernel: i4b: unit 0, assigned TEI = 253 = 0xfd (example), This warning can be ignored. I4B looks for a Voice type byte which is not there and the safety wrapper returns zero. Try this patch: Modified: trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h Log: i4b: Silence warning when using HDLC. Modified: trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h =================================================================== --- trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h +++ trunk/i4b/src/sys/i4b/dss1/dss1_l3decoder.h @@ -177,8 +177,10 @@ break; default: - NDBGL3(L3_P_ERR, "IEI_BEARERCAP - " + if (dss1_get_valid(buf,4)) { + NDBGL3(L3_P_ERR, "IEI_BEARERCAP - " "Unsupported B-Sub-Protocol 0x%02x", temp); + } cd->channel_bsubprot = BSUBPROT_UNKNOWN; } break; > > but the incoming SETUP frame is ok. Can you give me a hint how to deal > with this ? In /etc/isdn/isdnd.rc I do not have any subaddress specific > parameters. Subaddress is not matched unless specified. I'll roll out a new tarball when time permits. Until further simply checkout code via SVN and type "make package" in the i4b direction to get a new tarball for ports. After replacing the file in /usr/ports/distfiles, you type make makesum or something like that to update the checksum file. Thanks for testing! --HPS