ISDN4BSD (HPS version) is going into ports

[Hans Petter Selasky]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: avm_pci.diff
Type: text/x-patch
Size: 4128 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-isdn/attachments/20130110/2d529f3c/attachment.bin>