-
Notifications
You must be signed in to change notification settings - Fork 5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Revert "softirq: Let ksoftirqd do its job"
This reverts commit 4cd13c2.
- Loading branch information
1 parent
8c7e717
commit 0d118e3
Showing
1 changed file
with
1 addition
and
15 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey,
So this commit needs to be reverted if one wants to build a realtime kernel.
Can you explain if this breaks something critical?
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That commit is already reverted (removed, actually) in the rpi-4.14.y-rt kernel branch.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pelwell Cool! Are you guys maintaining rpi-4.14.y-rt? Or are you just playing with it?
I am the maintainer of https://github.com/guysoft/RealtimePi .
Should I just I maintain my patches there? Or do you want people to use this branch?
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are essentially just hosting it for the benefit of our users. @TiejunChina has created it and is maintaining it with our blessing.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sure he would welcome some more interest and help - it makes sense for the RPi RT enthusiasts to work together.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Posted about it here too:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=206750&p=1306688#p1306688
(but personally prefer github to talks, dono why, they just seem more productive).
Sounds like you guys have the kernel and I have the the nightly build system. Would love to have some talk and get this as a steady release which is coordinated. Just say when.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It sounds like the best way forward would be for you to switch to building the rpi-4.14.y-rt branch, feeding back any improvements you have.
The branch model for the
-rt
branch(es) mirrors the way therpi-
branches track upstream. Upstream (Linux) patches are always merged, not rebased. During the bring-up period for a new kernel version downstream patches can be rebased and squashed, but once it goes live we only use fast-forward commits, merging in upstream commits incrementally as they are released.For the
-rt
branch, "upstream" is the appropriaterpi-
branch, sorpi-
commits (and the Linux commits it includes) are always merged, not rebased.0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I pushed this branch (which basically deletes all the locally maintained patches). Waiting for the current new kernel build to finish so I have a nightly build. Then will try to build the rpi-4.14.y-rt branch.
They current build system upside is that its super easy to maintain, but the down is that it can take several hours to build both kernels. Still, since I was never in a hurry I didn't mind waiting.
But would really want to hear what @TiejunChina has to say. I don't want to switch systems without having everyone on the same page.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@guysoft Welcome to contribute -rt branch. @pelwell But actually I didn't revert this since I always think this commit is in standard rpi branch so I keep this in -rt as well. But yes, to be honest, I really don't understand why we have this in standard branch. Unfortunately, this commit didn't provide a long log to explain something. So if you think this doesn't make sense, I would say we can remove this commit from standard branch directly.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TiejunChina At the moment I am maintaining a list of patches that are applied before and after applying the RT patches to a specific commit to the raspberrypi kernel.
Attaching graphic to make it easy to understand:
It makes it easy for me to understand what went in, what didn't against the master of raspberrypi/linux branch.
the usdb-dwc_otg patch is taken from here. And is stored here
The questions is - should I move to what you are doing and expect it to be maintained?
I can contribute, but not maintain your method.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@guysoft
Basically, there are two stages. Here we are talking about rpi-4.14.y vs rpi-4.14.y-rt.
Stage 0: This means rpi-4.14.y was not frozen. At this stage, I applied -rt patches onto the mainline base branch of rpi-4.14.y, and then rebase all patches specific to rpi. If we can get new version of -rt patches, we repeat that step again to make sure we have the latest -rt patches. This our rpi-4.14.y-rt in the beginning.
Stage 1: Once rpi-4.14.y is released, we don't rebase anything. Instead, essentially we only apply -rt delta stuff between last -rt version patches existed in rpi-4.14.y-rt and new -rt version patches. At the same time, we merge rpi-4.14.y regularly and apply any fix specific to -rt.
the usdb-dwc_otg patch was already in rpi-4.14.y-rt in the very beginning.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok,
raspberrypi/linux
and they break something.So I am not really sure which method is better.
Will confess am tempted to just use
rpi-4.14.y-rt
because it means less maintenance on my end.Will RealtimePi benefit you if it uses
rpi-4.14.y-rt
?It would mean users can try out and report bugs directly to both of us.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maintainer should play this role of rebasing this with fixing any conflict.
I think -rt is like sort of another kernel type. Ideally, -rt = mainline Linux base + rt patches + all BSP parches specific to different platform + Any fix to conflict between standard and rt + -rt fix specific to BSP.
What do you want to play here?
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to play here is disro builder. Aka each time there is a new raspbian release or change in the kernel, release an image people can flash.
So you have raspbian, and you have realtime raspbian that was built and tested.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See: http://unofficialpi.org/Distros/RealtimePi/nightly/
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok
Nightly builds of 0.4.0 are pointed to the rpi-4.14.y-rt branch.
Also since the talks here I added an option to export the kernel. So I am also shipping a .tar.gz that includes all you need to install the kernel on a running raspbian distro. Or better yet - write a script that lets you switch between realtime and non-realtime.
So you get:
http://unofficialpi.org/Distros/RealtimePi/nightly/2018-06-28_2018-04-18-realtimepi-stretch-lite-0.4.0.zip
(md5:
6bbc1c3bc5d2d1e51e990660690dff7c
)And:
http://unofficialpi.org/Distros/RealtimePi/nightly/2018-06-28_realtimepi-kernel-4.14.43.tar.gz
For example.
Do we want to post this somewhere outside this small commit thread?
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice - it's good to see this resource being used.
If you want to publicise your service, start a topic in the Advanced Users forum.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: The background for the revert can be found here: https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965
A related discussion can be found on LKML (https://lkml.org/lkml/2018/1/6/252) where Linus suggests an alternative solution (https://lkml.org/lkml/2018/1/8/895), however that hasn't entirely solved the initial problem either.
0d118e3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pelwell
Finally got to posting here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=218939