Could not flush host TX2 fifo

[srp...@gmail.com]

Hi all,

I'm having difficulty with my Beaglebone Black while trying to control a HackRF. The issue only ever comes up if I try to transmit something, which makes sense since it seems to be trying to flush the TX buffer.

The device is connected to a powered USB hub, and works just fine from my desktop and laptop. I don't have another embedded device that I can try it on. 

I've seen some other posts about the same error, but I haven't found anything helpful or explanatory. Here's a post someone else made with the same issue, using a BladeRF. I've seen it pop up for other devices too, but I'm not getting anywhere close to finding a solution. 

Below is what dmesg is printing. It happens consistently any time that I try to transmit, and the entire bus seems to be dead once it happens (my WiFi dongle stops working too until I reboot). Does anyone have any insight or suggestions? This is a complete show-stopper for my project, in which I'd be using the HackRF to do some transmitting.

 

[  150.763241] ------------[ cut here ]------------

[  150.767932] WARNING: CPU: 0 PID: 574 at drivers/usb/musb/musb_host.c:128 musb_h_tx_flush_fifo+0x104/0x130()

[  150.777711] Could not flush host TX2 fifo: csr: 0103

[  150.782693] Modules linked in: ccm arc4 rtl8192cu rtl_usb rtl8192c_common rtlwifi mac80211 cfg80211 omap_aes omap_sham omap_rng rng_core tilcdc tda998x drm_kms_helper uio_pdrv_genirq uio sch_fq_codel ip_tables x_tables

[  150.802288] CPU: 0 PID: 574 Comm: fan.py Not tainted 4.2.0-1-ARCH #1

[  150.808666] Hardware name: Generic AM33XX (Flattened Device Tree)

[  150.814826] [<c001704c>] (unwind_backtrace) from [<c0014224>] (show_stack+0x20/0x24)

[  150.822617] [<c0014224>] (show_stack) from [<c08b4f58>] (dump_stack+0x24/0x28)

[  150.829881] [<c08b4f58>] (dump_stack) from [<c0049eb0>] (warn_slowpath_common+0x94/0xc0)

[  150.838010] [<c0049eb0>] (warn_slowpath_common) from [<c0049f1c>] (warn_slowpath_fmt+0x40/0x48)

[  150.846750] [<c0049f1c>] (warn_slowpath_fmt) from [<c066b938>] (musb_h_tx_flush_fifo+0x104/0x130)

[  150.855666] [<c066b938>] (musb_h_tx_flush_fifo) from [<c066d8a0>] (musb_cleanup_urb.isra.7+0x60/0xf4)

[  150.864929] [<c066d8a0>] (musb_cleanup_urb.isra.7) from [<c066dc04>] (musb_urb_dequeue+0x170/0x1b0)

[  150.874020] [<c066dc04>] (musb_urb_dequeue) from [<c0610b70>] (unlink1+0x3c/0x124)

[  150.881625] [<c0610b70>] (unlink1) from [<c0612d08>] (usb_hcd_unlink_urb+0x74/0xd8)

[  150.889318] [<c0612d08>] (usb_hcd_unlink_urb) from [<c0614248>] (usb_kill_urb+0x68/0xe8)

[  150.897448] [<c0614248>] (usb_kill_urb) from [<c062044c>] (usbdev_ioctl+0x105c/0x18b0)

[  150.905404] [<c062044c>] (usbdev_ioctl) from [<c0184fb8>] (do_vfs_ioctl+0x3c8/0x5a8)

[  150.913183] [<c0184fb8>] (do_vfs_ioctl) from [<c0185214>] (SyS_ioctl+0x7c/0x8c)

[  150.920525] [<c0185214>] (SyS_ioctl) from [<c00104e0>] (ret_fast_syscall+0x0/0x3c)

[  150.928125] ---[ end trace d9aef1845b59ce54 ]---

[  151.937620] ------------[ cut here ]------------

[  151.942311] WARNING: CPU: 0 PID: 157 at drivers/usb/musb/musb_host.c:128 musb_h_tx_flush_fifo+0x104/0x130()

[  151.952090] Could not flush host TX2 fifo: csr: 0103

[  151.957071] Modules linked in: ccm arc4 rtl8192cu rtl_usb rtl8192c_common rtlwifi mac80211 cfg80211 omap_aes omap_sham omap_rng rng_core tilcdc tda998x drm_kms_helper uio_pdrv_genirq uio sch_fq_codel ip_tables x_tables

[  151.976663] CPU: 0 PID: 157 Comm: systemd-timesyn Tainted: G        W       4.2.0-1-ARCH #1

[  151.985045] Hardware name: Generic AM33XX (Flattened Device Tree)

[  151.991198] [<c001704c>] (unwind_backtrace) from [<c0014224>] (show_stack+0x20/0x24)

[  151.998986] [<c0014224>] (show_stack) from [<c08b4f58>] (dump_stack+0x24/0x28)

[  152.006248] [<c08b4f58>] (dump_stack) from [<c0049eb0>] (warn_slowpath_common+0x94/0xc0)

[  152.014378] [<c0049eb0>] (warn_slowpath_common) from [<c0049f1c>] (warn_slowpath_fmt+0x40/0x48)

[  152.023117] [<c0049f1c>] (warn_slowpath_fmt) from [<c066b938>] (musb_h_tx_flush_fifo+0x104/0x130)

[  152.032031] [<c066b938>] (musb_h_tx_flush_fifo) from [<c066c880>] (musb_start_urb+0x7f8/0xd14)

[  152.040681] [<c066c880>] (musb_start_urb) from [<c066d5d4>] (musb_urb_enqueue+0x364/0x5d0)

[  152.048988] [<c066d5d4>] (musb_urb_enqueue) from [<c06123e8>] (usb_hcd_submit_urb+0xd8/0x984)

[  152.057555] [<c06123e8>] (usb_hcd_submit_urb) from [<c0614064>] (usb_submit_urb+0x41c/0x598)

[  152.066044] [<c0614064>] (usb_submit_urb) from [<bf213b04>] (rtl_usb_tx+0x250/0x3d4 [rtl_usb])

[  152.074746] [<bf213b04>] (rtl_usb_tx [rtl_usb]) from [<bf1f0c7c>] (rtl_op_tx+0xac/0xb0 [rtlwifi])

[  152.083932] [<bf1f0c7c>] (rtl_op_tx [rtlwifi]) from [<bf157e48>] (ieee80211_tx_frags+0x168/0x398 [mac80211])

[  152.093959] [<bf157e48>] (ieee80211_tx_frags [mac80211]) from [<bf15810c>] (__ieee80211_tx+0x94/0x180 [mac80211])

[  152.104407] [<bf15810c>] (__ieee80211_tx [mac80211]) from [<bf15a300>] (ieee80211_tx+0xc4/0xf4 [mac80211])

[  152.114243] [<bf15a300>] (ieee80211_tx [mac80211]) from [<bf15b924>] (ieee80211_xmit+0xb0/0x110 [mac80211])

[  152.124164] [<bf15b924>] (ieee80211_xmit [mac80211]) from [<bf15c710>] (__ieee80211_subif_start_xmit+0x4c0/0x6a8 [mac80211])

[  152.135570] [<bf15c710>] (__ieee80211_subif_start_xmit [mac80211]) from [<bf15c914>] (ieee80211_subif_start_xmit+0x1c/0x24 [mac80211])

[  152.147784] [<bf15c914>] (ieee80211_subif_start_xmit [mac80211]) from [<c078d334>] (dev_hard_start_xmit+0x250/0x394)

[  152.158362] [<c078d334>] (dev_hard_start_xmit) from [<c07addd0>] (sch_direct_xmit+0x114/0x1c8)

[  152.167015] [<c07addd0>] (sch_direct_xmit) from [<c078d7d0>] (__dev_queue_xmit+0x224/0x4fc)

[  152.175402] [<c078d7d0>] (__dev_queue_xmit) from [<c078dac8>] (dev_queue_xmit_sk+0x20/0x24)

[  152.183791] [<c078dac8>] (dev_queue_xmit_sk) from [<c07c7be8>] (ip_finish_output2+0x18c/0x408)

[  152.192442] [<c07c7be8>] (ip_finish_output2) from [<c07c9b48>] (ip_finish_output+0x154/0x1f8)

[  152.201003] [<c07c9b48>] (ip_finish_output) from [<c07c9fc4>] (ip_output+0xa4/0x10c)

[  152.208781] [<c07c9fc4>] (ip_output) from [<c07c7850>] (ip_local_out_sk+0x44/0x48)

[  152.216384] [<c07c7850>] (ip_local_out_sk) from [<c07ca92c>] (ip_send_skb+0x20/0x80)

[  152.224169] [<c07ca92c>] (ip_send_skb) from [<c07f1a24>] (udp_send_skb+0xf4/0x270)

[  152.231776] [<c07f1a24>] (udp_send_skb) from [<c07f3818>] (udp_sendmsg+0x2a4/0x7e4)

[  152.239472] [<c07f3818>] (udp_sendmsg) from [<c07fdc9c>] (inet_sendmsg+0x44/0x78)

[  152.246990] [<c07fdc9c>] (inet_sendmsg) from [<c07710ec>] (sock_sendmsg+0x44/0x54)

[  152.254595] [<c07710ec>] (sock_sendmsg) from [<c0772588>] (SyS_sendto+0xd8/0x114)

[  152.262116] [<c0772588>] (SyS_sendto) from [<c00104e0>] (ret_fast_syscall+0x0/0x3c)

[  152.269803] ---[ end trace d9aef1845b59ce55 ]---

[  162.924571] rtl_usb: reg 0x608, usbctrl_vendorreq TimeOut! status:0xffffff92 value=0xd3c000

[  172.919476] rtl_usb: reg 0x608, usbctrl_vendorreq TimeOut! status:0xffffff92 value=0xd30000

[  182.914417] rtl_usb: reg 0x608, usbctrl_vendorreq TimeOut! status:0xffffff92 value=0xf0002ace

[  192.909366] rtl_usb: reg 0x4fd, usbctrl_vendorreq TimeOut! status:0xffffff92 value=0x69543421

[William Hermans]

First, which distro are you using, and how old is the Linux image ? The reason why I ask is that this problem is similar to several posts on this group dating back to 2013 . . .

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

If you check this out, around line 127 seems to be where the error is issued.

http://lxr.free-electrons.com/source/drivers/usb/musb/musb_host.c

[Stephen Pape]

I'm using Arch Linux with all packages updated (kernel 4.2.0-1-ARCH). I noticed the older posts as well, but I haven't seen anyone offer a solution. My guess is that the problem was just never resolved.

[William Hermans]

You may want to setup and use, at least temporarily a Debian sdcard, and see if you can reproduce the error.

With that said, I bet if you're able to disable OTG USB, the problem will go away.

[Robert Nelson]

On Wed, Sep 23, 2015 at 9:47 AM, Stephen Pape <srp...@gmail.com> wrote:
> I'm using Arch Linux with all packages updated (kernel 4.2.0-1-ARCH). I
> noticed the older posts as well, but I haven't seen anyone offer a solution.
> My guess is that the problem was just never resolved.

They have pio mode set too..

https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-am33x/config#L4133-L4134

ARCH arm, sync's with our patchset, so it's almost exactly the same as
linux-image-4.2.0-bone2 in our debian repo..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

They have pio mode set too..

https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-am33x/config#L4133-L4134

ARCH arm, sync's with our patchset, so it's almost exactly the same as
linux-image-4.2.0-bone2 in our debian repo..

Regards,

Ok, so trying a Debian image probably would not solve the problem then. However, I'm curious if disabling OTG on USB will fix it. Assuming the device Stephen is using does not require OTG USB . . .

[Stephen P]

Thanks, I'll try disabling it. Is there a way to do it without a kernel recompile?

-Stephen

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/7h_cvfGexVs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Stephen Pape]

I just checked out the code to attempt a build, and it looks like the kernel config already has CONFIG_USB_OTG disabled, unless I'm looking at the wrong configuration file somehow.

-Stephen

[William Hermans]

I just noticed that on my image too . .

william@xanbustester:~$ zcat /proc/config.gz | grep OTG
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_OTG_FSM is not set
# CONFIG_USB_FOTG210_HCD is not set
# CONFIG_USB_FOTG210_UDC is not set

Although I do recall someone posting a month or two ago in relation to the auto kernel reboots, how to disable the OTG USB stuff. I think it was a kernel level fix.

[William Hermans]

Here is the post I was talking about: https://groups.google.com/forum/#!searchin/beagleboard/reboot|sort:relevance/beagleboard/2yOpE3XYJ1Y/gXB5oSuM7VAJ

lisarden's 4th or 5th post, he talks about modifying board-am335xevm.c.

Anyway Im not sure this will fix anything. It is only a gut feeling I get when reading all the posts on the internet, and the "host" part of the error message. That you, and others are getting. I've been reading about a lot of musb host mode errors over the lat 2-3 years . . .

[Stephen P]

Well thanks for the help, but I guess that I'm going to have to use some other hardware for this project. Based on all of the other (unresolved) posts going back years, it seems the BBB just doesn't have stable USB support.

A few posts below the one you're referring to, they just disable the kernel config option instead. It looks like it didn't really help anyway, and the only thing that worked was to power the board via USB instead of barrel plug, but then you can only get 500ma.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/7h_cvfGexVs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[William Hermans]

A few posts below the one you're referring to, they just disable the kernel config option instead. It looks like it didn't really help anyway, and the only thing that worked was to power the board via USB instead of barrel plug, but then you can only get 500ma.

Well, no. It puts the USB into peripheral mode, instead of being in OTG host mode. As for 500ma . .  that's all you're going to get anyway, so maybe that is your problem.

Anyway, the idea was to get the USB port out of host mode. Still not sure it would work, but I'm starting to wonder now if your problem is power related. As in power provided to you hackRF. Personally, I think it is a bit ridiculous that such a great piece of hardware is only power-able via USB ?!

[Stephen P]

What do you mean? I'm giving the board 2.5A via a wall plug. If I power the board over USB, then I can only give it 500ma.

[William Hermans]

Also, short term, using something else to get your project working would probably be a good idea. However, it'd be cool to get that problem resolved eventually too . . .

[William Hermans]

What a minute. Which port are you using to attempt to connect to your hackRF ? the mini, or full sized port ?

[Stephen P]

Also, like I said in my first post, the HackRF is connected to a powered USB hub. It should be getting plenty of power.

My project is already working on a desktop, but the whole point was to make it a small portable device.

[Stephen P]

The full sized. Why would I use the mini? I'd have to get an adapter, but I could try it I guess. I have a powered USB hub connected to the full sized USB port. Then a HackRF connected to the hub.

[William Hermans]

No, just making sure you were not using the mini - heh.

Anyway, I do not really know where to start in fixing this, well actually I do. . .  libusb, but after that . . . no idea.

Hubs can also sometimes cause problems, but you're already able to receive it seems. Which I guess as long as you're not trying receive and send at the same time. You're good.

[Stephen P]

Ah, I see. I've tried it with and without the hub. I actually bought the hub because I at first assumed that the HackRF wasn't getting enough power, but I saw the same behavior.

I might try a raspberry pi, but I'm kind of worried that it'll use the same USB stack and have the same issue. Might be worth a shot though.

[William Hermans]

I might try a raspberry pi, but I'm kind of worried that it'll use the same USB stack and have the same issue. Might be worth a shot though.

It shouldn't. But if you want flexibility in which distro you install I'd go with the rPI-2.

[Stephen P]

Alright, thanks for the help! I think I'll order one of those.

[William Hermans]

Stephen,

Somewhat off topic. But if you plan on blogging, or  just sharing your experiences, and / or project notes on that hackRF. Id be interesting in reading . . .

My buddy here has been an EE for a long time, and a professional radio station engineer. But as far as I know hes not worked with SDRs in this context so much. Anyway, we both have interest in that device of yours . . .

[Stephen P]

Sure, I did start to write about using the HackRF at http://blog.stephenpape.net/

I've actually completed that whole project (I can generate a signal to control a ceiling fan), but I've only written the first blog post about decoding the signal so far. I'll cover generating the packet and synthesizing the signal when I get around to writing more.

-Stephen

[Stephen P]

Just to sort of close the loop, the HackRF is working for me with Arch Linux on the Raspberry Pi 2. Same code and setup, not even using a hub.

It's a shame that the BBB doesn't work, but I'm happy to be moving forward.

Thanks!

-Stephen

[Yegor Yefremov]

Hi Stephen,

have you used this device? https://greatscottgadgets.com/hackrf/

I'm experiencing this issue with some GSM modems. See my post at TI forum (http://e2e.ti.com/support/arm/sitara_arm/f/791/p/385033/1801121#1801121)

Yegor

[Stephen P]

Hi Yegor,

I'm not sure what you're asking. The post you're replying to is literally me talking about trying to get the HackRF working, so yes I've used it.

-Stephen

[Yegor Yefremov]

Hi Stephen,

there a multiple HackRF compatible devices, so I just wanted to know, what particular device you were using.

Yegor