-
Notifications
You must be signed in to change notification settings - Fork 5.2k
RT patch for stable releases #2244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Although the current Raspbian Stretch release comes with 4.9.41 there should not be any hard dependencies on a particular kernel version. The rpi-update repo hosts hundreds of kernel versions (full list available here - notice the hexadecimal numbers identifying each release), a large number of which should work with Stretch. I suggest you use rpi-update to choose a 4.9.47 kernel:
Check that the kernel works (except without the RT support), then locate the corresponding point in the source tree - commit 807c5d9 ought to be OK - and apply the 4.9.47 patch. |
I did try your suggestion couple weeks ago and ran into issues of random sluggishness. Also when building my project it used to hang up. Today I started again from scratch with a fresh copy of Raspbian. After upgrading to v4.9.47 kernel using rpi-update, I did not see sluggishness and was able to compile my project (basically just compiling AVS device sdk from: https://github.com/alexa/avs-device-sdk/wiki/Raspberry-Pi-Quick-Start-Guide). After applying the RT patch, things still appear to work but when compiling my project again (using stock gcc) it randomly hangs in the middle, just as I saw before. After a reboot I found that some of the object files and a library were 0 bytes in size. After I removed these, I was able to complete building. If I recompile from scratch I am pretty sure it will hang again. Something is not right, which gets magnified when applying the RT patch. |
Is the Pi perhaps running out of memory and spending all its time swapping? Check the SDK Makefile and looks for I'm happy to leave this issue open for others to see and comment on, but I'm afraid we can't support the RT patch series - we have more than enough to do with mainline Linux. |
@az2022 Just for curiosity, what prevents you from using a mainline kernel + RT patches? |
@lategoodbye My Pi3 randomly hangs up. |
@az2022, @pelwell https://www.osadl.org/Single-View.111+M5c03315dc57.0.html https://autostatic.com/2017/06/27/rpi-3-and-the-real-time-kernel/ This could be easily fixed if you guys incorporate the fix to the Pi kernel sources. @az2022 : try these kernel parameters
and your Pi shouldn't hang when using the RT patches. It's a "workaround", not a solution. We need the kernel guys to incorporate the fix or manually apply the FIQ patch into upstream. It's a know problem in the linux foundation: Also, here are detailed instructions (not by me!) and a ready-to-use kernel: |
I presume you mean this patch? Any comments, @P33M ? |
@pelwell You could easily have an RT branch... there's a lot of demand for RT kernels on the Raspberry, and finding matching RT patches is not easy. |
Currently the FIQ lock is held only within the IRQ handler, which implies no other IRQs can preempt the dwc_otg interrupt and the driver-specific spinlock is held. I suppose that adding a "real" IRQ save/restore would be harmless in the non-RT case. The latency graph on the autostatic.com site is interesting. If the upper bound for latency is 75uS then this approaches the required hard-realtime horizon for some of the USB usecases - high-speed Isochronous transfers in particular. We know that even with the FIQ helping, it's possible to miss scheduling isochronous transfers at the boundary of every URB as this requires manipulating software queues. If RT makes this problem go away, then it'd be an interesting avenue to explore. |
@P33M: Would that improve USB HID input latency? |
No. The dwc_otg driver doesn't know about scheduling constraints higher up in the USB stack. By default we restrict HID mouse polling to 60Hz to reduce the Xserver load on BCM2835-based devices, so setting usbhid.mousepoll=0 in cmdline.txt will restore the default polling interval. |
@P33M Also, a basic question I have been asking myself these days, and maybe you can answer because I can't find the information: usb joysticks and mice are accessed through the modern evdev interface in all low-latency APIs available on the Pi, like SDL2 and LibRetro/RetroArch. They all use evded. (X11 is not important for this matter). |
@vanfanel Spot on. For a quick check I applied the command line arguments and I have not been able to reproduce the problem for 2+ hours now, which is very encouraging! Will leave it for over night test. |
I'd be interested in "RT-ready" RPi kernels, too. Running https://autostatic.com/2017/06/27/rpi-3-and-the-real-time-kernel/ for a few projects now, and currently trying to update to the latest 4.9-rt. It would be a huge help if the lockup workaround was in RPi-linux mainline if it doesn't harm the common usecases (or is even beneficial). Willing to test... |
Setting kernel paramaters, dwc_otg.fiq_enable=0, dwc_otg.fiq_fsm_enable=0 works well with both keyboard and mice but after some testing noticed it made my USB mic unusable. Applied the usb-fiq patch and rebuilt, USB mic now works. |
I'm just building a kernel from 4.9.61 (current HEAD) with https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.47-rt37.patch.gz and https://github.com/fedberry/kernel/blob/master/usb-dwc_otg-fix-system-lockup-when-interrupts-are-threaded.patch. All NEW options with default answer, full preemption, HZ=1000, one implicit declaration error (removed -Werror-implicit-function-declaration for now). Seems to compile, will test tomorrow. Update: this attempt did not work. Sorry for getting back to this so late... |
What is the current status of this issue? Should it be closed? |
Maybe we should open another issue requesting that just the FIQ patch is merged into RPi mainline? So that the RT patch can be applied out-of-the-box.... |
Sorry about the delayed response. Perhaps the issue could be well published/documented where users could immediately notice and choose whether to apply the USB patch or not. For a long term solution a RT ready image with the USB patch would be nice, but I understand the resource shortage as well. |
I got a recent RT kernel running on a Raspi 3.
I adapted the instructions from here: http://ffall007.16mb.com/post/applying-preempt-rt-kernel-patch-on-raspberry-pi/
I could not compile a later version, because of this patch:
Then follow the "normal" compilation and installation instructions for a RT kernel. |
I'd like to introduce -rt branch, and I'm planning to maintain this as well. https://github.com/TiejunChina/linux/tree/rpi-4.14.y-rt This is based on rpi-4.14.y but with the latest v4.14.20-rt17. This can boot on pi3, $ uname -a I also did cyclictest as well. @pelwell , You know, we also had a little bit of discussion on this previously. Please let me know how to put this into official raspberrypi/linux. |
The first Raspberry Pi PREEMPT_RT kernel branch went live this morning: https://github.com/raspberrypi/linux/tree/rpi-4.14.y-rt Thank you for your efforts and continuing support, @TiejunChina. |
Amazing! Thanks to all contributors! Can't wait to try this one out. |
Thanks for maintaining this, will save me some patching time. Out of curiosity, have you been able to run this on an armv6 device, with FIQ enabled? It will run with FIQ disabled, but suffers from all of the pre-fiq usb problems. |
@paul-1 Sorry, I have no armv6 device in my hand. I will try to get access to that later. But now, what is that problem? Is that a lockup issue? |
Just hangs during boot. There are no kernel panics/oops. |
@paul-1 Would like to try this branch? |
@TiejunChina I've been trying to build a working kernel out of your branch for over a week now. But I just can't get it to boot properly. I have posted more details in this forum thread, it would be nice if you could take a look at it: https://www.raspberrypi.org/forums/viewtopic.php?f=71&t=205604&p=1281396&sid=add236ca46e8f3ca05b9614a56f374d1#p1281396 |
It's on my list to look at - probably this afternoon. |
Try adding |
I just compiled the latest git rt-kernel branch. (I've been maintaining rt-kernels for Moode-Audio for a while) dwc_otg related cmdline.txt options are: cyclictest looks OK: However. The old and known dwc_otg load up2 as seen below 11.2% issue 149 root -51 0 0 0 0 R 11.2 0.0 1:05.54 irq/39-dwc2_hso As you can see I also tried the dwc2 overlay as suggested by pelwell. Any ideas how to approach the subject? |
One more: I forgot. I'm talking about: Below the loads with the dwc2 overlay removed again. 80 root -51 0 0 0 0 S 11.8 0.0 0:23.99 irq/39-dwc_otg_ I also tried to remove dwc_otg options from cmdline.txt. - now with the new kernel in place. |
@Soundchekk I think you should first check if you rpi is always receiving irq/39-dwc_otg, like |
I did some more testing. TC1: Average dwc_otg interrupts: 8164 /s TC2: Average dwc_otg interrupts: 274 /s ######## Average dwc_otg interrupts: 8244 /s TC4: Average dwc_otg interrupts: X /s Testcase TC4 failed because lock-up at boot! Lock-up occurs during printout of USB init messages. ################## Bottom line. Still. Don't know yet why my setup locks up (around USB dev init) when booting TC4. @ |
@Soundchekk Sorry for this delay response. Could you try the latest rpi-4.14.y-rt? I validated this on my side with pi3 mode B where I preinstalled ubuntu mate 16.04.2. I think your TC4 should work now. |
with 4.14.27-rt19-sc1 TC5:
Perhaps you should have merged latest 4.14.27-rt21 patch. Thx for looking into it. |
@Soundchekk Yes, I'm working on merging -rt21. I'm always curious why we have so many interrupts even in the case of none-rt. You know, that means threaded irq always spikes on CPU for a while, as you obverse. |
After many years of handcrafting RT kernels for Pi, even just for "normal" use cases, I might finally be able to let go of this occupation :) |
@andreasBihlmaier Thanks. We are still working on some known issues but any contributions are welcome. |
Dear all, I have been trying for days to build and boot this real time kernel on a Pi Zero W. However... I'm running into a strange problem during boot. When it gets to systemd, it kind of hangs. I mean it takes about 30 seconds to move to the next boot step as you can see in the attached boot log below. It goes on like this for a while (every 30 seconds a new message line) and in the end it just hangs... If anyone has any idea what might cause this, please let me know. These are my cmdline and config files... Thank you in advance, cmdline.txt dwc_otg.lpm_enable=0 console=tty1 console=serial0,115200 root=PARTUUID=cb4a1ae3-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait dwc_otg.fiq_fsm_enable=0 dwc_otg.fiq_enable=0 dwc_otg.nak_holdoff=0 config.txt avoid_safe_mode=1 dtparam=i2c1_baudrate=400000 Boot log [ 0.000000] Booting Linux on physical CPU 0x0 |
@jarodsmith Before we take a close look at your issue, please use the latest -rt branch version. Your -rt version is 4.14.22-rt17 is sort of outdated. |
Thank you for the answer. I have cloned and built the latest branch 4.14.31-rt25+ I get exactly the same behaviour... Please see boot log below. I would really appreciate it if you could help with this. [ 0.000000] Booting Linux on physical CPU 0x0 |
@jarodsmith This is another similar thing to #2424 since we can see "Disabling IRQ #53" here as well. @pelwell is working on this. |
Just built 4.14.52-rt34, and it is now booting just fine on a RPi0 & RPi0W |
@paul-1 Sounds good :) |
I have "raspberrypi 4.14.52-rt34-v7+ #1 SMP PREEMPT RT" running stable with kernel parameters "dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0" or device tree overlay "dtoverlay=dwc2", but audio recordings from my USB sound card (C-Media Electronics, Inc.) are of poor quality (stuttering, noise, etc.). |
Upgrade to the latest kernel, and then remove the fiq stuff from the command line. The latest kernel has patches to fix the fiq problems. |
Use a standard kernel if you don't really know what you're doing. Trying to use a rt-kernel properly on the Pi is trying to tune a 20 strings guitar by ear. E.g. Using a USB DAC and network at the same time usually causes severe hickups if the entire There's more. Not to be discussed over here I'd say. Except there'd be a real issue associated. |
I've updated to Linux raspberrypi 4.14.59-rt37-v7+ #4 SMP PREEMPT RT, removed the fiq stuff and now the kernel doesn't freeze that quickly. |
@FischC Could you try the latest rpi-4.14.y-rt? If you still can reproduce that problem, please ping me again. But just sorry, I will probably not respond that timely because I will have a business travel this week. |
@TiejunChina I've tested with Linux "raspberrypi 4.14.66-rt40-v7+ #6 SMP PREEMPT RT Tue Aug 28 13:54:36 CEST 2018 armv7l GNU/Linux" and I can still reproduce the problem. Shall I create a new ticket? |
@FischC Please, go ahead. |
I'd like to close this issue since we have had our -rt branch for a while. |
With the app I work on, one of the requirement is to use Raspbian kernel with real-time patch applied. It has become an issue of finding a match to what kernel version is released by raspberry-pi org and which kernel version patch is released by kernel.org (https://www.kernel.org/pub/linux/kernel/projects/rt/). Lot of times they don't match, for e.g. I got the latest Raspbian (Stretch) which hosts kernel v4.9.41 while the real time patch is available for 4.9.40 and 4.9.47. I checked-out Raspbian source commit available right after 4.9.47 was committed to the source tree, applied RT patch and built. Everything went well and Pi3 boots fine, but sometimes hangs when apps (for e.g. gitk) are started or midway of a gcc build. Understandably Raspbian was not released with 4.9.47 but I had to try! Bottom line, it would be nice to have a RT patch available for the released/stable Rapbian images, unless there's a way around this? :)
The text was updated successfully, but these errors were encountered: