ISDN4BSD (HPS version) is going into ports

[Hans Petter Selasky]

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