ISDN4BSD (HPS version) is going into ports

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
Hi,

I am runnung FreeBSD 8.3 with isdn4bsd 2.0.4 + chan_capi 2.0.2 from
ports and asterisk 1.8.16. On my production system with two HFC-4S
adapters (one in NT-mode, the other in TE-mode) and some SIP-phones I
have the following problem: asterisk runs in a deadlock two or three
times a week, nothing but kill -9 helps.

During looking for a possible reason for the deadlock I found that
asterisk never destroys a channel from a call initiated inbound by i4b.

On the asterisk console the command "capi show" always gives the correct
infos about busy isdn channels, but "core show channels verbose" lists
more and more channels. For every call incoming via i4b the channel
remains in the list of active asterisk channels. Outgoing isdn channels
and all sip channels disappear after hangup.

For a call incoming via i4b I see on hangup that chan_capi_hangup() is
called and then cd_free() with state=6 (CAPI_STATE_CONNECTED),
send_release_complete=1, causeOut=0x3490 and hangup_what=0. Afterwards I
see the call of capi_send_disconnect_req.

In the case of dir_incoming I can see nothing that informs asterisk
about the free channel. I suppose in the case dir_outgoing this is done
by  "ast_setstate(pbx_chan, AST_STATE_DOWN)" in cd_free().


--
Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
On Saturday 10 November 2012 17:59:27 Andreas Longwitz wrote:

> Hi,
>
> I am runnung FreeBSD 8.3 with isdn4bsd 2.0.4 + chan_capi 2.0.2 from
> ports and asterisk 1.8.16. On my production system with two HFC-4S
> adapters (one in NT-mode, the other in TE-mode) and some SIP-phones I
> have the following problem: asterisk runs in a deadlock two or three
> times a week, nothing but kill -9 helps.
>
> During looking for a possible reason for the deadlock I found that
> asterisk never destroys a channel from a call initiated inbound by i4b.
>
> On the asterisk console the command "capi show" always gives the correct
> infos about busy isdn channels, but "core show channels verbose" lists
> more and more channels. For every call incoming via i4b the channel
> remains in the list of active asterisk channels. Outgoing isdn channels
> and all sip channels disappear after hangup.
>
> For a call incoming via i4b I see on hangup that chan_capi_hangup() is
> called and then cd_free() with state=6 (CAPI_STATE_CONNECTED),
> send_release_complete=1, causeOut=0x3490 and hangup_what=0. Afterwards I
> see the call of capi_send_disconnect_req.
>
> In the case of dir_incoming I can see nothing that informs asterisk
> about the free channel. I suppose in the case dir_outgoing this is done
> by  "ast_setstate(pbx_chan, AST_STATE_DOWN)" in cd_free().

Hi,

I'll have a look at this issue this week. Sounds like reproducible. We
probably should compare with other channel drivers what they are doing.

Do you see this problem using older versions of asterisk?

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
Hi,

>> On the asterisk console the command "capi show" always gives the correct
>> infos about busy isdn channels, but "core show channels verbose" lists
>> more and more channels. For every call incoming via i4b the channel
>> remains in the list of active asterisk channels. Outgoing isdn channels
>> and all sip channels disappear after hangup.
>>
>> For a call incoming via i4b I see on hangup that chan_capi_hangup() is
>> called and then cd_free() with state=6 (CAPI_STATE_CONNECTED),
>> send_release_complete=1, causeOut=0x3490 and hangup_what=0. Afterwards I
>> see the call of capi_send_disconnect_req.
>>
>> In the case of dir_incoming I can see nothing that informs asterisk
>> about the free channel. I suppose in the case dir_outgoing this is done
>> by  "ast_setstate(pbx_chan, AST_STATE_DOWN)" in cd_free().
>
> Hi,
>
> I'll have a look at this issue this week. Sounds like reproducible. We
> probably should compare with other channel drivers what they are doing.

As far as I can see sip_hangup() makes no difference between incoming
and outgoing calls. chan_capi_hangup() calls cd_free(cd, 0), a function
with extra handling for dir_outgoing.

>
> Do you see this problem using older versions of asterisk?
Difficult to say. In asterisk 1.4 (with FreeBSD 6) not, in asterisk 1.6
probably yes.


--
Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Paul Schenkeveld-20
In reply to this post by Hans Petter Selasky
On Sun, Nov 11, 2012 at 10:46:44PM +0100, Hans Petter Selasky wrote:

> On Saturday 10 November 2012 17:59:27 Andreas Longwitz wrote:
> > Hi,
> >
> > I am runnung FreeBSD 8.3 with isdn4bsd 2.0.4 + chan_capi 2.0.2 from
> > ports and asterisk 1.8.16. On my production system with two HFC-4S
> > adapters (one in NT-mode, the other in TE-mode) and some SIP-phones I
> > have the following problem: asterisk runs in a deadlock two or three
> > times a week, nothing but kill -9 helps.
> >
> > During looking for a possible reason for the deadlock I found that
> > asterisk never destroys a channel from a call initiated inbound by i4b.
> >
> > On the asterisk console the command "capi show" always gives the correct
> > infos about busy isdn channels, but "core show channels verbose" lists
> > more and more channels. For every call incoming via i4b the channel
> > remains in the list of active asterisk channels. Outgoing isdn channels
> > and all sip channels disappear after hangup.
> >
> > For a call incoming via i4b I see on hangup that chan_capi_hangup() is
> > called and then cd_free() with state=6 (CAPI_STATE_CONNECTED),
> > send_release_complete=1, causeOut=0x3490 and hangup_what=0. Afterwards I
> > see the call of capi_send_disconnect_req.
> >
> > In the case of dir_incoming I can see nothing that informs asterisk
> > about the free channel. I suppose in the case dir_outgoing this is done
> > by  "ast_setstate(pbx_chan, AST_STATE_DOWN)" in cd_free().
>
> Hi,
>
> I'll have a look at this issue this week. Sounds like reproducible. We
> probably should compare with other channel drivers what they are doing.
>
> Do you see this problem using older versions of asterisk?

I still have one asterisk 1.8.8.1 server on FreeBSD 8.2 with a single
HFC card connected to the public ISDN network.  It's only used to
receive calls.

Seems my channels hang till next restart of asterisk too:

  pbx*CLI> core show channels verbose

  Channel      Context  Extension  Prio State  Application  Data    CallerID    Duration Accountcode PeerAccount BridgedTo
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Ring   (None)       (None)  yyyyyyyyyy         -                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Ring   (None)       (None)  yyyyyyyyyy         -                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Ring   (None)       (None)  yyyyyyyyyy         -                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Ring   (None)       (None)  yyyyyyyyyy         -                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Ring   (None)       (None)  yyyyyyyyyy         -                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Ring   (None)       (None)  yyyyyyyyyy         -                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Ring   (None)       (None)  yyyyyyyyyy         -                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  351:59:4                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  336:01:3                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     7 Up     (None)       (None)  yyyyyyyyyy         -                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)              331:27:2                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  315:21:5                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)              302:36:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  290:39:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  280:28:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)              278:20:4                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)              277:53:5                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)              277:45:4                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  264:39:5                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  264:24:5                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  254:25:3                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  239:24:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  234:59:0                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  232:32:3                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  231:07:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  210:29:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  187:45:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  167:34:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  167:10:2                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  147:33:0                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)              142:21:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  140:36:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  113:32:1                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx    10 Up     (None)       (None)                     -                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  88:15:20                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Up     (None)       (None)  yyyyyyyyyy  64:05:35                         (None)
  CAPI/isdn/30 isdn-in  xxxxxxxxx     5 Ring   (None)       (None)  yyyyyyyyyy         -                         (None)
  37 active channels
  0 active calls
  111 calls processed

The asterisk process was started on Oct 28, 2012 which matches the
oldest channel.

HTH

Paul Schenkeveld
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
Hi,

I looks like this is a problem on 1.8.x only. I have a 1.6.x system bridging
to SIP and more and I don't see lots of unref'ed structures.

It appears to me that the Asterisk API has changed, and now needs a final de-
ref, by the allocator of the call structure. Could you try this patch, on a
non-production system and see what happens:

Index: chan_capi/chan_capi.c
===================================================================
--- chan_capi/chan_capi.c (revision 2419)
+++ chan_capi/chan_capi.c (working copy)
@@ -1945,6 +1945,11 @@
  if (pbx_chan->rings == 0)
  pbx_chan->rings = 1;
     }
+ } else {
+#if (CC_AST_VERSION >= 0x10800)
+ /* drop final refcount */
+ hangup_what |= 2;
+#endif
  }
 
  if (hard_hangup) {


Thank you,
  -- HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Paul Schenkeveld-20
On Mon, Nov 12, 2012 at 02:58:01PM +0100, Hans Petter Selasky wrote:
> Hi,
>
> I looks like this is a problem on 1.8.x only. I have a 1.6.x system bridging
> to SIP and more and I don't see lots of unref'ed structures.
>
> It appears to me that the Asterisk API has changed, and now needs a final de-
> ref, by the allocator of the call structure. Could you try this patch, on a
> non-production system and see what happens:

I don't have a non-production system with ISDN installed atm, will try
and get hold of one for testing.

With kind regards,

Paul Schenkeveld
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
In reply to this post by Hans Petter Selasky
Hi Hans

> It appears to me that the Asterisk API has changed, and now needs a
> final deref, by the allocator of the call structure. Could you try
> this patch, on a non-production system and see what happens:

> Index: chan_capi/chan_capi.c
> ===================================================================
> --- chan_capi/chan_capi.c       (revision 2419)
> +++ chan_capi/chan_capi.c       (working copy)
> @@ -1945,6 +1945,11 @@
>                if (pbx_chan->rings == 0)
>                        pbx_chan->rings = 1;
>            }
> +       } else {
> +#if (CC_AST_VERSION >= 0x10800)
> +               /* drop final refcount */
> +               hangup_what |= 2;
> +#endif
>        }
>
>        if (hard_hangup) {

I have tried this patch and the result with one incoming call looks like
this:

-> asterisk -rx "core show channels" (before the call)
Channel              Location             State   Application(Data)
0 active channels
0 active calls
0 calls processed
Asterisk ending (0).
-> asterisk -rx "core show channels" (during the call)
Channel              Location             State   Application(Data)
CAPI/ISDN_TE_1/49940 4994068@capi_telekom Up
Playback(rup_ansage_zeiten)
1 active channel
1 active call
1 call processed
Asterisk ending (0).
-> asterisk -rx "core show channels" (after hangup)
Channel              Location             State   Application(Data)
                     4994068@capi_telekom Up      (None)
1 active channel
0 active calls
1 call processed
Asterisk ending (0)

With the patch, only the name of the channel has gone, not the channel
itself. Without the patch the output of the last command (after hangup)
was the same as during the call.

.
--
Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
Hi,

The issue about "core show channels" that shows more and more channels,
happens only in Asterisk 1.8.x and is due to chan_capi not updating the
channel name correctly according to how Asterisk expects it being done.

The issue about deadlock should be solved by moving the channel allocation
outside of the CAPI applications lock. Channel free is already outside this
lock. There now will always be a free channel, when no call is pending. Please
also note that the CDR start time might be different than before. That means
it should be set to the time when the PBX thread was started for incoming
calls, not when doing DID (dial in digits), and for outgoing calls, when the
asterisk channel was allocated.

Fixes are available in my I4B SVN repository in the trunk/chan_capi folder.

Please test and report back!

Thanks for valuable feedback!

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
Hi Hans,

> The issue about "core show channels" that shows more and more channels,
> happens only in Asterisk 1.8.x and is due to chan_capi not updating the
> channel name correctly according to how Asterisk expects it being done.

With revision 2473 of isnd4bsd this problem is solved:

-> asterisk -rx "core show channels" (before incoming call)
Channel              Location             State   Application(Data)
CAPI//-free          s@default:1          Down    (None)
1 active channel
0 active calls
0 calls processed
Asterisk ending (0).
-> asterisk -rx "core show channels" (during the call)
Channel              Location             State   Application(Data)
SIP/34-00000000      4994068@from-interna Ringing AppDial((Outgoing Line))
CAPI/ISDN_TE_1/49940 4994068@capi_telekom Ring    Dial(SIP/34,30,gj)
CAPI//-free          s@default:1          Down    (None)
3 active channels
1 active call
1 call processed
Asterisk ending (0).
-> asterisk -rx "core show channels" (after hangup)
Channel              Location             State   Application(Data)
CAPI//-free          s@default:1          Down    (None)
1 active channel
0 active calls
1 call processed
Asterisk ending (0).

> The issue about deadlock should be solved by moving the channel allocation
> outside of the CAPI applications lock. Channel free is already outside this
> lock. There now will always be a free channel, when no call is pending. Please
> also note that the CDR start time might be different than before. That means
> it should be set to the time when the PBX thread was started for incoming
> calls, not when doing DID (dial in digits), and for outgoing calls, when the
> asterisk channel was allocated.
>
> Fixes are available in my I4B SVN repository in the trunk/chan_capi folder.
>
> Please test and report back!

I will do some tests and then update my production server and report the
results.

> Thanks for valuable feedback!

Thanks for valuable correction!


--
Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
In reply to this post by Andreas Longwitz
Hi,

The chan_capi port has now been updated to version "chan_capi-2.0.3" which
should resolve the mentioned issues. If not, please let me know.

Thanks!

-_HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
Hi Hans,

> The chan_capi port has now been updated to version "chan_capi-2.0.3" which
> should resolve the mentioned issues. If not, please let me know.

1. chan_capi:
Good news: I can confirm that all deadlock problems with asterisk 1.8
are gone with your new port chan_capi-2.0.3 ! Everything works fine for
a week now.

2. isdn4bsd-utils-2.0.4:
Works fine, but to start isdnd reliable a minor patch mentioned earlier
is necessary:

-- src/usr.sbin/i4b/isdnd/support.c.orig       2011-10-10
20:34:44.000000000 +0200
+++ src/usr.sbin/i4b/isdnd/support.c    2012-07-10 15:53:26.00000 +0200
@@ -854,7 +854,7 @@
                case 0:                 /* child */
                        break;
                default:                /* parent */
-                       exit(0);
+                       _exit(0);
        }
Further I propose that you integrate a file named files/isdnd.in in the
port like this:

#!/bin/sh

# PROVIDE: isdnd
# REQUIRE: netif FILESYSTEMS cleanvar
# KEYWORD: nojail

. /etc/rc.subr

name="isdnd"
rcvar=`set_rcvar`
pidfile="/var/run/${name}.pid"
command="/usr/local/sbin/isdnd"

load_rc_config $name
isdnd_enable=${isdnd_enable:-"NO"}
run_rc_command "$1"

3. isdn4bsd-kmod-2.0.4:
One thing is left: the handling of DISCONNECT including error codes like
"busy". We had some discussion about this in late 2010, I wrote

> My understanding of the standard closing of a Q.931 connection is
>       --> DISCONNECT
>       <-- RELEASE
>       --> RELEASE_COMPLETE
> it is like closing a tcp socket (-> FIN; <- FIN+ACK; -> ACK). I have
> never seen an example that RELEASE and RELESE_COMPLETE is send in the
> same direction. Your method of finishing a Q.931 connection is correct
> but not standard: In the active case you send RELEASE_COMLETE, in the
> passive case you answer the incoming DISCONNECT with RELEASE_COMPLETE.

and your answer was that the statemachine in ISDN4BSD must be changed to
accomplish my requirement. If you have a patch for this, I would like to
test this.

One last thing: As you know for my old PBX I need a patch called
patch-no_status_enquiry_in_NT_MODE:

--- src/sys/i4b/dss1/dss1_l2fsm.c.orig  2012-07-08 17:42:19.00000 +0200
+++ src/sys/i4b/dss1/dss1_l2fsm.c       2012-07-08 18:10:10.00000 +0200
@@ -1494,9 +1494,11 @@
                 * STATUS_ENQUIRY seems to not
                 * be included by this rule.
                 */
-               *ptr++ = PD_Q931;
-                ptr   = make_callreference(pipe_adapter, 0x7f, ptr);
-               *ptr++ = STATUS_ENQUIRY;
+               if(!(NT_MODE(sc))) {
+                  *ptr++ = PD_Q931;
+                   ptr   = make_callreference(pipe_adapter, 0x7f, ptr);
+                  *ptr++ = STATUS_ENQUIRY;
+               }

                m->m_len = ptr - ((__typeof(ptr))m->m_data);
            }
--- src/sys/i4b/dss1/dss1_l3fsm.h.orig  2012-07-08 17:42:19.00000 +0200
+++ src/sys/i4b/dss1/dss1_l3fsm.h       2012-07-08 18:10:10.00000 +0200
@@ -298,6 +298,17 @@
                newstate--;
            }
        }
+       else if (NT_MODE(sc) &&
+               ((newstate == ST_L3_UC_TO) ||
+                (newstate == ST_L3_UA_TO) ||
+                (newstate == ST_L3_U3_TO) ||
+                (newstate == ST_L3_U4_TO) ||
+                (newstate == ST_L3_U6_TO) ||
+                (newstate == ST_L3_U7_TO))) {
+               /* don't send status enquiry */
+               send_status_enquiry = 0;
+               newstate--;
+       }

        cd->state = newstate;

Should this become a config option in the port or would you prefer a
sysctl for this ?


Regards

Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
On Friday 23 November 2012 12:18:17 Andreas Longwitz wrote:
> Hi Hans,
>
> > The chan_capi port has now been updated to version "chan_capi-2.0.3"
> > which should resolve the mentioned issues. If not, please let me know.
>

Hi,

I've made a new release of ISDN4BSD, now version 2.0.6. I4B SVN has been
updated with new ports.

> 1. chan_capi:
> Good news: I can confirm that all deadlock problems with asterisk 1.8
> are gone with your new port chan_capi-2.0.3 ! Everything works fine for
> a week now.

Good!

>
> 2. isdn4bsd-utils-2.0.4:
> Works fine, but to start isdnd reliable a minor patch mentioned earlier
> is necessary:

Fixed. Please test updated port.

> Further I propose that you integrate a file named files/isdnd.in in the
> port like this:

Fixed with some modifications. Please test updated port.

> 3. isdn4bsd-kmod-2.0.4:
> One thing is left: the handling of DISCONNECT including error codes like
> "busy". We had some discussion about this in late 2010, I wrote
>
> > My understanding of the standard closing of a Q.931 connection is
> >
> >       --> DISCONNECT
> >       <-- RELEASE
> >       --> RELEASE_COMPLETE
> >
> > it is like closing a tcp socket (-> FIN; <- FIN+ACK; -> ACK). I have
> > never seen an example that RELEASE and RELESE_COMPLETE is send in the
> > same direction. Your method of finishing a Q.931 connection is correct
> > but not standard: In the active case you send RELEASE_COMLETE, in the
> > passive case you answer the incoming DISCONNECT with RELEASE_COMPLETE.
>
> and your answer was that the statemachine in ISDN4BSD must be changed to
> accomplish my requirement. If you have a patch for this, I would like to
> test this.

I haven't had time to look into this one yet. I will see if I can find some
time to do this. Else keep in reminding me or if you want you can suggest a
patch. I think we already have a DISCONNECT state, where we can go instead of
release complete. I'm just not sure how that will interact with STATUS
enquiry, what state we get back.

Does the Q.931 define a maximum time before we can expect a RELEASE_COMPLETE?
When I wrote the code, I tried to simplify. What makes the case difficult is
that we need to hold on to the call descriptor after the application has left
it.

>
> One last thing: As you know for my old PBX I need a patch called
> patch-no_status_enquiry_in_NT_MODE:

Fixed with some modifications. Please test updated port.

See:

isdnconfig
isdnconfig -u XXX status_enquiry_enable
isdnconfig -u XXX status_enquiry_disable

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
Hi,

> I've made a new release of ISDN4BSD, now version 2.0.6. I4B SVN has been
> updated with new ports.

I tested all the last changes in version 2.0.6 of isdn4bsd-kmod and
isdn4-utils and everything worked as expected.

Thanks!

>> One thing is left: the handling of DISCONNECT including error codes like
>> "busy". We had some discussion about this in late 2010, I wrote
>>
>>> My understanding of the standard closing of a Q.931 connection is
>>>
>>>       --> DISCONNECT
>>>       <-- RELEASE
>>>       --> RELEASE_COMPLETE
>>>
>>> it is like closing a tcp socket (-> FIN; <- FIN+ACK; -> ACK). I have
>>> never seen an example that RELEASE and RELESE_COMPLETE is send in the
>>> same direction. Your method of finishing a Q.931 connection is correct
>>> but not standard: In the active case you send RELEASE_COMLETE, in the
>>> passive case you answer the incoming DISCONNECT with RELEASE_COMPLETE.
>> and your answer was that the statemachine in ISDN4BSD must be changed to
>> accomplish my requirement. If you have a patch for this, I would like to
>> test this.
>
> I haven't had time to look into this one yet. I will see if I can find some
> time to do this. Else keep in reminding me or if you want you can suggest a
> patch. I think we already have a DISCONNECT state, where we can go instead of
> release complete. I'm just not sure how that will interact with STATUS
> enquiry, what state we get back.
>
> Does the Q.931 define a maximum time before we can expect a RELEASE_COMPLETE?

After sending out a DISCONNECT to the D-channel the timer T105 should be
started (default ist 30 sec). This is the information given in Table 9-2
of Recommendation Q.931 (05/98) free available for download at
www.itu.int/rec/T-REC-Q.931-199805-I/e.

> isdnconfig -u XXX status_enquiry_enable
> isdnconfig -u XXX status_enquiry_disable

Works perfect.

One more thing: I have some ISDN cards "AVM Fritz!Card version 2 PCI":

ihfc1@pci0:0:7:0:
  class=0x028000 card=0x0e001244 chip=0x0e001244 rev=0x02 hdr=0x00
  vendor     = 'AVM Audiovisuelles MKTG & Computer GmbH'
  device     = 'Fritz!PCI v2.0 ISDN Controller'
  class      = network
  bar   [10] = type Memory, range 32, base 0xfb145000, size 32, enabled
  bar   [14] = type I/O Port, range 32, base 0x54c0, size 32, enabled
  cap 01[40] = powerspec 2  supports D0 D2 D3  current D0

and know that these cards do not work with isdn4bsd at the moment mainly
because of missing information from AVM. At the moment these cards run
in servers or soekris devices with FreeBSD 6 Stable without any problem
for years now using the ifpi2 driver of FreeBSD 6 and the old isdnd:

ifpi2-0@pci0:14:0:
  class=0x028000 card=0x0e001244 chip=0x0e001244 rev=0x02 hdr=0x00
  vendor     = 'AVM AUDIOVISUELLES MKTG & Computer GmbH'
  device     = 'Fritz!PCI v2.0 ISDN Controller'
  class      = network

Because I would like to update all these boxes from FreeBSD 6 to FreeBSD
>= 8, I will try to get isdnd working with isdn4bsd-kmod/utils.

First step of analyze is done: I see in the isdntrace that several of
the incoming D-channel frames have an extra byte at the end of the frame:
       10101110 UNKNOWN single octet IE = 0xae
Further I see many single outgoing bytes on L3 level:
  L3 04 AE 10101110 Protocol = Other Layer 3 or X.25        (0xae)

On the other side of the ISDN-line all length are correct. Maybe there
is a "one byte length problem" in the D-channel communication between
the i4b driver and the card.


--
Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
On Thursday 29 November 2012 17:25:46 Andreas Longwitz wrote:
> First step of analyze is done: I see in the isdntrace that several of
> the incoming D-channel frames have an extra byte at the end of the frame:
>        10101110 UNKNOWN single octet IE = 0xae
> Further I see many single outgoing bytes on L3 level:
>   L3 04 AE 10101110 Protocol = Other Layer 3 or X.25        (0xae)
>
> On the other side of the ISDN-line all length are correct. Maybe there
> is a "one byte length problem" in the D-channel communication between
> the i4b driver and the card.

Hi,

Maybe you can read out the chip numbers? Maybe some of the chips used are
documented. Should not be impossible to get this working!

The driver is located here:

src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h

Should be easy to compare with the old driver from FreeBSD 6.x.

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
Hi,

>> First step of analyze is done: I see in the isdntrace that several of
>> the incoming D-channel frames have an extra byte at the end of the frame:
>>        10101110 UNKNOWN single octet IE = 0xae
>> Further I see many single outgoing bytes on L3 level:
>>   L3 04 AE 10101110 Protocol = Other Layer 3 or X.25        (0xae)

I have to correct myself: Further I see many single incoming (not
outgoing) bytes. In the meantime I am convinced that every incoming L2
frame from the card has exactly one superfluos byte at the end.

>> On the other side of the ISDN-line all length are correct. Maybe there
>> is a "one byte length problem" in the D-channel communication between
>> the i4b driver and the card.
>
> Maybe you can read out the chip numbers? Maybe some of the chips used are
> documented. Should not be impossible to get this working!

Would be fine! The driver working in FreeBSD 6 gives ifpi2-0: ISACSX
PSB3186, but this is hardcoded in the source. On the chip I can read
"AVM PSB 3100 F".

> Should be easy to compare with the old driver from FreeBSD 6.x.

In the meantime I was able to do a verbose boot. Sounds strange, but
there was a another problem solved by Andriy Gapon:
   lists.freebsd.org/pipermail/freebsd-stable/2012-November/070634.html.

During verbose boot i4b gives for my AVM Fritz!Card version 2 PCI card:

i4b-L1 ihfc1: ihfc_pnp_probe_sub: this unit has 6 transmit and
              receive channels and 1 sub-controllers
i4b-L1 ihfc1: ihfc_alloc_all_resources: Internal IRQ-address: 0x17
ihfc1: Reserved 0x20 bytes for rid 0x10 type 3 at 0xfb145000
i4b-L1 ihfc1: ihfc_fifo_setup_soft: HFC_MAX_FRAMES >= f->fm.h.Fsize
i4b-L1 ihfc1: avm_pci_chip_status_read: status=0x48
i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x20
i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00
i4b-L1 ihfc1: __ihfc_chip_interrupt: del=00000014 ista=0x0000,
     exir=0x0000, h_ista=0x0000, h_exir=0x0000, s_int_s1=0x00
i4b-L1 ihfc1: ihfc_fsm_update: Undefined state:  1!. (p0,a0,c0,u0,d0,i1)
ihfc1: <AVM Fritz!Card version 2 PCI> port 0x54c0-0x54df mem
     0xfb145000-0xfb14501f irq 23 at device 7.0 on pci0
i4b-L1 ihfc1: ihfc_post_setup: Setting up IRQ
ihfc1: [MPSAFE]
ihfc1: [ITHREAD]
ihfc1: Attaching I4B controller 0.
i4b-L1 ihfc1: ihfc_B_get_fifo_translator:
ihfc1: Creating /dev/ihfc0.X.
i4b-L1 ihfc1: avm_pci_chip_status_read: status=0x49
i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x11
i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90
i4b-L1 ihfc1: ihfc_fsm_update: Activate indication (priority=8/9).
     (p0,a1,c1,u0,d0,i0)
i4b-L1 ihfc1: fsm_write: Start activation, cmd[0]=0x20
i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00
i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00
i4b-L1 ihfc1: __ihfc_chip_interrupt: del=00000010 ista=0x0000,
      exir=0x0000, h_ista=0x0000, h_exir=0x0000, s_int_s1=0x00

Maybe the "Undefined state" message in ihfc_fsm_update gives a hint ?

P.S.
With bootverbose in function ihfc_pnp_probe_sub() the debugbit
L1_HFC_DBG is set producing very very lot of messages and the system
comes to complete congestion, therefore after a few minutes my watchdog
triggers, If you think this not ok, then I can give more details. At the
moment I avoid this problem reliable with "isdndebug -d" as soon as
userland gets control after verbose boot.


--
Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
On Sunday 02 December 2012 00:07:36 Andreas Longwitz wrote:

> Hi,
>
> >> First step of analyze is done: I see in the isdntrace that several of
> >>
> >> the incoming D-channel frames have an extra byte at the end of the frame:
> >>        10101110 UNKNOWN single octet IE = 0xae
> >>
> >> Further I see many single outgoing bytes on L3 level:
> >>   L3 04 AE 10101110 Protocol = Other Layer 3 or X.25        (0xae)
>
> I have to correct myself: Further I see many single incoming (not
> outgoing) bytes. In the meantime I am convinced that every incoming L2
> frame from the card has exactly one superfluos byte at the end.
>
> >> On the other side of the ISDN-line all length are correct. Maybe there
> >> is a "one byte length problem" in the D-channel communication between
> >> the i4b driver and the card.
> >
> > Maybe you can read out the chip numbers? Maybe some of the chips used are
> > documented. Should not be impossible to get this working!
>
> Would be fine! The driver working in FreeBSD 6 gives ifpi2-0: ISACSX
> PSB3186, but this is hardcoded in the source. On the chip I can read
> "AVM PSB 3100 F".
>
> > Should be easy to compare with the old driver from FreeBSD 6.x.
>
> In the meantime I was able to do a verbose boot. Sounds strange, but
> there was a another problem solved by Andriy Gapon:
>    lists.freebsd.org/pipermail/freebsd-stable/2012-November/070634.html.
>
> During verbose boot i4b gives for my AVM Fritz!Card version 2 PCI card:
>
> i4b-L1 ihfc1: ihfc_pnp_probe_sub: this unit has 6 transmit and
>               receive channels and 1 sub-controllers
> i4b-L1 ihfc1: ihfc_alloc_all_resources: Internal IRQ-address: 0x17
> ihfc1: Reserved 0x20 bytes for rid 0x10 type 3 at 0xfb145000
> i4b-L1 ihfc1: ihfc_fifo_setup_soft: HFC_MAX_FRAMES >= f->fm.h.Fsize
> i4b-L1 ihfc1: avm_pci_chip_status_read: status=0x48
> i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x20
> i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00
> i4b-L1 ihfc1: __ihfc_chip_interrupt: del=00000014 ista=0x0000,
>      exir=0x0000, h_ista=0x0000, h_exir=0x0000, s_int_s1=0x00
> i4b-L1 ihfc1: ihfc_fsm_update: Undefined state:  1!. (p0,a0,c0,u0,d0,i1)
> ihfc1: <AVM Fritz!Card version 2 PCI> port 0x54c0-0x54df mem
>      0xfb145000-0xfb14501f irq 23 at device 7.0 on pci0
> i4b-L1 ihfc1: ihfc_post_setup: Setting up IRQ
> ihfc1: [MPSAFE]
> ihfc1: [ITHREAD]
> ihfc1: Attaching I4B controller 0.
> i4b-L1 ihfc1: ihfc_B_get_fifo_translator:
> ihfc1: Creating /dev/ihfc0.X.
> i4b-L1 ihfc1: avm_pci_chip_status_read: status=0x49
> i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x11
> i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90
> i4b-L1 ihfc1: ihfc_fsm_update: Activate indication (priority=8/9).
>      (p0,a1,c1,u0,d0,i0)
> i4b-L1 ihfc1: fsm_write: Start activation, cmd[0]=0x20
> i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00
> i4b-L1 ihfc1: avm_pci_b_status_read: b_status=0x00
> i4b-L1 ihfc1: __ihfc_chip_interrupt: del=00000010 ista=0x0000,
>       exir=0x0000, h_ista=0x0000, h_exir=0x0000, s_int_s1=0x00
>
> Maybe the "Undefined state" message in ihfc_fsm_update gives a hint ?
>
> P.S.
> With bootverbose in function ihfc_pnp_probe_sub() the debugbit
> L1_HFC_DBG is set producing very very lot of messages and the system
> comes to complete congestion, therefore after a few minutes my watchdog
> triggers, If you think this not ok, then I can give more details. At the
> moment I avoid this problem reliable with "isdndebug -d" as soon as
> userland gets control after verbose boot.
Hi,

The warning can be ignored I think.

I see that my driver differs a bit from the origin. That's basically my fault,
when I did the porting, I tried to make things simpler. Maybe I have to port
more stuff from the working one. Mostly it requires some 32-bit register magic
instead of 8-bit register access. I'm using transparent mode only for B-
channels, and have optimised away some programming in that regard.

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/ifpci2.c?annotate=1.19.22.1

Can you try the attached patch?

--HPS

Index: src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h
===================================================================
--- src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h (revision 2511)
+++ src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h (working copy)
@@ -113,9 +113,19 @@
 
  if(reg & 0x80)
  {
+    enum { BUFFER_SIZE = 64 };
+    u_int32_t buffer[BUFFER_SIZE];
+    IHFC_LEN_T x;
+
+    if (len > BUFFER_SIZE)
+ len = BUFFER_SIZE; /* should not happen */
+
     /* ISAC-SX REGISTER */
     bus_space_write_4(t, h, REG_ISACSX_INDEX, (reg & 0x7F));
-    bus_space_read_multi_1(t, h, REG_ISACSX_DATA, ptr, len);
+    bus_space_read_multi_4(t, h, REG_ISACSX_DATA, buffer, len);
+
+    for (x = 0; x != len; x++)
+ ptr[x] = (u_int8_t)buffer[x];
  }
  else
  {
@@ -148,9 +158,19 @@
 
  if(reg & 0x80)
  {
+    enum { BUFFER_SIZE = 64 };
+    u_int32_t buffer[BUFFER_SIZE];
+    IHFC_LEN_T x;
+
+    if (len > BUFFER_SIZE)
+ len = BUFFER_SIZE; /* should not happen */
+
+    for (x = 0; x != len; x++)
+ buffer[x] = ptr[x];
+
     /* ISAC-SX REGISTER */
     bus_space_write_4(t, h, REG_ISACSX_INDEX, (reg & 0x7F));
-    bus_space_write_multi_1(t, h, REG_ISACSX_DATA, ptr, len);
+    bus_space_write_multi_4(t, h, REG_ISACSX_DATA, buffer, len);
  }
  else
  {
@@ -215,7 +235,8 @@
 {
  IPAC_BUS_VAR(sc);
 
- u_int8_t buffer[0x40 + 0x10]; /* allocate a buffer on the stack */
+ /* allocate a buffer on the stack */
+ u_int32_t buffer[(0x40 + 0x10) / 4];
  u_int8_t temp;
 
  /* read status */
@@ -257,9 +278,9 @@
 
     /* read FIFO */
     bus_space_read_multi_4(t, h, offset + HSCX_FIFO,
-   (void *)&buffer[0], (temp+3)/4);
+        buffer, (temp + 3) / 4);
 
-    (f+receive)->Z_ptr = &buffer[0];
+    (f+receive)->Z_ptr = (uint8_t *)buffer;
     (f+receive)->Z_chip = temp;
 
     /* call filter */
@@ -279,7 +300,7 @@
     temp = 32;
 
     (f+transmit)->i_ista &= ~(I_ISTA_ERR|I_ISTA_XPR);
-    (f+transmit)->Z_ptr = &buffer[0];
+    (f+transmit)->Z_ptr = (uint8_t *)buffer;
     (f+transmit)->Z_chip = temp;
 
     /* call filter */
@@ -299,9 +320,16 @@
     /* update state */
     (f+transmit)->state &= ~(ST_FRAME_ERROR|ST_FRAME_END);
 
+    /* write FIFO length */
+    bus_space_write_1(t, h, offset + HSCX_LEN, 0);
+
+    /* write FIFO command */
+    bus_space_write_1(t, h, offset + HSCX_STAT,
+ HSCX_CMD_XME);
+
     /* write FIFO */
     bus_space_write_multi_4(t, h, offset + HSCX_FIFO,
-    (void *)&buffer[0], (temp+3)/4);
+ buffer, (temp + 3) / 4);
  }
  return;
 }

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
Hans Petter Selasky wrote:

> I see that my driver differs a bit from the origin. That's basically my fault,
> when I did the porting, I tried to make things simpler. Maybe I have to port
> more stuff from the working one. Mostly it requires some 32-bit register magic
> instead of 8-bit register access. I'm using transparent mode only for B-
> channels, and have optimised away some programming in that regard.
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/ifpci2.c?annotate=1.19.22.1
>
> Can you try the attached patch?

Yes I did, but was not happy, nothing changed. I have introduced some
messages in the source and get this every 10 seconds:

i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x80
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x05
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xae
i4b-L1 ihfc1: avm_pci_fifo_read: len=5
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=5
i4b-L1 ihfc1: avm_pci_chip_read: got 0x02d30151ae

The corresponding isdndecode looks like this:

-- NT->TE - unit:00  frame:000059 - time:03.12 00:07:14.744795 -
length:5 -----
L2 00 02 000000-- SAPI = 0              (Call Control)
         ------1- C/R = Command
         -------0 Extension Bit = 0     (with extension, octet follows)
L2 01 D3 1101001- TEI = 105 = 0x69      (Automatic TEI)
         -------1 Extension Bit = 1     (no extension, final octet)
L2 02 01 00000001 S-Frame: RR           (Receiver Ready)
L2 03 51 0101000- N(R) = 40             (receive sequence number)
         -------1 P/F, Poll = Immediate Response Required
L3 04 AE 10101110 Protocol = Other Layer 3 or X.25              (0xae)
Dumping Layer3 data, 0 bytes:


--
Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Hans Petter Selasky
On Monday 03 December 2012 00:53:58 Andreas Longwitz wrote:

> Hans Petter Selasky wrote:
> > I see that my driver differs a bit from the origin. That's basically my
> > fault, when I did the porting, I tried to make things simpler. Maybe I
> > have to port more stuff from the working one. Mostly it requires some
> > 32-bit register magic instead of 8-bit register access. I'm using
> > transparent mode only for B- channels, and have optimised away some
> > programming in that regard.
> >
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/ifpci2.c?annotate=1.1
> > 9.22.1
> >
> > Can you try the attached patch?
>
> Yes I did, but was not happy, nothing changed. I have introduced some
> messages in the source and get this every 10 seconds:
>
> i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1
> i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01
> i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1
> i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x80
> i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1
> i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x05
> i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1
> i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xae
> i4b-L1 ihfc1: avm_pci_fifo_read: len=5
> i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=5
> i4b-L1 ihfc1: avm_pci_chip_read: got 0x02d30151ae
>
> The corresponding isdndecode looks like this:
>
> -- NT->TE - unit:00  frame:000059 - time:03.12 00:07:14.744795 -
> length:5 -----
> L2 00 02 000000-- SAPI = 0              (Call Control)
>          ------1- C/R = Command
>          -------0 Extension Bit = 0     (with extension, octet follows)
> L2 01 D3 1101001- TEI = 105 = 0x69      (Automatic TEI)
>          -------1 Extension Bit = 1     (no extension, final octet)
> L2 02 01 00000001 S-Frame: RR           (Receiver Ready)
> L2 03 51 0101000- N(R) = 40             (receive sequence number)
>          -------1 P/F, Poll = Immediate Response Required
> L3 04 AE 10101110 Protocol = Other Layer 3 or X.25              (0xae)
> Dumping Layer3 data, 0 bytes:

Hi,

Could you show what code you added?

I think we are onto something. The rstad=0xae too, so apparently this byte is
added to the FIFO.

Could you try to send a dummy frame that is greater than 64 bytes? I want to
see if len = 0, is used at all.

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
Hans Petter Selasky wrote:

> Could you show what code you added?

Yes of course: In i4b_avm_pci.h I have applied your last patch and then
added some IHFC_ERR messages triggered by debug.bootverbose:

--- i4b_avm_pci.h       2012-12-03 15:27:20.000000000 +0100
+++ i4b_avm_pci.h.debug 2012-12-03 00:29:03.000000000 +0100
@@ -111,6 +111,10 @@
 {
        IPAC_BUS_VAR(sc);

+        if (bootverbose) {
+           IHFC_ERR("reg=0x%04x, len=%d\n", reg, len);
+        }
+
        if(reg & 0x80)
        {
            enum { BUFFER_SIZE = 64 };
@@ -126,6 +130,12 @@

            for (x = 0; x != len; x++)
                ptr[x] = (u_int8_t)buffer[x];
+            if (bootverbose && len == 4) {
+               IHFC_ERR("got 0x%02x%02x%02x%02x\n",
ptr[0],ptr[1],ptr[2],ptr[3]);
+            }
+            if (bootverbose && len == 5) {
+               IHFC_ERR("got 0x%02x%02x%02x%02x%02x\n",
ptr[0],ptr[1],ptr[2],ptr[3],ptr[4]);
+            }
        }
        else
        {
@@ -139,6 +149,9 @@
 {
        if(FIFO_NO(f) == d1r)
        {
+            if (bootverbose) {
+               IHFC_ERR("len=%d\n", len);
+            }
            avm_pci_chip_read(sc,(f->fm.h.Zdata),ptr,len);
        }
        else
@@ -209,6 +222,9 @@

        /* read CIR0 */
        avm_pci_chip_read(sc, REG_isacsx_cir0, &temp, 1);
+        if (bootverbose) {
+           IHFC_ERR("cir0=0x%02x\n", temp);
+        }

        *ptr = (temp >> 4) & 0xf;

@@ -357,23 +373,33 @@
            /* read ISTA (ISAC) */
            avm_pci_chip_read(sc, REG_isacsx_ista, &ista, 1);

-           IHFC_MSG("ista=0x%02x\n", ista);
+            if (bootverbose) {
+              IHFC_ERR("ista=0x%02x\n", ista);
+            }

            if(ista & 0x01 /* ICD */)
            {
                /* read ISTAD (ISAC) */
                avm_pci_chip_read(sc, REG_isacsx_istad, &ista_d, 1);

-               IHFC_MSG("ista_d=0x%02x\n", ista_d);
+                if (bootverbose) {
+                  IHFC_ERR("ista_d=0x%02x\n", ista_d);
+                }

                if(ista_d & 0x80 /* RME */)
                {
                    /* read RBCL (ISAC) */
                    avm_pci_chip_read(sc, REG_isacsx_rbcld, &temp, 1);
+                    if (bootverbose) {
+                      IHFC_ERR("rbcld=0x%02x\n", temp);
+                    }
                    sc->sc_fifo[d1r].Z_chip = temp;

                    /* read RSTA (ISAC) */
                    avm_pci_chip_read(sc, REG_isacsx_rstad, &temp, 1);
+                    if (bootverbose) {
+                      IHFC_ERR("rstad=0x%02x\n", temp);
+                    }
                    sc->sc_fifo[d1r].F_chip = temp;
                }


> I think we are onto something. The rstad=0xae too, so apparently this byte is
> added to the FIFO.
>
> Could you try to send a dummy frame that is greater than 64 bytes? I want to
> see if len = 0, is used at all.

I am sorry, but I don't know how to generate a frame in D-channel with
more than 64 bytes. If I activate the extra debug messages with sysctl
debug.bootverbose=1 and try a ping to the other side of the isp0
interface, the system crashes after some debugging output:

i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00ae, len=1
i4b-L1 ihfc1: avm_pci_fsm_read: cir0=0xc0
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x09
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xab
i4b-L1 ihfc1: avm_pci_fifo_read: len=9
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=9
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x04
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xac
i4b-L1 ihfc1: avm_pci_fifo_read: len=4
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=4
i4b-L1 ihfc1: avm_pci_chip_read: got 0x009573ac
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x05
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xae
i4b-L1 ihfc1: avm_pci_fifo_read: len=5
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=5
i4b-L1 ihfc1: avm_pci_chip_read: got 0x00950102ac
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x90
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x0d
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xac
i4b-L1 ihfc1: avm_pci_fifo_read: len=13
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=13
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x80
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a6, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rbcld=0x05
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a8, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: rstad=0xac
i4b-L1 ihfc1: avm_pci_fifo_read: len=5
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x0080, len=5
i4b-L1 ihfc1: avm_pci_chip_read: got 0x00950105ac
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00e0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista=0x01
i4b-L1 ihfc1: avm_pci_chip_read: reg=0x00a0, len=1
i4b-L1 ihfc1: avm_pci_chip_status_read: ista_d=0x14
panic: vm_fault: fault on nofault entry, addr: e5158000
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c0984233,fb,e514b7a4,c08f2ed3,fb,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c09a2e37,0,c09992fe,e514b80c,0,...) at kdb_backtrace+0x2a
panic(c09992fe,e5158000,1,e514b948,e514b938,...) at panic+0x15c
vm_fault(c17dc000,e5158000,1,0,4175e6,...) at vm_fault+0x1a4
trap_pfault(c4d332e0,4,c097e974,369,c4d31560,...) at trap_pfault+0x284
trap(e514ba60) at trap+0x3f3
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0xc0bd2338, esp = 0xe514baa0, ebp = 0xe514bbc0 ---
avm_pci_chip_write(c50cd000,80,c6334800,0,c50cd000,...) at
avm_pci_chip_write+0xa8
filter_tx(c50cddd8,20,e514bc2c,c0bcf372,c50cd000,...) at filter_tx+0x57
tx_hdlc(c50cd000,c50cddd8,c0bfeb4e,c50cd000,c0bfa0ca,...) at tx_hdlc+0x5e
i4b_ipac_tx_program(c50cd000,c50cddd8,c4de3b80,e514bc4c,1,...) at
i4b_ipac_tx_program+0x62
__ihfc_chip_interrupt(c50cd000,0,c0bfd197,39b,c4f212c0,...) at
__ihfc_chip_interrupt+0x171
ihfc_chip_interrupt(c50cd000,c4de38a0,0,109,73e3dd24,...) at
ihfc_chip_interrupt+0x38
intr_event_execute_handlers(c4d31560,c4d76b80,c097e974,52c,c4d76bf0,...)
at intr_event_execute_handlers+0x13b
ithread_loop(c525b040,e514bd28,0,c4d31560,0,...) at ithread_loop+0x6b
fork_exit(c06b0290,c525b040,e514bd28) at fork_exit+0x97
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe514bd60, ebp = 0 ---
KDB: enter: panic
[thread pid 12 tid 100028 ]
Stopped at      kdb_enter+0x3a: movl    $0,kdb_why
db:0:kdb.enter.panic> watchdog
No argument provided, disabling watchdog
db:0:kdb.enter.panic>  run ddbinfo
db:1:ddbinfo> capture on
db:1:on>  run lockinfo
db:2:lockinfo> show lock Giant
 class: sleep mutex
 name: Giant
 flags: {DEF, RECURSE}
 state: {UNOWNED}
db:2:Giant>  show lockedvnods
Locked vnodes

0xc5d0cb84: tag ufs, type VREG
    usecount 1, writecount 1, refcount 24 mountedhere 0
    flags ()
    v_object 0xc5f3e908 ref 0 pages 88
    lock type ufs: EXCL by thread 0xc5be02e0 (pid 858)
        ino 94218, on dev amrd0p4
db:2:lockedvnods>  show lockchain
thread 100028 (pid 12, irq23: ihfc1) running on CPU 0
db:2:lockchain>  show sleepchain
thread 100028 (pid 12, irq23: ihfc1) running on CPU 0
db:1:sleepchain>  show pcpu
cpuid        = 0
dynamic pcpu = 0x61ed80
curthread    = 0xc4de38a0: pid 12 "irq23: ihfc1"
curpcb       = 0xe514bd80
fpcurthread  = none
idlethread   = 0xc4d335c0: tid 100004 "idle: cpu0"
APIC ID      = 3
currentldt   = 0x50
db:1:pcpu>  show allpcpu
Current CPU: 0

cpuid        = 0
dynamic pcpu = 0x61ed80
curthread    = 0xc4de38a0: pid 12 "irq23: ihfc1"
curpcb       = 0xe514bd80
fpcurthread  = none
idlethread   = 0xc4d335c0: tid 100004 "idle: cpu0"
APIC ID      = 3
currentldt   = 0x50

cpuid        = 1
dynamic pcpu = 0x3fbcd80
curthread    = 0xc5be1b80: pid 1104 "isdndecode"
curpcb       = 0xe7463d80
fpcurthread  = none
idlethread   = 0xc4d338a0: tid 100003 "idle: cpu1"
APIC ID      = 0
currentldt   = 0x50

db:1:allpcpu>  bt
Tracing pid 12 tid 100028 td 0xc4de38a0
kdb_enter(c098203e,c098203e,c09992fe,e514b80c,0,...) at kdb_enter+0x3a
panic(c09992fe,e5158000,1,e514b948,e514b938,...) at panic+0x179
vm_fault(c17dc000,e5158000,1,0,4175e6,...) at vm_fault+0x1a4
trap_pfault(c4d332e0,4,c097e974,369,c4d31560,...) at trap_pfault+0x284
trap(e514ba60) at trap+0x3f3
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0xc0bd2338, esp = 0xe514baa0, ebp = 0xe514bbc0 ---
avm_pci_chip_write(c50cd000,80,c6334800,0,c50cd000,...) at
avm_pci_chip_write+0xa8
filter_tx(c50cddd8,20,e514bc2c,c0bcf372,c50cd000,...) at filter_tx+0x57
tx_hdlc(c50cd000,c50cddd8,c0bfeb4e,c50cd000,c0bfa0ca,...) at tx_hdlc+0x5e
i4b_ipac_tx_program(c50cd000,c50cddd8,c4de3b80,e514bc4c,1,...) at
i4b_ipac_tx_program+0x62
__ihfc_chip_interrupt(c50cd000,0,c0bfd197,39b,c4f212c0,...) at
__ihfc_chip_interrupt+0x171
ihfc_chip_interrupt(c50cd000,c4de38a0,0,109,73e3dd24,...) at
ihfc_chip_interrupt+0x38
intr_event_execute_handlers(c4d31560,c4d76b80,c097e974,52c,c4d76bf0,...)
at intr_event_execute_handlers+0x13b
ithread_loop(c525b040,e514bd28,0,c4d31560,0,...) at ithread_loop+0x6b
fork_exit(c06b0290,c525b040,e514bd28) at fork_exit+0x97
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe514bd60, ebp = 0 ---
db:1:bt>  ps
  pid  ppid  pgrp   uid   state   wmesg     wchan    cmd
11060 10660 11060     0  S+      select   0xc5f621a4 ping
11010  1151    23     0  S       nanslp   0xc0a37984 sleep
10660 10659 10660     0  S+      wait     0xc5b47810 sh
......
100028                   Run     CPU 0               [irq23: ihfc1]
......
db:1:ps>  show thread
Thread 100028 at 0xc4de38a0:
 proc (pid 12): 0xc4d31560
 name: irq23: ihfc1
 stack: 0xe514a000-0xe514bfff
 flags: 0x4  pflags: 0x200500
 state: RUNNING (CPU 0)
 priority: 16
 container lock: sched lock 0 (0xc0a3b980)
db:1:thread>  alltrace

Tracing command ping pid 11060 tid 100157 td 0xc64388a0
sched_switch(c64388a0,0,104,3ceeb53c,316c,...) at sched_switch+0x293
mi_switch(104,0,c5f62180,c6490000,e7553a2c,...) at mi_switch+0x12f
sleepq_switch(c64388a0,0,c0985116,1a5,c64388a0,...) at sleepq_switch+0xcc
sleepq_catch_signals(c5f62180,0,c64388a0,e7553a78,c06910f7,...) at
sleepq_catch_signals+0x52
sleepq_timedwait_sig(c5f621a4,0,c0986a0f,101,0,...) at
sleepq_timedwait_sig+0x1c
_cv_timedwait_sig(c5f621a4,c5f62190,3e9,c8833670,58,...) at
_cv_timedwait_sig+0x1b7
seltdwait(e7553c18,e7553c20,c5ced000,c64388a0,e7553ac8,...) at
seltdwait+0xc1
kern_select(c64388a0,4,bfbee854,0,0,e7553c60,20,0,f4231) at
kern_select+0x571
select(c64388a0,e7553cec,c,c,c,...) at select+0x66
syscall(e7553d28) at syscall+0x342
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (93, FreeBSD ELF32, select), eip = 0x881a5053, esp =
0xbfbee74c, ebp = 0xbfbfec18 ---
....
db:1:alltrace>  capture off
db:0:kdb.enter.panic>  call doadump
Physical memory: 1011 MB
Dumping 168 MB:

I get this debug information via a ddb configuration in ddb.conf.
Unfortunately the write of the dump hangs, but that is another story.
If it is relevant, I can give more stack traces or any other debug
information.


Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ISDN4BSD (HPS version) is going into ports

Andreas Longwitz
In reply to this post by Hans Petter Selasky
Hans Petter Selasky wrote:

Hi,

i have continued to get my AVM Fritz!Card version 2 PCI card working
with isdn4bsd using isdnd and there is some progress: D-channel works
correct now with isdn4bsd 2.0.6 and the following patch:

--- i4b_filter.h.orig   2009-01-09 20:07:38.000000000 +0100
+++ i4b_filter.h        2013-01-08 18:23:01.000000000 +0100
@@ -158,6 +158,12 @@
         (f->buf_len)     -= (io_len);
         (f->Z_chip)      -= (io_len);

+        /* Hack:  <AVM Fritz!Card version 2 PCI> is ihfc1 */
+        if((FIFO_NO(f) == d1r) && sc->sc_nametmp[4] == '1' ) {
+           (f->buf_ptr)     -= 1;
+           (f->buf_len)     += 1;
+       }
+
        return;
 }

We have to read the complete D-channel message from the FIFO of the chip
and then ignore always the last byte, because register rstad is always
appended to every frame by the chip in transparent mode 0. It would be
better to handle this in i4b_avm_pnp.h, but I did not know how to
realize this. On my testserver the Fritzcard is ihfc1, therefore the
patch includes the condition "sc->sc_nametmp[4] == '1'.


> I see that my driver differs a bit from the origin. That's basically my fault,
> when I did the porting, I tried to make things simpler. Maybe I have to port
> more stuff from the working one. Mostly it requires some 32-bit register magic
> instead of 8-bit register access. I'm using transparent mode only for B-
> channels, and have optimised away some programming in that regard.
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/ifpci2.c?annotate=1.19.22.1
>
> Can you try the attached patch?

I have analyzed the i4b_ifpi2_pci.c source from FreeBSD 6 (nearly
identical to the NetBSD source ifpci2.c) and found that your patch
brings us a step forward to the way the BSD-source ifpci2.c works.
But there are some more differences between isdn4bsd and BSD:

1. Access to the PCI bus via mem in isdn4bsd, via I/O port in BSD.
2. DELAY times on startup is different: 4 ms in isdn4bsd, 10 ms in BSD
3. Initializing the chip is more expansive in BSD, otherwise the
   register cmdrd is only used in isdn4bsd.
4. In avm_pci_fifo_reset() we write two single bytes, but BSD does one
   (atomic) four byte read. Particularly we do not write the HSCX_LEN
   byte between the both written bytes (must set to 0 ?)
5. In avm_pci_b_status_read() - analog to 4. - we read two single bytes,
   BSD (atomic) four bytes.
6. After an interrupt BSD checks explicit HSCX_INT_MASK before working,
   Afterwords the use of HSCX_INT_RPR and HSCX_INT_XPR seems a little
   bit different to me.
7. isdn4bsd and BSD both set HSCX_MODE_TRANS at startup, but BSD changes
   this to HSCX_MODE_ITF_FLAG (ITF: interframe time fill) at the moment
   a B-channel is coming up. Simultaneously the HSCX_CMD_RRS bit is
   dropped (RRS = ?).

Especially the last point does not have a counterpart in isdn4bsd - or I
am wrong ?


--
Andreas Longwitz

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "[hidden email]"
12