usb driver crashes on DVSDK 2, DM365

1. What all usb devices have you connected to USB port? Please provide the output of $cat /proc/bus/usb/devices , you would need to enable CONFIG_USB_DEVICEFS.

2. Looks like your FIFO table is not properly configured. Please provide the FIFO table used in drivers/usb/musb/musb_core.c file "mode_2_cfg"

Regards,
Ajay

1. I tried several different DOKs.

This is the output of $cat /proc/bus/usb/devices before I run the decode demo:

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 1
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.18_pro500-davinci_evm-arm_v5t_le dummy_hcd
S:  Product=Dummy host controller
S:  SerialNumber=dummy_hcd
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs=  2
P:  Vendor=0525 ProdID=a4a2 Rev= 2.02
S:  Manufacturer=Linux 2.6.18_pro500-davinci_evm-arm_v5t_le/dummy_
S:  Product=RNDIS/Ethernet Gadget
C:  #Ifs= 2 Cfg#= 2 Atr=c0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=
E:  Ad=83(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
C:  #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=
E:  Ad=83(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 1
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.18_pro500-davinci_evm-arm_v5t_le musb-hcd
S:  Product=MUSB HDRC host driver
S:  SerialNumber=musb_hdrc
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0781 ProdID=5151 Rev= 0.10
S:  Manufacturer=SanDisk Corporation
S:  Product=Cruzer Micro
S:  SerialNumber=20060876621DFB603E50
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=200mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

After the crash the last "paragraph" is gone, of course.

2.

/* mode 2 - fits in 4KB */
static struct fifo_cfg __initdata mode_2_cfg[] = {
{ .hw_ep_num = 1, .style = FIFO_TX,   .maxpacket = 512, },
{ .hw_ep_num = 1, .style = FIFO_RX,   .maxpacket = 512, },
{ .hw_ep_num = 2, .style = FIFO_TX,   .maxpacket = 512, },
{ .hw_ep_num = 2, .style = FIFO_RX,   .maxpacket = 512, },
{ .hw_ep_num = 3, .style = FIFO_TX,   .maxpacket = 512, },
{ .hw_ep_num = 3, .style = FIFO_RX,   .maxpacket = 512, },
{ .hw_ep_num = 4, .style = FIFO_RXTX, .maxpacket = 256, },
};

Thanks.

The last two paragraph of outout of /proc/bus/usb/devices shows one Sandisk stick connected to musb port directly. for this configuration the FIFO table is correct and sufficient.

Have you enabled dummy hcd somehow for which we have first two paragraph? I think they would have just got enabled in defconfig by mistake. Anyways they should not affect musb and sandisk host operations but would suggest you to disable dummy hcd.

Do you have any other stick or USB HDD to repeat the test? Sometime we have observed some stick not behaving properly. Another possibility could be that usb bus is not getting bus priority while decoding is in progress and thus the "reset" messages. Do you see the issue without decoding in parallel?

Regards,

Ajay

I checked with a different stick, and also with two other USB HDDs and I got the same results.

I also checked with a different board and got the same results.

I tried to just read from the files or copy them with different buffer sizes and there was no problem.

I also tried to run the decoder on a file from NFS (which normally works) but I made changes to the code so whenever it reads from the file, it also reads from a copy of the file that is on the usb device (and does nothing with the data from the usb device), and the issue did occure. In this test, there was a decoding in parallel - but only of the file from NFS.

This error can happen if USB is given low priority at master interconnect than EDMA. So, USB requests are not serviced when Decoder is trying to do continuous large EDMA transfers and blocking the accesses by USB for long time. 

You can get it fixed by changing the priority of USB when kernel starts up by editing the following file and recompiling kernel:

ti-davinci\arch\arm\mach-davinci\board-dm365-evm.c At Line #504 add below two lines of code:

        val = 0x0;

        davinci_writel(val, 0x1c40040); //master priority1 register1 - to set USB

More details on Master Priorities Register 1 are in http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdf

I tried it and the issue remains.

I'm not sure if I added the command you gave me in the right place though.

This is what I got surrounding line #504 (with the added command):

static void __init davinci_map_io(void)
{
        davinci_irq_priorities = dm365_default_priorities;
        davinci_map_common_io();

        davinci_writel(0x0, 0x1c40040); //master priority1 register1 - to set USB

        davinci_init_common_hw();

#ifdef CONFIG_KGDB_8250
        kgdb8250_add_platform_port(CONFIG_KGDB_PORT_NUM,
                                 &serial_platform_data[CONFIG_KGDB_PORT_NUM]);
#endif
}

Thanks.

As far as I can tell right now, it works.

Thanks!

I'll post again if the issue will make a come back.

I have the problem looking similar, but this patch did not help me.

My application starts recording and also opens watchdog(!).

Today, for testing, on purpose I stop WD treatment after 2 minutes of recording. This leads to WD strike, the system restarts, but very often (not always) after such a reset it comes up with the same message "no URB for end 0"  & "usb1-1: device descriptor read/64, error -110". This leads to the WD kicking the system out again. And again the same USB issue. To stop the loop, I need to switch power-off. Then the next power-up process ends normal and no USB errors are detected till the next "artificial" WD reset.

If I take out the DOK and check it outside - neither M$W nor Linux see any problem in it.

Many thanks for any possible help.