Re: [ 00/17] 3.4.58-stable review

Re: [ 00/17] 3.4.58-stable review

[Geert Uytterhoeven]

On Thu, Aug 15, 2013 at 9:43 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> I screwed up my stable repo clone again :(, so the full build will take a
> bit.
>
> mips builds on on 3.4 with all patches applied now fail with:
> arch/mips/include/asm/page.h: Assembler messages:
> arch/mips/include/asm/page.h:178: Error: Unrecognized opcode `static inline
> int pfn_valid(unsigned long pfn)'
> arch/mips/include/asm/page.h:179: Error: junk at end of line, first
> unrecognized character is `{'
> arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern
> unsigned long max_mapnr'
> arch/mips/include/asm/page.h:183: Error: Unrecognized opcode `return
> pfn>=ARCH_PFN_OFFSET&&pfn<max_mapnr'
> arch/mips/include/asm/page.h:184: Error: junk at end of line, first
> unrecognized character is `}'
>
> This is the error I referred to above. Reverting above pfn rework patch
> fixes that problem,
> so you might want to remove that patch from the patch queue for now.

Perhaps this one got applied too soon?

 commit 730b8dfe016dd1e91f73d8d3e6724da91397171c
Author: Ralf Baechle <ralf@linux-mips.org>
Date:   Fri Dec 28 15:18:02 2012 +0100

    MIPS: page.h: Remove now unnecessary #ifndef __ASSEMBLY__ wrapper.

    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [ 00/17] 3.4.58-stable review

[Guenter Roeck]

On 08/15/2013 12:55 AM, Geert Uytterhoeven wrote:
> On Thu, Aug 15, 2013 at 9:43 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> I screwed up my stable repo clone again :(, so the full build will take a
>> bit.
>>
>> mips builds on on 3.4 with all patches applied now fail with:
>> arch/mips/include/asm/page.h: Assembler messages:
>> arch/mips/include/asm/page.h:178: Error: Unrecognized opcode `static inline
>> int pfn_valid(unsigned long pfn)'
>> arch/mips/include/asm/page.h:179: Error: junk at end of line, first
>> unrecognized character is `{'
>> arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern
>> unsigned long max_mapnr'
>> arch/mips/include/asm/page.h:183: Error: Unrecognized opcode `return
>> pfn>=ARCH_PFN_OFFSET&&pfn<max_mapnr'
>> arch/mips/include/asm/page.h:184: Error: junk at end of line, first
>> unrecognized character is `}'
>>
>> This is the error I referred to above. Reverting above pfn rework patch
>> fixes that problem,
>> so you might want to remove that patch from the patch queue for now.
>
> Perhaps this one got applied too soon?
>
>   commit 730b8dfe016dd1e91f73d8d3e6724da91397171c
> Author: Ralf Baechle <ralf@linux-mips.org>
> Date:   Fri Dec 28 15:18:02 2012 +0100
>
>      MIPS: page.h: Remove now unnecessary #ifndef __ASSEMBLY__ wrapper.
>
I applied it on top of the other patches, but that did not help.
On the contrary, I get even more errors. Must be something else,
or it needs even more patches.

Guenter

Re: [ 00/17] 3.4.58-stable review

[Guenter Roeck]

On 08/15/2013 12:55 AM, Geert Uytterhoeven wrote:
> On Thu, Aug 15, 2013 at 9:43 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> I screwed up my stable repo clone again :(, so the full build will take a
>> bit.
>>
>> mips builds on on 3.4 with all patches applied now fail with:
>> arch/mips/include/asm/page.h: Assembler messages:
>> arch/mips/include/asm/page.h:178: Error: Unrecognized opcode `static inline
>> int pfn_valid(unsigned long pfn)'
>> arch/mips/include/asm/page.h:179: Error: junk at end of line, first
>> unrecognized character is `{'
>> arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern
>> unsigned long max_mapnr'
>> arch/mips/include/asm/page.h:183: Error: Unrecognized opcode `return
>> pfn>=ARCH_PFN_OFFSET&&pfn<max_mapnr'
>> arch/mips/include/asm/page.h:184: Error: junk at end of line, first
>> unrecognized character is `}'
>>
>> This is the error I referred to above. Reverting above pfn rework patch
>> fixes that problem,
>> so you might want to remove that patch from the patch queue for now.
>
> Perhaps this one got applied too soon?
>
>   commit 730b8dfe016dd1e91f73d8d3e6724da91397171c
> Author: Ralf Baechle <ralf@linux-mips.org>
> Date:   Fri Dec 28 15:18:02 2012 +0100
>
>      MIPS: page.h: Remove now unnecessary #ifndef __ASSEMBLY__ wrapper.
>
>      Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>

Actually, you are on the right track, only in the opposite direction.
The problem is that commit 8b9232141b changed
	#define pfn_valid ...
to
	static inline pfn_valid()
in arch/mips/include/asm/page.h. In the 3.4 kernel the file _is_
still included from assembler code. This obviously doesn't work.

Fix would be to surround the new static inline function with #ifndef __ASSEMBLY__.
With this change, "mips allmodconfig" compiles with the 3.4 kernel.
It should be a safe change, since the static inline will never be used
from assembler code.

Question is if that would be acceptable as back-port of 8b9232141b to 3.4.
Greg, any comments ? If it is ok I can submit a back-port request with
the modified patch to -stable. That would be one more build fixed,
three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).

Thanks,
Guenter

Re: [ 00/17] 3.4.58-stable review

[Greg Kroah-Hartman]

On Thu, Aug 15, 2013 at 09:53:25PM -0700, Guenter Roeck wrote:
> On 08/15/2013 12:55 AM, Geert Uytterhoeven wrote:
> > On Thu, Aug 15, 2013 at 9:43 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> >> I screwed up my stable repo clone again :(, so the full build will take a
> >> bit.
> >>
> >> mips builds on on 3.4 with all patches applied now fail with:
> >> arch/mips/include/asm/page.h: Assembler messages:
> >> arch/mips/include/asm/page.h:178: Error: Unrecognized opcode `static inline
> >> int pfn_valid(unsigned long pfn)'
> >> arch/mips/include/asm/page.h:179: Error: junk at end of line, first
> >> unrecognized character is `{'
> >> arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern
> >> unsigned long max_mapnr'
> >> arch/mips/include/asm/page.h:183: Error: Unrecognized opcode `return
> >> pfn>=ARCH_PFN_OFFSET&&pfn<max_mapnr'
> >> arch/mips/include/asm/page.h:184: Error: junk at end of line, first
> >> unrecognized character is `}'
> >>
> >> This is the error I referred to above. Reverting above pfn rework patch
> >> fixes that problem,
> >> so you might want to remove that patch from the patch queue for now.
> >
> > Perhaps this one got applied too soon?
> >
> >   commit 730b8dfe016dd1e91f73d8d3e6724da91397171c
> > Author: Ralf Baechle <ralf@linux-mips.org>
> > Date:   Fri Dec 28 15:18:02 2012 +0100
> >
> >      MIPS: page.h: Remove now unnecessary #ifndef __ASSEMBLY__ wrapper.
> >
> >      Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> >
> 
> Actually, you are on the right track, only in the opposite direction.
> The problem is that commit 8b9232141b changed
> 	#define pfn_valid ...
> to
> 	static inline pfn_valid()
> in arch/mips/include/asm/page.h. In the 3.4 kernel the file _is_
> still included from assembler code. This obviously doesn't work.
> 
> Fix would be to surround the new static inline function with #ifndef __ASSEMBLY__.
> With this change, "mips allmodconfig" compiles with the 3.4 kernel.
> It should be a safe change, since the static inline will never be used
> from assembler code.
> 
> Question is if that would be acceptable as back-port of 8b9232141b to 3.4.
> Greg, any comments ? If it is ok I can submit a back-port request with
> the modified patch to -stable. That would be one more build fixed,
> three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).

That sounds reasonable to me, as it is a valid fix, and I do know of
some MIPS people using 3.4 (although their versions all seem to be
heavily patched, perhaps for issues like this, I don't really know...)

So, feel free to send such a backport on to me.

thanks,

greg k-h

Re: [ 00/17] 3.4.58-stable review

[Guenter Roeck]

On 08/15/2013 10:10 PM, Greg Kroah-Hartman wrote:
[ .. ]

>> three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).
>

Please add (in this order) the following patches to 3.4.

de36e66d5f sparc32: add ucmpdi2
74c7b28953 sparc32: Add ucmpdi2.o to obj-y instead of lib-y.

This fixes the sparc32:defconfig build error.

Thanks,
Guenter

Re: [ 00/17] 3.4.58-stable review

[Greg Kroah-Hartman]

On Fri, Aug 16, 2013 at 01:26:05AM -0700, Guenter Roeck wrote:
> On 08/15/2013 10:10 PM, Greg Kroah-Hartman wrote:
> [ .. ]
> 
> >> three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).
> >
> 
> Please add (in this order) the following patches to 3.4.
> 
> de36e66d5f sparc32: add ucmpdi2
> 74c7b28953 sparc32: Add ucmpdi2.o to obj-y instead of lib-y.
> 
> This fixes the sparc32:defconfig build error.

Now applied, thanks.

greg k-h

Re: [ 00/17] 3.4.58-stable review

[Guenter Roeck]

On Fri, Aug 16, 2013 at 05:41:40AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Aug 16, 2013 at 01:26:05AM -0700, Guenter Roeck wrote:
> > On 08/15/2013 10:10 PM, Greg Kroah-Hartman wrote:
> > [ .. ]
> > 
> > >> three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).
> > >
> > 
> > Please add (in this order) the following patches to 3.4.
> > 
> > de36e66d5f sparc32: add ucmpdi2
> > 74c7b28953 sparc32: Add ucmpdi2.o to obj-y instead of lib-y.
> > 
> > This fixes the sparc32:defconfig build error.
> 
> Now applied, thanks.
> 
Down to three failures now, out of 69 builds.

Still failing:
	arm:allmodconfig
	sparc64:allmodconfig
	xtensa:defconfig

None of those appear simple to fix.

In case someone wants to have a look, here is the latest log:

http://server.roeck-us.net:8010/builders/stable-queue-3.4/builds/45/steps/shell/logs/stdio
	
Guenter

Re: [ 00/17] 3.4.58-stable review

[Geert Uytterhoeven]

On Fri, Aug 16, 2013 at 10:27 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> Still failing:
>         sparc64:allmodconfig
> /opt/buildbot/slave/stable-queue-3_4/build/usr/include/linux/types.h:27:1: error: unknown type name ‘__u16’

According to my log collection, this same error message was fixed in v3.3-rc2,
but I couldn't easily find a matching commit.
But this is v3.4-stable, which is after v3.3-rc2, so it got reintroduced?

>         xtensa:defconfig
> dev.c:(.text.unlikely+0x3): dangerous relocation: l32r: literal placed after use: .literal.unlikely

Fixed in v3.7-rc1:

commit f6a03a12ecdbe0dd80a55f6df3b7206c5a403a49
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Mon Sep 17 05:44:31 2012 +0400

    xtensa: fix linker script transformation for .text.unlikely

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [ 00/17] 3.4.58-stable review

[Guenter Roeck]

On Fri, Aug 16, 2013 at 11:55:02PM +0200, Geert Uytterhoeven wrote:
> On Fri, Aug 16, 2013 at 10:27 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > Still failing:
> >         sparc64:allmodconfig
> > /opt/buildbot/slave/stable-queue-3_4/build/usr/include/linux/types.h:27:1: error: unknown type name ‘__u16’
> 
> According to my log collection, this same error message was fixed in v3.3-rc2,
> but I couldn't easily find a matching commit.
> But this is v3.4-stable, which is after v3.3-rc2, so it got reintroduced?
> 
It was fixed recently with

commit cbf1ef6b3345d2cc7e62407eec6a6f72a8b1346f
Author: Sam Ravnborg <sam@ravnborg.org>
Date:   Sun Mar 31 07:01:47 2013 +0000

    sparc: use asm-generic version of types.h

and

commit a2d34dd41212032c03e77bc30c2023725def841a
Author: Sam Ravnborg <sam@ravnborg.org>
Date:   Sat Mar 30 11:44:22 2013 +0000

    sparc: use generic headers

I tried to apply those patches, but it failed miserably due to the
userspace/kernel header separation. Given that, I figured that
it would be too invasive to fix, at least for me.

> >         xtensa:defconfig
> > dev.c:(.text.unlikely+0x3): dangerous relocation: l32r: literal placed after use: .literal.unlikely
> 
> Fixed in v3.7-rc1:
> 
> commit f6a03a12ecdbe0dd80a55f6df3b7206c5a403a49
> Author: Max Filippov <jcmvbkbc@gmail.com>
> Date:   Mon Sep 17 05:44:31 2012 +0400
> 
>     xtensa: fix linker script transformation for .text.unlikely
> 
Yes, that fixes this problem, except now we get another known error:

kernel/built-in.o:(.text+0x8c8): undefined reference to `_sdata'

which you had fixed with

commit 5e7b6ed8e9bf3c8e3bb579fd0aec64f6526f8c81
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Wed Jun 20 12:52:58 2012 -0700

    xtensa: replace xtensa-specific _f{data,text} by _s{data,text}

After applying both patches to the 3.4-stable queue, xtensa:defconfig builds
successfully.

Thanks,
Guenter

Re: [ 00/17] 3.4.58-stable review

[Greg Kroah-Hartman]

On Fri, Aug 16, 2013 at 03:39:50PM -0700, Guenter Roeck wrote:
> On Fri, Aug 16, 2013 at 11:55:02PM +0200, Geert Uytterhoeven wrote:
> > On Fri, Aug 16, 2013 at 10:27 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > > Still failing:
> > >         sparc64:allmodconfig
> > > /opt/buildbot/slave/stable-queue-3_4/build/usr/include/linux/types.h:27:1: error: unknown type name ‘__u16’
> > 
> > According to my log collection, this same error message was fixed in v3.3-rc2,
> > but I couldn't easily find a matching commit.
> > But this is v3.4-stable, which is after v3.3-rc2, so it got reintroduced?
> > 
> It was fixed recently with
> 
> commit cbf1ef6b3345d2cc7e62407eec6a6f72a8b1346f
> Author: Sam Ravnborg <sam@ravnborg.org>
> Date:   Sun Mar 31 07:01:47 2013 +0000
> 
>     sparc: use asm-generic version of types.h
> 
> and
> 
> commit a2d34dd41212032c03e77bc30c2023725def841a
> Author: Sam Ravnborg <sam@ravnborg.org>
> Date:   Sat Mar 30 11:44:22 2013 +0000
> 
>     sparc: use generic headers
> 
> I tried to apply those patches, but it failed miserably due to the
> userspace/kernel header separation. Given that, I figured that
> it would be too invasive to fix, at least for me.
> 
> > >         xtensa:defconfig
> > > dev.c:(.text.unlikely+0x3): dangerous relocation: l32r: literal placed after use: .literal.unlikely
> > 
> > Fixed in v3.7-rc1:
> > 
> > commit f6a03a12ecdbe0dd80a55f6df3b7206c5a403a49
> > Author: Max Filippov <jcmvbkbc@gmail.com>
> > Date:   Mon Sep 17 05:44:31 2012 +0400
> > 
> >     xtensa: fix linker script transformation for .text.unlikely
> > 
> Yes, that fixes this problem, except now we get another known error:
> 
> kernel/built-in.o:(.text+0x8c8): undefined reference to `_sdata'
> 
> which you had fixed with
> 
> commit 5e7b6ed8e9bf3c8e3bb579fd0aec64f6526f8c81
> Author: Geert Uytterhoeven <geert@linux-m68k.org>
> Date:   Wed Jun 20 12:52:58 2012 -0700
> 
>     xtensa: replace xtensa-specific _f{data,text} by _s{data,text}
> 
> After applying both patches to the 3.4-stable queue, xtensa:defconfig builds
> successfully.

Thanks, both now applied.

greg k-h