Hi,
On Thu, May 7, 2015 at 4:07 PM, Chan-Taek Park <park.chantaek@xxxxxxxxx> wrote:
> On Thu, May 7, 2015 at 2:17 PM, Tim Nordell <tim.nordell@xxxxxxxxxxx> wrote:
>> Hi -
>>
>> On 05/07/15 11:16, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> On Thu, May 07, 2015 at 09:06:06AM -0700, Tony Lindgren wrote:
>>>>
>>>> * Tim Nordell <tim.nordell@xxxxxxxxxxx> [150506 16:19]:
>>>>>
>>>>> Hi all -
>>>>>
>>
>> *snip*
>>
>>>>>
>>>>> Something about this feels race conditiony too. Depending on the kernel
>>>>> configuration options in the kernel debug menu (which slows down other
>>>>> parts
>>>>> of the kernel), or if I enable verbose debug message output from the
>>>>> MUSB
>>>>> driver, it lasts much, much longer before keeling over as a system. You
>>>>> can
>>>>> restore normal behavior by unplugging/replugging in the device.
>>>>
>>>>
>>>> This sounds like some issue dealing with certain size transfers where
>>>> there's data remaining after a DMA transfer. You might be able to make
>>>> it easily reproducable with a variable size ping from your PC even with
>>>> debugging enabled. Something like the script below.
>>>>
>>>> Regards,
>>>>
>>>> Tony
>>>>
>>>> 8< --------------
>>>> #!/bin/bash
>>>>
>>>> device=$1
>>>> size=$2
>>>>
>>>> while [ 1 ]; do
>>>> #echo "Pinging with size $size"
>>>> if ! ping -w0 -c1 $device -s$size > /dev/null 2>&1; then
>>>> break;
>>>> fi
>>>> size=$(expr $SIZE + 1)
>>
>>
>> (This line should have referred to $size instead of $SIZE.)
>>
>>>>
>>>> if [ $size -gt 8192 ]; then
>>>> size=1
>>>> fi
>>>> done
>>>>
>>>> echo "Test ran up to $size"
>>>
>>>
>>> I'd be very much interested in getting such logs :-)
>>>
>>
>> Unfortunately, the driver works with the script above (after fixing the one
>> line) so it's not a "certain size" style scenario.
>>
>> Using iperf I can get traffic to stop flowing within a second of usage so
>> fortunately it's highly reproducible. One thing I tried this morning was to
>> simply "ignore" the fact the RXCSR register didn't have the expected bit and
>> continue in the driver. While the throughput was abysmal (and DMA "errors"
>> were reported), at least the driver didn't die. I could still ping after
>> stopping iperf. (I don't think this is the appropriate thing to do, but it
>> was just a quick and dirty test.)
>>
>> However, iperf does have the ability to adjust the packet size while still
>> spewing out a high-rate (configurable bandwidth) of packets. Armed with
>> this, I modified the ping test above to utilize iperf instead at various
>> packet sizes (granted, this would get fragmented above the MTU size by the
>> IP stack), leaving it at 1000 packets per second.
>>
>> Doing that as an exercise with the Ethernet dongle, it first keeled over at
>> 1059 byte UDP datagrams (1101 bytes on Ethernet - I don't know how many USB
>> transactions this split into exactly), at 1000 packets per second. However,
>> it doesn't consistently keel over at the same bytes per datagram. Another
>> attempt keeled over at 1052 byte UDP datagrams.
>>
>> Upping the ante to 1500 packets per second, and jumping at 16-byte intervals
>> for the size, it lasted from 1000 to 1352 byte size packets and keeled over
>> at 1368 byte sized packets.
>>
>> Some of the configurations of iperf against MUSB in DMA mode causes the ASIX
>> driver (the Ethernet dongle driver) to complain too, even to the point of
>> doing a NULL dereference (I will dig into this dereference). Not seen with
>> the MUSB in PIO mode.
>>
>> Note: Same system/kernel, configured as an Ethernet gadget does not exhibit
>> the issues, although, I'm not convinced it's actually using DMA for this.
>> INTC 93 does not have any activity as a gadget (INTC 92 gets all the
>> traffic). I can improve the performance (~35% improvement) in PIO mode of
>> an Ethernet gadget by configuring the dynamic FIFO in the MUSB to utilize
>> double buffering, but DMA mode still falls over with a USB ethernet dongle
>> attached with double buffering. I haven't tried the series of iperf
>> bandwidth tests against double buffering yet. I also have the idle loops in
>> the system disabled to improve interrupt latency ("nohlt cpuidle.off=1").
>>
>> - Tim
>>
>
> I'm sorry if you are already aware of this information.
> Just wanted to share my experience.
>
> AFAIK, there is a hardware bug with MUSB Host controller.
> See ARM_MPU.KERNEL.39 at
> http://processors.wiki.ti.com/index.php/Sitara_SDK_6.00.00_Release_Notes
> I assume it is common across AM335x and DM3730.
No, it is not.
>
> TI has this pre-mature TX complete interrupt issue on host controller side.
The AM335x bug does not apply to DM3730, because both use different
DMA controller.
Regards,
-Bin.
> Freescale has a similar pre-mature TX interrupt issue on device controller side.
>
> It looks like TI has a patch to work around that issue.
> https://gitorious.org/opensuse/kernel/commit/a655f481d83d6d37bec0a2ddfdd24c30ff8f541f
>
> Maybe, in your case would it be due to the 25us wait loop which is too
> short (I guess)?
>
> To me TI's approach looks complicated.
>
> Freescale's approach looks a lot simpler.
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/drivers/usb/gadget/arcotg_udc.c?h=imx_2.6.28&id=f34bd00b7b0295e723158db1f55f28416026ad94
>
>
> -chan
> --
> 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
--
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
