[USRP-users] Software reset of B210

Marcus Müller marcus.mueller at ettus.com
Sat Oct 3 05:59:30 EDT 2015


Hi Dario,

this might mean that it's actually a different USB chipset, and that
your kernel/lspci doesn't yet actually know how to translate 8cb1 into a
nice device name; to verify could you display the PCI device ID on each
of your machines?
cat /sys/bus/pci/devices/0000:${PCI address}/device
with ${PCI address} being the first entry of lspci's output, i.e.
00:14.0 on your machines.
As it happens, my USB host has device ID 0x8cb1, but is identified as
00:14.0 USB controller: Intel Corporation 9 Series Chipset Family USB
xHCI Controller (prog-if 30 [XHCI])
So my suspicion is that Ubuntu's kernel is just too old.

Best regards,
Marcus
On 02.10.2015 22:51, Dario Fertonani wrote:
> Marcus,
>
> The kernel is 3.13.0-63-lowlatency on all of our machines, with Ubuntu
> 14.04.3 as OS.
>
> Your note on lspci sounded interesting, so I ran a few tests on three
> machines that run the same up-to-date OS (hence, the same lspci). The
> first two are i7 Haswell desktop machines, while the last one is an i5
> Broadwell NUC. It turns out the weird lspci output happens only for
> the newest machine.
>
> $ lspci -v | grep USB
> 00:14.0 USB controller: Intel Corporation Device 8cb1 (prog-if 30 [XHCI])
> 00:1a.0 USB controller: Intel Corporation Device 8cad (prog-if 20 [EHCI])
> 00:1d.0 USB controller: Intel Corporation Device 8ca6 (prog-if 20 [EHCI])
>
> $ lspci -v | grep USB
> 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB xHCI (rev 05) (prog-if 30 [XHCI])
> 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB EHCI #2 (rev 05) (prog-if 20 [EHCI])
> 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB EHCI #1 (rev 05) (prog-if 20 [EHCI])
>
> $ lspci -v | grep USB
> 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI
> Controller (rev 03) (prog-if 30 [XHCI])
> 00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI
> Controller (rev 03) (prog-if 20 [EHCI])
>
>
>
>
>
>
> On Fri, Oct 2, 2015 at 1:07 PM, Marcus Müller
> <marcus.mueller at ettus.com <mailto:marcus.mueller at ettus.com>> wrote:
>
>     Hi Dario,
>
>     of course, we'd like to solve that issue; but basically, I don't
>     have something "quick" to try. What might be of interest might be
>     your current kernel version (i.e. `uname -r`), and also your lspci
>     version (mine (f22) still gives the output that your older lspci
>     gave, so this is more out of private curiosity).
>
>     Thank you so much for being so helpful on this!
>     Marcus
>
>
>     On 01.10.2015 17:05, Dario Fertonani wrote:
>>     USB info on my PC:
>>
>>         $ lspci -v | grep -i usb
>>         00:14.0 USB controller: Intel Corporation Device 8cb1
>>         (prog-if 30 [XHCI])
>>         00:1a.0 USB controller: Intel Corporation Device 8cad
>>         (prog-if 20 [EHCI])
>>         00:1d.0 USB controller: Intel Corporation Device 8ca6
>>         (prog-if 20 [EHCI])
>>
>>     Same command run a few months ago on the same HW with older
>>     Ubuntu version (fished out from my Feb 24 message to this list):
>>
>>         $ lspci -v | grep -i usb
>>         00:14.0 USB controller: Intel Corporation 8 Series/C220
>>         Series Chipset Family USB xHCI (rev 05) (prog-if 30 [XHCI])
>>         00:1a.0 USB controller: Intel Corporation 8 Series/C220
>>         Series Chipset Family USB EHCI #2 (rev 05) (prog-if 20 [EHCI])
>>         00:1d.0 USB controller: Intel Corporation 8 Series/C220
>>         Series Chipset Family USB EHCI #1 (rev 05) (prog-if 20 [EHCI])
>>
>>     Basically it's Intel 8 Series, typical of a Haswell Desktop PC.
>>
>>     UHD is compiled from source (via build-gnuradio script), giving
>>     string UHD_003.008.005-10-g3dbced2d in each output. I reverted
>>     back from 3.9 after seeing that it wasn't stable for our usage. I
>>     plan to upgrade to 3.9.1 soon.
>>
>>     The problem is relatively new, but I'm not sure this is a fair
>>     statement since we started only recently to run very long LTE
>>     tests on B210, which are the ones that trigger the problem. The
>>     flow goes like this: long MIMO full-duplex run, app dies because
>>     recv stops getting samples, debug shows the USB error, reset the
>>     board, repeat.
>>
>>     From my side the SW solution you provided is good enough. Unless
>>     you have something I can test, I'll defer and look more into this
>>     problem if it persists after upgrading UHD.
>>
>>     Dario
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     On Thu, Oct 1, 2015 at 6:51 AM, Marcus Müller
>>     <marcus.mueller at ettus.com <mailto:marcus.mueller at ettus.com>> wrote:
>>
>>         Hi Dario,
>>         admittedly, not right now; transfer status 1 is
>>         "LIBUSB_TRANSFER_ERROR", which basically tells me nothing :(.
>>         Is that a new problem or did it exist before? What USB
>>         chipset are you using ("lspci|grep -i usb")?
>>
>>         It's a bit surprising to me that uhd_usrp_probe still works,
>>         though. I'd like to reproduce; what's your UHD version?
>>
>>         Best regards,
>>         Marcus
>>
>>
>>         On 30.09.2015 19:55, Dario Fertonani wrote:
>>>         Thank you Marcus. That did work.
>>>         Any idea on what could be the cause of the error?
>>>
>>>         Thanks,
>>>         Dario
>>>
>>>         On Wed, Sep 30, 2015 at 9:00 AM, Marcus Müller
>>>         <usrp-users at lists.ettus.com
>>>         <mailto:usrp-users at lists.ettus.com>> wrote:
>>>
>>>             Hi Dario,
>>>
>>>             have you tried
>>>             b2xx_fx3_utils -D
>>>
>>>             You can usually find that program in your uhd/utils
>>>             folder, e.g. /usr/local/lib/uhd/utils.
>>>             -D resets the device, -F only the FPGA, -U tries to
>>>             reset the USB subsystem on your computer.
>>>
>>>             Best regards,
>>>             Marcus
>>>
>>>
>>>             On 30.09.2015 17:55, Dario Fertonani via USRP-users wrote:
>>>>             I'm looking for a software command that resets B210
>>>>             boards to a usable state. Currently my default solution
>>>>             consists of unplugging the USB cable (which is also the
>>>>             only source of power, in this setup), waiting a couple
>>>>             of seconds, and plugging it back. This "solution" is
>>>>             not ideal as it requires humans around the board.
>>>>
>>>>             My definition of unusable state is: B210 returns this
>>>>             message
>>>>
>>>>                 terminate called after throwing an instance of
>>>>                 'uhd::runtime_error'
>>>>                   what():  RuntimeError: usb rx6 transfer status: 1
>>>>
>>>>             Interestingly, the unusable state doesn't
>>>>             prevent uhd_usrp_probe from working and dumping the
>>>>             expected strings.
>>>>
>>>>             Any software solution available? UHD API or shell
>>>>             commands are both fine, since the event is rare enough
>>>>             that we can tolerate some level of "manual" interaction.
>>>>
>>>>             Thanks,
>>>>             Dario
>>>>
>>>>
>>>>
>>>>             _______________________________________________
>>>>             USRP-users mailing list
>>>>             USRP-users at lists.ettus.com
>>>>             <mailto:USRP-users at lists.ettus.com>
>>>>             http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>             _______________________________________________
>>>             USRP-users mailing list
>>>             USRP-users at lists.ettus.com
>>>             <mailto:USRP-users at lists.ettus.com>
>>>             http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151003/e47261da/attachment-0002.html>


More information about the USRP-users mailing list