Linux stable vs RT stable and RT dev

Linux stable vs RT stable and RT dev

[Mills, William]

Hello,

I am trying to understand the policy WRT the RT stable branches and the Linux stable releases.
It appears not every Linux stable gets its own RT stable. [1]

What is the goal?  
	Not getting behind by more than X weeks?
	Only change when RT series needs to be updated?
What is the expected consumer model?:
	Use only the version published by the maintainer
	Merge in upstream point release themselves between rt-stable releases
How is the policy different for rt-dev vs rt-stable?

I know Steven wrote up a stable RT maintainer's howto but I did not find it.  Can I get a pointer?
I did find Steven's slides from 2106[2] and skimmed them.

[1] https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.4/older/
[2] https://wiki.linuxfoundation.org/_media/realtime/events/rt-summit2016/how-much-stable-do-we-need_steven-rostedt.pdf

Long version / background
-----------------------------------------------------------------------------------
TI publishes 3 variants of our kernel for customers:
	Base + TI + [Linaro LSK]
	Base + TI + RT
	Base + TI + Android Common

All this is based on the latest GKH LTS and there is maintenance of last years LTS

(Yes we understand this is all very simple if the TI set is nil.  We have never achieved that to date.  In the very least it is backports from tip to latest LTS.  In reality it is more.)

Right now Base above is always the very latest stable from GKH LTS.  It is auto merged as soon as it is published and picked up by our nightly builds.   Any merge conflict in any of the variants stops auto merge progress.

In this structure we tend to be the first to merge RT with a new stable.  Most of the time this is OK but sometimes it is not.

Is it reasonable / expected for us to get ahead of you or should we arrange things to just wait?

I used 4.9 in this example but right now we are executing this on 4.14, 4.9, and (somewhat) 4.4.

Thanks,
Bill

---------------------------------------------------
William A. Mills
Chief Technologist, Open Source
Texas Instruments, Processors
20450 Century Blvd
Germantown MD, 20874
(work/mobile) +1-240-643-0836

Re: Linux stable vs RT stable and RT dev

[Julia Cartwright]

On Fri, Feb 02, 2018 at 07:00:12PM +0000, Mills, William wrote:
> Hello,

Hey Bill-

> I am trying to understand the policy WRT the RT stable branches and
> the Linux stable releases.  It appears not every Linux stable gets its
> own RT stable. [1]

I'm assuming you mean not every Linux stable release gets it's own
stable-rt release, correct?  If so, then you're correct.  Some times
I'll jump a few upstream stable versions if it's been awhile since I did
an upstream merge.

The only guarantee is that the merged upstream stable release is
monotonically increasing.

You can consider a stable-rt release to be a synchronization point
between the upstream stable release process and the rt-devel process.

> What is the goal?
> 	Not getting behind by more than X weeks?
> 	Only change when RT series needs to be updated?

In an ideal world, we could turn around a stable-rt release ontop of an
upstream stable release in the time it takes to test it.  However, we're
not in an ideal world, and merging in an upstream stable release can
and does cause rt-specific regressions.

That being said, we do have a goal to be releasing a new stable-rt
release within a month of an upstream stable release -OR- an rt-devel
tree release with stable-targeted fixes.

> What is the expected consumer model?:
> 	Use only the version published by the maintainer
> 	Merge in upstream point release themselves between rt-stable releases

It's expected that a consumer use the version released by the
maintainer.

Obviously, you're in control of your own destiny here, though.  One
option for you would be to merge in an upstream point release for
testing, then once a maintainer has released a new version, compare the
two.

> How is the policy different for rt-dev vs rt-stable?

I'm not sure it is.

> Long version / background
> -----------------------------------------------------------------------------------
> TI publishes 3 variants of our kernel for customers:
> 	Base + TI + [Linaro LSK]
> 	Base + TI + RT
> 	Base + TI + Android Common
>
> All this is based on the latest GKH LTS and there is maintenance of last years LTS
>
> (Yes we understand this is all very simple if the TI set is nil.  We
> have never achieved that to date.  In the very least it is backports
> from tip to latest LTS.  In reality it is more.)
>
> Right now Base above is always the very latest stable from GKH LTS.
> It is auto merged as soon as it is published and picked up by our
> nightly builds.   Any merge conflict in any of the variants stops auto
> merge progress.
>
> In this structure we tend to be the first to merge RT with a new
> stable.  Most of the time this is OK but sometimes it is not.

Yes, obviously there are many way things can fail that wouldn't trigger
a textual merge conflict.  It's the responsibility of the maintainer to
try to catch these things, or resolve them once they've been found.

What I would like to understand is how you are testing these automerged
branches.

   Julia

Re: Linux stable vs RT stable and RT dev

[William Mills]

Hi Julia,

On 02/02/2018 04:46 PM, Julia Cartwright wrote:
> On Fri, Feb 02, 2018 at 07:00:12PM +0000, Mills, William wrote:
>> Hello,
> 
> Hey Bill-
> 
>> I am trying to understand the policy WRT the RT stable branches and
>> the Linux stable releases.  It appears not every Linux stable gets its
>> own RT stable. [1]
> 
> I'm assuming you mean not every Linux stable release gets it's own
> stable-rt release, correct?  If so, then you're correct.  Some times
> I'll jump a few upstream stable versions if it's been awhile since I did
> an upstream merge.
> 
> The only guarantee is that the merged upstream stable release is
> monotonically increasing.
> 
> You can consider a stable-rt release to be a synchronization point
> between the upstream stable release process and the rt-devel process.
> 
>> What is the goal?
>> 	Not getting behind by more than X weeks?
>> 	Only change when RT series needs to be updated?
> 
> In an ideal world, we could turn around a stable-rt release ontop of an
> upstream stable release in the time it takes to test it.  However, we're
> not in an ideal world, and merging in an upstream stable release can
> and does cause rt-specific regressions.
> 
> That being said, we do have a goal to be releasing a new stable-rt
> release within a month of an upstream stable release -OR- an rt-devel
> tree release with stable-targeted fixes.
> 
>> What is the expected consumer model?:
>> 	Use only the version published by the maintainer
>> 	Merge in upstream point release themselves between rt-stable releases
> 
> It's expected that a consumer use the version released by the
> maintainer.
> 
> Obviously, you're in control of your own destiny here, though.  One
> option for you would be to merge in an upstream point release for
> testing, then once a maintainer has released a new version, compare the
> two.
> 
>> How is the policy different for rt-dev vs rt-stable?
> 
> I'm not sure it is.
> 

Thanks for the answers.  That may be all me need for now and we will
think about this more.

See below.

>> Long version / background
>> -----------------------------------------------------------------------------------
>> TI publishes 3 variants of our kernel for customers:
>> 	Base + TI + [Linaro LSK]
>> 	Base + TI + RT
>> 	Base + TI + Android Common
>>
>> All this is based on the latest GKH LTS and there is maintenance of last years LTS
>>
>> (Yes we understand this is all very simple if the TI set is nil.  We
>> have never achieved that to date.  In the very least it is backports
>> from tip to latest LTS.  In reality it is more.)
>>
>> Right now Base above is always the very latest stable from GKH LTS.
>> It is auto merged as soon as it is published and picked up by our
>> nightly builds.   Any merge conflict in any of the variants stops auto
>> merge progress.
>>
>> In this structure we tend to be the first to merge RT with a new
>> stable.  Most of the time this is OK but sometimes it is not.
> 
> Yes, obviously there are many way things can fail that wouldn't trigger
> a textual merge conflict.  It's the responsibility of the maintainer to
> try to catch these things, or resolve them once they've been found.
> 
> What I would like to understand is how you are testing these automerged
> branches.
> 
>    Julia
> 

+ Carlos (TI integration & test lead) who will correct me if I am wrong
+ Grygorii who actually solves these problems when they come up (and is
a subscriber here anyway)

TI has a pretty extensive test plan.  Not every test is run every night
but the rest is picked up on -rc (~weekly) and by the time of the
release (once per 6 weeks) a full test plan is executed.

Most of our tests are focused on TI drivers and platform code for both
functional and performance regressions.  We do run cyclic test for RT
performance regressions and (I believe) general LTP tests to make sure
we did not break the kernel.  Just the process of running the tests
exercises a good bit of functionality.

It should be a TI TODO to see if there is anything in RT-CI that we
don't already run and incorporate it.

Thanks again,
Bill

Re: Linux stable vs RT stable and RT dev

[Dan Murphy]

Hi Julia

On 02/02/2018 07:20 PM, William Mills wrote:
> Hi Julia,
> 
> On 02/02/2018 04:46 PM, Julia Cartwright wrote:
>> On Fri, Feb 02, 2018 at 07:00:12PM +0000, Mills, William wrote:
>>> Hello,
>>
>> Hey Bill-
>>
>>> I am trying to understand the policy WRT the RT stable branches and
>>> the Linux stable releases.  It appears not every Linux stable gets its
>>> own RT stable. [1]
>>
>> I'm assuming you mean not every Linux stable release gets it's own
>> stable-rt release, correct?  If so, then you're correct.  Some times
>> I'll jump a few upstream stable versions if it's been awhile since I did
>> an upstream merge.
>>
>> The only guarantee is that the merged upstream stable release is
>> monotonically increasing.
>>
>> You can consider a stable-rt release to be a synchronization point
>> between the upstream stable release process and the rt-devel process.
>>
>>> What is the goal?
>>> 	Not getting behind by more than X weeks?
>>> 	Only change when RT series needs to be updated?
>>
>> In an ideal world, we could turn around a stable-rt release ontop of an
>> upstream stable release in the time it takes to test it.  However, we're
>> not in an ideal world, and merging in an upstream stable release can
>> and does cause rt-specific regressions.
>>
>> That being said, we do have a goal to be releasing a new stable-rt
>> release within a month of an upstream stable release -OR- an rt-devel
>> tree release with stable-targeted fixes.
>>
>>> What is the expected consumer model?:
>>> 	Use only the version published by the maintainer
>>> 	Merge in upstream point release themselves between rt-stable releases
>>
>> It's expected that a consumer use the version released by the
>> maintainer.
>>
>> Obviously, you're in control of your own destiny here, though.  One
>> option for you would be to merge in an upstream point release for
>> testing, then once a maintainer has released a new version, compare the
>> two.
>>
>>> How is the policy different for rt-dev vs rt-stable?
>>
>> I'm not sure it is.
>>
> 
> Thanks for the answers.  That may be all me need for now and we will
> think about this more.
> 
> See below.
> 
>>> Long version / background
>>> -----------------------------------------------------------------------------------
>>> TI publishes 3 variants of our kernel for customers:
>>> 	Base + TI + [Linaro LSK]
>>> 	Base + TI + RT
>>> 	Base + TI + Android Common
>>>
>>> All this is based on the latest GKH LTS and there is maintenance of last years LTS
>>>
>>> (Yes we understand this is all very simple if the TI set is nil.  We
>>> have never achieved that to date.  In the very least it is backports
>>> from tip to latest LTS.  In reality it is more.)
>>>
>>> Right now Base above is always the very latest stable from GKH LTS.
>>> It is auto merged as soon as it is published and picked up by our
>>> nightly builds.   Any merge conflict in any of the variants stops auto
>>> merge progress.
>>>
>>> In this structure we tend to be the first to merge RT with a new
>>> stable.  Most of the time this is OK but sometimes it is not.
>>
>> Yes, obviously there are many way things can fail that wouldn't trigger
>> a textual merge conflict.  It's the responsibility of the maintainer to
>> try to catch these things, or resolve them once they've been found.
>>
>> What I would like to understand is how you are testing these automerged
>> branches.
>>
>>    Julia
>>
> 
> + Carlos (TI integration & test lead) who will correct me if I am wrong
> + Grygorii who actually solves these problems when they come up (and is
> a subscriber here anyway)
> 
> TI has a pretty extensive test plan.  Not every test is run every night
> but the rest is picked up on -rc (~weekly) and by the time of the
> release (once per 6 weeks) a full test plan is executed.
> 
> Most of our tests are focused on TI drivers and platform code for both
> functional and performance regressions.  We do run cyclic test for RT
> performance regressions and (I believe) general LTP tests to make sure
> we did not break the kernel.  Just the process of running the tests
> exercises a good bit of functionality.
> 
> It should be a TI TODO to see if there is anything in RT-CI that we
> don't already run and incorporate it.
> 
> Thanks again,
> Bill
> 

In addition to functional testing we compile test ~57 variations of defconfigs.
We are catching warnings and errors with these defconfigs.  I have reported 2 warnings but
I have not received a response.  I guess I should report these to this list as opposed to the maintainers.

We have a "next" process that runs nightly that merges in the stable rc candidate into our branch
so we can anticipate if the new stable or TI developer branches will cause a merge conflict when merged into our branch sets.

For instance 4.14.17 stable rc caused a merge conflict in the hrtimer.c file. This became a known issue as soon as the stable rc was
available.  The RT 4.14 upstream branch is currently on 4.14.15 so now our RT branch is blocked from receiving a new stable until the
RT upstream branch is updated.

We do not attempt to resolve merge conflicts, unless they are minor, on kernel files that are modified by RT patches.
These conflicts usually happen when the RT branch is in development, once it migrates to the stable repo we see very little
conflicts.

We can create a Jenkins job that can take the RT development branch and merge in GKH stable rc and report any merge conflicts.
We can send it to the list or if there was a maintainer that would like to see this that would be great.

Let me know I can throw something together based on our auto merge scripts we have now.

Dan

-- 
------------------
Dan Murphy

Re: Linux stable vs RT stable and RT dev

[Sebastian Andrzej Siewior]

On 2018-02-05 15:17:56 [-0600], Dan Murphy wrote:
> We are catching warnings and errors with these defconfigs.  I have reported 2 warnings but
> I have not received a response.  I guess I should report these to this list as opposed to the maintainers.

You reported two warnings to my private address while I was traveling.
The usual workflow for reporting is to send this to the mailing list and
Cc the RT maintainer(s) (which would contain the email address I am
using right now).

> We have a "next" process that runs nightly that merges in the stable rc candidate into our branch
> so we can anticipate if the new stable or TI developer branches will cause a merge conflict when merged into our branch sets.
> 
> For instance 4.14.17 stable rc caused a merge conflict in the hrtimer.c file. This became a known issue as soon as the stable rc was
> available.  The RT 4.14 upstream branch is currently on 4.14.15 so now our RT branch is blocked from receiving a new stable until the
> RT upstream branch is updated.

I usually do a new release once I have something in my pipe or if people
ask to update new stable due to $reason.

> Dan

Sebastian

Re: Linux stable vs RT stable and RT dev

[Dan Murphy]

Sebastian

On 02/06/2018 08:34 AM, Sebastian Andrzej Siewior wrote:
> On 2018-02-05 15:17:56 [-0600], Dan Murphy wrote:
>> We are catching warnings and errors with these defconfigs.  I have reported 2 warnings but
>> I have not received a response.  I guess I should report these to this list as opposed to the maintainers.
> 
> You reported two warnings to my private address while I was traveling.
> The usual workflow for reporting is to send this to the mailing list and
> Cc the RT maintainer(s) (which would contain the email address I am
> using right now).

Agreed sorry for that.  I sent the issues before I got the mail list information.

> 
>> We have a "next" process that runs nightly that merges in the stable rc candidate into our branch
>> so we can anticipate if the new stable or TI developer branches will cause a merge conflict when merged into our branch sets.
>>
>> For instance 4.14.17 stable rc caused a merge conflict in the hrtimer.c file. This became a known issue as soon as the stable rc was
>> available.  The RT 4.14 upstream branch is currently on 4.14.15 so now our RT branch is blocked from receiving a new stable until the
>> RT upstream branch is updated.
> 
> I usually do a new release once I have something in my pipe or if people
> ask to update new stable due to $reason.
> 

OK.  I see the stable RT tree for 4.9 gets updated with every GKH stable release.
Since RT touches kernel files would it be advantageous to keep the development branch up to date until
especially if we still have RT patches?  Or at the very least if there is an upcoming merge conflict to update and resolve on the RT
development branch when we know?

This is where we can put an automated job in place to merge GKH rc stable into the RT branch and report only upcoming merge conflicts.
Then no one actually has to report or ask it would just be assumed?

Dan

>> Dan
> 
> Sebastian
> 


-- 
------------------
Dan Murphy

Re: Linux stable vs RT stable and RT dev

[Steven Rostedt]

On Tue, 6 Feb 2018 09:47:15 -0600
Dan Murphy <dmurphy@ti.com> wrote:

> This is where we can put an automated job in place to merge GKH rc
> stable into the RT branch and report only upcoming merge conflicts.
> Then no one actually has to report or ask it would just be assumed?

I'd be careful about this. There's a few (not many) subtle changes that
get backported to stable that can break RT. You wont be able to notice
it with compiling, but it can cause deadlocks in certain scenarios.

-- Steve

Re: Linux stable vs RT stable and RT dev

[Dan Murphy]

Steve

On 02/06/2018 10:17 AM, Steven Rostedt wrote:
> On Tue, 6 Feb 2018 09:47:15 -0600
> Dan Murphy <dmurphy@ti.com> wrote:
> 
>> This is where we can put an automated job in place to merge GKH rc
>> stable into the RT branch and report only upcoming merge conflicts.
>> Then no one actually has to report or ask it would just be assumed?
> 
> I'd be careful about this. There's a few (not many) subtle changes that
> get backported to stable that can break RT. You wont be able to notice
> it with compiling, but it can cause deadlocks in certain scenarios.
> 

We agree merge conflicts are only half the battle.  I guess I was not clear that the auto
merge would not be distributed or even public it would just be informative.

It would just be a test for merge conflicts.  And maybe build errors/warnings if we had a limited set
of defconfig options.

Again the merge would be informative so we would know that the Linux stable will merge cleanly or not.
If there was a conflict then that could trigger the merging of the stable into the RT branch to
help the community consumers of the RT branch.

Dan


> -- Steve
> 


-- 
------------------
Dan Murphy

Re: Linux stable vs RT stable and RT dev

[Sebastian Andrzej Siewior]

On 2018-02-06 09:47:15 [-0600], Dan Murphy wrote:
> Sebastian
Hi Dan,

> Agreed sorry for that.  I sent the issues before I got the mail list information.

You complained about two warnings. For number one I cherry-picked
15f7b41f70dd ("brd: remove unused brd_mutex"). 

The other thing was a warning in
pl011_console_write::drivers/tty/serial/amba-pl011.c the flags member. I
have here:

    CC      drivers/tty/serial/amba-pl011.o

with gcc version 7.3.0 (Debian 7.3.0-1). Looking at the code, flags is
not be initialized in the uap->port.sysrq case but it is also not used.
So it is a compiler thing and not a bug. There is the same pattern in
the 8250 UART or the omap-serial driver. If you care enough to get this
one fixed, please send a patch.

Sebastian

Re: Linux stable vs RT stable and RT dev

[Dan Murphy]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

Sebastian

On 02/09/2018 11:39 AM, Sebastian Andrzej Siewior wrote:
> On 2018-02-06 09:47:15 [-0600], Dan Murphy wrote:
>> Sebastian
> Hi Dan,
> 
>> Agreed sorry for that.  I sent the issues before I got the mail list information.
> 
> You complained about two warnings. For number one I cherry-picked
> 15f7b41f70dd ("brd: remove unused brd_mutex"). 
> 

Great thanks.  I did see a LKML patch for this but it was old not sure if it was reposted or
reported to the list.

> The other thing was a warning in
> pl011_console_write::drivers/tty/serial/amba-pl011.c the flags member. I
> have here:
> 
>     CC      drivers/tty/serial/amba-pl011.o
> 
> with gcc version 7.3.0 (Debian 7.3.0-1). Looking at the code, flags is
> not be initialized in the uap->port.sysrq case but it is also not used.

I was using 7.2 gcc compiler distributed via Linaro.

> So it is a compiler thing and not a bug. There is the same pattern in
> the 8250 UART or the omap-serial driver. If you care enough to get this
> one fixed, please send a patch.

Hmmm I wonder why the compiler does not complain about this warning then.

I will look into it.  This warning has been around for a while (4.9-rt as well).

We also noticed that there are 2 merge conflicts when going to 4.14.18.
Any comments about providing a merge conflict email to the list?

Attached is the merge conflicts we are seeing 4.14.15-> 4.14.18

Dan

> 
> Sebastian
> 


-- 
------------------
Dan Murphy

[-- Attachment #2: linux_base_rt_merge_conflict.txt --]
[-- Type: text/plain, Size: 4115 bytes --]

diff --cc arch/x86/include/asm/thread_info.h
index 4721692,eda3b68..0000000
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@@ -55,8 -55,7 +55,12 @@@ struct task_struct
  
  struct thread_info {
  	unsigned long		flags;		/* low level flags */
++<<<<<<< HEAD
 +	int                     preempt_lazy_count;     /* 0 => lazy preemptable
 +							   <0 => BUG */
++=======
+ 	u32			status;		/* thread synchronous flags */
++>>>>>>> e94830efe7587ed0b733341934aca406edeaccc8
  };
  
  #define INIT_THREAD_INFO(tsk)			\
diff --cc kernel/time/hrtimer.c
index fb3413d,052773d..0000000
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@@ -649,32 -587,77 +649,39 @@@ hrtimer_force_reprogram(struct hrtimer_
  	tick_program_event(cpu_base->expires_next, 1);
  }
  
 +/* High resolution timer related functions */
 +#ifdef CONFIG_HIGH_RES_TIMERS
 +
  /*
 - * When a timer is enqueued and expires earlier than the already enqueued
 - * timers, we have to check, whether it expires earlier than the timer for
 - * which the clock event device was armed.
 - *
 - * Called with interrupts disabled and base->cpu_base.lock held
 + * High resolution timer enabled ?
   */
 -static void hrtimer_reprogram(struct hrtimer *timer,
 -			      struct hrtimer_clock_base *base)
 -{
 -	struct hrtimer_cpu_base *cpu_base = this_cpu_ptr(&hrtimer_bases);
 -	ktime_t expires = ktime_sub(hrtimer_get_expires(timer), base->offset);
 -
 -	WARN_ON_ONCE(hrtimer_get_expires_tv64(timer) < 0);
 -
 -	/*
 -	 * If the timer is not on the current cpu, we cannot reprogram
 -	 * the other cpus clock event device.
 -	 */
 -	if (base->cpu_base != cpu_base)
 -		return;
 -
 -	/*
 -	 * If the hrtimer interrupt is running, then it will
 -	 * reevaluate the clock bases and reprogram the clock event
 -	 * device. The callbacks are always executed in hard interrupt
 -	 * context so we don't need an extra check for a running
 -	 * callback.
 -	 */
 -	if (cpu_base->in_hrtirq)
 -		return;
 -
 -	/*
 -	 * CLOCK_REALTIME timer might be requested with an absolute
 -	 * expiry time which is less than base->offset. Set it to 0.
 -	 */
 -	if (expires < 0)
 -		expires = 0;
 -
 -	if (expires >= cpu_base->expires_next)
 -		return;
 -
 -	/* Update the pointer to the next expiring timer */
 -	cpu_base->next_timer = timer;
 -
 -	/*
 -	 * If a hang was detected in the last timer interrupt then we
 -	 * do not schedule a timer which is earlier than the expiry
 -	 * which we enforced in the hang detection. We want the system
 -	 * to make progress.
 -	 */
 -	if (cpu_base->hang_detected)
 -		return;
 +static bool hrtimer_hres_enabled __read_mostly  = true;
 +unsigned int hrtimer_resolution __read_mostly = LOW_RES_NSEC;
 +EXPORT_SYMBOL_GPL(hrtimer_resolution);
  
 -	/*
 -	 * Program the timer hardware. We enforce the expiry for
 -	 * events which are already in the past.
 -	 */
 -	cpu_base->expires_next = expires;
 -	tick_program_event(expires, 1);
 +/*
 + * Enable / Disable high resolution mode
 + */
 +static int __init setup_hrtimer_hres(char *str)
 +{
 +	return (kstrtobool(str, &hrtimer_hres_enabled) == 0);
  }
  
 +__setup("highres=", setup_hrtimer_hres);
 +
  /*
 - * Initialize the high resolution related parts of cpu_base
 + * hrtimer_high_res_enabled - query, if the highres mode is enabled
   */
 -static inline void hrtimer_init_hres(struct hrtimer_cpu_base *base)
 +static inline int hrtimer_is_hres_enabled(void)
  {
++<<<<<<< HEAD
 +	return hrtimer_hres_enabled;
++=======
+ 	base->expires_next = KTIME_MAX;
+ 	base->hang_detected = 0;
+ 	base->hres_active = 0;
+ 	base->next_timer = NULL;
++>>>>>>> e94830efe7587ed0b733341934aca406edeaccc8
  }
  
  /*
@@@ -1900,13 -1593,9 +1907,14 @@@ int hrtimers_prepare_cpu(unsigned int c
  		timerqueue_init_head(&cpu_base->clock_base[i].active);
  	}
  
+ 	cpu_base->active_bases = 0;
  	cpu_base->cpu = cpu;
 -	hrtimer_init_hres(cpu_base);
 +	cpu_base->hres_active = 0;
 +	cpu_base->expires_next = KTIME_MAX;
 +	cpu_base->softirq_expires_next = KTIME_MAX;
 +#ifdef CONFIG_PREEMPT_RT_BASE
 +	init_waitqueue_head(&cpu_base->wait);
 +#endif
  	return 0;
  }
  

Re: Linux stable vs RT stable and RT dev

[Sebastian Andrzej Siewior]

On 2018-02-09 12:59:43 [-0600], Dan Murphy wrote:
> Sebastian
HI Dan,

> Hmmm I wonder why the compiler does not complain about this warning then.
> 
> I will look into it.  This warning has been around for a while (4.9-rt as well).

probably once the local_irq_save() was removed.

> We also noticed that there are 2 merge conflicts when going to 4.14.18.
> Any comments about providing a merge conflict email to the list?

I am not sure about how helpful this actually is. Usually I do a RT
release a week while I have stuff in my pipe. Currently Greg is
releasing a lot. On the other hand it is almost two weeks since my last
release.

> Attached is the merge conflicts we are seeing 4.14.15-> 4.14.18

In meantime I already uploaded the patch queue for v4.14.18-rt14.
I plan to sync with Steven's tracing then release -rt15 probably later
today.

> Dan

Sebastian

Re: Linux stable vs RT stable and RT dev

[Dan Murphy]

Sebastian

On 02/09/2018 01:30 PM, Sebastian Andrzej Siewior wrote:
> On 2018-02-09 12:59:43 [-0600], Dan Murphy wrote:
>> Sebastian
> HI Dan,
> 
>> Hmmm I wonder why the compiler does not complain about this warning then.
>>
>> I will look into it.  This warning has been around for a while (4.9-rt as well).
> 
> probably once the local_irq_save() was removed.
> 
>> We also noticed that there are 2 merge conflicts when going to 4.14.18.
>> Any comments about providing a merge conflict email to the list?
> 
> I am not sure about how helpful this actually is. Usually I do a RT
> release a week while I have stuff in my pipe. Currently Greg is
> releasing a lot. On the other hand it is almost two weeks since my last
> release.

For us it is helpful to have the experts resolve these stable->rt conflicts that occur
in the base kernel files.  At least if there is a merge conflict that will occur this
could be the "stuff" in your pipe.  If there were no merge conflicts detected for upcoming
merges there would be no expectation to move quicker.

I mean GKH 4.14.19 is coming on Monday it may be better just to wait for that to be released
then merge that in.  There were only 22 patches added to 4.14.19 so it should be minimal.

Dan

> 
>> Attached is the merge conflicts we are seeing 4.14.15-> 4.14.18
> 
> In meantime I already uploaded the patch queue for v4.14.18-rt14.
> I plan to sync with Steven's tracing then release -rt15 probably later
> today.
> 
>> Dan
> 
> Sebastian
> 


-- 
------------------
Dan Murphy