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
(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.
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.
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.
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).
Created attachment 571233 [details] uhd_usrp_probe output w/ clues about DBSRX
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.
I posted a message on usrp-users with subject "uhd_usrp_probe hangs w/ DBSRX on USRP1".
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.
FYI, josh 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.
Thanks, I will apply it, for reference it is upstream commit 097f20df1653c33035b6dcfefbbef22572426c65.
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
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
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).
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!
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.
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.