Bug 6074

Already sent the fix to RP for this over the weekend.

Hi Bruce,
are you referring to 4f80de9a568bcf0280c7e8b8f89ee6c2adfa477d ?

linux-yocto/3.10: fix qemuarm build failure
    
    The v3.10.24 merge created a merge conflict, which was not properly
    resolved. Fixing the merge conflict and fixing the build of qemu arm.
    
    (From OE-Core rev: 2116e326d9d7039aac4ec6c7ae5d2a2bedfb4a74)


I already have that in and it still fails.

(In reply to comment #2)
> Hi Bruce,
> are you referring to 4f80de9a568bcf0280c7e8b8f89ee6c2adfa477d ?
> 
> linux-yocto/3.10: fix qemuarm build failure
>     
>     The v3.10.24 merge created a merge conflict, which was not properly
>     resolved. Fixing the merge conflict and fixing the build of qemu arm.
>     
>     (From OE-Core rev: 2116e326d9d7039aac4ec6c7ae5d2a2bedfb4a74)
> 
> 
> I already have that in and it still fails.

If you are really running that commit, you cannot be seeing the merge conflict markers. They
are completely gone. 

So whatever issue you are seeing, is different, and I can say that I obviously built and rebuilt
with a clean tree before sending that fix.

Head to your kernel source, this is the top commit for the BSP, and then grep the entire tree
for merge conflicts. you won't see any.

Bruce

commit 52a6807f42846c7d1442e11227722f59221fc64e
Author: Bruce Ashfield <bruce.ashfield@windriver.com>
Date:   Sun Mar 30 14:20:12 2014 -0400

    arm: fix v3.10.34 merge issue
    
    Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index fe49ffd2030c..6b4867d9ce38 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -548,7 +548,6 @@ int __init arm_add_memory(u64 start, u64 size)
         * Size is appropriately rounded down, start is rounded up.
         */
        size -= start & ~PAGE_MASK;
-<<<<<<< HEAD
        aligned_start = PAGE_ALIGN(start);
 
 #ifndef CONFIG_ARCH_PHYS_ADDR_T_64BIT
@@ -557,27 +556,8 @@ int __init arm_add_memory(u64 start, u64 size)
                       "32-bit physical address space\n", (long long)start);
                return -EINVAL;
        }
-||||||| merged common ancestors
-       bank->start = PAGE_ALIGN(start);
-=======
-       aligned_start = PAGE_ALIGN(start);
->>>>>>> v3.10.34
-
-<<<<<<< HEAD
-       if (aligned_start + size > ULONG_MAX) {
-||||||| merged common ancestors
-#ifndef CONFIG_ARM_LPAE
-       if (bank->start + size < bank->start) {
-=======
-#ifndef CONFIG_ARCH_PHYS_ADDR_T_64BIT
-       if (aligned_start > ULONG_MAX) {
-               printk(KERN_CRIT "Ignoring memory at 0x%08llx outside "
-                      "32-bit physical address space\n", (long long)start);
-               return -EINVAL;
-       }
-       }
 
        if (aligned_start + size > ULONG_MAX) {
->>>>>>> v3.10.34
                printk(KERN_CRIT "Truncating memory at 0x%08llx to fit in "
                        "32-bit physical address space\n", (long long)start);
                /*
@@ -589,10 +569,6 @@ int __init arm_add_memory(u64 start, u64 size)
        }
 #endif
 
-<<<<<<< HEAD
-       bank->start = aligned_start;
-||||||| merged common ancestors
-=======
        if (aligned_start < PHYS_OFFSET) {
                if (aligned_start + size <= PHYS_OFFSET) {
                        pr_info("Ignoring memory below PHYS_OFFSET: 0x%08llx-0x%08llx\n",
@@ -608,7 +584,6 @@ int __init arm_add_memory(u64 start, u64 size)
        }
 
        bank->start = aligned_start;
->>>>>>> v3.10.34
        bank->size = size & ~(phys_addr_t)(PAGE_SIZE - 1);
 
        /*

The machine I am testing, vexpressa9, is based on beagleboard kernel. Means we have a: KMACHINE_vexpressa9 = "beagleboard"

And I did browse to /tmp/work/vexpressa9-poky-linux-gnueabi/linux-yocto/3.10.34+gitAUTOINC+df3aa753c8_c7739be126-r0 and saw the merge conflicts in linux/arch/arm/kernel/setup.c as I already said above.

Thanks,
Florin

Then I'll look forward to a patch that fixes the issue. I have my hands full supporting
the boards, releases and combinations that already exist.

I'm happy to take patches for other boards, but I won' t have configs or cycles to 
build test them until the final 3.14 is integrated and tested.

(In reply to comment #4)
> The machine I am testing, vexpressa9, is based on beagleboard kernel. Means
> we have a: KMACHINE_vexpressa9 = "beagleboard"
> 
> And I did browse to
> /tmp/work/vexpressa9-poky-linux-gnueabi/linux-yocto/3.10.
> 34+gitAUTOINC+df3aa753c8_c7739be126-r0 and saw the merge conflicts in
> linux/arch/arm/kernel/setup.c as I already said above.
> 
> Thanks,
> Florin

That being said, I cherry picked the patch over to the branch and pushed it out,
update your SRCREV locally and test. I'll send a SRCREV update after 3.14 is out.

The point here is not that the fix was simple, it is about getting clear bug reports
and people sending patches versus just bug submissions.

(In reply to comment #5)
> Then I'll look forward to a patch that fixes the issue. I have my hands full
> supporting
> the boards, releases and combinations that already exist.
> 
> I'm happy to take patches for other boards, but I won' t have configs or
> cycles to 
> build test them until the final 3.14 is integrated and tested.
> 
> (In reply to comment #4)
> > The machine I am testing, vexpressa9, is based on beagleboard kernel. Means
> > we have a: KMACHINE_vexpressa9 = "beagleboard"
> > 
> > And I did browse to
> > /tmp/work/vexpressa9-poky-linux-gnueabi/linux-yocto/3.10.
> > 34+gitAUTOINC+df3aa753c8_c7739be126-r0 and saw the merge conflicts in
> > linux/arch/arm/kernel/setup.c as I already said above.
> > 
> > Thanks,
> > Florin

It wasn't my intention to not send any bug fixes. It's just that I did not figure it out from the beginning what was wrong with it, considering also I saw your commit in poky for fixing the merge conflicts. And I do believe my bug report was accurate enough, hence it took a very short while to get it fixed.

That being said, I am using AUTOREV anyway in my kernel append and the issue is fixed now.

Thank you.