Date: Thu, 10 Jan 2013 08:13:33 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Andreas Longwitz <longwitz@incore.de> Cc: freebsd-isdn@freebsd.org Subject: Re: ISDN4BSD (HPS version) is going into ports Message-ID: <201301100813.33186.hselasky@c2i.net> In-Reply-To: <50EDDDD7.2000006@incore.de> References: <509E87EF.9070607@incore.de> <201301091015.39124.hselasky@c2i.net> <50EDDDD7.2000006@incore.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <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;
> >>
> >> }
> >
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301100813.33186.hselasky>