ttyUSB infinitely URB_BULK in

[nikropenko]

I experience problems with usb modems

please read this thread https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=163184

i decided to trace usb data with wireshark

please look at pcap file

when i open ttyUSB serial port there is plenty of "URB_BULK in" messages infinitely go to wireshark

[P33M]

Duplicate of raspberrypi/firmware#582

Opening so many devices at once is never going to work due to the way the hardware works.

To confirm, can you open one less than the number of devices that makes the system unresponsive, then run the commands in the linked issue?

[nikropenko]

Done.

//usb_test.c
//compile: gcc usb_test.c -o usb_test

#include <fcntl.h>          /* O_RDWR  */
#include <stdio.h>
#include <unistd.h> 
#include <string.h>


void read_reg() {

    int i;

    for (i = 0; i < 5; i++) {
        system("cat /sys/devices/platform/soc/3f980000.usb/regvalue");
        sleep(1);
    }
}


void open_port(char * portname) {

    int fd;

    printf("opening [%s] ", portname);
    sleep(5);
    fd = open(portname, O_RDWR);
    if(fd == -1) {
        printf("failed \n");
        return;
    }
    printf("ok \n");

    read_reg();
}

int main() {
    system("echo 0x418  > /sys/devices/platform/soc/3f980000.usb/regoffset");

    printf("idle \n");
    read_reg();

    printf("1st usb modem \n");
    open_port("/dev/ttyUSB0");
    open_port("/dev/ttyUSB1");
    open_port("/dev/ttyUSB2");

    printf("2nd usb modem \n");
    open_port("/dev/ttyUSB3");
    open_port("/dev/ttyUSB4");
    open_port("/dev/ttyUSB5");

    printf("3rd usb modem \n");
    open_port("/dev/ttyUSB6");
    open_port("/dev/ttyUSB7");
    open_port("/dev/ttyUSB8");

}

sudo ./usb_test

out:
idle
Reg@0x000418 = 0x00000000
Reg@0x000418 = 0x00000000
Reg@0x000418 = 0x00000000
Reg@0x000418 = 0x00000000
Reg@0x000418 = 0x00000000
1st usb modem
opening [/dev/ttyUSB0] ok
Reg@0x000418 = 0x00000010
Reg@0x000418 = 0x00000010
Reg@0x000418 = 0x00000010
Reg@0x000418 = 0x00000010
Reg@0x000418 = 0x00000010
opening [/dev/ttyUSB1] ok
Reg@0x000418 = 0x00000050
Reg@0x000418 = 0x00000050
Reg@0x000418 = 0x00000050
Reg@0x000418 = 0x00000050
Reg@0x000418 = 0x00000070
opening [/dev/ttyUSB2] ok
Reg@0x000418 = 0x00000058
Reg@0x000418 = 0x00000058
Reg@0x000418 = 0x00000058
Reg@0x000418 = 0x00000051
Reg@0x000418 = 0x00000051
2nd usb modem
opening [/dev/ttyUSB3] ok
Reg@0x000418 = 0x000000d1
Reg@0x000418 = 0x000000d1
Reg@0x000418 = 0x000000f0
Reg@0x000418 = 0x000000f0
Reg@0x000418 = 0x000000f0
opening [/dev/ttyUSB4] ok
Reg@0x000418 = 0x000000f8
Reg@0x000418 = 0x000000f8
Reg@0x000418 = 0x000000f8
Reg@0x000418 = 0x000000f8
Reg@0x000418 = 0x000000f8
opening [/dev/ttyUSB5] ok
Reg@0x000418 = 0x000000fb
Reg@0x000418 = 0x000000f9
Reg@0x000418 = 0x000000f9
Reg@0x000418 = 0x000000f9
Reg@0x000418 = 0x000000f9
3rd usb modem
opening [/dev/ttyUSB6] ok
Reg@0x000418 = 0x000000fb
Reg@0x000418 = 0x000000fb
Reg@0x000418 = 0x000000fb
Reg@0x000418 = 0x000000fb
Reg@0x000418 = 0x000000fb
opening [/dev/ttyUSB7] ok
Reg@0x000418 = 0x000000ff
Reg@0x000418 = 0x000000ff
Reg@0x000418 = 0x000000ff
Reg@0x000418 = 0x000000ff
Reg@0x000418 = 0x000000ff
opening [/dev/ttyUSB8] ok
Reg@0x000418 = 0x000000ff
Reg@0x000418 = 0x000000ff
Reg@0x000418 = 0x000000ff
Reg@0x000418 = 0x000000ff
Reg@0x000418 = 0x000000ff

it is sad i exactly reached the maximum of the host channels. Thank you for your explanations.
Why opening serial port consume so many host channels? I did not read or write anything to that ports. May be setting lower baudrate(say 9600) will increase free host channels? Or there is no way to improve this limitation?

[nikropenko]

pcap from RPI
usb_modems_dump_usb_rpi_split1000.pcapng.zip

pcap from PC
usb_modems_dump_usb_pc.pcapng.zip

On RPI "URB_BULK in" messages never stop after i run usb_test.

[P33M]

It's odd that the system becomes completely unresponsive. Endpoints are serviced first-come-first-served in the case where all host channels are busy, so you should get degraded performance not inoperable performance.

I'll look at your logs tomorrow.

[P33M]

The majority of your devices have high speed bulk endpoints. Submitting a transfer to a HS bulk endpoint will tie up a host channel until the bulk endpoint returns enough data to finish the transfer, or a short packet. This could be seconds in the case of a cellular modem waiting for network.

There should be a rudimentary QoS mechanism in that permits no more than 7 host channels to be used for bulk data - so your keyboard (an interrupt endpoint) should still work. I will have a look to see why it doesn't.

[nikropenko]

Thank you very much! I will try to debug drivers/usb/serial/option.c, drivers/usb/serial/usb_wwan.c to understand how it is working under the hood of linux kernel.

[JamesH65]

@P33M Was there any progress on this?

[P33M]

Even though we limit the maximum number of channels used for non-periodic endpoints to num_channels - 1, this doesn't stop the case where of the available host channels, all rotate through and end up being used to poll endpoints that never return data.

Forcibly stopping a host channel to re-use it is likely to drop data on the floor, so this is a hardware limitation that's not going to be worked around in software.