USB errors and kernel panics with USB modem

Hey, I’ve found some similar posts around but no solutions, I’m wondering if anyone knows how to fix this…

uname -a

Linux arm 3.8.13-bone64 #1 SMP PREEMPT Fri Aug 22 12:11:18 ADT 2014 armv7l GNU/Linux

I’ve got a cellular/GPS modem that gives me 4 ttyUSB devices, one for cell data, one for modem control and one for GPS data. Everything seems to be working except for the GPS. I can read data from /dev/ttyUSB1 (the GPS device), but when I am done reading and try to close the file, I get varying errors and occasionally a kernel panic. Using cat on /dev/ttyUSB1 generates the problem, but I’ve written a small C program to verify; the failure always happens when the program tries to call close().

It looks like an issue with the USB driver, or maybe I did something when I compiled the kernel (RT-PREEMPT maybe)?

Here is a section from dmesg:

[ 100.271254] WARNING: at drivers/usb/musb/musb_host.c:125 musb_h_tx_flush_fifo+0x5f/0x6c()
[ 100.271281] Could not flush host TX2 fifo: csr: 2003
[ 100.271303] Modules linked in: option usb_wwan usbserial omap_rng
[ 100.271425] [] (unwind_backtrace+0x1/0x98) from [] (warn_slowpath_common+0x33/0x48)
[ 100.271475] [] (warn_slowpath_common+0x33/0x48) from [] (warn_slowpath_fmt+0x1d/0x28)
[ 100.271522] [] (warn_slowpath_fmt+0x1d/0x28) from [] (musb_h_tx_flush_fifo+0x5f/0x6c)
[ 100.271571] [] (musb_h_tx_flush_fifo+0x5f/0x6c) from [] (musb_cleanup_urb+0x1b/0x5c)
[ 100.271617] [] (musb_cleanup_urb+0x1b/0x5c) from [] (musb_urb_dequeue+0x9d/0xc8)
[ 100.271674] [] (musb_urb_dequeue+0x9d/0xc8) from [] (unlink1+0x19/0xbc)
[ 100.271724] [] (unlink1+0x19/0xbc) from [] (usb_hcd_unlink_urb+0x31/0x7c)
[ 100.271770] [] (usb_hcd_unlink_urb+0x31/0x7c) from [] (usb_kill_urb+0x35/0x90)
[ 100.271841] [] (usb_kill_urb+0x35/0x90) from [] (usb_wwan_close+0x44/0x5c [usb_wwan])
[ 100.271932] [] (usb_wwan_close+0x44/0x5c [usb_wwan]) from [] (serial_down+0x1a/0x1c [usbserial])
[ 100.272012] [] (serial_down+0x1a/0x1c [usbserial]) from [] (tty_port_shutdown+0x3d/0x40)
[ 100.272070] [] (tty_port_shutdown+0x3d/0x40) from [] (tty_port_close+0x15/0x34)
[ 100.272135] [] (tty_port_close+0x15/0x34) from [] (serial_close+0x10/0x14 [usbserial])
[ 100.272201] [] (serial_close+0x10/0x14 [usbserial]) from [] (tty_release+0x9f/0x344)
[ 100.272261] [] (tty_release+0x9f/0x344) from [] (__fput+0x5b/0x15c)
[ 100.272320] [] (__fput+0x5b/0x15c) from [] (task_work_run+0x6d/0xa4)
[ 100.272384] [] (task_work_run+0x6d/0xa4) from [] (do_work_pending+0x6d/0x70)
[ 100.272434] [] (do_work_pending+0x6d/0x70) from [] (work_pending+0x9/0x1a)
[ 100.272463] —[ end trace 4c88d925e8d40d87 ]—

Here is more dmesg:
http://pastebin.com/dsFKuzha

And here is the output from a kernel panic:
http://pastebin.com/JPbVPpWB

Anyone have any ideas on how to prevent this?

Thanks,

Matt

Looks like it’s been quite a while, but were you able to find a solution to this issue?