I would suspect that your setting of the time_spec with an uninitialized
value could be a problem. rx_multi_samples sets up multi-channel RX with an
initialized time_spec:

https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/host/examples/rx_multi_samples.cpp

Can you compile and run that example on 3.15?

-Sam

On Fri, Mar 27, 2020 at 4:33 PM Carmichael, Ryan via USRP-users <
[email protected]> wrote:

> *From:* USRP-users <[email protected]> *On Behalf Of *Marcus
> D. Leech via USRP-users
> *Sent:* Friday, March 27, 2020 4:27 PM
> *To:* [email protected]
> *Subject:* [EXTERNAL] Re: [USRP-users] X310 UHD 3.15 Lockups
>
>
>
> On 03/27/2020 04:15 PM, Carmichael, Ryan via USRP-users wrote:
>
> I recently updated from 3.11.1 to 3.15LTS to try to resolve a receive
> lockup problem, however it still appears to be happening (albeit seemingly
> less frequently).
>
>
>
> Essentially, stream->recv() gets into a state where it never returns, even
> though we are using the default timeout (0.1). Verified via debugger that
> recv() itself is just hanging.
>
>
>
> We essentially have a function A that roughly looks like the code below
> (I’m not leaving much out). We call this function A over and over quite
> frequently. Are there any red flags here?
>
>
>
> A() {
>
>     uhd::stream_cmd_t
> rxStreamCmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>
>     rxStreamCmd.stream_now = true;
>
>     rxStreamCmd.time_spec = uhd::time_spec_t();
>
>     rxStreamCmd.num_samps = nSamples_a;
>
>
>
>     rxStream ->issue_stream_cmd(rxStreamCmd);
>
>
>
>     numReceived = 0;
>
>     uhd::rx_metadata_t metaData
>
>
>
>     while (numReceived < nSamples_a) {
>
>         .
>
>         .
>
>         // calculate numLeftToRead
>
>         .
>
>         .
>
>         uint samplesReceived = rxStream->recv(buffer, numLeftToRead,
> metaData);
>
>         .
>
>         .
>
>         // calculate numReceived
>
>     }
>
> }
>
>
>
> This “lockup” typically does not require the radio to be restarted, just
> my application.
>
>
> * ------------------------------ *
>
>
>
> Windows or Linux?   Native or VM?
>
> My gut says this is an IP/Network stack issue.
>
>
> * ------------------------------ *
>
>
>
> Native, RHEL 7 - Linux localhost.localdomain 3.10.0-1062.1.1.el7.x86_64 #1
> SMP Tue Aug 13 18:39:59 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>
> 10 GB NICs. MTUs set to 9000.
>
> 0b:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
> Network Connection (rev 01)
>
> 0b:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
> Network Connection (rev 01)
>
> 0d:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
> Network Connection (rev 01)
>
> 0d:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+
> Network Connection (rev 01)
>
>
>
>
>
> * ------------------------------ The information contained in this
> message, and any attachments, may contain privileged and/or proprietary
> information that is intended solely for the person or entity to which it is
> addressed. Moreover, it may contain export restricted technical data
> controlled by Export Administration Regulations (EAR) or the International
> Traffic in Arms Regulations (ITAR). Any review, retransmission,
> dissemination, or re-export to foreign or domestic entities by anyone other
> than the intended recipient in accordance with EAR and/or ITAR regulations
> is prohibited. *
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to