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.
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
the problem does not occur with the single-line (=single-usb-interfac) firmware.
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
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.
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?
:/
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.
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()
debugged this slightly further: The libusb_iso_packet_descriptor->status
field is LIBUSB_TRANSFER_ERROR in each of those "-5" cases.
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.
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.
- 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).
- Assignee changed from ahuemer to laforge
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.
- 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.
Also available in: Atom
PDF
