osmocom-sdr

Download

osmocom-sdr@lists.osmocom.org

January 2026

3 participants
2 discussions

[PATCH] Fix application hang on USB transfer errors
by Ramon Smits 26 Jan '26

26 Jan '26

Hello, I'm submitting a patch that fixes a critical issue where applications using rtlsdr_read_async() hang indefinitely when USB transfer errors occur. ## Background I encountered this issue while running long-term monitoring with rtl_fm for FLEX paging signals. When the RTL-SDR dongle would shift slightly in the USB socket (causing USB transfer errors), rtl_fm would hang indefinitely instead of exiting cleanly. ## Root Cause The problem occurs in two parts: 1. The _libusb_callback() function calls rtlsdr_cancel_async() from within the libusb event handler callback. This creates a race condition where dev->async_cancel is modified while libusb_handle_events_timeout_completed() is actively using it as a parameter, leading to unpredictable behavior. 2. Even when the dev->dev_lost flag is set, the async read loop doesn't properly exit, and applications like rtl_fm have no way to detect that the device is lost. ## Solution The attached patch: - Removes the problematic rtlsdr_cancel_async() call from the callback - Adds detection of dev->dev_lost in the main event loop to properly transition to RTLSDR_CANCELING state - Makes rtlsdr_read_async() return -1 when the device is lost - Updates rtl_fm to check the return value and terminate gracefully ## Testing Tested with RTL2832U dongle (FC0012 tuner) by deliberately triggering USB errors through physical movement. The applications now terminate cleanly with an appropriate error message instead of hanging indefinitely. Normal operation (Ctrl+C termination) continues to work correctly. This fix makes rtl-sdr more robust for long-running monitoring applications and deployment scenarios where physical interference might occur (e.g., Raspberry Pi installations). Please review and consider merging. Best regards, Ramon Smits

2 1

Fwd: Raspberry Pi 5 + RTL-SDR Blog V4 – rtl_* CLI tools produce zero output
by Bodó Richárd 03 Jan '26

03 Jan '26

Subject: Raspberry Pi 5 + RTL-SDR Blog V4 – rtl_* CLI tools produce zero output Dear Developers, I would like to report a reproducible issue observed with a Raspberry Pi 5 and an RTL-SDR Blog V4 device. *Hardware setup:* Raspberry Pi 5 (8 GB) RTL-SDR Blog V4 Direct USB connection (no external hub) Adequate power supply (official Raspberry Pi 5 power supply) *Software environment:* Raspberry Pi OS 64-bit (Bookworm) rtl-sdr package (rtl_sdr, rtl_fm, rtl_power) librtlsdr installed via distribution packages Fully updated kernel and system *Issue description:* rtl_test -p runs successfully USB streaming is active and samples are reported PLL lock messages are shown and the device appears stable *However, the following CLI tools produce no output data:* rtl_sdr rtl_fm rtl_power Output files remain at 0 bytes Processes run without errors, but no IQ samples or audio data are produced *Important observation:* The same RTL-SDR Blog V4 device works correctly on Raspberry Pi 3 and Raspberry Pi 4 systems using the same software stack. *Conclusion:* Based on testing, this appears to be an interaction issue between the Raspberry Pi 5 USB subsystem and/or kernel, librtlsdr, and the RTL-SDR Blog V4. Since rtl_test confirms that USB streaming is functional, the problem seems to occur at the level of sample delivery or processing in the CLI tools. I am happy to provide logs, detailed version information, or perform additional tests if required. Thank you for your time and for maintaining these tools. Kind regards, An RTL-SDR user P.S. My original goal was to develop an Airband (voice) scanner application with the help of ChatGPT, capable of scanning and monitoring airband frequencies. Neither the RTL-SDR Blog V3 nor the V4 worked as expected on the Raspberry Pi 5 during this effort. Based on recommendations, I specifically purchased an RTL-SDR Blog V4 because it was expected to be better aligned with the Raspberry Pi 5 USB implementation. This report is the result of several days of systematic testing and comparison across different Raspberry Pi models. The device enumerates correctly on USB and remains stable during operation. rtl_test confirms continuous sample streaming, indicating that bulk USB transfers are functional. No kernel errors, USB resets, or xHCI faults are observed in dmesg during runtime. The issue appears after device initialization, at the stage where librtlsdr-based tools should consume and process the incoming samples. USB-related kernel and firmware boot parameters were reviewed and adjusted via /boot/firmware/cmdline.txt, including settings related to USB behavior and buffering; these changes did not alter the observed issue. This suggests a possible interaction issue between the Raspberry Pi 5 USB/xHCI implementation, kernel behavior, and librtlsdr buffer handling rather than a physical USB or power problem uname -a lsusb lsusb -t dmesg | grep -i usb rtl_test -p rtl_sdr test.iq rtl_fm -f 118M -M am -s 240k - rtl_power -f 118M:137M:25k test.csv I did not purchase the Raspberry Pi 5 and the RTL-SDR Blog V4 as experimental or disposable hardware. This report is submitted in good faith, with the expectation that this platform can be made fully functional through proper investigation and resolution

1 0