B210 USB Disconnects

[drewvian]

The latest update completed today, 8/22/2014 broke the operation of UHD driver for the B210. My system is running Ubuntu 14.04 LTS and using the UHD driver through Gnuradio. The installation was completed using Pybombs, which is a build from source from the git repository. After a short time of operation even with just a basic USRP source and FFT Sink, there is an error message for USB communications, and then repeated USB error messages until the program is terminated. This problem is accompanied by a response in dmesg showing the USB disconnect and immediately reconnect at USB 3 speeds. This problem was repeated with reboots to the computer, resets of the firmware/fpga image, and fresh re-installs of the UHD driver and Gnuradio. I have already been troubleshooting the issue, so I no longer have the exact error message easily retrievable. The up to date installation yesterday 8/21/2014 worked properly, so it was in the new commit today. I tested manually built firmware from revision 3.7.1 with the 3.7.2 code, since at first I thought it was from the firmware change, but that did not correct the issue. A full reversion to 3.7.1 returned full operation of the UHD driver.

[drewvian]

Here is more information for troubleshooting purposes. My USB 3.0 chipset is the Intel 7 Series/C210 chipset on a Macbook Pro Retina 10,1, Mid 2012.

The initial error is:
UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: usb rx8 transfer status: 5

Then this error is repeatedly spammed until the program is terminated:
UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 5
UHD source block got error code 0xf

This problem does not seem to be dependent on sample rate or clock rate. I have tried a variety of different values for both and they all have the same behavior.

[drewvian]

Here is also the relevant part of the dmesg log.

[ 2739.271585] usb 4-2: USB disconnect, device number 3
[ 2739.511409] usb 4-2: new SuperSpeed USB device number 4 using xhci_hcd
[ 2739.528711] usb 4-2: New USB device found, idVendor=2500, idProduct=0020
[ 2739.528713] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2739.528716] usb 4-2: Product: USRP B200
[ 2739.528717] usb 4-2: Manufacturer: Ettus Research LLC
[ 2739.528719] usb 4-2: SerialNumber: F57203

[bhilburn]

Thanks for the bug report, @drewvian!

Just to clarify, when you say that it was a "new commit on 08/21", were you working off of the master or maint branch?

[michaelld]

I'm running my B210 on the exact same MacBook Pro as you, using OSX 10.8 and the current public UHD master installed via MacPorts ("uhd-devel"). I also have a recent GNU Radio install (via "gnuradio-devel"). I've been running "uhd-fft" for 2 hours without incident. I do, of course, have to do the usual plug, uhd_usrp_probe, replug before UHD works on my Mac (a known issue); but, otherwise it all seems to work nicely together.

I'm wondering if on the dates you meant "8/22" and so forth instead of "7/22" ... that would make some sense.

I'm also wondering if maybe you have the wrong images for the given install. I've made sure that in MacPorts the correct images are always installed when UHD is updated.

[drewvian]

Yes, I meant 8/22. I edited the original to correct the dates. I am working off the master branch. I did an update on 8/21 to the current version, which worked fine. Then on 8/22, I checked and it showed new updates again. After completing the updates on 8/22 the problems started. That was also when I spotted that the firmware went from reporting version 4 to version 6. I also noticed that some of the changes were showing a day old, and some were showing 2 days old, so on 8/21 I probably got a version in between the different updates. I have not tested in OSX to determine if the issue affects that version since I primarily use Ubuntu. I can give it a try in OSX tomorrow.

[bhilburn]

@drewvian - Maybe you ended up with a FW and FPGA image mismatch at some point? I suggest also re-downloading the latest images and trying with the UHD-3.7.2 tag on Ubuntu. I just tested this, as well, and could not reproduce it.

[drewvian]

Each time I changed versions fresh images were downloaded using uhd_images_downloader.py.
It prompted each time since of course with the firmware revision change causes an error message for compatibility. When I mentioned I tried the version 4 firmware with 3.7.2, I changed the code to read as version 6 and compiled from source, so it would run with the updated software.

[bhilburn]

@drewvian - By changing the code, you actually removed the feature that prevented you from using mismatched versions of the host code, FW, and FPGA code. If you had to change the code, that's an indication that you didn't have the right images, the right host code, or both.

If you clone UHD-3.7.2, build from source, and downloading the matching images, you should not see any report of mismatched compat numbers. If you do, that's the problem that needs to be addressed.

This appears to not be a bug, but is rather a support case. Can you please e-mail [email protected] to continue this conversation?

[drewvian]

I said I tested both versions of the firmware, and confirmed that it was not the firmware that was the problem. I did not change any code other than building a separate firmware image from source, which did not fix the problem. Each time, whether going from Head to 3.7.1 or from 3.7.1 to Head, it prompted for updated images using uhd_images_downloader.py. There was no problem with mismatched compat numbers that the image downloader didn't take care of. The problem is with usb disconnects on the Master branch Head.

[michaelld]

On my side, can you boot into Mac OS X and try the same on that side? Since I have the exact same setup as you, if you experience issues on OSX I can better work with you to figure out what's going on. That said ... as @bhilburn wrote: This appears to not be a bug, but is rather a support case. Can you please e-mail [email protected] to continue this conversation?

[bhilburn]

@drewvian - Until we get further information, it would be easier for us to handle this as a support case. You will get faster turn-around times on responses, and direct support. Please take the conversation to [email protected]. I promise we aren't just cutting you loose without solving your problem - the Github issue tracker just isn't a good medium for this conversation.

[drewvian]

So I emailed the issue to support the same day as the last comments, including more information on the testing. I ran testing in OSX using Macports and have similar result. I have received absolutely no response in 10 days, so I will try posting the information here. Here are the emails I sent to support.

Andrew Vian
Aug 26 (10 days ago)
to support
Hi,
The latest builds of the Master branch of the UHD driver cause USB disconnects after a short period of time receiving. This problem began with the latest UHD updates on 8/22. The up-to-date UHD version I pulled on 8/21 worked properly.
The initial error is:

UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: usb rx8 transfer status: 5

Then this error is repeatedly spammed until the program is terminated:

UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 5
UHD source block got error code 0xf

This problem is accompanied by a standard message in the dmesg log showing the USB disconnected and immediately reconnected.

I am running Ubuntu 14.04 LTS and using the UHD driver with Gnuradio installed through pybombs, which is a direct build from source from the UHD git repository. The computer is a Macbook Pro Retina 10,1, Mid 2012. It uses an Intel 7 Series/C210 USB 3.0 chipset. I have tested several times with fresh installs including completely wiping the directory structure. Installation and operation from the 3.7.1 tag worked properly. I also just tested installation explicitly using the 3.7.2 tag, and that seems to work correctly also. The problem is when no tag is specified and it pulls directly from the Head.

I have already reported this as an issue on the UHD driver, which was quickly dismissed incorrectly as a firmware version mismatch. The link to that discussion is below. Note that my mentions in those posts of 3.7.2 were using the Head, not explicitly using the 3.7.2 tag.
#10

Thanks,
Andrew Vian

Andrew Vian
Aug 26 (10 days ago)

to support
Hi,
I have tested the Macports version in OSX Mavericks. The uhd-devel branch has the same issue, where it almost immediately drops the connection. The regular uhd version ran properly in OSX. The error messages are slightly different with one of them seeming to be garbled. Once again the final error message is repeatedly spammed until the program is terminated. The error messages are included below.

UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 1

UHD Error:
An uUHD sourcnexpectede e xbcleopctki ogno tw aesr rcoaru gchotd ei n0 xa fta
sk loop.
The task loop will now exit, things may not work.
RuntimeError: usb rx8 transfer status: 1

UHD Error:
The receive packet handler caught an exception.
RuntimeError: usb rx6 transfer status: 1
UHD source block got error code 0xf

There is also an error message window that say 'Python quit unexpectedly'. Running it in OSX also showed another interesting side effect that is different from Ubuntu. When the USB disconnect happens, my USB ethernet connection drops. I have an external USB 2.0 hub with a USB gigabit ethernet adapter attached to my other usb port, which is run by the same chipset. The connection is lost there, and will not reconnect without unplugging it and replugging it in. To connect to the B210 again it also requires unplugging it and plugging it back in. Neither of these problems showed up in Ubuntu. I ran tests without the USB 2.0 devices connected, and still had the same errors.

Thanks,
Andrew Vian

[michaelld]

Hi Andrew - I apologize for the delay in getting back to you. It looks like Neel is assisting you via Ettus Support now, and since both this ticket and the support site reflect all of the postings, there's nothing more to be done on this ticket (hence, leaving it as closed). Neel will bring me and/or Ben in as needed to help him work through your issue. - MLD

[drewvian]

Yes, I am conversing with Neel now. Thank you.

[coinchon]

I have had the same issue of USB disconnect with a B200 on an Intel NUC i5 with debian linux and UHD 3.7.2. Downgrading to UHD 3.7.1 has not helped. Here's the error:
UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: usb rx8 transfer status: 5
what(): RuntimeError: usb tx2 transfer status: 5

The application is sending a continous stream that is transmitted by the B200 (broadcast signal)
By setting the CPU scaling off (using cpufreq-set to put governor to "Performance"), it seems this has solved the issue.

[bhilburn]

@coinchon - Whoa! That is very interesting. Thanks so much for sharing this - we really appreciate it.

[dmaynor]

I am getting the same error as coinchon. I have the same hardware as well (Intel NUC i5). I built gnuradio/uhd with the build-gnuradio script.

[bhilburn]

@dmaynor - Please e-mail [email protected]. Thanks!

[coinchon]

Well, I was quick, I got the same error again with UHD 3.7.1.
I tried a downgrade to UHD 3.7.0 and now my application segfaults:
[445487.037100] odr-dabmod[7567]: segfault at 0 ip 00007f67eb74e806 sp 00007fff12e019a0 error 4 in libuhd.so.003.007[7f67eb5e7000+524000]
I then tried UHD 3.7.3 and it also segfaults (I noticed image downloader does get 3.7.0 images with it).
So finally only 3.7.1 and 3.7.2 are working for us but with these sporadic RuntimeError: usb rx8 transfer status: 5 leading to a disconnect and restart.

We have another machine (Lenovo) with exactly the same OS/Version (Debian Wheezy amd64), app version, B200 and UHD driver (3.7.0) and it works fine. The only difference is that the B200 is connected on USB2 (ehci_hcd) and not USB3 (xhci_hcd) like on the Intel NUC. I suspect that the combination of the USB3 controller/driver with UHD to be the problem.
Or is it the way we manage UHD in our app ? https://github.com/Opendigitalradio/ODR-DabMod/blob/master/src/OutputUHD.cpp

Any help welcome. Thank you.

[bhilburn]

@coinchon - The Github bug tracker really isn't a good medium for providing support. Can you please e-mail [email protected], where we can give you direct support?

For anyone else who finds this thread, it is very difficult for us to provide technical support to you via this bug tracker. Please e-mail [email protected] if you have this the issue described in this bug, and we will provide direct support to you. Thanks!