OpenWrt Forum Archive

Topic: dwc_otg usb driver

The content of this topic has been archived on 17 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Post #1
aniello.human
8 Apr 2013, 20:25

Hi,

I'm using a sierra modem with the sierra_directip driver (sierra_net).  Once I've brought the data connection (/dev/ttyUSB4) the control channel (/dev/ttyUSB3) basically stops working.  It becomes slow and AT commands seem to timeout.  I've tried this hardware on the Ralink SoC SDK which is kernel 2.6.21 and the same issue happens.  On my Linux PC at home I'm using the same driver and there is no issue.

The only common denominator seems to be the dwc_otg driver.  From googling it seems this usb driver services the usb bus through interrupt polling (you can see /proc/interrupts climb really fast when the data connection is up).  It also seems like the same driver the guys are using for Rasberry PI and they've done a lot of work to get this driver more stable.

It also seems like the driver shipped with OpenWRT is really old compared to what's being used on the Rasberry Pi kernel tree.

I'm not sure I could manage a port myself but am willing to test as I have neccessary hardware hardware.

Basically what I'm after is if anyone else has run into trouble with dwc_otg driver and whether OpenWRT wouldn't benefit by pulling the changes that the Rasberry Pi guys have done into the OpenWRT kernel branch.  Not sure where to go (IRC?) or get a developer that would be interested in helping me debug this problem.

Thanks

Post #2
aniello.human
19 Apr 2013, 13:24

I'm posting a solution to this problem in case some other poor unfortunate soul runs into the same issue:

You need these 2 patches: http://trac.fonosfera.org/fon-ng/ticket/857

(In [2293]) ra_usb: Fix lockup on 2.0n due to IRQ overload on USB bulk NAKs.
(In [2295]) ra_usb: Prevent queue starvation due to limited number of host channels.

" The USB controller hardware only has four "host controllers", used to communicate with USB devices. When communication with a device blocks (e.g. a 3G stick that does not have any data to send yet), it could happen that no free host channels are available for other USB transfers, causing these to time out (most often shown as "application timed out on ep0in" in the kernel log).

This problem surfaced in particular when using a 3G modem using an USB hub, since the hub and the 3G modem typically need one host channel each for their interrupt endpoint and the 3G modem typically has a control and data port, each of which uses blocking bulk transfers, filling up the four available host channels. "

Specifically the second one.  The same problem persists even on the latest trunk of OpenWRT.  I could not apply these 2 patches to the dwg_otc driver on the OpenWRT trunk because it seems they are using a different/patched version of the dwg_otc sources and didn't have the motivation to resolve the failed hunks in the patches yet (although not too difficult it seems).

My 3G modem also has a GPS and ran into the above constraint. I went back to the Ralink SDK sources and patched the dwg_otc drivers that are compilied into their 2.6.21 tree and it works fine now.

Post #3
mvhaen
2 May 2013, 09:44

Has anyone else had any experiences with this problem or worked on patching more recent kernels than 2.6.21? I think I have a related problem here where an interrupt most likely coming from the sierra 3G card since it is the only device connected results in a kernel panic.

Before the kernel panic occurs in some cases the ttyUSB devices seem to go unresponsive, gcom failing etc. Which is why I think this might be related.

I'm going to try porting the patches to the kernel version I'm currently on (2.6.39.4) and see if this resolves the problem, any feedback is more than welcome.

root@OpenWrt:/# Unable to handle kernel NULL pointer dereference at virtual address 00000032
pgd = 80004000
[00000032] *pgd=00000000
Internal error: Oops: 17 [#1]
last sysfs file: /sys/kernel/uevent_seqnum
Modules linked in: dummy mbt_netlink mbt sierra ftdi_sio gpio_buttons uhci_hcd ebt_snat ebt_dnat ebt_arpreply ebt_ip ]
CPU: 0    Not tainted  (2.6.39.4 #1)
PC is at handle_hc_xacterr_intr+0x1c/0x168
LR is at dwc_otg_hcd_handle_hc_n_intr+0x1ec/0x69c
pc : [<801b4650>]    lr : [<801b4d30>]    psr: 60000193
sp : 8036bdc0  ip : 00000002  fp : 8036bde4
r10: 00000000  r9 : 890005c0  r8 : 0000003f
r7 : 87a3e8d4  r6 : 00000002  r5 : 87a3e8d4  r4 : 86ebb488
r3 : 86ebb488  r2 : 890005c0  r1 : 87a33960  r0 : 87a3e8d4
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 00c5787d  Table: 26e1c008  DAC: 00000015
Process swapper (pid: 0, stack limit = 0x8036a268)
Stack: (0x8036bdc0 to 0x8036c000)
bdc0: 00000000 8036be30 00000000 87a3e8d4 00000002 87a33960 8036be34 8036bde8
bde0: 801b4d30 801b4640 00000001 8036bdec 00000002 86ebb488 ffde47e0 ffde47e0
be00: 871421c0 00000002 8036be94 00000006 00000040 00000000 87a3e8d4 0000003f
be20: 8038ea14 80376eb8 8036be54 8036be38 801b5224 801b4b50 00000000 87a3e8d4
be40: 00000002 02000000 8036be74 8036be58 801b556c 801b51ec 87a3e8d4 00000001
be60: 87a3e800 00000000 8036be94 8036be78 801b2d5c 801b54b8 87a3e800 00000001
be80: a0000193 00000000 8036beb4 8036be98 801bb5b8 801b2d4c 87a336e0 00000000
bea0: 00000000 00000000 8036beec 8036beb8 8006ad04 801bb58c 0000001c 00000000
bec0: 00000006 80376eb8 8037b290 00000000 8036c000 20000000 410fb024 2002169c
bee0: 8036bf04 8036bef0 8006ae8c 8006acd8 80376eb8 8037b290 8036bf1c 8036bf08
bf00: 8006cf50 8006ae68 0000003f 8037b290 8036bf3c 8036bf20 8002807c 8006ce9c
bf20: ffffffff ff000100 0000003f 8036c000 8036bf94 8036bf40 8002dad8 8002800c
bf40: 803736d0 00000000 00000000 8036a000 8036a000 80387e44 803712c4 8036c000
bf60: 20000000 410fb024 2002169c 8036bf94 8036bf98 8036bf88 8002e8a4 8002e8a8
bf80: 60000013 ffffffff 8036bfb4 8036bf98 8002ee4c 8002e888 8036c0e8 80387e1c
bfa0: 80022138 8036c000 8036bfc4 8036bfb8 802a25b4 8002ee10 8036bff4 8036bfc8
bfc0: 80008994 802a2560 800084b8 00000000 00000000 80022f54 00c5387d 8036c040
bfe0: 80022f50 803712bc 00000000 8036bff8 20008038 80008740 00000000 00000000
Backtrace: 
[<801b4634>] (handle_hc_xacterr_intr+0x0/0x168) from [<801b4d30>] (dwc_otg_hcd_handle_hc_n_intr+0x1ec/0x69c)
 r7:87a33960 r6:00000002 r5:87a3e8d4 r4:00000000
[<801b4b44>] (dwc_otg_hcd_handle_hc_n_intr+0x0/0x69c) from [<801b5224>] (dwc_otg_hcd_handle_hc_intr+0x44/0x6c)
[<801b51e0>] (dwc_otg_hcd_handle_hc_intr+0x0/0x6c) from [<801b556c>] (dwc_otg_hcd_handle_intr+0xc0/0xe8)
 r7:02000000 r6:00000002 r5:87a3e8d4 r4:00000000
[<801b54ac>] (dwc_otg_hcd_handle_intr+0x0/0xe8) from [<801b2d5c>] (dwc_otg_hcd_irq+0x1c/0x40)
 r7:00000000 r6:87a3e800 r5:00000001 r4:87a3e8d4
[<801b2d40>] (dwc_otg_hcd_irq+0x0/0x40) from [<801bb5b8>] (usb_hcd_irq+0x38/0xa0)
 r7:00000000 r6:a0000193 r5:00000001 r4:87a3e800
[<801bb580>] (usb_hcd_irq+0x0/0xa0) from [<8006ad04>] (handle_irq_event_percpu+0x38/0x190)
 r7:00000000 r6:00000000 r5:00000000 r4:87a336e0
[<8006accc>] (handle_irq_event_percpu+0x0/0x190) from [<8006ae8c>] (handle_irq_event+0x30/0x40)
[<8006ae5c>] (handle_irq_event+0x0/0x40) from [<8006cf50>] (handle_level_irq+0xc0/0xe8)
 r5:8037b290 r4:80376eb8
[<8006ce90>] (handle_level_irq+0x0/0xe8) from [<8002807c>] (asm_do_IRQ+0x7c/0x9c)
 r5:8037b290 r4:0000003f
[<80028000>] (asm_do_IRQ+0x0/0x9c) from [<8002dad8>] (__irq_svc+0x38/0x80)
Exception stack(0x8036bf40 to 0x8036bf88)
bf40: 803736d0 00000000 00000000 8036a000 8036a000 80387e44 803712c4 8036c000
bf60: 20000000 410fb024 2002169c 8036bf94 8036bf98 8036bf88 8002e8a4 8002e8a8
bf80: 60000013 ffffffff
 r7:8036c000 r6:0000003f r5:ff000100 r4:ffffffff
[<8002e87c>] (default_idle+0x0/0x30) from [<8002ee4c>] (cpu_idle+0x48/0x84)
[<8002ee04>] (cpu_idle+0x0/0x84) from [<802a25b4>] (rest_init+0x60/0x78)
 r7:8036c000 r6:80022138 r5:80387e1c r4:8036c0e8
[<802a2554>] (rest_init+0x0/0x78) from [<80008994>] (start_kernel+0x260/0x2b4)
[<80008734>] (start_kernel+0x0/0x2b4) from [<20008038>] (0x20008038)
Code: e24dd008 e593c01c e1a04003 e1a07000 (e59c3030) 
---[ end trace d5551ca069dfcfb6 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Backtrace: 
[<80030cc4>] (dump_backtrace+0x0/0x108) from [<802aa660>] (dump_stack+0x18/0x1c)
 r7:801b4650 r6:8036a000 r5:00000000 r4:00000000
[<802aa648>] (dump_stack+0x0/0x1c) from [<802aa6c4>] (panic+0x60/0x178)
[<802aa664>] (panic+0x0/0x178) from [<80030fe0>] (die+0x214/0x298)
 r3:00010000 r2:8038c778 r1:00000000 r0:8031d770
[<80030dcc>] (die+0x0/0x298) from [<80032ff8>] (__do_kernel_fault+0x6c/0x8c)
[<80032f8c>] (__do_kernel_fault+0x0/0x8c) from [<800331f4>] (do_page_fault+0x1dc/0x204)
 r9:00000017 r8:8036bd78 r7:80370330 r6:00000032 r5:00000000
r4:803717e8
[<80033018>] (do_page_fault+0x0/0x204) from [<8002829c>] (do_DataAbort+0x3c/0x9c)
[<80028260>] (do_DataAbort+0x0/0x9c) from [<8002da8c>] (__dabt_svc+0x4c/0x60)
Exception stack(0x8036bd78 to 0x8036bdc0)
bd60:                                                       87a3e8d4 87a33960
bd80: 890005c0 86ebb488 86ebb488 87a3e8d4 00000002 87a3e8d4 0000003f 890005c0
bda0: 00000000 8036bde4 00000002 8036bdc0 801b4d30 801b4650 60000193 ffffffff
[<801b4634>] (handle_hc_xacterr_intr+0x0/0x168) from [<801b4d30>] (dwc_otg_hcd_handle_hc_n_intr+0x1ec/0x69c)
 r7:87a33960 r6:00000002 r5:87a3e8d4 r4:00000000
[<801b4b44>] (dwc_otg_hcd_handle_hc_n_intr+0x0/0x69c) from [<801b5224>] (dwc_otg_hcd_handle_hc_intr+0x44/0x6c)
[<801b51e0>] (dwc_otg_hcd_handle_hc_intr+0x0/0x6c) from [<801b556c>] (dwc_otg_hcd_handle_intr+0xc0/0xe8)
 r7:02000000 r6:00000002 r5:87a3e8d4 r4:00000000
[<801b54ac>] (dwc_otg_hcd_handle_intr+0x0/0xe8) from [<801b2d5c>] (dwc_otg_hcd_irq+0x1c/0x40)
 r7:00000000 r6:87a3e800 r5:00000001 r4:87a3e8d4
[<801b2d40>] (dwc_otg_hcd_irq+0x0/0x40) from [<801bb5b8>] (usb_hcd_irq+0x38/0xa0)
 r7:00000000 r6:a0000193 r5:00000001 r4:87a3e800
[<801bb580>] (usb_hcd_irq+0x0/0xa0) from [<8006ad04>] (handle_irq_event_percpu+0x38/0x190)
 r7:00000000 r6:00000000 r5:00000000 r4:87a336e0
[<8006accc>] (handle_irq_event_percpu+0x0/0x190) from [<8006ae8c>] (handle_irq_event+0x30/0x40)
[<8006ae5c>] (handle_irq_event+0x0/0x40) from [<8006cf50>] (handle_level_irq+0xc0/0xe8)
 r5:8037b290 r4:80376eb8
[<8006ce90>] (handle_level_irq+0x0/0xe8) from [<8002807c>] (asm_do_IRQ+0x7c/0x9c)
 r5:8037b290 r4:0000003f
[<80028000>] (asm_do_IRQ+0x0/0x9c) from [<8002dad8>] (__irq_svc+0x38/0x80)
Exception stack(0x8036bf40 to 0x8036bf88)
bf40: 803736d0 00000000 00000000 8036a000 8036a000 80387e44 803712c4 8036c000
bf60: 20000000 410fb024 2002169c 8036bf94 8036bf98 8036bf88 8002e8a4 8002e8a8
bf80: 60000013 ffffffff
 r7:8036c000 r6:0000003f r5:ff000100 r4:ffffffff
[<8002e87c>] (default_idle+0x0/0x30) from [<8002ee4c>] (cpu_idle+0x48/0x84)
[<8002ee04>] (cpu_idle+0x0/0x84) from [<802a25b4>] (rest_init+0x60/0x78)
 r7:8036c000 r6:80022138 r5:80387e1c r4:8036c0e8
[<802a2554>] (rest_init+0x0/0x78) from [<80008994>] (start_kernel+0x260/0x2b4)
[<80008734>] (start_kernel+0x0/0x2b4) from [<20008038>] (0x20008038)
Rebooting in 3 seconds..
Post #4
lsoltero
6 Jul 2013, 22:09

hello all,

I believe I have run into an issue which might be related to this problem.  Using BB r36813 on an alfa R36 based on a RT3050 SoC using ralink dtw_otg driver I have a situation where the 3G modem works fine when plugged into the USB port of the router.  When connected to a full speed hub  (usb 1.1) the 3G modem works fine.  However, when the USB modem is plugged into a USB high speed hub (USB 2.0) the router silently reboots after about 10 seconds and no visible data is transferred to the modem.

here is what is enabled in .config

CONFIG_DEFAULT_kmod-usb-core=y
CONFIG_PACKAGE_kmod-ledtrig-usbdev=y
CONFIG_PACKAGE_kmod-usb-acm=y
CONFIG_PACKAGE_kmod-usb-core=y
CONFIG_PACKAGE_kmod-usb-rt305x-dwc_otg=y
CONFIG_PACKAGE_kmod-usb-serial=y
CONFIG_PACKAGE_kmod-usb-serial-ftdi=y
CONFIG_PACKAGE_kmod-usb-serial-pl2303=y
CONFIG_PACKAGE_kmod-usb2=y


here is what is reported when the USB 2.0 hub is plugged into the USB port.
[12329.840000] usb 1-1: new high-speed USB device number 8 using dwc_otg
[12330.040000] hub 1-1:1.0: USB hub found
[12330.050000] hub 1-1:1.0: 4 ports detected

I tried applying the fonera patches but the code is sufficiently different between the openwrt main and fonera branches to make this impossible for a me.  I think someone with a little better understanding on the workings of this driver will need to do this. 

anyway... looking for suggestions...

Thanks,

--luis

Post #5
sanyok
13 Jan 2014, 23:39

I had same problem with unbranded xdx-rn502j on ralink RT3052, bought there: http://dx.com/p/sl-r720-dd-wrt-802-11b- … 052-104507 with a cheap non-powered usb 2.0 hub, bought also here: http://dx.com/p/mini-rectangle-shape-us … mbps-45773

When I tried to connect through the hub devices that provide serial ports: Arduino Duemilanove and 1-wire master USB9097, system just hanged after trying to read something from /dev/ttyUSB0, without serving wi-fi, and resume working only after unplugging device.

I applied Fonera patches to my attitude_adjustment (kernel: 3.3.8) and after that it started working fine.
It was patched almost cleanly, but I'm posting patch files and compiled module for rt305x in order for people without corresponding experience and/or openwrt build environment be able to utilize it.
https://dl.dropboxusercontent.com/u/550 … atched.zip

(Last edited by sanyok on 13 Jan 2014, 23:53)

Post #6
matthias87
29 Jan 2014, 20:35

I am having issues with dwc_otg driver on WBMR-HP-G300H (Lantiq-AR9, AA 12.09). Devices connected to USB just disappear while accessing them (e.g. writing to pen drive).

I wanted to give your patches a try using the AA SDK for cross-compiling. Are these patches for the version included in the AA sources?

EDIT: I set up AA buildroot and tried to apply the patches.

(Last edited by matthias87 on 30 Jan 2014, 08:33)

Post #7
matthias87
30 Jan 2014, 08:32

I tried to apply your patches and they seem not to fit my source files:

Applying patch platform/103-USB-nak-holdoff.patch
patching file drivers/usb/dwc_otg/dwc_otg_hcd.c
Hunk #1 succeeded at 2208 with fuzz 2 (offset -45 lines).
Hunk #2 FAILED at 2290.
Hunk #3 succeeded at 2814 (offset 17 lines).
1 out of 3 hunks FAILED -- rejects in file drivers/usb/dwc_otg/dwc_otg_hcd.c
patching file drivers/usb/dwc_otg/dwc_otg_hcd.h
Hunk #1 succeeded at 200 (offset 2 lines).
patching file drivers/usb/dwc_otg/dwc_otg_hcd_intr.c
Hunk #1 succeeded at 1141 with fuzz 1 (offset -9 lines).
patching file drivers/usb/dwc_otg/dwc_otg_hcd_queue.c
Hunk #1 FAILED at 204.
1 out of 1 hunk FAILED -- rejects in file drivers/usb/dwc_otg/dwc_otg_hcd_queue.c
Patch platform/103-USB-nak-holdoff.patch does not apply (enforce with -f)

Can you please give me a hint? Which source code revision did you use?

Post #8
sanyok
30 Jan 2014, 10:33

I'm not sure now it's original AA, since last checkin is 2013-12-21,

$ svn info
Path: .
URL: svn://svn.openwrt.org/openwrt/branches/attitude_adjustment
Repository Root: svn://svn.openwrt.org/openwrt
Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73
Revision: 39203
Node Kind: directory
Schedule: normal
Last Changed Author: jow
Last Changed Rev: 39154
Last Changed Date: 2013-12-21 15:55:57 +0200 (Sat, 21 Dec 2013)

maybe also following will help you, https://dl.dropboxusercontent.com/u/550 … atches.zip
these are files itself

Post #9
matthias87
30 Jan 2014, 11:02

thank you a lot!!

The discussion might have continued from here.