Project

General

Profile

Actions

Support #6412

open

No alignment

Added by pfassberg 23 days ago. Updated 16 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
electrical
Target version:
-
Start date:
03/20/2024
Due date:
% Done:

0%

Spec Reference:

Description

I'm testing icE1usb to connect a ISDN PBX to a switch partly over SDH.

SS7/ISDN Switch - (STM-1) - ADM - (E1) - icE1usb - (IP) - icE1usb - (E1) - PABX

In the PABX side I have no problems, but between the ADM and the icE1usb I have problem to get the icE1usb aligned.

If I use a loopback cable I can get the ADM and the icE1usb aligned. But when I connect them only the ADM get aligned, never the icE1usb. The icE1usb don't act at all. The green LED keeps flashing and nothing in the logs or stat.

If I connect a Cisco modem pool to the same ADM port it immediately get aligned. I have MGWs and other stuff connected to the same ADM with no problems.

I've measured the voltage and find roughly 4 V Vp-p from icE1usb and 5 V Vp-p from the ADM.

I do not use CRC4 but I can't find any CRC4 settings in osmo-e1d config.

Any clues about what is going on and how to debug this?

// Peter

Actions #1

Updated by laforge 23 days ago

It most likely is the lack of CRC4. As far as I recall from memory, the gsteware supports operation with and without it, but we may never have exposed that through firmware and use protocol into osmo-e1d. I suffest to grep for CRC4 through the code to get some hints.

Actions #2

Updated by pfassberg 22 days ago

laforge wrote in #note-1:

It most likely is the lack of CRC4. As far as I recall from memory, the gsteware supports operation with and without it, but we may never have exposed that through firmware and use protocol into osmo-e1d. I suffest to grep for CRC4 through the code to get some hints.

You are right. After configuring CRC4 correctly I managed to get the D-channel up and also do a voice call.

Unfortunately I get this error instead:

Thu Mar 21 14:59:56 2024 DE1D usb.c:246 (I0:L1) IN EP 84 ISO packet 0 failed with status ERROR
Thu Mar 21 14:59:56 2024 DE1D usb.c:201 (I0:L1) Feedback transfer error

I have a CM3 in one end and a CM4 in the other end. This problem only occurs in the CM4 end. I use line 1 there (line 0 isn't configured as it can only cope with one single line).

It don't seem to be disturbing, only annoying.

Do you have any thought on this?

// Peter

Actions #3

Updated by laforge 22 days ago

On Thu, Mar 21, 2024 at 02:04:37PM +0000, pfassberg wrote:

Unfortunately I get this error instead:

> Thu Mar 21 14:59:56 2024 DE1D usb.c:246 (I0:L1) IN EP 84 ISO packet 0 failed with status ERROR
> Thu Mar 21 14:59:56 2024 DE1D usb.c:201 (I0:L1) Feedback transfer error
> 

I have a CM3 in one end and a CM4 in the other end. This problem only occurs in the CM4 end. I use line 1 there (line 0 isn't configured as it can only cope with one single line).

It don't seem to be disturbing, only annoying.

well, a lack of feedback endpoint trasnfers means that osmo-e1d cannot pace the speed of transmitted frames.
So you will likely see overruns or underruns at some point in the transmit direction between
firmware/gateware on the one hand side, and osmo-e1d on the other side.

Do you have any thought on this?

No, never I've never seen this. It looks like a problem in the kernel or the usb stack/driver or the USB
itself.

Actions #4

Updated by pfassberg 16 days ago

laforge wrote in #note-3:

On Thu, Mar 21, 2024 at 02:04:37PM +0000, pfassberg wrote:

Unfortunately I get this error instead:
[...]

I have a CM3 in one end and a CM4 in the other end. This problem only occurs in the CM4 end. I use line 1 there (line 0 isn't configured as it can only cope with one single line).

It don't seem to be disturbing, only annoying.

well, a lack of feedback endpoint trasnfers means that osmo-e1d cannot pace the speed of transmitted frames.
So you will likely see overruns or underruns at some point in the transmit direction between
firmware/gateware on the one hand side, and osmo-e1d on the other side.

Do you have any thought on this?

No, never I've never seen this. It looks like a problem in the kernel or the usb stack/driver or the USB
itself.

Agree. I have now done some additional testing with other hardware and it works as a charm.

Actions #5

Updated by tnt 16 days ago

Unfortunately a lot of xhci USB controller handle a lot of stuff in firmware and bugs are not rate, especially in isochronous transfers ...

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)