I overlooked that, great point. it should probably have read:
sudo apt-mark hold raspberrypi-bootloader
So far as rpi-update use, this should still be viable:
sudo SKIP_KERNEL=1 rpi-update
I am not familiar with how Raspberry handles headers - that’s usually where things go south when pinning upgrades and/or reverting again
EDIT: SKIP_KERNEL is still valid, but not without caveats. Best to read through this for those looking to monkey around:
I am using the rpi-update command. As far as i understand that does a rollback of the kernel only
I haven’t heard back from the original author of the kernel patch, so I reported the problem to the Pi Foundation kernel folks here: librtlsdr performance issues with 5.x kernels from approx 5.4.42 (USB zero-copy related) · Issue #3818 · raspberrypi/linux · GitHub
There is a revertable quite easy way to replace the librtlsdr …
It’s been linked in this thread and fixes the issue no matter which kernel you run.
Apart from manually reverting, Raspbian increments the library version (and probably fixes the issues in librtlsdr by not using zerocopy), the manual intervention will also no longer be relevant.
It uses the osmocom repository or you can just use the precompiled binary from me.
Replace librtlsdr on Raspbian · wiedehopf/adsb-wiki Wiki · GitHub
That’s great, thanks for your support
Tested your solution and i can confirm it works.
Current Kernel:
Linux Raspi3 5.4.59-v7+ #1336 SMP Wed Aug 19 16:03:09 BST 2020 armv7l GNU/Linux
Thanks!
Second device upgraded as well:
After the upgrade i’ve realized a small CPU increase, mainly driven by “USB”. Are you aware of this? Nothing critical, just a side note (screenshot of the graph, change at 10:46)
No clue, maybe it’s missing some fancy optimization the RPi compiled binaries have.
It’s not something i’ve looked into further beyond checking that it brings it to acceptable levels.
No problem. Maybe it is also something which was triggered by the last kernel update itself and not your binaries.
Not that it matters, but there is an apparently harmless difference in your compiled binaries (thanks for doing that!). Below is my CPU utilization first on the older kernel with RPi compiled binaries, then the first blip is after reboot with still the old kernel with your binaries, the final blip is your binaries with the latest kernel from sudo apt dist-upgrade.
I have CPU scaling governor set to Performance on this RPi so ADS-B CPU utilization usually only changes from gain changes or aircraft traffic spikes.I double-check there were no gain changes. (This is using the FA Blue + stick)
Changing from 0.7% to 1.5%
Doesn’t seem to be challenging for the device, or? 
I agree, really appreciated work getting the binaries ready to be used with new kernels as well.
I mean you can just execute a couple more commands and compile specifically for your pi, maybe that adds some optimization.
Replace librtlsdr on Raspbian · wiedehopf/adsb-wiki Wiki · GitHub
Then you don’t need to use what i precompiled.
Oh the pain… Did that. No change.
I’ve been using the latest dump1090 dev branch on my secondary/test/I’m-bored station for a day and half without issues. The USB CPU utilization, on latest kernel, is down by 0.3%, to where it was prior to compiling my own librtlsdr .
Just want to say this worked for me as well, thank you. Exact same problem with RPi 3B+, FA Pro Plus stick, and latest install of Raspbian Buster Lite.
Thanks. The rebuild instructions for librtlsdr worked for me. CPU went from 48% to 17% on a Pi4. I’ll watch what impact that has on my CPU temps.
For others, just remember to install the dependency packages. In particular cmake and libusb-1.0.
Update: Looks like about a 5C drop in CPU temps for me. 66C down to 61C.
Added some dependencies.
I came into the ADSB arena just last week with a Pi Zero W loaded with the FA Image plus FR24 and ADSBExchange.
Apparently with such configuration I’m in the edge of the Pi Zero limits. I experimented some clock inestability and applying the libsdr patch everything appears to work well now, but by reading this thread I’m now a little bit confused about what should be the proper dump1090-fa CPU usage.
I read some people saying their CPU usage (for dump1090-fa) climbed to 40% from 10% due to recent kernel updates.
My question is what CPU % is appropiate for the Pi Zero, I understand that because of it’s reduced specs, a standard 10% usage in a Pi4 maybe equivalent to a 40% usage in a PiZero.
I’m getting a 40% usage (top) on my PiZero, and I don’t know if it’s what it should be or if I should try to revert my kernel to lower it even more.
(BTW, I’m on: Linux piaware 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l GNU/Linux)
That sounds about right with those services running. So long as you are no longer experiencing timing/MLAT issues, you’re good to go. One thing to consider with the PiZ is the USB connection/power - that could also be an issue. I think this is still valid on the PiZero and may help on that end.
sudo sh -c "echo 'max_usb_current=1' >> /boot/config.txt"
.
This also may or may not also help (some will argue both ways):
sudo apt -y install cpufrequtils
sudo sh -c "echo 'GOVERNOR=\"performance\"' > /etc/default/cpufrequtils"
sudo systemctl restart cpufrequtils
I also tend to disable as many other services as possible (wifi/bt if not being used, etc)
I also always use htop instead of top - easier to read in my opinion and sortable.
Traffic and gain will also have an effect on CPU use, etc. It’s been quite awhile since I messed with the Zero with PiAware, but sounds like you are on the right track. As you get more comfortable, you can move to installing the Raspbian Lite (or whatever they choose to call the OS these days), strip it down some and then go the package install route for even more efficiency, but there is a learning curve involved.
Above all, have some fun - it’s great learning on the side.