Hi!
> diff --git a/arch/sparc/include/asm/pgtable_32.h
> b/arch/sparc/include/asm/pgtable_32.h
> index ce6f569..cf19072 100644
> --- a/arch/sparc/include/asm/pgtable_32.h
> +++ b/arch/sparc/include/asm/pgtable_32.h
> @@ -91,9 +91,9 @@ extern unsigned long pfn_base;
> * ZERO_PAGE is a global
Hi!
> diff --git a/arch/sparc/include/asm/pgtable_32.h
> b/arch/sparc/include/asm/pgtable_32.h
> index ce6f569..cf19072 100644
> --- a/arch/sparc/include/asm/pgtable_32.h
> +++ b/arch/sparc/include/asm/pgtable_32.h
> @@ -91,9 +91,9 @@ extern unsigned long pfn_base;
> * ZERO_PAGE is a global
On 06/04/2017 10:34 PM, David Miller wrote:
> Please post your sparc64 system specs.
It's a SPARC-T5 running Debian inside an LDOM with 94 GiB RAM
and 128 active CPU threads.
I don't know the exact specs as the machine is owned by Anatoly
Pugachev. I'm CC'ing him so he can disclose the remaining
On 06/04/2017 10:34 PM, David Miller wrote:
> Please post your sparc64 system specs.
It's a SPARC-T5 running Debian inside an LDOM with 94 GiB RAM
and 128 active CPU threads.
I don't know the exact specs as the machine is owned by Anatoly
Pugachev. I'm CC'ing him so he can disclose the remaining
From: John Paul Adrian Glaubitz
Date: Sun, 4 Jun 2017 22:33:21 +0200
> On 06/04/2017 10:30 PM, David Miller wrote:
>> All of my testing is being done with gcc-6.3 vanilla and current
>> kernels, and in fact I'm doing parallel "make -j128" gcc and glibc
>> testsuite
From: John Paul Adrian Glaubitz
Date: Sun, 4 Jun 2017 22:33:21 +0200
> On 06/04/2017 10:30 PM, David Miller wrote:
>> All of my testing is being done with gcc-6.3 vanilla and current
>> kernels, and in fact I'm doing parallel "make -j128" gcc and glibc
>> testsuite runs and not hitting any
On 06/04/2017 10:30 PM, David Miller wrote:
> All of my testing is being done with gcc-6.3 vanilla and current
> kernels, and in fact I'm doing parallel "make -j128" gcc and glibc
> testsuite runs and not hitting any problems at all.
Did you try to build and run the gcc-7 testsuite? Because we
On 06/04/2017 10:30 PM, David Miller wrote:
> All of my testing is being done with gcc-6.3 vanilla and current
> kernels, and in fact I'm doing parallel "make -j128" gcc and glibc
> testsuite runs and not hitting any problems at all.
Did you try to build and run the gcc-7 testsuite? Because we
From: John Paul Adrian Glaubitz
Date: Sun, 4 Jun 2017 22:26:50 +0200
> You're the person who is most knowledgeable with the code and
> the bug seems pretty darn serious. Hence I was reporting it.
Ok, please report this again with a simple reproducable test case
and
From: John Paul Adrian Glaubitz
Date: Sun, 4 Jun 2017 22:26:50 +0200
> You're the person who is most knowledgeable with the code and
> the bug seems pretty darn serious. Hence I was reporting it.
Ok, please report this again with a simple reproducable test case
and I will try to reproduce it
On 06/04/2017 10:22 PM, David Miller wrote:
>> I think he means your kernel you are running might be miscompiled
>> with gcc 7.1.
>
> That's exactly what I am saying.
[0.00] Linux version 4.12.0-rc1-sparc64-smp
(debian-ker...@lists.debian.org) (gcc version 6.3.0 20170510 (Debian
On 06/04/2017 10:22 PM, David Miller wrote:
>> I think he means your kernel you are running might be miscompiled
>> with gcc 7.1.
>
> That's exactly what I am saying.
[0.00] Linux version 4.12.0-rc1-sparc64-smp
(debian-ker...@lists.debian.org) (gcc version 6.3.0 20170510 (Debian
On 06/04/2017 10:21 PM, David Miller wrote:
> It's the compiler. It's not compiling the kernel properly. What part
> of that do you not understand? The kernel, if miscompiled itself,
> cannot do anything about it.
How do you know it's the compiler? This has not happened with earlier
versions
On 06/04/2017 10:21 PM, David Miller wrote:
> It's the compiler. It's not compiling the kernel properly. What part
> of that do you not understand? The kernel, if miscompiled itself,
> cannot do anything about it.
How do you know it's the compiler? This has not happened with earlier
versions
From: Waldemar Brodkorb
Date: Sun, 4 Jun 2017 16:40:45 +0200
> Hi Adrian,
> John Paul Adrian Glaubitz wrote,
>
>> On 06/02/2017 07:28 PM, David Miller wrote:
>> >> Isn't a bug in the kernel if an application is able to crash to the point
>> >> that the machine has to be
From: Waldemar Brodkorb
Date: Sun, 4 Jun 2017 16:40:45 +0200
> Hi Adrian,
> John Paul Adrian Glaubitz wrote,
>
>> On 06/02/2017 07:28 PM, David Miller wrote:
>> >> Isn't a bug in the kernel if an application is able to crash to the point
>> >> that the machine has to be hard-rebooted?
>> >
>>
From: John Paul Adrian Glaubitz
Date: Sun, 4 Jun 2017 15:16:33 +0200
> On 06/02/2017 07:28 PM, David Miller wrote:
>>> Isn't a bug in the kernel if an application is able to crash to the point
>>> that the machine has to be hard-rebooted?
>>
>> It can be a bug in
From: John Paul Adrian Glaubitz
Date: Sun, 4 Jun 2017 15:16:33 +0200
> On 06/02/2017 07:28 PM, David Miller wrote:
>>> Isn't a bug in the kernel if an application is able to crash to the point
>>> that the machine has to be hard-rebooted?
>>
>> It can be a bug in the compiler too and not
Hi Waldemar!
On 06/04/2017 04:40 PM, Waldemar Brodkorb wrote:
>> So, in your point of view it's perfectly fine if an application is able
>> to crash the whole kernel with just user privileges?
>>
>> Shouldn't the kernel be able to cope with that?
>
> I think he means your kernel you are running
Hi Waldemar!
On 06/04/2017 04:40 PM, Waldemar Brodkorb wrote:
>> So, in your point of view it's perfectly fine if an application is able
>> to crash the whole kernel with just user privileges?
>>
>> Shouldn't the kernel be able to cope with that?
>
> I think he means your kernel you are running
Hi Adrian,
John Paul Adrian Glaubitz wrote,
> On 06/02/2017 07:28 PM, David Miller wrote:
> >> Isn't a bug in the kernel if an application is able to crash to the point
> >> that the machine has to be hard-rebooted?
> >
> > It can be a bug in the compiler too and not necessarily the kernel's
> >
Hi Adrian,
John Paul Adrian Glaubitz wrote,
> On 06/02/2017 07:28 PM, David Miller wrote:
> >> Isn't a bug in the kernel if an application is able to crash to the point
> >> that the machine has to be hard-rebooted?
> >
> > It can be a bug in the compiler too and not necessarily the kernel's
> >
On 06/02/2017 07:28 PM, David Miller wrote:
>> Isn't a bug in the kernel if an application is able to crash to the point
>> that the machine has to be hard-rebooted?
>
> It can be a bug in the compiler too and not necessarily the kernel's
> fault which is what I think is happening in your case.
On 06/02/2017 07:28 PM, David Miller wrote:
>> Isn't a bug in the kernel if an application is able to crash to the point
>> that the machine has to be hard-rebooted?
>
> It can be a bug in the compiler too and not necessarily the kernel's
> fault which is what I think is happening in your case.
From: John Paul Adrian Glaubitz
Date: Fri, 2 Jun 2017 18:33:45 +0200
> On 06/02/2017 04:22 PM, David Miller wrote:
>>> What remains to be fixed though is that the gcc-7 testsuite
>>> *reproducibly* kills the kernel on sparc64 when building with more than
>>> around
From: John Paul Adrian Glaubitz
Date: Fri, 2 Jun 2017 18:33:45 +0200
> On 06/02/2017 04:22 PM, David Miller wrote:
>>> What remains to be fixed though is that the gcc-7 testsuite
>>> *reproducibly* kills the kernel on sparc64 when building with more than
>>> around 20 jobs:
>>
>> Well, I
On 06/02/2017 04:22 PM, David Miller wrote:
>> What remains to be fixed though is that the gcc-7 testsuite
>> *reproducibly* kills the kernel on sparc64 when building with more than
>> around 20 jobs:
>
> Well, I already have a release gcc bug to fix so pretty much I have no
> time to look into
On 06/02/2017 04:22 PM, David Miller wrote:
>> What remains to be fixed though is that the gcc-7 testsuite
>> *reproducibly* kills the kernel on sparc64 when building with more than
>> around 20 jobs:
>
> Well, I already have a release gcc bug to fix so pretty much I have no
> time to look into
From: John Paul Adrian Glaubitz
Date: Fri, 2 Jun 2017 11:17:18 +0200
> On Wed, May 31, 2017 at 05:10:08PM -0400, David Miller wrote:
>> A fix for this is in Linus's tree and was submitted to -stable last
>> night:
>
> What remains to be fixed though is that the
From: John Paul Adrian Glaubitz
Date: Fri, 2 Jun 2017 11:17:18 +0200
> On Wed, May 31, 2017 at 05:10:08PM -0400, David Miller wrote:
>> A fix for this is in Linus's tree and was submitted to -stable last
>> night:
>
> What remains to be fixed though is that the gcc-7 testsuite
> *reproducibly*
On Wed, May 31, 2017 at 05:10:08PM -0400, David Miller wrote:
> A fix for this is in Linus's tree and was submitted to -stable last
> night:
What remains to be fixed though is that the gcc-7 testsuite
*reproducibly* kills the kernel on sparc64 when building with more than
around 20 jobs:
On Wed, May 31, 2017 at 05:10:08PM -0400, David Miller wrote:
> A fix for this is in Linus's tree and was submitted to -stable last
> night:
What remains to be fixed though is that the gcc-7 testsuite
*reproducibly* kills the kernel on sparc64 when building with more than
around 20 jobs:
From: Anatoly Pugachev
Date: Thu, 1 Jun 2017 15:46:04 +0300
> on the same topic , latest git does not compile for me with gcc-7.0.1
> gcc version 7.0.1 20170407 (experimental) [trunk revision 246759]
> (Debian 7-20170407-1)
>
> $ make
> ...
> CC arch/sparc/kernel/ds.o
From: Anatoly Pugachev
Date: Thu, 1 Jun 2017 15:46:04 +0300
> on the same topic , latest git does not compile for me with gcc-7.0.1
> gcc version 7.0.1 20170407 (experimental) [trunk revision 246759]
> (Debian 7-20170407-1)
>
> $ make
> ...
> CC arch/sparc/kernel/ds.o
>
On Thu, Jun 01, 2017 at 03:46:04PM +0300, Anatoly Pugachev wrote:
> on the same topic , latest git does not compile for me with gcc-7.0.1
> gcc version 7.0.1 20170407 (experimental) [trunk revision 246759]
> (Debian 7-20170407-1)
Let's first try this again once the 7.1.0-6 gcc-7 package has built
On Thu, Jun 01, 2017 at 03:46:04PM +0300, Anatoly Pugachev wrote:
> on the same topic , latest git does not compile for me with gcc-7.0.1
> gcc version 7.0.1 20170407 (experimental) [trunk revision 246759]
> (Debian 7-20170407-1)
Let's first try this again once the 7.1.0-6 gcc-7 package has built
on the same topic , latest git does not compile for me with gcc-7.0.1
gcc version 7.0.1 20170407 (experimental) [trunk revision 246759]
(Debian 7-20170407-1)
$ make
...
CC arch/sparc/kernel/ds.o
arch/sparc/kernel/ds.c: In function ‘register_services’:
arch/sparc/kernel/ds.c:912:3: error:
on the same topic , latest git does not compile for me with gcc-7.0.1
gcc version 7.0.1 20170407 (experimental) [trunk revision 246759]
(Debian 7-20170407-1)
$ make
...
CC arch/sparc/kernel/ds.o
arch/sparc/kernel/ds.c: In function ‘register_services’:
arch/sparc/kernel/ds.c:912:3: error:
Hi David,
thank you very much.
best regards
Waldemar
Hi David,
thank you very much.
best regards
Waldemar
A fix for this is in Linus's tree and was submitted to -stable last
night:
commit deba804c90642c8ed0f15ac1083663976d578f54
Author: Orlando Arias
Date: Tue May 16 15:34:00 2017 -0400
sparc: Fix -Wstringop-overflow warning
Greetings,
A fix for this is in Linus's tree and was submitted to -stable last
night:
commit deba804c90642c8ed0f15ac1083663976d578f54
Author: Orlando Arias
Date: Tue May 16 15:34:00 2017 -0400
sparc: Fix -Wstringop-overflow warning
Greetings,
GCC 7 introduced
Hi,
when compiling a kernel (4.11.3) for sparc with gcc 7.1 and
attached config I get following error:
/usr/bin/make -f ./scripts/Makefile.build obj=arch/sparc/mm
/home/wbx/openadk/toolchain_qemu-sparc_uclibc-ng_v8/usr/bin/sparc-openadk-linux-uclibc-gcc
-Wp,-MD,arch/sparc/mm/.init_32.o.d
Hi,
when compiling a kernel (4.11.3) for sparc with gcc 7.1 and
attached config I get following error:
/usr/bin/make -f ./scripts/Makefile.build obj=arch/sparc/mm
/home/wbx/openadk/toolchain_qemu-sparc_uclibc-ng_v8/usr/bin/sparc-openadk-linux-uclibc-gcc
-Wp,-MD,arch/sparc/mm/.init_32.o.d
44 matches
Mail list logo