[USRP-users] Software reset of B210

Henry Hallam henry at planet.com
Fri Oct 2 17:05:19 EDT 2015


FWIW USB3 xhci support seems to have improved in more recent kernels.
We've seen issues with the B210 even with 3.16 that went away with
4.1.

Henry

On Fri, Oct 2, 2015 at 1:51 PM, Dario Fertonani via USRP-users
<usrp-users at lists.ettus.com> 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>
> 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>
>> 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> 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
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> 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
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>




More information about the USRP-users mailing list