Re: Build regressions/improvements in v3.4-rc7

Re: Build regressions/improvements in v3.4-rc7

[Geert Uytterhoeven]

On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.4-rc7 to v3.4-rc6[3], the summaries are:
> =C2=A0- build errors: +15/-14

15 regressions:
  + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
fsl_diu_monitor_port' declared inside parameter list [-Werror]:  =3D>
70:9, 84:9, 88:36
  + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
a value, in function returning void [-Werror]:  =3D> 189:2
  + arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
declaration isn't a prototype [-Werror=3Dstrict-prototypes]:  =3D> 69:5,
88:6, 83:6, 187:1
  + arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
only this definition or declaration, which is probably not what you
want [-Werror]:  =3D> 70:9
  + drivers/virt/fsl_hypervisor.c: error: 'MSR_GS' undeclared (first
use in this function):  =3D> 799:80

powerpc randconfig

  + arch/x86/include/asm/uaccess_32.h: error: call to
'copy_from_user_overflow' declared with attribute error:
copy_from_user() buffer size is not provably correct:  =3D> 211:26

error in i386-randconfig, warning in i386-defconfig

  + drivers/ptp/ptp_pch.c: error: implicit declaration of function
'kfree' [-Werror=3Dimplicit-function-declaration]:  =3D> 576:2
  + drivers/ptp/ptp_pch.c: error: implicit declaration of function
'kzalloc' [-Werror=3Dimplicit-function-declaration]:  =3D> 587:2

Patch send.

  + error: "handle_edge_irq" [drivers/gpio/gpio-pch.ko] undefined!:  =3D> N=
/A
  + error: "irq_to_desc" [drivers/gpio/gpio-pch.ko] undefined!:  =3D> N/A

Fixed in the mean time, I guess.

  + error: No rule to make target include/config/auto.conf:  =3D> N/A

x86_64-randconfig

  + lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
constraints in an 'asm':  =3D> 50:70
  + lib/mpi/generic_mpih-mul2.c: error: inconsistent operand
constraints in an 'asm':  =3D> 49:70
  + lib/mpi/generic_mpih-mul3.c: error: inconsistent operand
constraints in an 'asm':  =3D> 49:70
  + lib/mpi/mpih-div.c: error: inconsistent operand constraints in an
'asm':  =3D> 135:122, 135:371, 97:122, 106:121, 106:370, 97:371

parisc-allmodconfig

Gr{oetje,eeting}s,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 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. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds

Re: Build regressions/improvements in v3.4-rc7

[James Bottomley]

On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>   + lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
> constraints in an 'asm':  => 50:70
>   + lib/mpi/generic_mpih-mul2.c: error: inconsistent operand
> constraints in an 'asm':  => 49:70
>   + lib/mpi/generic_mpih-mul3.c: error: inconsistent operand
> constraints in an 'asm':  => 49:70
>   + lib/mpi/mpih-div.c: error: inconsistent operand constraints in an
> 'asm':  => 135:122, 135:371, 97:122, 106:121, 106:370, 97:371
> 
> parisc-allmodconfig

Wow, lib/mpi/ is a complete horror: it's full of hand crafted asm code.
The error in this case appears to be that umul_ppm() is implemented as
an xmpyu instruction.  That's a floating point instruction.  We
deliberately compile the kernel with floating point disabled because we
don't want to save and restore the floating point register file on each
context switch, hence the operand constraints are unsatisfiable.

It appears to be completely untested on non-x86 and to have been
imported via the security tree ... what are we supposed to do with this?
I thought the general principle was that asm code was really supposed to
be confined to the arch directories?

James

Re: Build regressions/improvements in v3.4-rc7

[Kasatkin, Dmitry]

On Wed, May 16, 2012 at 5:46 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
>> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> =C2=A0 + lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 50:70
>> =C2=A0 + lib/mpi/generic_mpih-mul2.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 49:70
>> =C2=A0 + lib/mpi/generic_mpih-mul3.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 49:70
>> =C2=A0 + lib/mpi/mpih-div.c: error: inconsistent operand constraints in =
an
>> 'asm': =C2=A0=3D> 135:122, 135:371, 97:122, 106:121, 106:370, 97:371
>>
>> parisc-allmodconfig
>
> Wow, lib/mpi/ is a complete horror: it's full of hand crafted asm code.
> The error in this case appears to be that umul_ppm() is implemented as
> an xmpyu instruction. =C2=A0That's a floating point instruction. =C2=A0We
> deliberately compile the kernel with floating point disabled because we
> don't want to save and restore the floating point register file on each
> context switch, hence the operand constraints are unsatisfiable.
>
> It appears to be completely untested on non-x86 and to have been
> imported via the security tree ... what are we supposed to do with this?
> I thought the general principle was that asm code was really supposed to
> be confined to the arch directories?
>
> James
>
>

Yes.. it is suxx.
But it is only longlong.h and inherited from gpg..
And now there is a stuff such as /include/math-emu/soft-fp and
<stdlib/longlong.h>
I planned to look to that but now I will start doing it right away.

- Dmitry

Re: Build regressions/improvements in v3.4-rc7

[Geert Uytterhoeven]

On Wed, May 16, 2012 at 4:46 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
>> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> =C2=A0 + lib/mpi/generic_mpih-mul1.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 50:70
>> =C2=A0 + lib/mpi/generic_mpih-mul2.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 49:70
>> =C2=A0 + lib/mpi/generic_mpih-mul3.c: error: inconsistent operand
>> constraints in an 'asm': =C2=A0=3D> 49:70
>> =C2=A0 + lib/mpi/mpih-div.c: error: inconsistent operand constraints in =
an
>> 'asm': =C2=A0=3D> 135:122, 135:371, 97:122, 106:121, 106:370, 97:371
>>
>> parisc-allmodconfig
>
> Wow, lib/mpi/ is a complete horror: it's full of hand crafted asm code.
> The error in this case appears to be that umul_ppm() is implemented as
> an xmpyu instruction. =C2=A0That's a floating point instruction. =C2=A0We
> deliberately compile the kernel with floating point disabled because we
> don't want to save and restore the floating point register file on each
> context switch, hence the operand constraints are unsatisfiable.

It also does fishy things on m68k, cfr. https://lkml.org/lkml/2012/3/11/22

> It appears to be completely untested on non-x86 and to have been
> imported via the security tree ... what are we supposed to do with this?
> I thought the general principle was that asm code was really supposed to
> be confined to the arch directories?

Kick it out again, or contain it in staging?

Gr{oetje,eeting}s,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 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. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds

Re: Build regressions/improvements in v3.4-rc7

[John David Anglin]

On 16-May-12, at 10:46 AM, James Bottomley wrote:

> Wow, lib/mpi/ is a complete horror: it's full of hand crafted asm  
> code.
> The error in this case appears to be that umul_ppm() is implemented as
> an xmpyu instruction.  That's a floating point instruction.  We
> deliberately compile the kernel with floating point disabled because  
> we
> don't want to save and restore the floating point register file on  
> each
> context switch, hence the operand constraints are unsatisfiable.

I haven't tried this but I think the parisc implementation of umul_ppmm
can be deleted.  There is a generic version in the file.

Dave
--
John David Anglin	dave.anglin@bell.net

Re: Build regressions/improvements in v3.4-rc7

[Benjamin Herrenschmidt]

On Wed, 2012-05-16 at 10:47 +0200, Geert Uytterhoeven wrote:
> On Wed, May 16, 2012 at 10:30 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > JFYI, when comparing v3.4-rc7 to v3.4-rc6[3], the summaries are:
> >  - build errors: +15/-14
> 
> 15 regressions:
>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
> fsl_diu_monitor_port' declared inside parameter list [-Werror]:  =>
> 70:9, 84:9, 88:36
>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
> a value, in function returning void [-Werror]:  => 189:2
>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
> declaration isn't a prototype [-Werror=strict-prototypes]:  => 69:5,
> 88:6, 83:6, 187:1
>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
> only this definition or declaration, which is probably not what you
> want [-Werror]:  => 70:9
>   + drivers/virt/fsl_hypervisor.c: error: 'MSR_GS' undeclared (first
> use in this function):  => 799:80
>
> powerpc randconfig
 
Thanks. These are all freescale platforms, the relevant people should be
already but I've added Scott and Kumar to the CC list just in case.

Cheers,
Ben.

Re: Re: Build regressions/improvements in v3.4-rc7

[Timur Tabi]

Benjamin Herrenschmidt wrote:
> Thanks. These are all freescale platforms, the relevant people should be
> already but I've added Scott and Kumar to the CC list just in case.

Seeing how this is my code, I'd say the relevant people were not CC'd. :-)

Anyway, I think I see what the problem is, but it does appear when I use
the normal defconfigs.  What .config was being used?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Re: Build regressions/improvements in v3.4-rc7

[Tabi Timur-B04825]

On Thu, May 17, 2012 at 12:30 PM, Timur Tabi <timur@freescale.com> wrote:

> Anyway, I think I see what the problem is, but it does appear when I use
> the normal defconfigs. =A0What .config was being used?

I meant to say that it does NOT appear.

--=20
Timur Tabi
Linux kernel developer at Freescale=

Re: Re: Build regressions/improvements in v3.4-rc7

[Geert Uytterhoeven]

On Thu, May 17, 2012 at 7:52 PM, Tabi Timur-B04825 <B04825@freescale.com> w=
rote:
> On Thu, May 17, 2012 at 12:30 PM, Timur Tabi <timur@freescale.com> wrote:
>
>> Anyway, I think I see what the problem is, but it does appear when I use
>> the normal defconfigs. =C2=A0What .config was being used?
>
> I meant to say that it does NOT appear.

powerpc randconfig.

Gr{oetje,eeting}s,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 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. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds

Re: Build regressions/improvements in v3.4-rc7

[Timur Tabi]

Geert Uytterhoeven wrote:
> powerpc randconfig

Doesn't this generate a different .config every time it's run?  Do I keep
generating random .config files until the problem shows up?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Build regressions/improvements in v3.4-rc7

[Scott Wood]

On 05/17/2012 01:44 PM, Timur Tabi wrote:
> Geert Uytterhoeven wrote:
>> powerpc randconfig
> 
> Doesn't this generate a different .config every time it's run?  Do I keep
> generating random .config files until the problem shows up?
> 

Regardless of the config that shows this, the MSR[GS] check should go
away.  If you have a /hypervisor node, you already know you're a guest.

-Scott

Re: Build regressions/improvements in v3.4-rc7

[Timur Tabi]

Scott Wood wrote:
> Regardless of the config that shows this, the MSR[GS] check should go
> away.  If you have a /hypervisor node, you already know you're a guest.

Fair enough.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Re: Build regressions/improvements in v3.4-rc7

[Timur Tabi]

Benjamin Herrenschmidt wrote:
>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
>> fsl_diu_monitor_port' declared inside parameter list [-Werror]:  =>
>> 70:9, 84:9, 88:36
>>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
>> a value, in function returning void [-Werror]:  => 189:2
>>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
>> declaration isn't a prototype [-Werror=strict-prototypes]:  => 69:5,
>> 88:6, 83:6, 187:1
>>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
>> only this definition or declaration, which is probably not what you
>> want [-Werror]:  => 70:9

So I think I have a fix for these, but I still would like the actual
.config so that I can be sure.

>>   + drivers/virt/fsl_hypervisor.c: error: 'MSR_GS' undeclared (first
>> use in this function):  => 799:80

I can't reproduce this one.  MSR_GS is defined in reg_booke.h.
fsl_hypervisor.c should not be compiled on a non-booke platform.  I don't
know if the fix is to add this to fsl_hypervisor.c:

	#include <asm/reg_booke.h>

or if I should update the Kconfig:

config FSL_HV_MANAGER
	tristate "Freescale hypervisor management driver"
	depends on FSL_SOC

to

	depends on FSL_BOOKE

or maybe

	depends on FSL_BOOKE && FSL_SOC

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Re: Build regressions/improvements in v3.4-rc7

[Michael Ellerman]

On Thu, 2012-05-17 at 13:42 -0500, Timur Tabi wrote:
> Benjamin Herrenschmidt wrote:
> >   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
> >> fsl_diu_monitor_port' declared inside parameter list [-Werror]:  =>
> >> 70:9, 84:9, 88:36
> >>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
> >> a value, in function returning void [-Werror]:  => 189:2
> >>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
> >> declaration isn't a prototype [-Werror=strict-prototypes]:  => 69:5,
> >> 88:6, 83:6, 187:1
> >>   + arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
> >> only this definition or declaration, which is probably not what you
> >> want [-Werror]:  => 70:9
> 
> So I think I have a fix for these, but I still would like the actual
> .config so that I can be sure.

I believe it's this one:

http://kisskb.ellerman.id.au/kisskb/buildresult/6312867/config/


cheers