Hi,
On Tue, Mar 08, 2016 at 10:57:41AM +0200, Felipe Balbi wrote:
>
> 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.
am335x hasn't been validated with double buffering, at least in last few
years, and I am not sure any other musb devices use double buffering
too, but the musb driver has great refactoring in last few years
though, so there is no surprise if double buffering is broken in musb
driver.
But I tried double buffering on am335x recently with kernel v4.1.x .
With my limited test I didn't see any problem. On host port, I tried W/R
to/from a MSC device; while on device port, I tried g_zero and
g_mess_storage. I didn't try ethernet gongle though.
Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
