On Thu, May 14, 2020 at 6:15 AM Dragomir, Daniel
<[email protected]> wrote:
>
> Hello Bruce!
>
> I'm planning to send some patches for AXXIA branches for 4.9 linux-yocto
> kernels (also some for 4.1).
>
> First, it is still allowed to send patches for those old kernels?
>
> Then, when preparing the AXXIA patches against the latest tag (v4.9.202) for
> the preempt-rt branch (standard/preempt-rt/axxia/base) from
> git://git.yoctoproject.org/linux-yocto-4.9 repo, I get a lot of build errors.
>
> I also tried a clean poky build for qemuarm machine with linux-yocto-rt_4.9
> building the latest v4.9.202 tag from standard/preempt-rt/base branch and get
> the same errors. By default, 4.9 linux-yocto-rt recipe from poky (rocko
> branch) uses v4.9.113 version which builds ok.
>
> It's possible that some of the errors cames from some merge failures:
> - when v4.9.163 tag wes merged to the standard/preempt-rt/base branch. There
> were some extra changes in the merge commit
> 34a0f925427864bc92a556a533a73a12247709f4 ("Merge branch 'standard/base' into
> standard/preempt-rt/base") meant to fix merge conflicts maybe, but the
> changes to kernel/locking/rtmutex.c brings build errors
> - when v4.9.176 tag was merged to the standard/preempt-rt/base branch. There
> were some extra changes in the merge commit
> 369744f8022767ea2c1b6ca32f8249f5bdb1ce80 ("Merge branch 'standard/base' into
> standard/preempt-rt/base") meant to fix merge conflicts maybe, but the
> changes to kernel/cpu.c brings build errors
>
> The latest good tag I found is v4.9.162.
>
> Which is the best approach for this: working to fix all those failures in new
> commits on top of v4.9.202 even if this is an EOL kernel for yocto, or should
> we reset preempt-rt branches (axxia ones at least) to v4.9.162 version?
I'm still merging changes to those kernels, but they don't get the
normal set of build/boot tests that I do on newer kernels, hence why
things like this can slip through.
So in this case, incremental patches would be best. That way the
history is maintained fast forward.
>
> Here are some of the errors I get on qemuarm build:
>
> tmp/work-shared/qemuarm/kernel-source/kernel/cpu.c:1118:6: error:
> redefinition of 'set_cpu_possible'
> void set_cpu_possible(unsigned int cpu, bool possible
>
> tmp/work-shared/qemuarm/kernel-source/include/linux/cpumask.h:92:29: error:
> expected identifier or '(' before 'const'
> #define cpu_possible_mask ((const struct cpumask *)&__cpu_possible_mask)
>
> tmp/work-shared/qemuarm/kernel-source/include/linux/export.h:60:20: error:
> pasting "__kstrtab_" and "(" does not give a valid preprocessing token
> static const char __kstrtab_##sym[]
>
> tmp/work-shared/qemuarm/kernel-source/kernel/locking/rtmutex.c:351:21: error:
> redefinition of 'rt_mutex_get_top_task'
> | struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
>
> tmp/work-shared/qemuarm/kernel-source/kernel/locking/rtmutex.c:982:2: error:
> implicit declaration of function 'rt_mutex_deadlock_account_lock'; did you
> mean 'rt_mutex_deadlock_check'? [-Werror=implicit-function-declaration]
> | rt_mutex_deadlock_account_lock(lock, task)
I recall similar fixups on the newer -rt kernels, so hopefully there
are some references we can leverage.
Bruce
>
>
> Regards,
> Daniel
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#8668):
https://lists.yoctoproject.org/g/linux-yocto/message/8668
Mute This Topic: https://lists.yoctoproject.org/mt/74201726/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
