Bug 804440 - /usr/bin/uhd_usrp_probe hangs
/usr/bin/uhd_usrp_probe hangs
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: uhd (Show other bugs)
16
i386 Linux
unspecified Severity high
: ---
: ---
Assigned To: Jaroslav Škarvada
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-18 15:58 EDT by Ken
Modified: 2012-04-25 23:32 EDT (History)
2 users (show)

See Also:
Fixed In Version: gnuradio-3.4.2-7.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-14 00:36:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of uhd_usrp_probe (intermittent) (4.29 KB, text/plain)
2012-03-19 12:09 EDT, Ken
no flags Details
uhd_usrp_probe output w/ clues about DBSRX (476 bytes, text/plain)
2012-03-19 17:20 EDT, Ken
no flags Details

  None (edit)
Description Ken 2012-03-18 15:58:59 EDT
Description of problem: uhd_usrp_probe hangs


Version-Release number of selected component (if applicable): uhd-3.3.1-3.fc16.i686



How reproducible: Very


Steps to Reproduce:
1. run uhd_usrp_probe (with USRP1 attached via USB)
2. notice it hangs
3. shake fist
  
Actual results:

uhd_usrp_probe hangs

Expected results:

Report of USRP configuration


Additional info:


uhd_find_device runs OK (it outputs "Device Address: type: usrp1, serial: 48b98f68", etc).

When I run uhd_usrp_probe, it hangs.

I did an "strace", and there are these "poll" events every 60 seconds:

12:01:08.578463 clock_gettime(CLOCK_MONOTONIC, {576694, 182248028}) = 0
12:01:08.578691 poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLOUT}], 3, 60000) = 0 (Timeout)

... so it looks like it's waiting on a USB file descriptor.  

Also, uhd_find_device hangs at this point.

If I power cycle the USRP, then uhd_find_device works OK again.

So... that would indicate that the USRP has crashed.

One note: when I first ran uhd_find_devices, it complains about not finding the USRP firmware:

"""
UHD Warning:
    Could not locate USRP1 firmware.
    Please install the images package.
"""

I couldn't find the firmware on the Fedora repos, so I got the USRP firmware from the ettus site: http://files.ettus.com/uhd_releases/master_images/UHD-images-003.004.000-f500b92.zip

This might problem might be due to a mismatch between uhd_usrp_probe and the firmware.  I'm not sure how to isolate this further.

This USRP used to work OK with the old USRP interface (before UHD).

Perhaps the USRP firmware should be in the fedora repos (perhaps it is and I couldn't find it).

If it's a mismatch problem, maybe uhd_usrp_probe should be able determine that and display and error message.

Cheers,
Ken
Comment 1 Jaroslav Škarvada 2012-03-19 06:50:26 EDT
(In reply to comment #0)
Thanks for report. Currently I do not have the USRP HW for testing (I will have one in May). Please could you try the uhd update?:
https://admin.fedoraproject.org/updates/uhd-3.3.2-1.fc16

Please let me know if the problem persists after the update.

> This might problem might be due to a mismatch between uhd_usrp_probe and the
> firmware.  I'm not sure how to isolate this further.
> 
AFAIK it shouldn't do that (with firmware that is recent enough).

> This USRP used to work OK with the old USRP interface (before UHD).
> 
GNUradio upstream dropped the libusrp support, thus we need to go only with uhd in Fedora 17 and up.

> Perhaps the USRP firmware should be in the fedora repos (perhaps it is and I
> couldn't find it).
> 
Currently it isn't. It is known problem and it is on my list, but it will take a bit of time.
Comment 2 Ken 2012-03-19 12:00:04 EDT
Thanks for your response.

I installed uhd-3.3.2-1.fc16.i686

... however I still get the same symptom:  uhd_find_devices works OK, but uhd_usrp_probe hangs in "poll".

Cheers.
Comment 3 Ken 2012-03-19 12:09:19 EDT
Created attachment 571180 [details]
Output of uhd_usrp_probe (intermittent)

One update:  "uhd_usrp_probe" did run OK once (yesterday, with uhd-3.3.1-3.fc16.i686), so this problem is intermittent.  It did hang after that, however.  I've attached the output of that successful run.
Comment 4 Jaroslav Škarvada 2012-03-19 13:04:07 EDT
Thanks for info. AFAIK there was regression in UHD some time ago, but it should be already fixed. However to be sure, please try the latest devel scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3910375

Please try other USB ports, PCs / ports combination and also without USB hubs.

I will try to get the code "offline" overview later this week. If not successful I will try debug this when my USRP arrive (in May).
Comment 5 Ken 2012-03-19 17:20:44 EDT
Created attachment 571233 [details]
uhd_usrp_probe output w/ clues about DBSRX
Comment 6 Ken 2012-03-19 17:24:05 EDT
Oops... Bugzilla logged me out.  I meant to include the following with the above attachment:

I removed the "DBSRX-LF rev 2.2" module from the USRP1 and the uhd software works OK now.

I guess this means there is a problem with the firmware upstream.
Comment 7 Ken 2012-03-19 22:48:40 EDT
I posted a message on usrp-users with subject "uhd_usrp_probe hangs w/ DBSRX on USRP1".
Comment 8 Ken 2012-03-24 16:10:13 EDT
FYI, I posted this on "usrp-users":

Here's an interesting symptom:

The DBSRX works OK by itself (in either RXA or RXB) and the "TVRX rev
3" works OK by itself (in either RXA or RXB), but they don't work when
both DBSRX and TVRX are installed (in either position).

... and Marcus Leech asked me to run this:

UHD_LOG_LEVEL=1 uhd_usrp_probe --args "type=usrp1"

... I gave him the log files.
Comment 9 Ken 2012-03-26 21:09:44 EDT
FYI, josh@ettus.com says:

> This seems to be a hardware issue when (and only when):
> USRP1 rev 4.5 + DBSRX + another i2c-based dboard.
> In other words, this does not happen on USRP1 rev3.

... and:

> This patch seems to fix my setup: http://pastebin.com/RYMsxiTf
>
> Essentially, the host code was feeding DBSRX to high a clock rate on
> USRP1. I cant explain why this is an issue only under certain conditions
> that I described in the last email.

I tested the patch, and it works for me as well.
Comment 10 Jaroslav Škarvada 2012-03-27 04:12:59 EDT
Thanks, I will apply it, for reference it is upstream commit 097f20df1653c33035b6dcfefbbef22572426c65.
Comment 11 Fedora Update System 2012-03-27 10:52:10 EDT
uhd-3.4.0-1.fc17,gnuradio-3.5.2.1-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/uhd-3.4.0-1.fc17,gnuradio-3.5.2.1-2.fc17
Comment 12 Fedora Update System 2012-03-27 11:35:15 EDT
gnuradio-3.4.2-7.fc16,uhd-3.4.0-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/gnuradio-3.4.2-7.fc16,uhd-3.4.0-1.fc16
Comment 13 Fedora Update System 2012-03-28 01:51:53 EDT
Package uhd-3.4.0-1.fc17, gnuradio-3.5.2.1-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing uhd-3.4.0-1.fc17 gnuradio-3.5.2.1-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4736/uhd-3.4.0-1.fc17,gnuradio-3.5.2.1-2.fc17
then log in and leave karma (feedback).
Comment 14 Ken 2012-03-28 12:50:10 EDT
I installed uhd-3.4.0-1.fc16.i686, and /usr/bin/uhd_usrp_probe now works.

Also, I installed gnuradio-3.4.2-7.fc16.i686, and /usr/bin/uhd_fft.py works (so the fixes the ABI change).

Thanks Jaroslav!
Comment 15 Fedora Update System 2012-04-14 00:36:19 EDT
uhd-3.4.0-1.fc17, gnuradio-3.5.2.1-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Fedora Update System 2012-04-25 23:32:04 EDT
gnuradio-3.4.2-7.fc16, uhd-3.4.0-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.