Ethernet monopolizing LAN9514 upstream USB bus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Is there a way to stop the Ethernet controller from monopolizing the upstream USB channel, while in high usage, in detriment of other USB devices on LAN9514 (Raspberry Pi 2 USB-Hub/Ethernet chip)?

Basically, if you have a USB-attached storage device and start writing data that comes from the Ethernet into this USB disk, the Ethernet chip will always have priority on the USB bus and the kernel will never have the chance to use it to write on the storage device.

As a result, the data incoming from the Ethernet gets stored in the kernel IO buffer until memory runs out, and then the transfer stops for a while (as the kernel starting dropping TCP packets and the TCP flow control algorithm kicks in). On the other hand, if you stop the network transfer before the buffer is filled, the content on it is immediately flushed to disk.

This would not be a huge problem if the USB-attached storage devices didn't have a timeout: after not receiving some keepalive packets from the system it's attached to, it dies. With my USB disk, at least, you have to unplug its USB cable and plug it again to convince its controller that the system is back up.

Of course, this is a even bigger issue on Raspberry if the system's root is installed on this USB disk.

I'm not sure that this is fixed in the Raspberry Pi Foundation's remix of Debian, but I'm definitely hitting this bug on Fedora 25 beta with Linux 4.8.0-0.rc7.git0.1.fc25.armv7hl.

How to reproduce, considering /dev/sda is some USB-attached storage on the rasp2:
desktop$ dd if=some_big_file bs=8M | ssh root@rasp2 dd of=/dev/sda bs=8M

Meanwhile, you may watch the kernel buffer's filling up on the rasp2 with htop or free. You may also notice that if you cancel the SSH transfer before the rasp2 kernel buffer is filled (and also before your USB disk gives up waiting on the keepalive packet), the content stored on the buffer is almost immediately flushed to the disk.

How can we fix this?

--

Bernardo Donadio
DevOps Engineer at Alligo Tecnologia
https://bcdonadio.com/
_______________________________________________
arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux