Hi,
Victor Dodon <printesoi@xxxxxxxxxxxx> writes:
> [ text/plain ]
> Hi Felipe,
>
> On Mon, Mar 7, 2016 at 11:13 PM, Felipe Balbi <balbi@xxxxxxxxxx> wrote:
>>
>> Hi,
>>
>> Victor Dodon <printesoi@xxxxxxxxxxxx> writes:
>>> [ text/plain ]
>>> Sorry, I accidentally pressed Send
>>>
>>> On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon <printesoi@xxxxxxxxxxxx> wrote:
>>>> Hi all,
>>>>
>>>> I have some performance issues with the host port on a Beaglebone
>>>> board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue
>>>> still persists. Running a fio test with 64k random reads from a USB
>>>> flash drive yields a maximum of 14402.01 KiB/s (115216.08 Kb/s). The
>>>> 3.14 and 4.1 kernels where build with CONFIG_TI_CPPI41_DMA=y. I was
>>>> able to get a much better performance on the client USB port by
>>>> enabling fifo double buffering. Iperf over a gigabit connection and a Ethernet
>>>> to USB adapter plugged in the host port gives a maximum of 180Mbit/s with fifo
>>>> double buffering enabled for the ep1 and ep2.
>>>>
>>>> Are there any known performance issues in the musb driver? For my use
>>>> case I need
>>>> a higher bandwidth and I would like to improve the host controller,
>>>> but I'm a beginner in Kernel hacking and I would appreciate some help,
>>>> tips or any cues to start.
>>>>
>>>> I also found a few problems with the host port. For example:
>>>> Using the setup described above (gigabit connection and a Ethernet
>>>> to USB adapter plugged in the host port and with a running iSCSI
>>>> initiator on the BB,
>>>> in usb/musb/musb_core.c if I change mode_4_cfg to enable double
>>>> buffering, and I restart the board while doing a dd from the disk
>>>> mounted with iSCSI, the kernel stops at:
>>>
>>> *if I enable double buffering for both RX and TX for only for ep 1
>>> then the kernel stops at:
>>>
>>> [ 233.930764] blk_update_request: I/O error, dev sda, sector 1620736
>>> [ 234.451076] musb-hdrc musb-hdrc.1.auto: remove, state 1
>>> [ 234.469702] usb usb1: USB disconnect, device number 1
>>> [ 234.492716] init: iscsid main process (466) killed by TERM signal
>>> [ 234.510663] usb 1-1: USB disconnect, device number 2
>>> [ 234.533235] usb 1-1.1: USB disconnect, device number 3
>>> [ 234.555153] usb 1-1.3: USB disconnect, device number 4
>>> [ 234.586962] musb-hdrc musb-hdrc.1.auto: USB bus 1 deregistered
>>> [ 234.606098] reboot: Restarting system
>>>
>>> if I enable double buffering for RX and TX for ep 1 and 2, only when
>>
>> you mean you're using FIFO_RXTX ? IIRC, that's only for Isochronous
>> endpoints.
>
> No, I use:
> static struct musb_fifo_cfg mode_4_cfg[] = {
> { .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, .mode = BUF_DOUBLE, },
> { .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, .mode = BUF_DOUBLE, },
> { .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 512, },
> { .hw_ep_num = 2, .style = FIFO_RX, .maxpacket = 512, },
> ...
>
> in the first case, and:
>
> static struct musb_fifo_cfg mode_4_cfg[] = {
> { .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, .mode = BUF_DOUBLE, },
> { .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, .mode = BUF_DOUBLE, },
> { .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 512, .mode = BUF_DOUBLE, },
> { .hw_ep_num = 2, .style = FIFO_RX, .maxpacket = 512, .mode = BUF_DOUBLE, },
>
> in the second, with a few changes in the last endpoint to fit in 16k.
oh okay. I have some vague memory of some weird FIFO access bugs on
MUSB. Maybe you're falling into one of them. Hopefully Bin has more info.
--
balbi
Attachment:
signature.asc
Description: PGP signature
