[USRP-users] Software reset of B210

Dario Fertonani dario.fertonani at gmail.com
Sat Oct 3 12:34:50 EDT 2015


You are right Marcus. The newer Haswell machine has Intel 9 Series instead
of 8 Series. The two relevant outputs are pasted below. The one on i7-4790K
is too new for the stock Ubuntu 14.04.3 kernel to label it.

On [i7-4790K]
$ cat /sys/bus/pci/devices/0000\:00\:14.0/device
0x8cb1

On [i7-4770K]
$ cat /sys/bus/pci/devices/0000\:00\:14.0/device
0x8c31

Both machines support full-duplex MIMO at 16.36 MHz with very rare drops,
so overall the USB system is fine. The 9 Series just happens to cause B210
to "die" after long tests.
Anyway, I added the SW reset you suggested to the always-on loop that keeps
launching the app, and the behavior is acceptable.

Best,
Dario



On Sat, Oct 3, 2015 at 2:59 AM, Marcus Müller <marcus.mueller at ettus.com>
wrote:

> 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>
> 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>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>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 listUSRP-users at lists.ettus.comhttp://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
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151003/48926a5e/attachment-0002.html>


More information about the USRP-users mailing list