On my bare metal DragonOS HFDL Airspy HF+ D box with the DumbHFDL wrapper, recently I started seeing this: [348537.394603] dumphfdl[3742670]: segfault at 0 ip 00007a23282096dd sp 00007a22f9ff9f60 error 4 in libuhd.so.4.1.0[7a2327707000+ba8000] likely on CPU 4 (core 0, socket 0)
It happens a bunch of times and when it does, HFDL restarts with a new USB device # and often will crash HFDL if it just repeats this error. I looked up libuhd.so.4.1.0 on the tubes but can't find what error 4 is, othewr trhan looking for the wrong memory block. The file itself exists in /lib. AFIK, the Airspy drivers and dumphfdl do not use that library, so is there something in Dragon using it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please let me know what you’re running command line so I can try to replicate.
The libuhd 4.x is actually the library for ettus/usrp equipment so I’m not sure why it’d be loading up or saying that. If you’re never going to use ettus/usrp you could in theory uninstall libuhd but I’m still curious why in the world it’s even getting used.
On my bare metal DragonOS HFDL Airspy HF+ D box with the DumbHFDL wrapper, recently I started seeing this: [348537.394603] dumphfdl[3742670]: segfault at 0 ip 00007a23282096dd sp 00007a22f9ff9f60 error 4 in libuhd.so.4.1.0[7a2327707000+ba8000] likely on CPU 4 (core 0, socket 0)
It happens a bunch of times and when it does, HFDL restarts with a new USB device # and often will crash HFDL if it just repeats this error. I looked up libuhd.so.4.1.0 on the tubes but can't find what error 4 is, othewr trhan looking for the wrong memory block. The file itself exists in /lib. AFIK, the Airspy drivers and dumphfdl do not use that library, so is there something in Dragon using it?
I understand that libuhd is not supposed to be used with the Airspy. I'm using the dumbHFDL wrapper to run dumphfdl. The startup script is `./dumbhfdl.sh 2>&1 | tee -a ~/airframes_adjacent/dumphfdl/dumb.log
I also see similar errors on a different SBC with an RSP1a, but without the reference to libuhd. That box is dragonos also doing nothing else `[183134.657273] dumphfdl[1652668]: segfault at 10 ip 00005cf605526b37 sp 00007a10937fd750 error 4 in dumphfdl[5cf60551d000+15000] likely on CPU 1 (core 1, socket 0)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand that libuhd is not supposed to be used with the Airspy. I'm using the dumbHFDL wrapper to run dumphfdl. The startup script is `./dumbhfdl.sh 2>&1 | tee -a ~/airframes_adjacent/dumphfdl/dumb.log
I also see similar errors on a different SBC with an RSP1a, but without the reference to libuhd. That box is dragonos also doing nothing else `[183134.657273] dumphfdl[1652668]: segfault at 10 ip 00005cf605526b37 sp 00007a10937fd750 error 4 in dumphfdl[5cf60551d000+15000] likely on CPU 1 (core 1, socket 0)
That’s really interesting and lots going on in there. Out of curiosity, have you found a seg fault manually running dumphfdl directly with a list of frequencies and such? I tried on my end and had it running the past couple days without an issue yet.
I’ll try this project and see if there’s a difference.
I started using dumbhfdl wrapper because I thought that an HF Discovery + (or more than one ) would be more stable that the RSP1a api, which for me crashes pretty often. Right now I am running a test with a RSPia bare metal with the Wiedehoph frequency hopper wrapper against another Dragon box with the Discovery. Same 300' longwire through a Sdrisdberg Engineering RX multi-coupler to the SDRs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On my bare metal DragonOS HFDL Airspy HF+ D box with the DumbHFDL wrapper, recently I started seeing this:
[348537.394603] dumphfdl[3742670]: segfault at 0 ip 00007a23282096dd sp 00007a22f9ff9f60 error 4 in libuhd.so.4.1.0[7a2327707000+ba8000] likely on CPU 4 (core 0, socket 0)
It happens a bunch of times and when it does, HFDL restarts with a new USB device # and often will crash HFDL if it just repeats this error. I looked up libuhd.so.4.1.0 on the tubes but can't find what error 4 is, othewr trhan looking for the wrong memory block. The file itself exists in /lib. AFIK, the Airspy drivers and dumphfdl do not use that library, so is there something in Dragon using it?
Gary,
I have a Airspy HF+ here.
Please let me know what you’re running command line so I can try to replicate.
The libuhd 4.x is actually the library for ettus/usrp equipment so I’m not sure why it’d be loading up or saying that. If you’re never going to use ettus/usrp you could in theory uninstall libuhd but I’m still curious why in the world it’s even getting used.
Sent from Proton Mail for iOS
On Mon, May 27, 2024 at 11:41 PM, Gary McAuliffe <lothar-hill@users.sourceforge.net> wrote:
I understand that libuhd is not supposed to be used with the Airspy. I'm using the dumbHFDL wrapper to run dumphfdl. The startup script is
`./dumbhfdl.sh 2>&1 | tee -a ~/airframes_adjacent/dumphfdl/dumb.logI also see similar errors on a different SBC with an RSP1a, but without the reference to libuhd. That box is dragonos also doing nothing else
`[183134.657273] dumphfdl[1652668]: segfault at 10 ip 00005cf605526b37 sp 00007a10937fd750 error 4 in dumphfdl[5cf60551d000+15000] likely on CPU 1 (core 1, socket 0)Can you shoot me the contents of that wrapper? I’m looking around trying to see where you got it from.
Sent from Proton Mail for iOS
On Wed, May 29, 2024 at 1:13 AM, Gary McAuliffe <lothar-hill@users.sourceforge.net> wrote:
the dumbhfdl wrapper is ay : https://github.com/kuupaork/airframes_adjacent
That’s really interesting and lots going on in there. Out of curiosity, have you found a seg fault manually running dumphfdl directly with a list of frequencies and such? I tried on my end and had it running the past couple days without an issue yet.
I’ll try this project and see if there’s a difference.
Sent from Proton Mail for iOS
On Wed, May 29, 2024 at 7:41 PM, Gary McAuliffe <lothar-hill@users.sourceforge.net> wrote:
I started using dumbhfdl wrapper because I thought that an HF Discovery + (or more than one ) would be more stable that the RSP1a api, which for me crashes pretty often. Right now I am running a test with a RSPia bare metal with the Wiedehoph frequency hopper wrapper against another Dragon box with the Discovery. Same 300' longwire through a Sdrisdberg Engineering RX multi-coupler to the SDRs.
Gary,
I now have the dumphfdl wrapper you shared up and running with the Airspy HF attached to a WarDragon. I'll leave it running as long as I can.
Mahalo!