From owner-freebsd-isdn@FreeBSD.ORG Tue Jan 8 23:42:01 2013 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8ABC85C2 for ; Tue, 8 Jan 2013 23:42:01 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 1DABD343 for ; Tue, 8 Jan 2013 23:42:00 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 1CBED5C754; Wed, 9 Jan 2013 00:41:52 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id LQ5p6sA2JdMC; Wed, 9 Jan 2013 00:41:48 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 712685C62C; Wed, 9 Jan 2013 00:41:48 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 082AB5083F; Wed, 9 Jan 2013 00:41:47 +0100 (CET) Message-ID: <50ECAEBB.3030604@incore.de> Date: Wed, 09 Jan 2013 00:41:47 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-isdn@freebsd.org Subject: Re: ISDN4BSD (HPS version) is going into ports References: <509E87EF.9070607@incore.de> <201211300844.37917.hselasky@c2i.net> <50BA8DB8.1090004@incore.de> <201212021043.53151.hselasky@c2i.net> In-Reply-To: <201212021043.53151.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 23:42:01 -0000 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: 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 From owner-freebsd-isdn@FreeBSD.ORG Wed Jan 9 09:14:19 2013 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C98D9FD5 for ; Wed, 9 Jan 2013 09:14:19 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id 40625B9D for ; Wed, 9 Jan 2013 09:14:18 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 192148374; Wed, 09 Jan 2013 10:14:10 +0100 From: Hans Petter Selasky To: Andreas Longwitz Subject: Re: ISDN4BSD (HPS version) is going into ports Date: Wed, 9 Jan 2013 10:15:39 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <509E87EF.9070607@incore.de> <201212021043.53151.hselasky@c2i.net> <50ECAEBB.3030604@incore.de> In-Reply-To: <50ECAEBB.3030604@incore.de> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 09:14:19 -0000 --Boundary-00=_7UT7Qc0cZWUWRf1 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit On Wednesday 09 January 2013 00:41:47 Andreas Longwitz wrote: > 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: is ihfc1 */ > + if((FIFO_NO(f) == d1r) && sc->sc_nametmp[4] == '1' ) { > + (f->buf_ptr) -= 1; > + (f->buf_len) += 1; > + } > + > return; > } Can you try the attached patch instead? And revert the one above? > > 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 = ?). There is no specific reason. Some of this programming was guessed based on other drivers and common thinking in this area. Please fix if something is wrong. However, note that my driver only uses transparent mode and HDLC emulation. This makes the driver much simpler. > > Especially the last point does not have a counterpart in isdn4bsd - or I > am wrong ? --HPS --Boundary-00=_7UT7Qc0cZWUWRf1 Content-Type: text/x-patch; charset="iso-8859-15"; name="avm_pci.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="avm_pci.diff" Index: src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h =================================================================== --- src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h (revision 2522) +++ src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h (working copy) @@ -113,9 +113,19 @@ if(reg & 0x80) { + IHFC_LEN_T x; + + /* sanity check */ + if (len > (sizeof(sc->sc_buffer) / 4)) + len = (sizeof(sc->sc_buffer) / 4); + /* 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, + (u_int32_t *)sc->sc_buffer, len); + + for (x = 0; x != len; x++) + ptr[x] = ((u_int32_t *)sc->sc_buffer)[x]; } else { @@ -130,6 +140,24 @@ if(FIFO_NO(f) == d1r) { avm_pci_chip_read(sc,(f->fm.h.Zdata),ptr,len); + + sc->sc_d1r_fifo_keep_len -= len; + + /* + * The RSTAD register is always appended to every frame. + * Remove that byte. + */ + if (sc->sc_d1r_fifo_keep_len == 0 && + sc->sc_d1r_fifo_strip_len != 0) { + IPAC_BUS_VAR(sc); + + if (len == 0) { + bus_space_write_4(t, h, REG_ISACSX_INDEX, + (f->fm.h.Zdata & 0x7F)); + } + bus_space_read_4(t, h, REG_ISACSX_DATA); + sc->sc_d1r_fifo_strip_len = 0; + } } else { @@ -148,9 +176,19 @@ if(reg & 0x80) { + IHFC_LEN_T x; + + /* sanity check */ + if (len > (sizeof(sc->sc_buffer) / 4)) + len = (sizeof(sc->sc_buffer) / 4); + + for (x = 0; x != len; x++) + ((u_int32_t *)sc->sc_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, + (u_int32_t *)sc->sc_buffer, len); } else { @@ -214,9 +252,6 @@ avm_pci_b_status_read(ihfc_sc_t *sc, ihfc_fifo_t *f, u_int8_t offset) { IPAC_BUS_VAR(sc); - - /* allocate a buffer on the stack */ - u_int8_t buffer[0x40 + 0x10] __aligned(4); u_int8_t temp; /* read status */ @@ -258,9 +293,9 @@ /* read FIFO */ bus_space_read_multi_4(t, h, offset + HSCX_FIFO, - (void *)&buffer[0], (temp+3)/4); + (u_int32_t *)sc->sc_buffer, (temp + 3) / 4); - (f+receive)->Z_ptr = &buffer[0]; + (f+receive)->Z_ptr = (u_int8_t *)sc->sc_buffer; (f+receive)->Z_chip = temp; /* call filter */ @@ -280,7 +315,7 @@ temp = 32; (f+transmit)->i_ista &= ~(I_ISTA_ERR|I_ISTA_XPR); - (f+transmit)->Z_ptr = &buffer[0]; + (f+transmit)->Z_ptr = (u_int8_t *)sc->sc_buffer; (f+transmit)->Z_chip = temp; /* call filter */ @@ -300,9 +335,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); + (u_int32_t *)sc->sc_buffer, (temp + 3) / 4); } return; } @@ -345,6 +387,14 @@ avm_pci_chip_read(sc, REG_isacsx_rbcld, &temp, 1); sc->sc_fifo[d1r].Z_chip = temp; + if (temp != 0) { + sc->sc_d1r_fifo_strip_len = 1; + sc->sc_d1r_fifo_keep_len = temp - 1; + } else { + sc->sc_d1r_fifo_strip_len = 0; + sc->sc_d1r_fifo_keep_len = 0; + } + /* read RSTA (ISAC) */ avm_pci_chip_read(sc, REG_isacsx_rstad, &temp, 1); sc->sc_fifo[d1r].F_chip = temp; Index: src/sys/i4b/layer1/ihfc3/i4b_ihfc2.h =================================================================== --- src/sys/i4b/layer1/ihfc3/i4b_ihfc2.h (revision 2522) +++ src/sys/i4b/layer1/ihfc3/i4b_ihfc2.h (working copy) @@ -2583,7 +2583,7 @@ struct usb_callout sc_pollout_timr; /* T50 ms */ struct usb_callout sc_pollout_timr_wait; /* T125 us */ - u_int8_t sc_buffer[1024]; + u_int8_t sc_buffer[1024] __aligned(4); struct sc_fifo * sc_fifo_select_last; /* used by * FIFO_SELECT(,) @@ -2600,6 +2600,9 @@ u_int16_t sc_f0_counter_offset; u_int32_t sc_f0_counter_last; + + u_int8_t sc_d1r_fifo_strip_len; + u_int8_t sc_d1r_fifo_keep_len; }; /*---------------------------------------------------------------------------* --Boundary-00=_7UT7Qc0cZWUWRf1-- From owner-freebsd-isdn@FreeBSD.ORG Wed Jan 9 21:15:08 2013 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BFF9F9F7 for ; Wed, 9 Jan 2013 21:15:08 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 6A8ABE7A for ; Wed, 9 Jan 2013 21:15:07 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 414265CB50; Wed, 9 Jan 2013 22:15:06 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id Mdvp42OVk_KK; Wed, 9 Jan 2013 22:15:05 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 2CCD85CB4F; Wed, 9 Jan 2013 22:15:05 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 60E2750876; Wed, 9 Jan 2013 22:15:04 +0100 (CET) Message-ID: <50EDDDD7.2000006@incore.de> Date: Wed, 09 Jan 2013 22:15:03 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ISDN4BSD (HPS version) is going into ports References: <509E87EF.9070607@incore.de> <201212021043.53151.hselasky@c2i.net> <50ECAEBB.3030604@incore.de> <201301091015.39124.hselasky@c2i.net> In-Reply-To: <201301091015.39124.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 21:15:08 -0000 Hans Petter Selasky wrote: >> >> --- 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: is ihfc1 */ >> + if((FIFO_NO(f) == d1r) && sc->sc_nametmp[4] == '1' ) { >> + (f->buf_ptr) -= 1; >> + (f->buf_len) += 1; >> + } >> + >> return; >> } > > Can you try the attached patch instead? And revert the one above? Yes I did, but no success in eliminating the superfluous byte at the end of every incoming D-channel frame, isdntrace gives one line L3 04 AE 10101110 Protocol = Other Layer 3 or X.25 (0xae) after every L2 frame and L3 0C AE 1------- Single octet Information element 10101110 UNKNOWN single octet IE = 0xae if an L3 frame occurs. Your patch seems to fiddle something in the chip in contrast to my i4b_filter.h hack. >> 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 = ?). > > There is no specific reason. Some of this programming was guessed based on > other drivers and common thinking in this area. > > Please fix if something is wrong. However, note that my driver only uses > transparent mode and HDLC emulation. This makes the driver much simpler. I try to understand what you mean - for B-channels - exactly with terms "transparent mode" and "HDLC emulation". I have b1protocol=hdlc in the file isdnd.rc and isdnd sets up the B-channel with P_HDLC (=1). If I activate the first MSG in ihfc_B_setup() I get i4b-L1 ihfc1: ihfc_B_setup: fifo(#2/#3), protocol_1=1. I introduced the following debug patch in i4b_avm_pci.h: @@ -253,13 +291,16 @@ (f+receive)->i_ista &= ~(I_ISTA_RPF|I_ISTA_ERR); temp = bus_space_read_1(t, h, offset + HSCX_LEN) & 0x3F; - if(temp == 0) temp = 32; + if (bootverbose) { + IHFC_ERR("HSCX_LEN=%d, protocol_1=%d\n", temp, f->prot_curr.protocol_1); + } + if(temp == 0) temp = 32; /* read FIFO */ and get - the other side sends ppp frames - i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=1 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=0, protocol_1=17 and nothing more. After the first read P_HDLC changed to P_HDLC_EMU_D (=17), is this correct and where this is done ? No more data after HSCX_LEN=0. My vision of "transparent mode" of a B-channel was that we have to handle a 64kbit data stream all the time, seems to be wrong ? -- Andreas Longwitz From owner-freebsd-isdn@FreeBSD.ORG Thu Jan 10 07:12:15 2013 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F630F83 for ; Thu, 10 Jan 2013 07:12:15 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id E3EBC75B for ; Thu, 10 Jan 2013 07:12:14 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 364988487; Thu, 10 Jan 2013 08:12:06 +0100 From: Hans Petter Selasky To: Andreas Longwitz Subject: Re: ISDN4BSD (HPS version) is going into ports Date: Thu, 10 Jan 2013 08:13:33 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <509E87EF.9070607@incore.de> <201301091015.39124.hselasky@c2i.net> <50EDDDD7.2000006@incore.de> In-Reply-To: <50EDDDD7.2000006@incore.de> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 07:12:15 -0000 On Wednesday 09 January 2013 22:15:03 Andreas Longwitz wrote: > Hans Petter Selasky wrote: > >> --- 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: is ihfc1 */ > >> + if((FIFO_NO(f) == d1r) && sc->sc_nametmp[4] == '1' ) { > >> + (f->buf_ptr) -= 1; > >> + (f->buf_len) += 1; > >> + } > >> + > >> > >> return; > >> > >> } > > > > Can you try the attached patch instead? And revert the one above? > Hi, > Yes I did, but no success in eliminating the superfluous byte at the end > of every incoming D-channel frame, isdntrace gives one line Can you add prints to track the "sc->sc_d1r_fifo_keep_len" and "sc- >sc_d1r_fifo_strip_len" variables? > > L3 04 AE 10101110 Protocol = Other Layer 3 or X.25 (0xae) > > after every L2 frame and > > L3 0C AE 1------- Single octet Information element > 10101110 UNKNOWN single octet IE = 0xae > > if an L3 frame occurs. > Your patch seems to fiddle something in the chip in contrast to my > i4b_filter.h hack. i4b_filter.h is not the right place to do this. > >> 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 = ?). > > > > There is no specific reason. Some of this programming was guessed based > > on other drivers and common thinking in this area. > > > > Please fix if something is wrong. However, note that my driver only uses > > transparent mode and HDLC emulation. This makes the driver much simpler. > > I try to understand what you mean - for B-channels - exactly with terms > "transparent mode" and "HDLC emulation". I have b1protocol=hdlc in the > file isdnd.rc and isdnd sets up the B-channel with P_HDLC (=1). If I > activate the first MSG in ihfc_B_setup() I get > i4b-L1 ihfc1: ihfc_B_setup: fifo(#2/#3), protocol_1=1. > My I4B falls back to HDLC emulation if hardware HDLC is not provided by the driver. > I introduced the following debug patch in i4b_avm_pci.h: > > @@ -253,13 +291,16 @@ > (f+receive)->i_ista &= ~(I_ISTA_RPF|I_ISTA_ERR); > > temp = bus_space_read_1(t, h, offset + HSCX_LEN) & 0x3F; > - if(temp == 0) temp = 32; > > + if (bootverbose) { > + IHFC_ERR("HSCX_LEN=%d, protocol_1=%d\n", temp, > f->prot_curr.protocol_1); > + } > + if(temp == 0) temp = 32; > /* read FIFO */ > > and get - the other side sends ppp frames - > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=1 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=0, protocol_1=17 Possibly some FIFO status bits are not cleared like they should, and then the stream stops. I know that some chips have a filter which stops the stream on HDLC idle bytes. It might also be worth to try dumping the register from which the HSCX_LEN comes from, if it is 2x32=64 bytes, because I mask that value with 0x1F. > > and nothing more. After the first read P_HDLC changed to P_HDLC_EMU_D > (=17), is this correct and where this is done ? > > No more data after HSCX_LEN=0. My vision of "transparent mode" of a > B-channel was that we have to handle a 64kbit data stream all the time, > seems to be wrong ? --HPS From owner-freebsd-isdn@FreeBSD.ORG Thu Jan 10 11:12:57 2013 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B650B974 for ; Thu, 10 Jan 2013 11:12:57 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 46BC2622 for ; Thu, 10 Jan 2013 11:12:56 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 776F75CB62; Thu, 10 Jan 2013 12:12:52 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id S2pilDvRrE-7; Thu, 10 Jan 2013 12:12:51 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 72D695C7B7; Thu, 10 Jan 2013 12:12:51 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id 382B850875; Thu, 10 Jan 2013 12:12:51 +0100 (CET) Message-ID: <50EEA232.2030403@incore.de> Date: Thu, 10 Jan 2013 12:12:50 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ISDN4BSD (HPS version) is going into ports References: <509E87EF.9070607@incore.de> <201301091015.39124.hselasky@c2i.net> <50EDDDD7.2000006@incore.de> <201301100813.33186.hselasky@c2i.net> In-Reply-To: <201301100813.33186.hselasky@c2i.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 11:12:57 -0000 Hans Petter Selasky wrote: 1. Problem: "last byte" on incomig D-channel frames: > Can you add prints to track the "sc->sc_d1r_fifo_keep_len" and "sc- > sc_d1r_fifo_strip_len" variables? Yes. With the following two prints avm_pci_chip_read(sc,(f->fm.h.Zdata),ptr,len); sc->sc_d1r_fifo_keep_len -= len; if (bootverbose == 2) { IHFC_ERR("len=%d, sc->sc_d1r_fifo_keep/strip_len=%d/%d\n", len, sc->sc_d1r_fifo_keep_len, sc->sc_d1r_fifo_strip_len); } and if (temp != 0) { sc->sc_d1r_fifo_strip_len = 1; sc->sc_d1r_fifo_keep_len = temp - 1; } else { sc->sc_d1r_fifo_strip_len = 0; sc->sc_d1r_fifo_keep_len = 0; } if (bootverbose == 2) { IHFC_ERR("temp=%d, sc->sc_d1r_fifo_keep/strip_len=%d/%d\n", temp, sc->sc_d1r_fifo_keep_len, sc->sc_d1r_fifo_strip_len); } I got avm_pci_chip_status_read: temp=5, sc->sc_d1r_fifo_keep/strip_len=4/1 avm_pci_fifo_read: len=5, sc->sc_d1r_fifo_keep/strip_len=255/1 avm_pci_chip_status_read: temp=9, sc->sc_d1r_fifo_keep/strip_len=8/1 avm_pci_fifo_read: len=9, sc->sc_d1r_fifo_keep/strip_len=255/1 avm_pci_chip_status_read: temp=4, sc->sc_d1r_fifo_keep/strip_len=3/1 avm_pci_fifo_read: len=4, sc->sc_d1r_fifo_keep/strip_len=255/1 avm_pci_chip_status_read: temp=5, sc->sc_d1r_fifo_keep/strip_len=4/1 avm_pci_fifo_read: len=5, sc->sc_d1r_fifo_keep/strip_len=255/1 avm_pci_chip_status_read: temp=5, sc->sc_d1r_fifo_keep/strip_len=4/1 avm_pci_fifo_read: len=5, sc->sc_d1r_fifo_keep/strip_len=255/1 avm_pci_chip_status_read: temp=13, sc->sc_d1r_fifo_keep/strip_len=12/1 avm_pci_fifo_read: len=13, sc->sc_d1r_fifo_keep/strip_len=255/1 avm_pci_chip_status_read: temp=5, sc->sc_d1r_fifo_keep/strip_len=4/1 avm_pci_fifo_read: len=5, sc->sc_d1r_fifo_keep/strip_len=255/1 avm_pci_chip_status_read: temp=5, sc->sc_d1r_fifo_keep/strip_len=4/1 avm_pci_fifo_read: len=5, sc->sc_d1r_fifo_keep/strip_len=255/1 avm_pci_chip_status_read: temp=16, sc->sc_d1r_fifo_keep/strip_len=15/1 avm_pci_fifo_read: len=16, sc->sc_d1r_fifo_keep/strip_len=255/1 avm_pci_chip_status_read: temp=12, sc->sc_d1r_fifo_keep/strip_len=11/1 avm_pci_fifo_read: len=12, sc->sc_d1r_fifo_keep/strip_len=255/1 avm_pci_chip_status_read: temp=29, sc->sc_d1r_fifo_keep/strip_len=28/1 avm_pci_fifo_read: len=29, sc->sc_d1r_fifo_keep/strip_len=255/1 > i4b_filter.h is not the right place to do this. I agree, should be done in i4b_avm_pci.h. 2. Problem: B-channel does not work. > Possibly some FIFO status bits are not cleared like they should, and then the > stream stops. > I know that some chips have a filter which stops the stream on HDLC idle > bytes. > It might also be worth to try dumping the register from which the HSCX_LEN > comes from, if it is 2x32=64 bytes, because I mask that value with 0x1F. I did not find a masking with 0x1F, or do you mean 0x3F (typing error) ? I will do more work on B-channel analysis. It would be very helpful for me, if you can give an answer to the following question: After the B-channel is established, the other side starts sending the following data packet (from isdndecode of the other side): -- TE->NT - unit:00 frame:351318 - time:10.01 11:34:12.595168 - length:18 ---- B01:000 ff 03 c0 21 01 d8 00 0e 05 06 31 13 cd b3 03 04 B01:010 c0 23 What should we read in avm_pci_b_status_read() with if(temp == 0) temp = 32; /* read FIFO */ bus_space_read_multi_4(t, h, offset + HSCX_FIFO, (u_int32_t *)sc->sc_buffer, (temp + 3) / 4); if everything works correct and how many interrupts can we expect for the message of 18 bytes ? -- Dr. Andreas Longwitz Data Service GmbH Beethovenstr. 2A 23617 Stockelsdorf Amtsgericht Lübeck, HRB 318 BS Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau From owner-freebsd-isdn@FreeBSD.ORG Thu Jan 10 16:54:59 2013 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A5CCDB4 for ; Thu, 10 Jan 2013 16:54:59 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 17CCC95C for ; Thu, 10 Jan 2013 16:54:58 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 362162848; Thu, 10 Jan 2013 17:54:50 +0100 From: Hans Petter Selasky To: Andreas Longwitz Subject: Re: ISDN4BSD (HPS version) is going into ports Date: Thu, 10 Jan 2013 17:56:16 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <509E87EF.9070607@incore.de> <201301100813.33186.hselasky@c2i.net> <50EEA232.2030403@incore.de> In-Reply-To: <50EEA232.2030403@incore.de> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 16:54:59 -0000 --Boundary-00=_wKv7Q3MCbSnoBf5 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit On Thursday 10 January 2013 12:12:50 Andreas Longwitz wrote: > Hans Petter Selasky wrote: > > 1. Problem: "last byte" on incomig D-channel frames: > > Can you add prints to track the "sc->sc_d1r_fifo_keep_len" and "sc- > > sc_d1r_fifo_strip_len" variables? > > Yes. With the following two prints > I see. Can you try the attached patch? Revert the previous ones. > > Possibly some FIFO status bits are not cleared like they should, and then > > the stream stops. > > I know that some chips have a filter which stops the stream on HDLC idle > > bytes. > > It might also be worth to try dumping the register from which the > > HSCX_LEN comes from, if it is 2x32=64 bytes, because I mask that value > > with 0x1F. > > I did not find a masking with 0x1F, or do you mean 0x3F (typing error) ? Yes. > > I will do more work on B-channel analysis. It would be very helpful for > me, if you can give an answer to the following question: > > After the B-channel is established, the other side starts sending the > following data packet (from isdndecode of the other side): > > -- TE->NT - unit:00 frame:351318 - time:10.01 11:34:12.595168 - > length:18 ---- > B01:000 ff 03 c0 21 01 d8 00 0e 05 06 31 13 cd b3 03 04 > B01:010 c0 23 > > What should we read in avm_pci_b_status_read() with > > if(temp == 0) temp = 32; > /* read FIFO */ > bus_space_read_multi_4(t, h, offset + HSCX_FIFO, > (u_int32_t *)sc->sc_buffer, (temp + 3) / 4); > > if everything works correct and how many interrupts can we expect for > the message of 18 bytes ? You should either get 32+32+32+32+32 and so on, or you will get: (18+((number_of_bit_stuffings+7)/8) +2) bytes. --HPS --Boundary-00=_wKv7Q3MCbSnoBf5 Content-Type: text/x-patch; charset="iso-8859-15"; name="avm_pci.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="avm_pci.diff" Index: src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h =================================================================== --- src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h (revision 2522) +++ src/sys/i4b/layer1/ihfc3/i4b_avm_pci.h (working copy) @@ -113,9 +113,19 @@ if(reg & 0x80) { + IHFC_LEN_T x; + + /* sanity check */ + if (len > (sizeof(sc->sc_buffer) / 4)) + len = (sizeof(sc->sc_buffer) / 4); + /* 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, + (u_int32_t *)sc->sc_buffer, len); + + for (x = 0; x != len; x++) + ptr[x] = ((u_int32_t *)sc->sc_buffer)[x]; } else { @@ -148,9 +158,19 @@ if(reg & 0x80) { + IHFC_LEN_T x; + + /* sanity check */ + if (len > (sizeof(sc->sc_buffer) / 4)) + len = (sizeof(sc->sc_buffer) / 4); + + for (x = 0; x != len; x++) + ((u_int32_t *)sc->sc_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, + (u_int32_t *)sc->sc_buffer, len); } else { @@ -214,9 +234,6 @@ avm_pci_b_status_read(ihfc_sc_t *sc, ihfc_fifo_t *f, u_int8_t offset) { IPAC_BUS_VAR(sc); - - /* allocate a buffer on the stack */ - u_int8_t buffer[0x40 + 0x10] __aligned(4); u_int8_t temp; /* read status */ @@ -258,9 +275,9 @@ /* read FIFO */ bus_space_read_multi_4(t, h, offset + HSCX_FIFO, - (void *)&buffer[0], (temp+3)/4); + (u_int32_t *)sc->sc_buffer, (temp + 3) / 4); - (f+receive)->Z_ptr = &buffer[0]; + (f+receive)->Z_ptr = (u_int8_t *)sc->sc_buffer; (f+receive)->Z_chip = temp; /* call filter */ @@ -280,7 +297,7 @@ temp = 32; (f+transmit)->i_ista &= ~(I_ISTA_ERR|I_ISTA_XPR); - (f+transmit)->Z_ptr = &buffer[0]; + (f+transmit)->Z_ptr = (u_int8_t *)sc->sc_buffer; (f+transmit)->Z_chip = temp; /* call filter */ @@ -300,9 +317,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); + (u_int32_t *)sc->sc_buffer, (temp + 3) / 4); } return; } @@ -604,7 +628,7 @@ I4B_DBASE_ADD(i4b_option_value , 0); I4B_DBASE_ADD(d_fifo_map[d1t] , FM2OFF (isac_fifo_map[0])); - I4B_DBASE_ADD(d_fifo_map[d1r] , FM2OFF (isac_fifo_map[0])); + I4B_DBASE_ADD(d_fifo_map[d1r] , FM2OFF (isac_remove_stat_fifo_map[0])); I4B_DBASE_ADD(o_RES_IRQ_0 , 1); /* enable */ I4B_DBASE_ADD(o_RES_MEMORY_0 , 1); /* enable */ Index: src/sys/i4b/layer1/ihfc3/i4b_isac.h =================================================================== --- src/sys/i4b/layer1/ihfc3/i4b_isac.h (revision 2522) +++ src/sys/i4b/layer1/ihfc3/i4b_isac.h (working copy) @@ -330,6 +330,20 @@ * fifo maps. *---------------------------------------------------------------------------*/ +I4B_FIFO_MAP_DECLARE(isac_remove_stat_fifo_map[]) = +{ + /* + * IPAC D-channel FIFO map + */ + + [ 0].i= + { + .Zdata = REG_isac_data, + .remove_stat = 1, /* present */ + .block_size = 0x20, /* = 32 bytes */ + }, +}; + I4B_FIFO_MAP_DECLARE(isac_fifo_map[]) = { /* Index: src/sys/i4b/layer1/ihfc3/i4b_ihfc2.h =================================================================== --- src/sys/i4b/layer1/ihfc3/i4b_ihfc2.h (revision 2522) +++ src/sys/i4b/layer1/ihfc3/i4b_ihfc2.h (working copy) @@ -2583,7 +2583,7 @@ struct usb_callout sc_pollout_timr; /* T50 ms */ struct usb_callout sc_pollout_timr_wait; /* T125 us */ - u_int8_t sc_buffer[1024]; + u_int8_t sc_buffer[1024] __aligned(4); struct sc_fifo * sc_fifo_select_last; /* used by * FIFO_SELECT(,) --Boundary-00=_wKv7Q3MCbSnoBf5-- From owner-freebsd-isdn@FreeBSD.ORG Thu Jan 10 22:30:01 2013 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5E8B5BA9 for ; Thu, 10 Jan 2013 22:30:01 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id D40CADAE for ; Thu, 10 Jan 2013 22:30:00 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id CFBDF5CC05; Thu, 10 Jan 2013 23:29:58 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id qWywaxMAfD73; Thu, 10 Jan 2013 23:29:57 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 5255E5CBF8; Thu, 10 Jan 2013 23:29:57 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 7CB7550876; Thu, 10 Jan 2013 23:29:56 +0100 (CET) Message-ID: <50EF40E4.7030805@incore.de> Date: Thu, 10 Jan 2013 23:29:56 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: ISDN4BSD (HPS version) is going into ports References: <509E87EF.9070607@incore.de> <201301100813.33186.hselasky@c2i.net> <50EEA232.2030403@incore.de> <201301101756.16289.hselasky@c2i.net> In-Reply-To: <201301101756.16289.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 22:30:01 -0000 Hans Petter Selasky wrote: > Can you try the attached patch? Revert the previous ones. Yes I did, but system always crashes after first ping immediately after ihfc_b_setup was called: i4b-L1 ihfc1: ihfc_B_setup: fifo(#2/#3), protocol_1=1 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 00 fault virtual address = 0xbe fault code = supervisor write, page not present instruction pointer = 0x20:0xc06c7bff stack pointer = 0x28:0xc49e8be8 frame pointer = 0x28:0xc49e8bfc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock) [thread pid 12 tid 100006 ] Stopped at _mtx_lock_flags+0x1f: lock cmpxchgl %edx,0x10(%ecx) db:0:kdb.enter.default> watchdog No argument provided, disabling watchdog db:0:kdb.enter.default> 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 db:2:lockedvnods> show lockchain thread 100006 (pid 12, swi4: clock) running on CPU 1 db:2:lockchain> show sleepchain thread 100006 (pid 12, swi4: clock) running on CPU 1 db:1:sleepchain> show pcpu cpuid = 1 dynamic pcpu = 0x3fbcd80 curthread = 0xc4d33000: pid 12 "swi4: clock" curpcb = 0xc49e8d80 fpcurthread = none idlethread = 0xc4d338a0: tid 100003 "idle: cpu1" APIC ID = 0 currentldt = 0x50 db:1:pcpu> show allpcpu Current CPU: 1 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 = 0xc4d33000: pid 12 "swi4: clock" curpcb = 0xc49e8d80 fpcurthread = none idlethread = 0xc4d338a0: tid 100003 "idle: cpu1" APIC ID = 0 currentldt = 0x50 db:1:allpcpu> bt Tracing pid 12 tid 100006 td 0xc4d33000 _mtx_lock_flags(ae,0,c0bff2a6,f8,c4d33000,...) at _mtx_lock_flags+0x1f i4bisppp_start(c5532800,0,c49e8c50,c06fb6fc,c0a3c02c,...) at i4bisppp_start+0x5a softclock(c0a379c0,c4d33000,0,109,56c88f72,...) at softclock+0x237 intr_event_execute_handlers(c4d31560,c4d76680,c097e974,52c,c4d766f0,...) at intr_event_execute_handlers+0x13b ithread_loop(c4d30180,c49e8d28,0,c4d31560,0,...) at ithread_loop+0x6b fork_exit(c06b0290,c4d30180,c49e8d28) at fork_exit+0x97 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc49e8d60, ebp = 0 --- db:1:bt> ps pid ppid pgrp uid state wmesg wchan cmd 1584 1357 1584 1003 S+ select 0xc63fb0e4 ping 1577 1 1562 0 S+ select 0xc5be1a64 isdndecode 1576 1 1562 0 S+ select 0xc56cb4a4 isdndecode 1575 1 1562 0 S+ select 0xc63fb5e4 isdndecode 1542 1094 23 0 S nanslp 0xc0a37984 sleep 1357 1356 1357 1003 Ss+ wait 0xc5fd22b0 bash .... 100022 I [swi6: task queue] 100021 I [swi6: Giant taskq] 100019 I [swi5: +] 100008 I [swi3: vm] 100007 RunQ [swi4: clock] 100006 Run CPU 1 [swi4: clock] 100005 I [swi1: netisr 0] 11 0 0 0 RL (threaded) idle 100004 CanRun [idle: cpu0] 100003 CanRun [idle: cpu1] 1 0 1 0 SLs wait 0xc4d31ac0 [init] 10 0 0 0 SL audit_wo 0xc0a53ac0 [audit] 0 0 0 0 SLs (threaded) kernel 100040 D - 0xc56ca6c0 [dummynet] 100038 D - 0xc5534940 [mca taskq] 100023 D - 0xc4e106c0 [kqueue taskq] 100020 D - 0xc4e10940 [thread taskq] 100018 D - 0xc4e10a00 [ffs_trim taskq] 100017 D - 0xc4e10a40 [acpi_task_2] 100016 D - 0xc4e10a40 [acpi_task_1] 100015 D - 0xc4e10a40 [acpi_task_0] 100000 D sched 0xc0a350a0 [swapper] db:1:ps> show thread Thread 100006 at 0xc4d33000: proc (pid 12): 0xc4d31560 name: swi4: clock stack: 0xc49e7000-0xc49e8fff flags: 0x50004 pflags: 0x200500 state: RUNNING (CPU 1) priority: 52 container lock: sched lock 1 (0xc0a3c000) db:1:thread> alltrace Tracing command ping pid 1584 tid 100156 td 0xc639f8a0 sched_switch(c639f8a0,0,104,56ccd79a,15d,...) at sched_switch+0x293 mi_switch(104,0,c63fb0c0,c63eb000,e754fa2c,...) at mi_switch+0x12f sleepq_switch(c639f8a0,0,c0985116,1a5,c639f8a0,...) at sleepq_switch+0xcc sleepq_catch_signals(c63fb0c0,0,c639f8a0,e754fa78,c06910f7,...) at sleepq_catch_signals+0x52 sleepq_timedwait_sig(c63fb0e4,0,c0986a0f,101,0,...) at sleepq_timedwait_sig+0x1c _cv_timedwait_sig(c63fb0e4,c63fb0d0,3e9,c6292b44,58,...) at _cv_timedwait_sig+0x1b7 seltdwait(e754fc18,e754fc20,c62b1300,c639f8a0,e754fac8,...) at seltdwait+0xc1 kern_select(c639f8a0,4,bfbee884,0,0,e754fc60,20,0,f4233) at kern_select+0x571 select(c639f8a0,e754fcec,c,c,c,...) at select+0x66 syscall(e754fd28) at syscall+0x342 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (93, FreeBSD ELF32, select), eip = 0x881ae053, esp = 0xbfbee77c, ebp = 0xbfbfec48 --- Tracing command intr pid 12 tid 100028 td 0xc4de38a0 cpustop_handler(1,e514bb60,c08fe166,0,e514bb0c,...) at cpustop_handler+0x34 ipi_nmi_handler(0,e514bb0c,c0606dbb,c5510000,c4d31560,...) at ipi_nmi_handler+0x2f trap(e514bb6c) at trap+0x36 calltrap() at calltrap+0x6 --- trap 0x13, eip = 0xc0bd4fd6, esp = 0xe514bbac, ebp = 0xe514bbc4 --- avm_pci_chip_read(c50cd000,80,c64a6820,0,c50cd000,...) at avm_pci_chip_read+0x56 filter_rx(e514bc1d,c50cd000,49,c50cde78,20,...) at filter_rx+0x5c rx_hdlc(c50cd000,c50cde78,8001ae30,c50cd000,c4d76b80,...) at rx_hdlc+0x5d i4b_ipac_rx_program(c50cd000,c50cde78,c4de38a0,e514bc4c,c4d335c0,...) at i4b_ipac_rx_program+0x4a __ihfc_chip_interrupt(c50cd000,0,c0bfceb7,39b,c4f212c0,...) at __ihfc_chip_interrupt+0x171 ihfc_chip_interrupt(c50cd000,c4de38a0,0,109,4dbdab7e,...) 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 --- ... If I revert the use of isac_remove_stat_fifo_map from your last patch and use my i4b_filter.h hack instead, then no crash occurs and D-channel is ok. >> I will do more work on B-channel analysis. It would be very helpful for >> me, if you can give an answer to the following question: >> >> After the B-channel is established, the other side starts sending the >> following data packet (from isdndecode of the other side): >> >> -- TE->NT - unit:00 frame:351318 - time:10.01 11:34:12.595168 - >> length:18 ---- >> B01:000 ff 03 c0 21 01 d8 00 0e 05 06 31 13 cd b3 03 04 >> B01:010 c0 23 >> >> What should we read in avm_pci_b_status_read() with >> >> if(temp == 0) temp = 32; >> /* read FIFO */ >> bus_space_read_multi_4(t, h, offset + HSCX_FIFO, >> (u_int32_t *)sc->sc_buffer, (temp + 3) / 4); >> >> if everything works correct and how many interrupts can we expect for >> the message of 18 bytes ? > > You should either get 32+32+32+32+32 and so on, or you will get: > (18+((number_of_bit_stuffings+7)/8) +2) bytes. > The other side sends 11 frames of length 18 in B-channel and with my last kernel described above I see login: i4b-L1 ihfc1: ihfc_B_setup: fifo(#2/#3), protocol_1=1 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=1 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 i4b-L1 ihfc1: ihfc_B_setup: fifo(#2/#3), protocol_1=0 The debug message comes from temp = bus_space_read_1(t, h, offset + HSCX_LEN); if (bootverbose == 2) IHFC_ERR("HSCX_LEN=%d, protocol_1=%d\n", temp, f->prot_curr.protocol_1); temp = temp & 0x3F; if(temp == 0) temp = 32; This proves that your use of 0x3F is ok. I am not sure, but it seems to me, that the use of __aligned for the sc_buffer has changed things. In the sourcefile i4b_avm_pci.h of the ports version 2.0.6 the __aligned option was not present, you have introduced this later in your repository. -- Andreas Longwitz From owner-freebsd-isdn@FreeBSD.ORG Fri Jan 11 10:49:30 2013 Return-Path: Delivered-To: freebsd-isdn@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB22A74 for ; Fri, 11 Jan 2013 10:49:30 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 53AF72D3 for ; Fri, 11 Jan 2013 10:49:29 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 365429242; Fri, 11 Jan 2013 11:49:21 +0100 From: Hans Petter Selasky To: Andreas Longwitz Subject: Re: ISDN4BSD (HPS version) is going into ports Date: Fri, 11 Jan 2013 11:50:47 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <509E87EF.9070607@incore.de> <201301101756.16289.hselasky@c2i.net> <50EF40E4.7030805@incore.de> In-Reply-To: <50EF40E4.7030805@incore.de> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: freebsd-isdn@freebsd.org X-BeenThere: freebsd-isdn@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Using ISDN with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:49:30 -0000 On Thursday 10 January 2013 23:29:56 Andreas Longwitz wrote: > Hans Petter Selasky wrote: > > Can you try the attached patch? Revert the previous ones. > > Yes I did, but system always crashes after first ping immediately after > ihfc_b_setup was called: > > i4b-L1 ihfc1: ihfc_B_setup: fifo(#2/#3), protocol_1=1 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 00 > fault virtual address = 0xbe > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc06c7bff > stack pointer = 0x28:0xc49e8be8 > frame pointer = 0x28:0xc49e8bfc > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (swi4: clock) > [thread pid 12 tid 100006 ] > Stopped at _mtx_lock_flags+0x1f: lock cmpxchgl %edx,0x10(%ecx) > db:0:kdb.enter.default> watchdog > No argument provided, disabling watchdog > db:0:kdb.enter.default> 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 > db:2:lockedvnods> show lockchain > thread 100006 (pid 12, swi4: clock) running on CPU 1 > db:2:lockchain> show sleepchain > thread 100006 (pid 12, swi4: clock) running on CPU 1 > db:1:sleepchain> show pcpu > cpuid = 1 > dynamic pcpu = 0x3fbcd80 > curthread = 0xc4d33000: pid 12 "swi4: clock" > curpcb = 0xc49e8d80 > fpcurthread = none > idlethread = 0xc4d338a0: tid 100003 "idle: cpu1" > APIC ID = 0 > currentldt = 0x50 > db:1:pcpu> show allpcpu > Current CPU: 1 > > 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 = 0xc4d33000: pid 12 "swi4: clock" > curpcb = 0xc49e8d80 > fpcurthread = none > idlethread = 0xc4d338a0: tid 100003 "idle: cpu1" > APIC ID = 0 > currentldt = 0x50 > > db:1:allpcpu> bt > Tracing pid 12 tid 100006 td 0xc4d33000 > _mtx_lock_flags(ae,0,c0bff2a6,f8,c4d33000,...) at _mtx_lock_flags+0x1f > i4bisppp_start(c5532800,0,c49e8c50,c06fb6fc,c0a3c02c,...) at > i4bisppp_start+0x5a > softclock(c0a379c0,c4d33000,0,109,56c88f72,...) at softclock+0x237 > intr_event_execute_handlers(c4d31560,c4d76680,c097e974,52c,c4d766f0,...) > at intr_event_execute_handlers+0x13b > ithread_loop(c4d30180,c49e8d28,0,c4d31560,0,...) at ithread_loop+0x6b > fork_exit(c06b0290,c4d30180,c49e8d28) at fork_exit+0x97 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc49e8d60, ebp = 0 --- > db:1:bt> ps > pid ppid pgrp uid state wmesg wchan cmd > 1584 1357 1584 1003 S+ select 0xc63fb0e4 ping > 1577 1 1562 0 S+ select 0xc5be1a64 isdndecode > 1576 1 1562 0 S+ select 0xc56cb4a4 isdndecode > 1575 1 1562 0 S+ select 0xc63fb5e4 isdndecode > 1542 1094 23 0 S nanslp 0xc0a37984 sleep > 1357 1356 1357 1003 Ss+ wait 0xc5fd22b0 bash > .... > 100022 I [swi6: task queue] > 100021 I [swi6: Giant taskq] > 100019 I [swi5: +] > 100008 I [swi3: vm] > 100007 RunQ [swi4: clock] > 100006 Run CPU 1 [swi4: clock] > 100005 I [swi1: netisr 0] > 11 0 0 0 RL (threaded) idle > 100004 CanRun [idle: cpu0] > 100003 CanRun [idle: cpu1] > 1 0 1 0 SLs wait 0xc4d31ac0 [init] > 10 0 0 0 SL audit_wo 0xc0a53ac0 [audit] > 0 0 0 0 SLs (threaded) kernel > 100040 D - 0xc56ca6c0 [dummynet] > 100038 D - 0xc5534940 [mca taskq] > 100023 D - 0xc4e106c0 [kqueue taskq] > 100020 D - 0xc4e10940 [thread taskq] > 100018 D - 0xc4e10a00 [ffs_trim taskq] > 100017 D - 0xc4e10a40 [acpi_task_2] > 100016 D - 0xc4e10a40 [acpi_task_1] > 100015 D - 0xc4e10a40 [acpi_task_0] > 100000 D sched 0xc0a350a0 [swapper] > db:1:ps> show thread > Thread 100006 at 0xc4d33000: > proc (pid 12): 0xc4d31560 > name: swi4: clock > stack: 0xc49e7000-0xc49e8fff > flags: 0x50004 pflags: 0x200500 > state: RUNNING (CPU 1) > priority: 52 > container lock: sched lock 1 (0xc0a3c000) > db:1:thread> alltrace > > Tracing command ping pid 1584 tid 100156 td 0xc639f8a0 > sched_switch(c639f8a0,0,104,56ccd79a,15d,...) at sched_switch+0x293 > mi_switch(104,0,c63fb0c0,c63eb000,e754fa2c,...) at mi_switch+0x12f > sleepq_switch(c639f8a0,0,c0985116,1a5,c639f8a0,...) at sleepq_switch+0xcc > sleepq_catch_signals(c63fb0c0,0,c639f8a0,e754fa78,c06910f7,...) at > sleepq_catch_signals+0x52 > sleepq_timedwait_sig(c63fb0e4,0,c0986a0f,101,0,...) at > sleepq_timedwait_sig+0x1c > _cv_timedwait_sig(c63fb0e4,c63fb0d0,3e9,c6292b44,58,...) at > _cv_timedwait_sig+0x1b7 > seltdwait(e754fc18,e754fc20,c62b1300,c639f8a0,e754fac8,...) at > seltdwait+0xc1 > kern_select(c639f8a0,4,bfbee884,0,0,e754fc60,20,0,f4233) at > kern_select+0x571 > select(c639f8a0,e754fcec,c,c,c,...) at select+0x66 > syscall(e754fd28) at syscall+0x342 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (93, FreeBSD ELF32, select), eip = 0x881ae053, esp = > 0xbfbee77c, ebp = 0xbfbfec48 --- > > Tracing command intr pid 12 tid 100028 td 0xc4de38a0 > cpustop_handler(1,e514bb60,c08fe166,0,e514bb0c,...) at cpustop_handler+0x34 > ipi_nmi_handler(0,e514bb0c,c0606dbb,c5510000,c4d31560,...) at > ipi_nmi_handler+0x2f > trap(e514bb6c) at trap+0x36 > calltrap() at calltrap+0x6 > --- trap 0x13, eip = 0xc0bd4fd6, esp = 0xe514bbac, ebp = 0xe514bbc4 --- > avm_pci_chip_read(c50cd000,80,c64a6820,0,c50cd000,...) at > avm_pci_chip_read+0x56 > filter_rx(e514bc1d,c50cd000,49,c50cde78,20,...) at filter_rx+0x5c > rx_hdlc(c50cd000,c50cde78,8001ae30,c50cd000,c4d76b80,...) at rx_hdlc+0x5d > i4b_ipac_rx_program(c50cd000,c50cde78,c4de38a0,e514bc4c,c4d335c0,...) at > i4b_ipac_rx_program+0x4a > __ihfc_chip_interrupt(c50cd000,0,c0bfceb7,39b,c4f212c0,...) at > __ihfc_chip_interrupt+0x171 > ihfc_chip_interrupt(c50cd000,c4de38a0,0,109,4dbdab7e,...) 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 --- > ... > > If I revert the use of isac_remove_stat_fifo_map from your last patch > and use my i4b_filter.h hack instead, then no crash occurs and D-channel > is ok. > > >> I will do more work on B-channel analysis. It would be very helpful for > >> me, if you can give an answer to the following question: > >> > >> After the B-channel is established, the other side starts sending the > >> following data packet (from isdndecode of the other side): > >> > >> -- TE->NT - unit:00 frame:351318 - time:10.01 11:34:12.595168 - > >> > >> length:18 ---- > >> > >> B01:000 ff 03 c0 21 01 d8 00 0e 05 06 31 13 cd b3 03 04 > >> B01:010 c0 23 > >> > >> What should we read in avm_pci_b_status_read() with > >> > >> if(temp == 0) temp = 32; > >> > >> /* read FIFO */ > >> bus_space_read_multi_4(t, h, offset + HSCX_FIFO, > >> > >> (u_int32_t *)sc->sc_buffer, (temp + 3) / 4); > >> > >> if everything works correct and how many interrupts can we expect for > >> the message of 18 bytes ? > > > > You should either get 32+32+32+32+32 and so on, or you will get: > > (18+((number_of_bit_stuffings+7)/8) +2) bytes. > > The other side sends 11 frames of length 18 in B-channel and with my > last kernel described above I see > > login: i4b-L1 ihfc1: ihfc_B_setup: fifo(#2/#3), protocol_1=1 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=1 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 > i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=18, protocol_1=17 > i4b-L1 ihfc1: ihfc_B_setup: fifo(#2/#3), protocol_1=0 > > The debug message comes from > > temp = bus_space_read_1(t, h, offset + HSCX_LEN); > if (bootverbose == 2) > IHFC_ERR("HSCX_LEN=%d, protocol_1=%d\n", temp, > f->prot_curr.protocol_1); > temp = temp & 0x3F; > if(temp == 0) temp = 32; > > This proves that your use of 0x3F is ok. > I am not sure, but it seems to me, that the use of __aligned for the > sc_buffer has changed things. In the sourcefile i4b_avm_pci.h of the > ports version 2.0.6 the __aligned option was not present, you have > introduced this later in your repository. Hi, Looks like you are almost there. I will reply to your other comments later. Can you try to add a printf in "src/sys/i4b/driver/i4b_isppp.c": static void i4bisppp_start(struct ifnet *ifp) { struct i4bisppp_softc *sc = ifp->if_softc; printf("ifp=%p sc=%p\n", sc, ifp); is the "sc" NULL ? Looks like another issue. --HPS