Project

General

Profile

Actions

Bug #5387

closed

icE1usb / osmo-e1d on Raspberry Pi 3B doesn't work (at least with two interfaces)

Added by laforge over 2 years ago. Updated over 1 year ago.

Status:
Rejected
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
01/08/2022
Due date:
% Done:

0%

Spec Reference:

Description

This is already using the dual-interface firmware.

<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:159 (I0:L1) Feedback transfer error
<0000> usb.c:159 (I0:L1) Feedback transfer error
<0000> usb.c:159 (I0:L0) Feedback transfer error
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:159 (I0:L1) Feedback transfer error
<0000> usb.c:325 (I0:L1) UNDERFLOW error count 20 (was 19)
<0000> usb.c:159 (I0:L0) Feedback transfer error
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:159 (I0:L1) Feedback transfer error
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:159 (I0:L1) Feedback transfer error
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:159 (I0:L0) Feedback transfer error
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:325 (I0:L0) UNDERFLOW error count 20 (was 19)
<0000> usb.c:159 (I0:L0) Feedback transfer error
root@remsim-server:/etc/osmocom# dpkg -l osmo-e1d
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version                   Architecture Description
+++-==============-=========================-============-=======================================
ii  osmo-e1d       0.3.0.4.3bea.202201080026 armhf        osmo-e1d: Osmocom's E1 interface daemon
Actions #1

Updated by laforge over 2 years ago

the problem does not occur with the single-line (=single-usb-interfac) firmware.

Actions #2

Updated by laforge over 2 years ago

in the non-working case with two interfaces, dmesg also shows:

[2147312.812372] usb 1-1.2: usbfs: usb_submit_urb returned -90
[2147325.180673] usb 1-1.2: usbfs: usb_submit_urb returned -90
[2147325.183170] usb 1-1.2: usbfs: usb_submit_urb returned -90
[2147327.696549] usb 1-1.2: usbfs: usb_submit_urb returned -90
[2147327.698902] usb 1-1.2: usbfs: usb_submit_urb returned -90
[2147348.500854] usb 1-1.2: usbfs: usb_submit_urb returned -90
[2147348.503394] usb 1-1.2: usbfs: usb_submit_urb returned -90
[2148336.276833] usb 1-1.2: usbfs: usb_submit_urb returned -90
[2148336.279222] usb 1-1.2: usbfs: usb_submit_urb returned -90
[2148368.078109] usb 1-1.2: usbfs: usb_submit_urb returned -90
[2148368.080608] usb 1-1.2: usbfs: usb_submit_urb returned -90

Actions #3

Updated by tnt over 2 years ago

What if you modify e1d to only enable 1 of the 2 interfaces ?

To see if it's related to the bandwidth / load or some other change in the firmware.

Actions #4

Updated by laforge over 2 years ago

tnt wrote in #note-3:

What if you modify e1d to only enable 1 of the 2 interfaces ?

To see if it's related to the bandwidth / load or some other change in the firmware.

it works (at least doesn'ts how the quoted error messages) if I do that. So I guess we're looking at some bug in the iso bandwidth allocation of the USB host controller driver] of the raspi 3b?

Actions #5

Updated by tnt over 2 years ago

:/

It uses EHCI right ?

That's weird because bandwidth allocation is made when switching the alt setting, not when trying to send a packet. Also this is handled in the kernel by common code, so I'm not sure how it can fail on only the rpi 3. It's also hard to imagine it realizes later that it can't fit the packets because the reserved bandwidth is larger than what actually gets used. 99% of the packets end up being 260 bytes and not 292 bytes, so there is quite a bit of free room in practice.

Not sure what -5 or -90 mean.

Actions #6

Updated by laforge over 2 years ago

On Sun, Jan 09, 2022 at 12:11:59PM +0000, tnt wrote:

It uses EHCI right ?

no, it has a completely custom host controller with associated kernel driver (dwc_otg):
https://github.com/raspberrypi/linux/tree/rpi-5.10.y/drivers/usb/host/dwc_otg

some people even have written different (bare metal) drivers like https://github.com/rsta2/uspi

I haven't looked at it in more detail, but I have the feeling it does a lot more in software
/space/home/laforge/projects/git/carambola2/target/linux/ramips/files/drivers/usb/dwc_otgthan UHCI/OHCI/EHCI does. Looks lik there's FSMs running in ARM FIQ.

Not sure what -5 or -90 mean.

The -5 is

e1_line_demux_in(flow->line, buf + 4, size - 4, buf3 & 0xf);

where 'size' the parameter passed to e1_usb_xfer_in(), and as we subtract
4 from it it must be -1.

This all probably relates to

/* FIXME: Check transfer status ? Error handling ? */

in _e1uf_xfr()

Actions #7

Updated by laforge over 2 years ago

debugged this slightly further: The libusb_iso_packet_descriptor->status
field is LIBUSB_TRANSFER_ERROR in each of those "-5" cases.

Actions #8

Updated by laforge over 2 years ago

Interestingly not all ISO packets fail:

<0000> usb.c:346 (I0:L0) UNDERFLOW error count 20 (was 19)
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 2 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:204 (I0:L1) EP 84 ISO packet 0 failed with status ERROR
<0000> usb.c:159 (I0:L1) Feedback transfer error
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 3 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L1) EP 84 ISO packet 0 failed with status ERROR
<0000> usb.c:159 (I0:L1) Feedback transfer error
<0000> usb.c:204 (I0:L1) EP 84 ISO packet 0 failed with status ERROR
<0000> usb.c:159 (I0:L1) Feedback transfer error
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:346 (I0:L1) UNDERFLOW error count 21 (was 20)
<0000> usb.c:204 (I0:L1) EP 84 ISO packet 0 failed with status ERROR
<0000> usb.c:159 (I0:L1) Feedback transfer error
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 3 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 3 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 3 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 3 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:346 (I0:L0) UNDERFLOW error count 21 (was 20)
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 0 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 81 ISO packet 0 failed with status ERROR
<0000> usb.c:159 (I0:L0) Feedback transfer error
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 81 ISO packet 0 failed with status ERROR
<0000> usb.c:159 (I0:L0) Feedback transfer error
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 0 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 3 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:346 (I0:L1) UNDERFLOW error count 22 (was 21)
<0000> usb.c:204 (I0:L0) EP 81 ISO packet 0 failed with status ERROR
<0000> usb.c:159 (I0:L0) Feedback transfer error
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 3 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 81 ISO packet 0 failed with status ERROR
<0000> usb.c:159 (I0:L0) Feedback transfer error
<0000> usb.c:204 (I0:L0) EP 81 ISO packet 0 failed with status ERROR
<0000> usb.c:159 (I0:L0) Feedback transfer error
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 2 failed with status ERROR
<0001> mux_demux.c:394 (I0:L1) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 82 ISO packet 1 failed with status ERROR
<0001> mux_demux.c:394 (I0:L0) IN ERROR: -5
<0000> usb.c:204 (I0:L0) EP 81 ISO packet 0 failed with status ERROR
<0000> usb.c:159 (I0:L0) Feedback transfer error
<0000> usb.c:346 (I0:L0) UNDERFLOW error count 22 (was 21)
<0000> usb.c:204 (I0:L1) EP 85 ISO packet 1 failed with status ERROR

So it's not 0/1/2/3 consecutive failing in one EP, but rather only 1-2
packets per transfer.

Actions #9

Updated by tnt over 2 years ago

If you have a openvizla around to dump what's going on the bus really, see if at any point it manages to put all the packets in one frame from time to time.

Actions #10

Updated by laforge over 2 years ago

  • Status changed from New to Feedback
  • Assignee set to ahuemer

will put that on my todo list. Not entirely trvial as the rpi3 used for testing is not near a "normal" PC (for the openvizsla).

Actions #11

Updated by laforge over 2 years ago

  • Assignee changed from ahuemer to laforge
Actions #12

Updated by laforge over 2 years ago

18:30 < tnt> LaF0rge: I just found a bug in the dual if firmware that maybe confused or set the rpi 
             controller in a weird state ... the very first feedbackpacket that was sent was huge ... 292 
             bytes instead of 3 ... way larger than wMaxPacketSize.
18:36 < tnt> Pushed into tnt/fw-work

re-tested with icE1usb-fw-0.1-61-g5e3fbfe.bin from that updated branch, no change.

Actions #13

Updated by laforge over 1 year ago

  • Status changed from Feedback to Rejected

I think we'll hjave to live with the fact that rpi3b is yet another device that doesn't do two E1 lines over USB. It's not available for purchase these days anyway. The beaglebone black/green is available and supports both E1 lines, so we do have a small, low-cost and low-power USB host that works.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)