discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: AW: USRP Errror "USER2: Invalid reason associated with wait request"


From: Dobler, Anton
Subject: AW: AW: USRP Errror "USER2: Invalid reason associated with wait request"
Date: Thu, 16 Jun 2022 07:40:18 +0000

Thank you for that info! So I know at least where not to look for the problem :))
BR,

Anton
Von: Marcus D. Leech <patchvonbraun@gmail.com>
Gesendet: Mittwoch, 15. Juni 2022 22:40:17
An: Dobler, Anton; discuss-gnuradio@gnu.org
Betreff: Re: AW: USRP Errror "USER2: Invalid reason associated with wait request"
 
On 2022-06-15 16:34, Dobler, Anton wrote:
The reason to run the flowgraph in su mode is that I want to use dpdk to ensure a reliable ethernet connection for sfp0/1… at least that’s what is mentioned by ettus in there AN regarding the usage of dpdk…
BR,
Anton
Von: Discuss-gnuradio <discuss-gnuradio-bounces+anton.dobler=unibw.de@gnu.org> im Auftrag von Marcus D. Leech <patchvonbraun@gmail.com>
Gesendet: Mittwoch, 15. Juni 2022 21:54:53
An: discuss-gnuradio@gnu.org
Betreff: Re: USRP Errror "USER2: Invalid reason associated with wait request"
 
On 2022-06-15 15:33, Dobler, Anton wrote:

Dear all,


I am running GNURadio 3.8.1 with UHD3.15 LTS on an Ubuntu 18.04 machine with 16 cores (Intel(R) Xeon(R) Gold 6144 CPU @ 3.50GHz) and a 10GigBit Ethernet card (DPDK enabled).


The output of the benchmark_rate test is:


root@dobler-Precision-7820-Tower:/home/dobler/rfnoc/uhd/host/build/examples# ./benchmark_rate --args "mgmt_addr=169.254.2.13,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1" --rx_rate=125e6 --tx_rate=125e6

[INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; UHD_3.15.0.HEAD-0-gaea0e2de
EAL: Detected 16 lcore(s)
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: PCI device 0000:00:1f.6 on NUMA socket 0
EAL:   probe driver: 8086:15b9 net_e1000_em
EAL: PCI device 0000:d5:00.0 on NUMA socket 0
EAL:   probe driver: 8086:10fb net_ixgbe
EAL:   using IOMMU type 1 (Type 1)
EAL: Ignore mapping IO port bar(2)
EAL: PCI device 0000:d5:00.1 on NUMA socket 0
EAL:   probe driver: 8086:10fb net_ixgbe
EAL: Ignore mapping IO port bar(2)
PMD: ixgbe_dev_link_status_print():  Port 0: Link Down
EAL: Port 0 MAC: 90 e2 ba f1 38 1c
PMD: ixgbe_dev_link_status_print():  Port 1: Link Down
EAL: Port 1 MAC: 90 e2 ba f1 38 1d
EAL: Waiting for links to come up...
EAL: Port 0 UP: 1, 10000 Mbps
EAL: Port 1 UP: 1, 10000 Mbps
EAL: Init DONE!
EAL: Starting I/O threads!
USER2: Thread 1 started
USER2: Thread 2 started
[00:00:00.000001] Creating the usrp device with: mgmt_addr=169.254.2.13,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1...
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=169.254.2.13,type=n3xx,product=n310,serial=3176E00,claimed=False,addr=1.0.1.2,second_addr=1.0.2.2,use_dpdk=1
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=169.254.2.13,product=n310,second_addr=1.0.2.2,use_dpdk=1,time_source=external,clock_source=external'.
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A00000000004)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_2] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_3] Initializing block control (NOC ID: 0xF1F0000000000000)
Using Device: Single USRP:
  Device: N300-Series Device
  Mboard 0: ni-n3xx-3176E00
  RX Channel: 0
    RX DSP: 0
    RX Dboard: A
    RX Subdev: Magnesium
  RX Channel: 1
    RX DSP: 1
    RX Dboard: A
    RX Subdev: Magnesium
  RX Channel: 2
    RX DSP: 0
    RX Dboard: B
    RX Subdev: Magnesium
  RX Channel: 3
    RX DSP: 1
    RX Dboard: B
    RX Subdev: Magnesium
  TX Channel: 0
    TX DSP: 0
    TX Dboard: A
    TX Subdev: Magnesium
  TX Channel: 1
    TX DSP: 1
    TX Dboard: A
    TX Subdev: Magnesium
  TX Channel: 2
    TX DSP: 0
    TX Dboard: B
    TX Subdev: Magnesium
  TX Channel: 3
    TX DSP: 1
    TX Dboard: B
    TX Subdev: Magnesium

[00:00:04.381956] Setting device timestamp to 0...
[00:00:04.452104] Testing receive rate 125.000000 Msps on 1 channels
[00:00:04.593488] Testing transmit rate 125.000000 Msps on 1 channels
[00:00:14.944083] Benchmark complete.


Benchmark rate summary:
  Num received samples:     1292668703
  Num dropped samples:      0
  Num overruns detected:    0
  Num transmitted samples:  1250045736
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:        0
  Num timeouts (Tx):        0
  Num timeouts (Rx):        0


This test is done with the default FPGA image for the N310 with XG. So far everything seems to be good!


Now for the application I am running I used the uhd_image_builder to generate a FPGA image with a DDCs and DUCs and moreover I included also a FFT.


The flowgraph consists basically of a file source, a fft and a duc (both on the fpga) and the radio (usrp n310) itself.


However, when I execute the flow-graph already with privileged rights (chrt -f 99 python3 flowgraph.py) I run into under-runs and moreover I get the following error "USER2: Invalid reason associated with wait request".


When I reduce the sampling rate obviously the under-runs disappear but the second error message still pops up after a time and also the LED on the front panel of the USRP goes off.


What do you think is the reason for this? Running the same flow-graph on a different workstation works fine. Could some issue with the network cards be the problem?


Any help is appreciated!


Best regards,


Anton




There's no reason that I can think of to run this in a privileged environment. What happens when you do this as an ordinary user?


Ah!  Sorry, I missed the "use_dpdk" in your command line.

What I can tell you is that this message is likely NOT coming from UHD itself, but perhaps from the DPDK library.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]