conda activate kraken doesn't help through sudo

[dennishiding]

Following the manual build instructions sets up a conda activate kraken environment on my user account. That seems to get through the compile and then sudo daq_start_sm.sh looks like it runs, but once I realize the _logs directory is where the output logs are I see that much of that script failed. The sudo removes the conda environment and

• the python scripts are failing due to missing packages.
  • fixed by various sudo dnf install and sudo pip install commands to make packages available in root environment.
• decimator.out fails to find libkfr_capi.so, maybe I missed a step on installing that library? (review of installation step problem added in comment blelow)
  • fixed by adding -Wl,-rpath='$$ORIGIN' to CFLAGS in Makefile
  • rebuilding
  • copying the libkfr_capi.so file to the same directory as decimator.out

corruption trap and fix split to seperate issue noted in comment below

• decimator.log indicates heap corruption trap now:

  16:21:47 INFO  fir_decimate.c:121: Decimation ratio: 1
  16:21:47 INFO  fir_decimate.c:122: CPI size: 1048576
  16:21:47 INFO  fir_decimate.c:123: Calibration sample size : 65536
  16:21:47 INFO  fir_decimate.c:147: Input shared memory interface succesfully ini
  tialized
  16:21:48 INFO  fir_decimate.c:161: Output shared memory interface succesfully in
  itialized
  16:21:48 INFO  fir_decimate.c:212: FIR filter coefficienrs are initialized, tap 
  size: 1
  double free or corruption (out)

  Maybe I'll manage to catch it under gdb later, but some of this weekend salvaged for other activities.

[dennishiding]

split to seperate issue in comment below

(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007eff478e7c73 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007eff47897986 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007eff478817f4 in __GI_abort () at abort.c:79
#4  0x00007eff478dbd5e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7eff47a1387c "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#5  0x00007eff478f195c in malloc_printerr (str=str@entry=0x7eff47a16450 "double free or corruption (out)") at malloc.c:5659
#6  0x00007eff478f3a80 in _int_free (av=0x7eff47a51c80 <main_arena>, p=0x7eff1a374030, have_lock=<optimized out>) at malloc.c:4583
#7  0x00007eff478f6103 in __GI___libc_free (mem=<optimized out>) at malloc.c:3386
#8  0x00000000004016c0 in main ()

recompiling with -g:

#8  0x00000000004016c0 in main (argc=<optimized out>, argv=<optimized out>) at fir_decimate.c:347

near end of main: free(fir_input_buffer_i);

so main was already bailing out for some other reason.

[dennishiding]

split to seperate issue in comment below

Adding instrumentation...

09:01:08 INFO  fir_decimate.c:198: kfr allocate fir buffers
fir_input_buffer_i = 0x7faca57d0040
cpi_size = 1048576
dec = 1
sizeof(kfr_f32)=4
09:01:08 INFO  fir_decimate.c:218: FIR filter coefficienrs are initialized, tap size: 1
09:01:08 INFO  fir_decimate.c:228: Entering main loop:
09:01:08 INFO  fir_decimate.c:231: top of main loop
09:01:08 INFO  fir_decimate.c:350: exiting main loop 255
double free or corruption (out)

[dennishiding]

• [x] fix the trap on termination in fir_decimate.c with: (split to separate issue )

#ifdef ARM_NEON
    free(fir_input_buffer_i);
    free(fir_input_buffer_q);
    free(fir_output_buffer_i);
    free(fir_output_buffer_q);
#else // X86
    kfr_release( fir_input_buffer_i);
    kfr_release( fir_input_buffer_q);
    kfr_release( fir_output_buffer_i);
    kfr_release( fir_output_buffer_q);
#endif

It looks like kfr's allocator is not compatible with free.

Still doesn't fix the termination question:

09:13:17 INFO  fir_decimate.c:228: Entering main loop: 
09:13:17 INFO  fir_decimate.c:231: top of main loop
09:13:17 INFO  fir_decimate.c:234: Active_buff_ind_in=255

fir_decimate.c

    log_info("Entering main loop: ");
    while(!exit_flag){

    log_info("top of main loop");
        // Acquire data buffer on the shared memory interface
        active_buff_ind_in = wait_buff_ready(input_sm_buff);
    log_info("Active_buff_ind_in=%i\n", active_buff_ind_in );
        if (active_buff_ind_in < 0 ){exit_flag = 1; break;}
        if (active_buff_ind_in == TERMINATE) {exit_flag = TERMINATE; break;}

[krakenrf]

What instructions are you using? The manual build documents the installation of KFR in step 3.

And what type of system are you building on? The scripts are working as expected at this time as far as I can see.

[dennishiding]

What instructions are you using? The manual build documents the installation of KFR in step 3.

dennis@fedora heimdall_daq_fw]$ git remote show origin  |grep "Fetch URL"
  Fetch URL: https://github.com/krakenrf/heimdall_daq_fw
[dennis@fedora heimdall_daq_fw]$ git branch
* main
[dennis@fedora heimdall_daq_fw]$ git show main
commit 72c04a1f49a3dea2c67e583d4bb8fa9c14640fd0 (HEAD -> main, origin/main, origin/HEAD)
Author: krakenrf <78108016+krakenrf@users.noreply.github.com>
Date:   Thu Nov 10 14:03:37 2022 +1300

    Delete config_files/pr_2ch_2pow16 directory
...
[dennis@fedora heimdall_daq_fw]$ grep -C 5 'kfr.*lib'  README.md

Copy the built library over to the system library folder:

sudo cp ~/kfr/build/lib/* /usr/local/lib

Copy the include file over to the system includes folder:

[dennis@fedora heimdall_daq_fw]$ ls /usr/local/lib/libkfr*
/usr/local/lib/libkfr_capi_avx2.a        /usr/local/lib/libkfr_capi_avx_pic.a   /usr/local/lib/libkfr_capi_sse41_pic.a
/usr/local/lib/libkfr_capi_avx2_pic.a    /usr/local/lib/libkfr_capi.so          /usr/local/lib/libkfr_dft.a
/usr/local/lib/libkfr_capi_avx512.a      /usr/local/lib/libkfr_capi_sse2.a      /usr/local/lib/libkfr_io.a
/usr/local/lib/libkfr_capi_avx512_pic.a  /usr/local/lib/libkfr_capi_sse2_pic.a
/usr/local/lib/libkfr_capi_avx.a         /usr/local/lib/libkfr_capi_sse41.a
[dennis@fedora heimdall_daq_fw]$ ldconfig -v 2>/dev/null | grep -v ^$'\t'
/usr/lib64/iscsi: (from /etc/ld.so.conf.d/libiscsi-x86_64.conf:1)
/usr/lib64/llvm13/lib: (from /etc/ld.so.conf.d/llvm13-x86_64.conf:1)
/usr/lib64/octave/6.4.0: (from /etc/ld.so.conf.d/octave-x86_64.conf:1)
/usr/lib64/pipewire-0.3/jack: (from /etc/ld.so.conf.d/pipewire-jack-x86_64.conf:1)
/usr/lib64/tcl8.6: (from /etc/ld.so.conf.d/tix-x86_64.conf:1)
/lib: (from <builtin>:0)
/lib64: (from <builtin>:0)
[dennis@fedora heimdall_daq_fw]$ ldconfig -p |grep libkfr
[dennis@fedora heimdall_daq_fw]$ 

So instructions copied to /usr/local/lib but /usr/local/lib isn't in ldconfig search path, so didn't get found. I probably should have translated the instruction line 'system library folders' and realized that /usr/local/lib wouldn't be correct but perhaps I hadn't run into enough of the /usr/local assumptions breaking yet.

And what type of system are you building on? The scripts are working as expected at this time as far as I can see.

[dennis@fedora heimdall_daq_fw]$ uname -a
Linux fedora 5.19.15-201.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Oct 13 18:58:38 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

LOL, yep quote board at office has many versions of "But it works for me" highly ranked.

Anyway the adding -Wl,-rpath='$$ORIGIN' to CFLAGS in Makefile and copying the erroring kfr libary to heimdall_daq_fw/Firmware/_daq_core/ worked to get around the kfr library linking issues. A bit of a quick hack, would normally use ${ORIGIN}:${ORIGIN}/../libs and put the embedded libraries in libs next to binaries.

It's a bit odd that the instructions say copy all the libkfr libaries but I only got the dynamic linking error from the one.

• [ ] Later, check if SMD engine specific libaries are still being loaded, and how getting path, rpath, ldconfig, or compiled in.

[dennishiding]

Looking at my existing check box I'll split the only clear bug to its own issue. Still need to look at the expected termination, but that appears to be flagged by an upstream package. Not sure that I'll get time this weekend to dig further.

[dennishiding]

Picking back up where left off with the termination question:

09:13:17 INFO  fir_decimate.c:228: Entering main loop: 
09:13:17 INFO  fir_decimate.c:231: top of main loop
09:13:17 INFO  fir_decimate.c:234: Active_buff_ind_in=255

fir_decimate.c

    log_info("Entering main loop: ");
    while(!exit_flag){

    log_info("top of main loop");
        // Acquire data buffer on the shared memory interface
        active_buff_ind_in = wait_buff_ready(input_sm_buff);
    log_info("Active_buff_ind_in=%i\n", active_buff_ind_in );
        if (active_buff_ind_in < 0 ){exit_flag = 1; break;}
        if (active_buff_ind_in == TERMINATE) {exit_flag = TERMINATE; break;}

Assuming this is something with librtlsdr

Looking back at notes for it

2. Install custom KrakenRF RTL-SDR kernel driver

git clone https://github.com/krakenrf/librtlsdr cd librtlsdr sudo cp rtl-sdr.rules /etc/udev/rules.d/rtl-sdr.rules mkdir build cd build cmake ../ -DINSTALL_UDEV_RULES=ON make sudo ln -s ~/librtlsdr/build/src/rtl_test /usr/local/bin/kraken_test

I notice that though it is built the only thing installed is the udev rules. I looks like I went ahead an ran make install anyway as there is an install_manifest in the build directory, with lots of stuff in /usr/local with no apparent configuration to support using it there. Since the instructions above don't cover installing at all, I'm not sure that the mis-installation is a problem or not.

Add the rtl-sdr.rules file that is copied doesn't reference the usb vender id that shows up when the the kraken is connected, though it looks like the usb connection fails based on the system log...

Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: [8086:15d3] type 01 class 0x060400
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: enabling Extended Tags
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: supports D1 D2
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
Jan 28 11:59:44 fedora kernel: pci 0000:04:00.0: [8086:15d3] type 01 class 0x060400
Jan 28 11:59:44 fedora kernel: pci 0000:04:00.0: enabling Extended Tags
Jan 28 11:59:44 fedora kernel: pci 0000:04:00.0: supports D1 D2
Jan 28 11:59:44 fedora kernel: pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: [8086:15d3] type 01 class 0x060400
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: enabling Extended Tags
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: supports D1 D2
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: PME# supported from D0 D1 D2 D3hot D3cold
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: [8086:15d3] type 01 class 0x060400
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: enabling Extended Tags
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: supports D1 D2
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: PME# supported from D0 D1 D2 D3hot D3cold
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: [8086:15d3] type 01 class 0x060400
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: enabling Extended Tags
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: supports D1 D2
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: PME# supported from D0 D1 D2 D3hot D3cold
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: PCI bridge to [bus 04-6d]
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0:   bridge window [mem 0xac000000-0xda0fffff]
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0:   bridge window [mem 0x60000000-0xa9ffffff 64bit pref]
Jan 28 11:59:44 fedora kernel: pci 0000:04:00.0: PCI bridge to [bus 05]
Jan 28 11:59:44 fedora kernel: pci 0000:04:00.0:   bridge window [mem 0xda000000-0xda0fffff]
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: PCI bridge to [bus 06-38]
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0:   bridge window [mem 0xac000000-0xc3efffff]
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0:   bridge window [mem 0x60000000-0x7fffffff 64bit pref]
Jan 28 11:59:44 fedora kernel: pci 0000:39:00.0: [8086:15d4] type 00 class 0x0c0330
Jan 28 11:59:44 fedora kernel: pci 0000:39:00.0: reg 0x10: [mem 0xc3f00000-0xc3f0ffff]
Jan 28 11:59:44 fedora kernel: pci 0000:39:00.0: enabling Extended Tags
Jan 28 11:59:44 fedora kernel: pci 0000:39:00.0: supports D1 D2
Jan 28 11:59:44 fedora kernel: pci 0000:39:00.0: PME# supported from D0 D1 D2 D3hot D3cold
Jan 28 11:59:44 fedora kernel: pci 0000:39:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:04:02.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: PCI bridge to [bus 39]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0:   bridge window [mem 0xc3f00000-0xc3ffffff]
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: PCI bridge to [bus 3a-6d]
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0:   bridge window [mem 0xc4000000-0xd9ffffff]
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0:   bridge window [mem 0x80000000-0xa9ffffff 64bit pref]
Jan 28 11:59:44 fedora kernel: pci_bus 0000:04: Allocating resources
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: bridge window [io  0x1000-0x0fff] to [bus 06-38] add_size 1000
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: bridge window [io  0x1000-0x0fff] to [bus 39] add_size 1000
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 39] add_size 200000 add_align 100000
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: bridge window [io  0x1000-0x0fff] to [bus 3a-6d] add_size 1000
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: bridge window [io  0x1000-0x0fff] to [bus 04-6d] add_size 4000
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: BAR 13: no space for [io  size 0x4000]
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: BAR 13: failed to assign [io  size 0x4000]
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: BAR 13: no space for [io  size 0x4000]
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: BAR 13: failed to assign [io  size 0x4000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pci 0000:04:00.0: PCI bridge to [bus 05]
Jan 28 11:59:44 fedora kernel: pci 0000:04:00.0:   bridge window [mem 0xda000000-0xda0fffff]
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0: PCI bridge to [bus 06-38]
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0:   bridge window [mem 0xac000000-0xc3efffff]
Jan 28 11:59:44 fedora kernel: pci 0000:04:01.0:   bridge window [mem 0x60000000-0x7fffffff 64bit pref]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0: PCI bridge to [bus 39]
Jan 28 11:59:44 fedora kernel: pci 0000:04:02.0:   bridge window [mem 0xc3f00000-0xc3ffffff]
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0: PCI bridge to [bus 3a-6d]
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0:   bridge window [mem 0xc4000000-0xd9ffffff]
Jan 28 11:59:44 fedora kernel: pci 0000:04:04.0:   bridge window [mem 0x80000000-0xa9ffffff 64bit pref]
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0: PCI bridge to [bus 04-6d]
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0:   bridge window [mem 0xac000000-0xda0fffff]
Jan 28 11:59:44 fedora kernel: pci 0000:03:00.0:   bridge window [mem 0x60000000-0xa9ffffff 64bit pref]
Jan 28 11:59:44 fedora kernel: xhci_hcd 0000:39:00.0: xHCI Host Controller
Jan 28 11:59:44 fedora kernel: xhci_hcd 0000:39:00.0: new USB bus registered, assigned bus number 3
Jan 28 11:59:44 fedora kernel: xhci_hcd 0000:39:00.0: hcc params 0x200077c1 hci version 0x110 quirks 0x0000000200009810
Jan 28 11:59:44 fedora kernel: xhci_hcd 0000:39:00.0: xHCI Host Controller
Jan 28 11:59:44 fedora kernel: xhci_hcd 0000:39:00.0: new USB bus registered, assigned bus number 4
Jan 28 11:59:44 fedora kernel: xhci_hcd 0000:39:00.0: Host supports USB 3.1 Enhanced SuperSpeed
Jan 28 11:59:44 fedora kernel: usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.01
Jan 28 11:59:44 fedora kernel: usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Jan 28 11:59:44 fedora kernel: usb usb3: Product: xHCI Host Controller
Jan 28 11:59:44 fedora kernel: usb usb3: Manufacturer: Linux 6.1.7-100.fc36.x86_64 xhci-hcd
Jan 28 11:59:44 fedora kernel: usb usb3: SerialNumber: 0000:39:00.0
Jan 28 11:59:44 fedora kernel: hub 3-0:1.0: USB hub found
Jan 28 11:59:44 fedora kernel: hub 3-0:1.0: 2 ports detected
Jan 28 11:59:44 fedora kernel: usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.01
Jan 28 11:59:44 fedora kernel: usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Jan 28 11:59:44 fedora kernel: usb usb4: Product: xHCI Host Controller
Jan 28 11:59:44 fedora kernel: usb usb4: Manufacturer: Linux 6.1.7-100.fc36.x86_64 xhci-hcd
Jan 28 11:59:44 fedora kernel: usb usb4: SerialNumber: 0000:39:00.0
Jan 28 11:59:44 fedora kernel: hub 4-0:1.0: USB hub found
Jan 28 11:59:44 fedora kernel: hub 4-0:1.0: 2 ports detected
Jan 28 11:59:44 fedora kernel: pci_bus 0000:04: Allocating resources
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:01.0: bridge window [io  0x1000-0x0fff] to [bus 06-38] add_size 1000
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:02.0: bridge window [io  0x1000-0x0fff] to [bus 39] add_size 1000
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 39] add_size 200000 add_align 100000
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:04.0: bridge window [io  0x1000-0x0fff] to [bus 3a-6d] add_size 1000
Jan 28 11:59:44 fedora kernel: pcieport 0000:03:00.0: bridge window [io  0x1000-0x0fff] to [bus 04-6d] add_size 4000
Jan 28 11:59:44 fedora kernel: pcieport 0000:03:00.0: BAR 13: no space for [io  size 0x4000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:03:00.0: BAR 13: failed to assign [io  size 0x4000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:03:00.0: BAR 13: no space for [io  size 0x4000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:03:00.0: BAR 13: failed to assign [io  size 0x4000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:01.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:01.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:02.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:02.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:04.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:04.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:04.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:04.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:02.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:02.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:01.0: BAR 13: no space for [io  size 0x1000]
Jan 28 11:59:44 fedora kernel: pcieport 0000:04:01.0: BAR 13: failed to assign [io  size 0x1000]
Jan 28 11:59:45 fedora kernel: usb usb3-port2: Cannot enable. Maybe the USB cable is bad?
Jan 28 11:59:46 fedora kernel: usb usb3-port2: Cannot enable. Maybe the USB cable is bad?
Jan 28 11:59:46 fedora kernel: usb usb3-port2: attempt power cycle
Jan 28 11:59:47 fedora kernel: usb usb3-port2: Cannot enable. Maybe the USB cable is bad?
Jan 28 11:59:48 fedora kernel: usb usb3-port2: Cannot enable. Maybe the USB cable is bad?
Jan 28 11:59:48 fedora kernel: usb usb3-port2: unable to enumerate USB device

Perhaps the most information in:

 New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: xHCI Host Controller
usb usb3: Manufacturer: Linux 6.1.7-100.fc36.x86_64 xhci-hcd
usb usb3: SerialNumber: 0000:39:00.0
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.01
usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb4: Product: xHCI Host Controller
usb usb4: Manufacturer: Linux 6.1.7-100.fc36.x86_64 xhci-hcd
usb usb4: SerialNumber: 0000:39:00.0
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detectedusb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.01

Thought would find 1d6b in the rtl-sdr.rules but didn't.

Feel like the kernel never even got to the point of considering this an rtl-sdr device.

Guessing that's why the fir_decimate is immediately bailing out on the TERMINATE condition.

[krakenrf]

You shouldn't be doing make install, but you can if you really want to install the drivers it globally. In step 7 of the Heimdall install the compiled librtlsdr.a library is copied over to the _daq_core folder, so the library is accessed locally. This was a user requested change a while ago as then the modified krakensdr RTL-SDR drivers will not overwrite any previously installed RTL-SDR system drivers, which may be used for other devices.

But your main issue appears to be that your system for whatever reason isn't able to access the RTL-SDRs on the KrakenSDR. That's usually just down to a power supply issue, but it could also be problems with the USB port on that PC.

Try running rtl_test or kraken_test, to see how many tuners show up.

[dennishiding]

rtl_test says nothing found.

(kraken) [dennis@fedora 221226krakenrf]$ find . -name rtl_test
./librtlsdr/build/src/rtl_test
(kraken) [dennis@fedora 221226krakenrf]$ cd librtlsdr/
(kraken) [dennis@fedora librtlsdr]$ cd build
(kraken) [dennis@fedora build]$ cd src
(kraken) [dennis@fedora src]$ ls
CMakeFiles               librtlsdr.so.0.8git  rtl_fm       rtl_test
cmake_install.cmake      Makefile             rtl_ir       rtl_udp
libconvenience_static.a  rtl_adsb             rtl_power    rtl_wavestat
librtlsdr.a              rtl_app_ver.h        rtl_raw2wav  rtl_wavestream
librtlsdr.so             rtl_biast            rtl_sdr
librtlsdr.so.0           rtl_eeprom           rtl_tcp
(kraken) [dennis@fedora src]$ ./rtl_test
No supported devices found.

I didn't find a kraken_test

(kraken) [dennis@fedora 221226krakenrf]$ find . -name kr*_test
(kraken) [dennis@fedora 221226krakenrf]$ find  . -name kraken_*
./heimdall_daq_fw/config_files/kraken_default
./heimdall_daq_fw/config_files/kraken_development

Modifying from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1426216/comments/7

[dennis@fedora 221226krakenrf]$ for i in $(journalctl -n 4000 | grep 'BAR 13: failed' | awk '{print $7}' | uniq | sort | uniq); do echo $i; done
0000:03:00.0:
0000:04:01.0:
0000:04:02.0:
0000:04:04.0:

...
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
03:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
04:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
04:01.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
04:02.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
04:04.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
39:00.0 USB controller: Intel Corporation JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016] (rev 02)
6e:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO
...

When unplug the kraken data cable get, where the above lines would have been between these lines.

...
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
6e:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO

lspci -k -b -PP -Q -nn
...
00:1c.4/03:00.0 PCI bridge [0604]: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] [8086:15d3] (rev 02)
    Kernel driver in use: pcieport
00:1c.4/03:00.0/04:00.0 PCI bridge [0604]: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] [8086:15d3] (rev 02)
    Kernel driver in use: pcieport
00:1c.4/03:00.0/04:01.0 PCI bridge [0604]: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] [8086:15d3] (rev 02)
    Kernel driver in use: pcieport
00:1c.4/03:00.0/04:02.0 PCI bridge [0604]: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] [8086:15d3] (rev 02)
    Kernel driver in use: pcieport
00:1c.4/03:00.0/04:04.0 PCI bridge [0604]: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] [8086:15d3] (rev 02)
    Kernel driver in use: pcieport
00:1c.4/03:00.0/04:02.0/39:00.0 USB controller [0c03]: Intel Corporation JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016] [8086:15d4] (rev 02)
    Subsystem: Device [2222:1111]
    Kernel driver in use: xhci_hcd

Feb 11 09:17:02 fedora kernel: usb usb3: Product: xHCI Host Controller
Feb 11 09:17:02 fedora kernel: usb usb3: Manufacturer: Linux 6.1.7-100.fc36.x86_64 xhci-hcd
Feb 11 09:17:02 fedora kernel: usb usb3: SerialNumber: 0000:39:00.0
Feb 11 09:17:02 fedora kernel: hub 3-0:1.0: USB hub found
Feb 11 09:17:02 fedora kernel: hub 3-0:1.0: 2 ports detected
Feb 11 09:17:02 fedora kernel: usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.01
Feb 11 09:17:02 fedora kernel: usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 11 09:17:02 fedora kernel: usb usb4: Product: xHCI Host Controller
Feb 11 09:17:02 fedora kernel: usb usb4: Manufacturer: Linux 6.1.7-100.fc36.x86_64 xhci-hcd
Feb 11 09:17:02 fedora kernel: usb usb4: SerialNumber: 0000:39:00.0
Feb 11 09:17:02 fedora kernel: hub 4-0:1.0: USB hub found
Feb 11 09:17:02 fedora kernel: hub 4-0:1.0: 2 ports detected
Feb 11 09:17:02 fedora kernel: pci_bus 0000:04: Allocating resources
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:01.0: bridge window [io  0x1000-0x0fff] to [bus 06-38] add_size 1000
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:02.0: bridge window [io  0x1000-0x0fff] to [bus 39] add_size 1000
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 39] add_size 200000 add_align 100000
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:04.0: bridge window [io  0x1000-0x0fff] to [bus 3a-6d] add_size 1000
Feb 11 09:17:02 fedora kernel: pcieport 0000:03:00.0: bridge window [io  0x1000-0x0fff] to [bus 04-6d] add_size 4000
Feb 11 09:17:02 fedora kernel: pcieport 0000:03:00.0: BAR 13: no space for [io  size 0x4000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:03:00.0: BAR 13: failed to assign [io  size 0x4000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:03:00.0: BAR 13: no space for [io  size 0x4000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:03:00.0: BAR 13: failed to assign [io  size 0x4000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:01.0: BAR 13: no space for [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:01.0: BAR 13: failed to assign [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:02.0: BAR 13: no space for [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:02.0: BAR 13: failed to assign [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:04.0: BAR 13: no space for [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:04.0: BAR 13: failed to assign [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:04.0: BAR 13: no space for [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:04.0: BAR 13: failed to assign [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:02.0: BAR 13: no space for [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:02.0: BAR 13: failed to assign [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:01.0: BAR 13: no space for [io  size 0x1000]
Feb 11 09:17:02 fedora kernel: pcieport 0000:04:01.0: BAR 13: failed to assign [io  size 0x1000]

In comparision to different bridge device on the system:

00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 [8086:9d10] (rev f1)
    Kernel driver in use: pcieport
00:1c.2 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 [8086:9d12] (rev f1)
    Kernel driver in use: pcieport
00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 [8086:9d14] (rev f1)
    Kernel driver in use: pcieport
00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 [8086:9d18] (rev f1)
    Kernel driver in use: pcieport
00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point LPC Controller/eSPI Controller [8086:9d4e] (rev 21)
    Subsystem: Dell Device [1028:07e6]

I haven't enough USB background to see how a power supply problem turns into these BAR errors that appear to be memory mappings. Though I have seen power supplies mentioned in reference to these errors, there's also been driver issues mentioned. Some mentions of a kernel driver issue that broke ports with thunderbolt support but was fixed a few months ago, in updates I had before I even ordered the kraken tuner.

But I do note that the brick I'm using says 3A, its apparently rated 3A at 12V and 15V, and only 2A at 5V and 9V, so I'll look for a option to swap. (don't think will find any with a C output or adapter today though)

[dennishiding]

Same results with 2 other power supplies both rated at 3A 5V. An inline USB power meter says the krakensdr is only drawing 120mA at 5V. So does the higher current doesn't kick in until actually connect to the tuners? But something is preventing setting that up.

So its OK that that pcieport is the driver being connected with the krakensdr. That doesn't need to be something special from the librtlsdr package?

[krakenrf]

The tuners don't fully power up until a program that accesses the drivers starts, so the initial low power draw makes sense.

Are you able to confirm on another PC that the 5 units can show up? If rtl_test is showing now supported tuners, then either the KrakenSDR itself is broken, or its your PC that is not recognizing it for some reason.

Do you have a standard RTL-SDR? Can that even connect to your PC?

The kernel issue with it breaking thunderbolt -> usb hardware compatibility sounds like it's the root cause of your issues, given the fact that rtl_test is not even seeing any tuner at all. Every other error you've gotten is just a symptom of the RTL-SDRs being unable to connect to the USB in the first place.

The last message in the kernel bug report says that the third non thunderbird port still works. Can you try connecting to that one?

[dennishiding]

No alternate SDR device, this was my first.

lsusb shows what I think are appropriate connections on a older desktop (no rtl-sdr or kraken-sdr software installed there).

Updated the laptop to latest FC36 picking up kernel 6.1.13

Feb 24 13:05:06 fedora kernel: xhci_hcd 0000:39:00.0: xHCI Host Controller
Feb 24 13:05:06 fedora kernel: xhci_hcd 0000:39:00.0: new USB bus registered, assigned bus number 3
Feb 24 13:05:06 fedora kernel: xhci_hcd 0000:39:00.0: hcc params 0x200077c1 hci version 0x110 quirks 0x0000000200009810
Feb 24 13:05:06 fedora kernel: xhci_hcd 0000:39:00.0: xHCI Host Controller
Feb 24 13:05:06 fedora kernel: xhci_hcd 0000:39:00.0: new USB bus registered, assigned bus number 4
Feb 24 13:05:06 fedora kernel: xhci_hcd 0000:39:00.0: Host supports USB 3.1 Enhanced SuperSpeed
Feb 24 13:05:06 fedora kernel: usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.01
Feb 24 13:05:06 fedora kernel: usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 24 13:05:06 fedora kernel: usb usb3: Product: xHCI Host Controller
Feb 24 13:05:06 fedora kernel: usb usb3: Manufacturer: Linux 6.1.13-100.fc36.x86_64 xhci-hcd
Feb 24 13:05:06 fedora kernel: usb usb3: SerialNumber: 0000:39:00.0
Feb 24 13:05:06 fedora kernel: hub 3-0:1.0: USB hub found
Feb 24 13:05:06 fedora kernel: hub 3-0:1.0: 2 ports detected
Feb 24 13:05:06 fedora kernel: usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.01
Feb 24 13:05:06 fedora kernel: usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Feb 24 13:05:06 fedora kernel: usb usb4: Product: xHCI Host Controller
Feb 24 13:05:06 fedora kernel: usb usb4: Manufacturer: Linux 6.1.13-100.fc36.x86_64 xhci-hcd
Feb 24 13:05:06 fedora kernel: usb usb4: SerialNumber: 0000:39:00.0
Feb 24 13:05:06 fedora kernel: hub 4-0:1.0: USB hub found
Feb 24 13:05:06 fedora kernel: hub 4-0:1.0: 2 ports detected
Feb 24 13:05:06 fedora kernel: pci_bus 0000:04: Allocating resources
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:01.0: bridge window [io  0x1000-0x0fff] to [bus 06-38] add_size 1000
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:02.0: bridge window [io  0x1000-0x0fff] to [bus 39] add_size 1000
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 39] add_size 200000 add_align 100000
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:04.0: bridge window [io  0x1000-0x0fff] to [bus 3a-6d] add_size 1000
Feb 24 13:05:06 fedora kernel: pcieport 0000:03:00.0: bridge window [io  0x1000-0x0fff] to [bus 04-6d] add_size 4000
Feb 24 13:05:06 fedora kernel: pcieport 0000:03:00.0: BAR 13: no space for [io  size 0x4000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:03:00.0: BAR 13: failed to assign [io  size 0x4000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:03:00.0: BAR 13: no space for [io  size 0x4000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:03:00.0: BAR 13: failed to assign [io  size 0x4000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:01.0: BAR 13: no space for [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:01.0: BAR 13: failed to assign [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:02.0: BAR 13: no space for [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:02.0: BAR 13: failed to assign [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:04.0: BAR 13: no space for [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:04.0: BAR 13: failed to assign [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:04.0: BAR 13: no space for [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:04.0: BAR 13: failed to assign [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:02.0: BAR 15: no space for [mem size 0x00200000 64bit pref]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:02.0: BAR 15: failed to assign [mem size 0x00200000 64bit pref]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:02.0: BAR 13: no space for [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:02.0: BAR 13: failed to assign [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:01.0: BAR 13: no space for [io  size 0x1000]
Feb 24 13:05:06 fedora kernel: pcieport 0000:04:01.0: BAR 13: failed to assign [io  size 0x1000]
Feb 24 13:05:07 fedora kernel: usb usb3-port2: Cannot enable. Maybe the USB cable is bad?
Feb 24 13:05:08 fedora kernel: usb usb3-port2: Cannot enable. Maybe the USB cable is bad?
Feb 24 13:05:08 fedora kernel: usb usb3-port2: attempt power cycle
Feb 24 13:05:09 fedora kernel: usb usb3-port2: Cannot enable. Maybe the USB cable is bad?
Feb 24 13:05:10 fedora kernel: usb usb3-port2: Cannot enable. Maybe the USB cable is bad?
Feb 24 13:05:10 fedora kernel: usb usb3-port2: unable to enumerate USB device

The lsusb output after connecting kracken picks up these two entries:

> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Curious these are already one of each of those devices on the fc36 laptop.

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

But this doesn't match the fc35 desktop machine lsusb shows these new entries:

> Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
> Bus 001 Device 007: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
> Bus 001 Device 006: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
> Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
> Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
> Bus 001 Device 003: ID 0424:2517 Microchip Technology, Inc. (formerly SMSC) Hub

Maybe will look for laptop firmware update /sigh

[dennishiding]

Was already on latest and greatest BIOS.

Tried disabling thunderbolt support in BIOS, same result.

Both the 6.1.7 and 6.1.13 kernels include the revert of the commit mentioned in https://bugzilla.kernel.org/show_bug.cgi?id=216497

@krakenrf Thanks for your continued feedback.

[dennishiding]

Was already on latest and greatest BIOS.

Tried disabling thunderbolt support in BIOS, same result.

Both the 6.1.7 and 6.1.13 kernels include the revert of the commit mentioned in https://bugzilla.kernel.org/show_bug.cgi?id=216497

@krakenrf Thanks for your continued feedback.

[dennishiding]

Though the dock was conflicting, and was trying without connecting the dock. No change. It appears that its connecting to the hub that connects the left 2 usb-C ports on the xps13. Two USB's on the left support thunderbolt and usb3.1 gen2. One the right supports only usb3.1 Gen 1. The problem persisted on those ports even with Thuderbolt disabled in bios.

Using the usb 3.1 Gen 1 port

[dennis@fedora ~]$ lsusb
Bus 004 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 004 Device 004: ID 0bda:0413 Realtek Semiconductor Corp. Dell dock
Bus 004 Device 003: ID 0bda:0487 Realtek Semiconductor Corp. Dell dock
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 005: ID 413c:b06e Dell Computer Corp. Dell dock
Bus 003 Device 006: ID 413c:b06f Dell Computer Corp. Dell dock
Bus 003 Device 007: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 003 Device 004: ID 0bda:5413 Realtek Semiconductor Corp. Dell dock
Bus 003 Device 003: ID 0bda:5487 Realtek Semiconductor Corp. Dell dock
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0489:e0a2 Foxconn / Hon Hai 
Bus 001 Device 003: ID 0bda:58f4 Realtek Semiconductor Corp. Integrated_Webcam_HD
Bus 001 Device 020: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 019: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 018: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 017: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 016: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 015: ID 0424:2517 Microchip Technology, Inc. (formerly SMSC) Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Success sort of.

[dennishiding]

rtl_test gets a bit futher, but still appears to fail. Note I have to get around the libraries being in the /usr/local/lib path.

(kraken) [dennis@fedora 221226krakenrf]$ export LD_LIBRARY_PATH=/usr/local/lib
(kraken) [dennis@fedora 221226krakenrf]$ rtl_test
Found 5 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 1004
  1:  Realtek, RTL2838UHIDIR, SN: 1000
  2:  Realtek, RTL2838UHIDIR, SN: 1001
  3:  Realtek, RTL2838UHIDIR, SN: 1002
  4:  Realtek, RTL2838UHIDIR, SN: 1003

Using device 0: Generic RTL2832U OEM
usb_claim_interface error -6
Failed to open rtlsdr device #0.

[krakenrf]

Could it be that the DVB-T drivers are not properly blacklisted on your system?

[dennishiding]

In both the kfr and librtlsdr directories use ccmake .. to set install prefix to /usr, configure, generate. then make; sudo make install; sudo ldconfig;

Then delete all the errant junk that has been put in /usr/local (sudo rm -rf /usr/local ) ( though I started piecemeal verifying it was only kraken stuff as I went. Then one more sudo ldconfig incase I had added any of that stuff to an ld config path.

rtl_test path from /usr/bin now. And links without LD_LIBRARY_PATH hack.

And runs....

[dennis@fedora 221226krakenrf]$ rtl_test
Found 5 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 1004
  1:  Realtek, RTL2838UHIDIR, SN: 1000
  2:  Realtek, RTL2838UHIDIR, SN: 1001
  3:  Realtek, RTL2838UHIDIR, SN: 1002
  4:  Realtek, RTL2838UHIDIR, SN: 1003

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T/2 tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
Allocating 15 (non-zero-copy) user-space buffers
lost at least  16 bytes in buffer 0

Now if I can remember what I was doing to fire up gnu radio...

change heimdall_daq_fw/Firmware/daq_chain_config.ini:log_level = 5 back from 1.

delay_sync.log seems noisy but willing to consider it may be running.

(kraken) [dennis@fedora _logs]$ grep "block analysis" delay_sync.log
DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:==== SSA block analysis pass on 10
DEBUG:numba.core.ssa:==== SSA block analysis pass on 12
DEBUG:numba.core.ssa:==== SSA block analysis pass on 74
DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:==== SSA block analysis pass on 52
DEBUG:numba.core.ssa:==== SSA block analysis pass on 54
DEBUG:numba.core.ssa:==== SSA block analysis pass on 175
DEBUG:numba.core.ssa:==== SSA block analysis pass on 62
DEBUG:numba.core.ssa:==== SSA block analysis pass on 174
DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:==== SSA block analysis pass on 14
DEBUG:numba.core.ssa:==== SSA block analysis pass on 16
DEBUG:numba.core.ssa:==== SSA block analysis pass on 32
DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:==== SSA block analysis pass on 30
DEBUG:numba.core.ssa:==== SSA block analysis pass on 34
DEBUG:numba.core.ssa:==== SSA block analysis pass on 42
DEBUG:numba.core.ssa:==== SSA block analysis pass on 58
DEBUG:numba.core.ssa:==== SSA block analysis pass on 62
DEBUG:numba.core.ssa:==== SSA block analysis pass on 72
DEBUG:numba.core.ssa:==== SSA block analysis pass on 126
DEBUG:numba.core.ssa:==== SSA block analysis pass on 130
DEBUG:numba.core.ssa:==== SSA block analysis pass on 140
DEBUG:numba.core.ssa:==== SSA block analysis pass on 0
DEBUG:numba.core.ssa:==== SSA block analysis pass on 30
DEBUG:numba.core.ssa:==== SSA block analysis pass on 32
DEBUG:numba.core.ssa:==== SSA block analysis pass on 174
DEBUG:numba.core.ssa:==== SSA block analysis pass on 40
DEBUG:numba.core.ssa:==== SSA block analysis pass on 173

(kraken) [dennis@fedora gr-krakensdr]$ python --version
Python 3.9.7
(kraken) [dennis@fedora gr-krakensdr]$ rpm -ql python3-gnuradio.x86_64
...
/usr/lib64/python3.10/site-packages/gnuradio
/usr/lib64/python3.10/site-packages/gnuradio/__init__.py
/usr/lib64/python3.10/site-packages/gnuradio/__init__.pyc
/usr/lib64/python3.10/site-packages/gnuradio/__init__.pyo
/usr/lib64/python3.10/site-packages/gnuradio/__pycache__
...

gnu radio doesn't run in the kraken environment different python version.

finally 5 channels of gnu-radio data. Ok they don't all fit on screen at once, i don't trust the axis etc. but that's for a different weekend. Pretty sure my intent had been a chunk of FM broadcast band and that looks believable.

Don't trust that i could zap the drive, start from scratch and get back to same point. Though in a few points I might know where to look and in what order to look for various things.

[dennishiding]