Re: sched: system doesn't boot since "sched: Add new migrate_disable() implementation"

On Tuesday, 20 October 2020, 13:30:09 CEST, Peter Zijlstra wrote: > On Mon, Oct 19, 2020 at 05:09:35PM +0200, Sebastian Andrzej Siewior wrote: > > On 2020-10-19 12:21:06 [+0200], Christian Eggers wrote: > > > I have problems with the latest 5.9-rt releases on i.MX6ULL (! CONFIG_SMP): > > … > > >

Re: sched: system doesn't boot since "sched: Add new migrate_disable() implementation"

On 2020-10-20 13:41:37 [+0200], Peter Zijlstra wrote: > Right, but this patch set doesn't include the lazy preemption stuff, and > given the 'fun' Valentin and me are still having with it, I'd like to > keep it like that. > > But yes, that might warrant a slightly less NOP implementation. Uh.

Re: sched: system doesn't boot since "sched: Add new migrate_disable() implementation"

On Tue, Oct 20, 2020 at 01:38:28PM +0200, Sebastian Andrzej Siewior wrote: > On 2020-10-20 13:30:09 [+0200], Peter Zijlstra wrote: > > On Mon, Oct 19, 2020 at 05:09:35PM +0200, Sebastian Andrzej Siewior wrote: > > > On 2020-10-19 12:21:06 [+0200], Christian Eggers wrote: > > > > I have problems

Re: sched: system doesn't boot since "sched: Add new migrate_disable() implementation"

On 2020-10-20 13:30:09 [+0200], Peter Zijlstra wrote: > On Mon, Oct 19, 2020 at 05:09:35PM +0200, Sebastian Andrzej Siewior wrote: > > On 2020-10-19 12:21:06 [+0200], Christian Eggers wrote: > > > I have problems with the latest 5.9-rt releases on i.MX6ULL (!CONFIG_SMP): > > > > > … > > > Any

Re: sched: system doesn't boot since "sched: Add new migrate_disable() implementation"

On Mon, Oct 19, 2020 at 05:09:35PM +0200, Sebastian Andrzej Siewior wrote: > On 2020-10-19 12:21:06 [+0200], Christian Eggers wrote: > > I have problems with the latest 5.9-rt releases on i.MX6ULL (!CONFIG_SMP): > > > … > > Any hints? > > Thank you for the report. The reason is the

Re: sched: system doesn't boot since "sched: Add new migrate_disable() implementation"

On 2020-10-19 12:21:06 [+0200], Christian Eggers wrote: > I have problems with the latest 5.9-rt releases on i.MX6ULL (!CONFIG_SMP): > … > Any hints? Thank you for the report. The reason is the migrate_disable() implementation for !SMP. > Best regards > Christian Sebastian

sched: system doesn't boot since "sched: Add new migrate_disable() implementation"

I have problems with the latest 5.9-rt releases on i.MX6ULL (!CONFIG_SMP): -rc8-rt13 works fine -rc8-rt14 doesn't compile (due to CONFIG_FRACE, already fixed in -rt16) -rt15 dito. -rt16 compiles, but doesn't boot (no console output at all) After reverting (on -rt16) de1c0755e6f9 ("tracing

Re: 4.17.0-rc1 doesn't boot.

Heh, your .config is insidious: 9ffe3000 B __brk_base 9ffe3000 B __bss_stop 9fff3000 b .brk.dmi_alloc a0003000 b .brk.early_pgt_alloc a000f000 B _end a000f000 B __brk_limit dmi_alloc is __init, so it gets freed at some point and the PTEs zeroed

Re: 4.17.0-rc1 doesn't boot.

Heh, your .config is insidious: 9ffe3000 B __brk_base 9ffe3000 B __bss_stop 9fff3000 b .brk.dmi_alloc a0003000 b .brk.early_pgt_alloc a000f000 B _end a000f000 B __brk_limit dmi_alloc is __init, so it gets freed at some point and the PTEs zeroed

Re: 4.17.0-rc1 doesn't boot.

On 17 April 2018 at 18:48, Dave Hansen wrote: > On 04/17/2018 09:00 AM, Mike Galbraith wrote: >> On Tue, 2018-04-17 at 17:31 +0200, Borislav Petkov wrote: >>> On Tue, Apr 17, 2018 at 05:21:30PM +0200, Jörg Otte wrote: finished bisection.

Re: 4.17.0-rc1 doesn't boot.

On 17 April 2018 at 18:48, Dave Hansen wrote: > On 04/17/2018 09:00 AM, Mike Galbraith wrote: >> On Tue, 2018-04-17 at 17:31 +0200, Borislav Petkov wrote: >>> On Tue, Apr 17, 2018 at 05:21:30PM +0200, Jörg Otte wrote: finished bisection. 39114b7a743e6759bab4d96b7d9651d44d17e3f9 is the

Re: 4.17.0-rc1 doesn't boot.

On 04/17/2018 09:00 AM, Mike Galbraith wrote: > On Tue, 2018-04-17 at 17:31 +0200, Borislav Petkov wrote: >> On Tue, Apr 17, 2018 at 05:21:30PM +0200, Jörg Otte wrote: >>> finished bisection. >>> 39114b7a743e6759bab4d96b7d9651d44d17e3f9 is the first bad commit >>> (x86/pti: Never implicitly clear

Re: 4.17.0-rc1 doesn't boot.

On 04/17/2018 09:00 AM, Mike Galbraith wrote: > On Tue, 2018-04-17 at 17:31 +0200, Borislav Petkov wrote: >> On Tue, Apr 17, 2018 at 05:21:30PM +0200, Jörg Otte wrote: >>> finished bisection. >>> 39114b7a743e6759bab4d96b7d9651d44d17e3f9 is the first bad commit >>> (x86/pti: Never implicitly clear

Re: 4.17.0-rc1 doesn't boot.

On Tue, 2018-04-17 at 17:31 +0200, Borislav Petkov wrote: > On Tue, Apr 17, 2018 at 05:21:30PM +0200, Jörg Otte wrote: > > finished bisection. > > 39114b7a743e6759bab4d96b7d9651d44d17e3f9 is the first bad commit > > (x86/pti: Never implicitly clear _PAGE_GLOBAL for kernel image). > > Looks like

Re: 4.17.0-rc1 doesn't boot.

On Tue, 2018-04-17 at 17:31 +0200, Borislav Petkov wrote: > On Tue, Apr 17, 2018 at 05:21:30PM +0200, Jörg Otte wrote: > > finished bisection. > > 39114b7a743e6759bab4d96b7d9651d44d17e3f9 is the first bad commit > > (x86/pti: Never implicitly clear _PAGE_GLOBAL for kernel image). > > Looks like

Re: 4.17.0-rc1 doesn't boot.

On Tue, Apr 17, 2018 at 05:21:30PM +0200, Jörg Otte wrote: > finished bisection. > 39114b7a743e6759bab4d96b7d9651d44d17e3f9 is the first bad commit > (x86/pti: Never implicitly clear _PAGE_GLOBAL for kernel image). Looks like you're not the only one:

Re: 4.17.0-rc1 doesn't boot.

On Tue, Apr 17, 2018 at 05:21:30PM +0200, Jörg Otte wrote: > finished bisection. > 39114b7a743e6759bab4d96b7d9651d44d17e3f9 is the first bad commit > (x86/pti: Never implicitly clear _PAGE_GLOBAL for kernel image). Looks like you're not the only one:

Re: 4.17.0-rc1 doesn't boot.

2018-04-17 16:27 GMT+02:00 Borislav Petkov : > On Tue, Apr 17, 2018 at 04:16:34PM +0200, Jörg Otte wrote: >> Current Linus master tree (4.17.0-rc1-00021-ga27fc14) does'nt fix it. > > Then pls continue bisecting. Unless someone has a better idea... > finished bisection.

Re: 4.17.0-rc1 doesn't boot.

2018-04-17 16:27 GMT+02:00 Borislav Petkov : > On Tue, Apr 17, 2018 at 04:16:34PM +0200, Jörg Otte wrote: >> Current Linus master tree (4.17.0-rc1-00021-ga27fc14) does'nt fix it. > > Then pls continue bisecting. Unless someone has a better idea... > finished bisection.

Re: 4.17.0-rc1 doesn't boot.

On Tue, Apr 17, 2018 at 04:16:34PM +0200, Jörg Otte wrote: > Current Linus master tree (4.17.0-rc1-00021-ga27fc14) does'nt fix it. Then pls continue bisecting. Unless someone has a better idea... -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

Re: 4.17.0-rc1 doesn't boot.

On Tue, Apr 17, 2018 at 04:16:34PM +0200, Jörg Otte wrote: > Current Linus master tree (4.17.0-rc1-00021-ga27fc14) does'nt fix it. Then pls continue bisecting. Unless someone has a better idea... -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.

Re: 4.17.0-rc1 doesn't boot.

2018-04-17 10:14 GMT+02:00 Borislav Petkov : > On Tue, Apr 17, 2018 at 10:00:25AM +0200, Jörg Otte wrote: >> Maybe the problem came in with: >> 6b0a02e: "Merge branch 'x86-pti-for-linus' of >> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" > > Fetch latest Linus master and

Re: 4.17.0-rc1 doesn't boot.

2018-04-17 10:14 GMT+02:00 Borislav Petkov : > On Tue, Apr 17, 2018 at 10:00:25AM +0200, Jörg Otte wrote: >> Maybe the problem came in with: >> 6b0a02e: "Merge branch 'x86-pti-for-linus' of >> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" > > Fetch latest Linus master and try again -

Re: 4.17.0-rc1 doesn't boot.

On Tue, Apr 17, 2018 at 10:00:25AM +0200, Jörg Otte wrote: > Maybe the problem came in with: > 6b0a02e: "Merge branch 'x86-pti-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" Fetch latest Linus master and try again - there might be a relevant fix there. -- Regards/Gruss,

Re: 4.17.0-rc1 doesn't boot.

On Tue, Apr 17, 2018 at 10:00:25AM +0200, Jörg Otte wrote: > Maybe the problem came in with: > 6b0a02e: "Merge branch 'x86-pti-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" Fetch latest Linus master and try again - there might be a relevant fix there. -- Regards/Gruss,

4.17.0-rc1 doesn't boot.

Hi, my notebook doesn't boot with 4.17.0-rc1. Booting stops right after displaying "loading initial ramdisk..". No further displays. Also nothing is wriiten to the logs. First known bad kernel is: 4.16.0-12564-g6b0a02e Last known good kernel is: 4.16.0-12548-g71b8ebb Maybe the pr

4.17.0-rc1 doesn't boot.

Hi, my notebook doesn't boot with 4.17.0-rc1. Booting stops right after displaying "loading initial ramdisk..". No further displays. Also nothing is wriiten to the logs. First known bad kernel is: 4.16.0-12564-g6b0a02e Last known good kernel is: 4.16.0-12548-g71b8ebb Maybe the pr

Re: arm64 kvm built with clang doesn't boot

e recently tried to boot clang built kernel on real hardware >> > (Odroid C2 board) instead of using a VM. The issue that I stumbled >> > upon is that arm64 kvm built with clang doesn't boot. >> > >> > Adding -fno-jump-tables compiler flag to arch/ar

Re: arm64 kvm built with clang doesn't boot

built kernel on real hardware >> > (Odroid C2 board) instead of using a VM. The issue that I stumbled >> > upon is that arm64 kvm built with clang doesn't boot. >> > >> > Adding -fno-jump-tables compiler flag to arch/arm64/kvm/* helps. There >> > was a p

Re: arm64 kvm built with clang doesn't boot

The thread I was thinking of is: http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/562953.html which is about b092201e0020614127f495c092e0a12d26a2116e `arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support`. As you mention, that commit uses the correct widths. Andrey had sent

Re: arm64 kvm built with clang doesn't boot

The thread I was thinking of is: http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/562953.html which is about b092201e0020614127f495c092e0a12d26a2116e `arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support`. As you mention, that commit uses the correct widths. Andrey had sent

Re: arm64 kvm built with clang doesn't boot

(+ Thomas) On 16 March 2018 at 17:13, Mark Rutland wrote: > On Fri, Mar 16, 2018 at 04:52:08PM +, Nick Desaulniers wrote: >> + Sami (Google), Takahiro (Linaro) >> >> Just so I fully understand the problem enough to articulate it, we'd be >> looking for the compiler to

Re: arm64 kvm built with clang doesn't boot

(+ Thomas) On 16 March 2018 at 17:13, Mark Rutland wrote: > On Fri, Mar 16, 2018 at 04:52:08PM +, Nick Desaulniers wrote: >> + Sami (Google), Takahiro (Linaro) >> >> Just so I fully understand the problem enough to articulate it, we'd be >> looking for the compiler to keep the jump tables

Re: arm64 kvm built with clang doesn't boot

On 16/03/18 16:52, Nick Desaulniers wrote: [dropping kernel-dynamic-to...@google.com which keeps bouncing] > Is this in regards to: commit "arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP > hardening support"? Has anyone tried to upstream a fix for this? We > probably want to be very explicit with

Re: arm64 kvm built with clang doesn't boot

On 16/03/18 16:52, Nick Desaulniers wrote: [dropping kernel-dynamic-to...@google.com which keeps bouncing] > Is this in regards to: commit "arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP > hardening support"? Has anyone tried to upstream a fix for this? We > probably want to be very explicit with

Re: arm64 kvm built with clang doesn't boot

On Fri, Mar 16, 2018 at 04:52:08PM +, Nick Desaulniers wrote: > + Sami (Google), Takahiro (Linaro) > > Just so I fully understand the problem enough to articulate it, we'd be > looking for the compiler to keep the jump tables for speed (I would guess > -fno-jump-tables would emit an if-else

Re: arm64 kvm built with clang doesn't boot

On Fri, Mar 16, 2018 at 04:52:08PM +, Nick Desaulniers wrote: > + Sami (Google), Takahiro (Linaro) > > Just so I fully understand the problem enough to articulate it, we'd be > looking for the compiler to keep the jump tables for speed (I would guess > -fno-jump-tables would emit an if-else

Re: arm64 kvm built with clang doesn't boot

+ Sami (Google), Takahiro (Linaro) Just so I fully understand the problem enough to articulate it, we'd be looking for the compiler to keep the jump tables for speed (I would guess -fno-jump-tables would emit an if-else chain) but only emit relative jumps (not absolute jumps)? > Perhaps Nick can

Re: arm64 kvm built with clang doesn't boot

+ Sami (Google), Takahiro (Linaro) Just so I fully understand the problem enough to articulate it, we'd be looking for the compiler to keep the jump tables for speed (I would guess -fno-jump-tables would emit an if-else chain) but only emit relative jumps (not absolute jumps)? > Perhaps Nick can

Re: arm64 kvm built with clang doesn't boot

On 16/03/18 14:53, Andrey Konovalov wrote: > On Fri, Mar 16, 2018 at 3:13 PM, Marc Zyngier wrote: >> I wasn't aware of that discussion, but this is indeed quite annoying. >> Note that you should be able to restrict this to arch/arm64/kvm/hyp/* >> and virt/kvm/arm/hyp/*. > >

Re: arm64 kvm built with clang doesn't boot

On 16/03/18 14:53, Andrey Konovalov wrote: > On Fri, Mar 16, 2018 at 3:13 PM, Marc Zyngier wrote: >> I wasn't aware of that discussion, but this is indeed quite annoying. >> Note that you should be able to restrict this to arch/arm64/kvm/hyp/* >> and virt/kvm/arm/hyp/*. > > That works as well

Re: arm64 kvm built with clang doesn't boot

On Fri, Mar 16, 2018 at 3:31 PM, Mark Rutland wrote: > > FWIW, with that same compiler and patch applied atop of v4.16-rc4, and > some bodges around clang not liking the rX register naming in the SMCCC > code, I get a kernel that boots on my Juno, though I immediately hit a

Re: arm64 kvm built with clang doesn't boot

On Fri, Mar 16, 2018 at 3:31 PM, Mark Rutland wrote: > > FWIW, with that same compiler and patch applied atop of v4.16-rc4, and > some bodges around clang not liking the rX register naming in the SMCCC > code, I get a kernel that boots on my Juno, though I immediately hit a > KASAN splat: > > [

Re: arm64 kvm built with clang doesn't boot

On Fri, Mar 16, 2018 at 3:13 PM, Marc Zyngier wrote: > I wasn't aware of that discussion, but this is indeed quite annoying. > Note that you should be able to restrict this to arch/arm64/kvm/hyp/* > and virt/kvm/arm/hyp/*. That works as well (tried it, the kernel boots).

Re: arm64 kvm built with clang doesn't boot

On Fri, Mar 16, 2018 at 3:13 PM, Marc Zyngier wrote: > I wasn't aware of that discussion, but this is indeed quite annoying. > Note that you should be able to restrict this to arch/arm64/kvm/hyp/* > and virt/kvm/arm/hyp/*. That works as well (tried it, the kernel boots). I've also tried

Re: arm64 kvm built with clang doesn't boot

On Fri, Mar 16, 2018 at 3:13 PM, Mark Rutland wrote: > I think that patch is our best bet currently, but to save ourselves pain > in future it would be *really* nice if GCC and clang could provide an > option line -fno-absolute-addressing that would implicitly disable any >

Re: arm64 kvm built with clang doesn't boot

On Fri, Mar 16, 2018 at 3:13 PM, Mark Rutland wrote: > I think that patch is our best bet currently, but to save ourselves pain > in future it would be *really* nice if GCC and clang could provide an > option line -fno-absolute-addressing that would implicitly disable any > feature that would

Re: arm64 kvm built with clang doesn't boot

issue that I stumbled > > upon is that arm64 kvm built with clang doesn't boot. > > > > Adding -fno-jump-tables compiler flag to arch/arm64/kvm/* helps. There > > was a patch some time ago that did exactly that > > (https://patchwork.kernel.org/patch/10060

Re: arm64 kvm built with clang doesn't boot

issue that I stumbled > > upon is that arm64 kvm built with clang doesn't boot. > > > > Adding -fno-jump-tables compiler flag to arch/arm64/kvm/* helps. There > > was a patch some time ago that did exactly that > > (https://patchwork.kernel.org/patch/10060

Re: arm64 kvm built with clang doesn't boot

Hi Andrey, On 16/03/18 13:49, Andrey Konovalov wrote: > Hi! > > I've recently tried to boot clang built kernel on real hardware > (Odroid C2 board) instead of using a VM. The issue that I stumbled > upon is that arm64 kvm built with clang doesn't boot. > > Adding -fno-jump

Re: arm64 kvm built with clang doesn't boot

Hi Andrey, On 16/03/18 13:49, Andrey Konovalov wrote: > Hi! > > I've recently tried to boot clang built kernel on real hardware > (Odroid C2 board) instead of using a VM. The issue that I stumbled > upon is that arm64 kvm built with clang doesn't boot. > > Adding -fno-jump

Re: arm64 kvm built with clang doesn't boot

On Fri, Mar 16, 2018 at 02:49:00PM +0100, Andrey Konovalov wrote: > Hi! Hi, > I've recently tried to boot clang built kernel on real hardware > (Odroid C2 board) instead of using a VM. The issue that I stumbled > upon is that arm64 kvm built with clang doesn't boot. > > Addin

Re: arm64 kvm built with clang doesn't boot

On Fri, Mar 16, 2018 at 02:49:00PM +0100, Andrey Konovalov wrote: > Hi! Hi, > I've recently tried to boot clang built kernel on real hardware > (Odroid C2 board) instead of using a VM. The issue that I stumbled > upon is that arm64 kvm built with clang doesn't boot. > > Addin

arm64 kvm built with clang doesn't boot

Hi! I've recently tried to boot clang built kernel on real hardware (Odroid C2 board) instead of using a VM. The issue that I stumbled upon is that arm64 kvm built with clang doesn't boot. Adding -fno-jump-tables compiler flag to arch/arm64/kvm/* helps. There was a patch some time ago that did

arm64 kvm built with clang doesn't boot

Hi! I've recently tried to boot clang built kernel on real hardware (Odroid C2 board) instead of using a VM. The issue that I stumbled upon is that arm64 kvm built with clang doesn't boot. Adding -fno-jump-tables compiler flag to arch/arm64/kvm/* helps. There was a patch some time ago that did

Re: 4.14.9 doesn't boot (regression)

On Sun, Dec 31, 2017 at 01:03:25AM +0300, Alexander Tsoy wrote: > > Turns out my previous code to print iret frames was a bit ... > > misguided, to put it nicely. Not sure what I was smoking. > > > > Hopefully the below patch should fix it (in place of the previous > > patch). Would you mind

Re: 4.14.9 doesn't boot (regression)

On Sun, Dec 31, 2017 at 01:03:25AM +0300, Alexander Tsoy wrote: > > Turns out my previous code to print iret frames was a bit ... > > misguided, to put it nicely. Not sure what I was smoking. > > > > Hopefully the below patch should fix it (in place of the previous > > patch). Would you mind

Re: 4.14.9 doesn't boot (regression)

В Sat, 30 Dec 2017 11:57:46 -0600 Josh Poimboeuf пишет: > On Sat, Dec 30, 2017 at 11:09:46AM -0600, Josh Poimboeuf wrote: > > On Sat, Dec 30, 2017 at 11:45:13AM +0300, Alexander Tsoy wrote: > > > В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет: > > > > On Fri, Dec

Re: 4.14.9 doesn't boot (regression)

В Sat, 30 Dec 2017 11:57:46 -0600 Josh Poimboeuf пишет: > On Sat, Dec 30, 2017 at 11:09:46AM -0600, Josh Poimboeuf wrote: > > On Sat, Dec 30, 2017 at 11:45:13AM +0300, Alexander Tsoy wrote: > > > В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет: > > > > On Fri, Dec 29, 2017 at 05:10:35PM

Re: 4.14.9 doesn't boot (regression)

On Sat, Dec 30, 2017 at 11:09:46AM -0600, Josh Poimboeuf wrote: > On Sat, Dec 30, 2017 at 11:45:13AM +0300, Alexander Tsoy wrote: > > В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет: > > > On Fri, Dec 29, 2017 at 05:10:35PM -0700, Andy Lutomirski wrote: > > > > (Also, Josh, the oops code

Re: 4.14.9 doesn't boot (regression)

On Sat, Dec 30, 2017 at 11:09:46AM -0600, Josh Poimboeuf wrote: > On Sat, Dec 30, 2017 at 11:45:13AM +0300, Alexander Tsoy wrote: > > В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет: > > > On Fri, Dec 29, 2017 at 05:10:35PM -0700, Andy Lutomirski wrote: > > > > (Also, Josh, the oops code

Re: 4.14.9 doesn't boot (regression)

On Sat, Dec 30, 2017 at 11:45:13AM +0300, Alexander Tsoy wrote: > В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет: > > On Fri, Dec 29, 2017 at 05:10:35PM -0700, Andy Lutomirski wrote: > > > (Also, Josh, the oops code should have printed the contents of the > > > struct pt_regs at the top of

Re: 4.14.9 doesn't boot (regression)

On Sat, Dec 30, 2017 at 11:45:13AM +0300, Alexander Tsoy wrote: > В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет: > > On Fri, Dec 29, 2017 at 05:10:35PM -0700, Andy Lutomirski wrote: > > > (Also, Josh, the oops code should have printed the contents of the > > > struct pt_regs at the top of

Re: 4.14.9 doesn't boot (regression)

On Sat, 30 Dec 2017, Toralf Förster wrote: > This made the issue go away : > > diff --git a/Makefile b/Makefile > index ac8c441866b7..11a12947c550 100644 > --- a/Makefile > +++ b/Makefile > @@ -414,7 +414,7 @@ LINUXINCLUDE:= \ > > KBUILD_AFLAGS := -D__ASSEMBLY__ > KBUILD_CFLAGS :=

Re: 4.14.9 doesn't boot (regression)

On Sat, 30 Dec 2017, Toralf Förster wrote: > This made the issue go away : > > diff --git a/Makefile b/Makefile > index ac8c441866b7..11a12947c550 100644 > --- a/Makefile > +++ b/Makefile > @@ -414,7 +414,7 @@ LINUXINCLUDE:= \ > > KBUILD_AFLAGS := -D__ASSEMBLY__ > KBUILD_CFLAGS :=

Re: 4.14.9 doesn't boot (regression)

On 12/30/2017 02:13 AM, Alexander Tsoy wrote: > You are right, It's due to fstack-check enabled in gentoo's gcc spec. > "-fstack-check=no" in KBUILD_CFLAGS fixed this problem for me. =/ This made the issue go away : diff --git a/Makefile b/Makefile index ac8c441866b7..11a12947c550 100644 ---

Re: 4.14.9 doesn't boot (regression)

On 12/30/2017 02:13 AM, Alexander Tsoy wrote: > You are right, It's due to fstack-check enabled in gentoo's gcc spec. > "-fstack-check=no" in KBUILD_CFLAGS fixed this problem for me. =/ This made the issue go away : diff --git a/Makefile b/Makefile index ac8c441866b7..11a12947c550 100644 ---

Re: 4.14.9 doesn't boot (regression)

On Fri, 29 Dec 2017, Linus Torvalds wrote: > Ok, so what does seem to be consistent for everybody is that > double-fault in the NMI backtrace. > > So the fact that the NMI always hits on a double-fault does make me > suspect that it's a infinite stream of double-faults, and that is > presumably

Re: 4.14.9 doesn't boot (regression)

On Fri, 29 Dec 2017, Linus Torvalds wrote: > Ok, so what does seem to be consistent for everybody is that > double-fault in the NMI backtrace. > > So the fact that the NMI always hits on a double-fault does make me > suspect that it's a infinite stream of double-faults, and that is > presumably

Re: 4.14.9 doesn't boot (regression)

On 12/30/2017 04:49 AM, Josh Poimboeuf wrote: > Alexander, would you mind reproducing again with the below patch? It > should still fail, but this time it should hopefully show another > RIP/RSP/EFLAGS instead of the "do_double_fault+0xb/0x140" line. I applied that too on top of

Re: 4.14.9 doesn't boot (regression)

On 12/30/2017 04:49 AM, Josh Poimboeuf wrote: > Alexander, would you mind reproducing again with the below patch? It > should still fail, but this time it should hopefully show another > RIP/RSP/EFLAGS instead of the "do_double_fault+0xb/0x140" line. I applied that too on top of

Re: 4.14.9 doesn't boot (regression)

On 12/30/2017 10:14 AM, Alexander Tsoy wrote: > Yes, and only in hardened profile, so most users don't have -fstack- > check by default. :) Indeed, I do run hardened Gentoo only. -- Toralf PGP C4EACDDE 0076E94E

Re: 4.14.9 doesn't boot (regression)

On 12/30/2017 10:14 AM, Alexander Tsoy wrote: > Yes, and only in hardened profile, so most users don't have -fstack- > check by default. :) Indeed, I do run hardened Gentoo only. -- Toralf PGP C4EACDDE 0076E94E

Re: 4.14.9 doesn't boot (regression)

В Пт, 29/12/2017 в 17:34 -0800, Linus Torvalds пишет: > On Fri, Dec 29, 2017 at 5:00 PM, Linus Torvalds > wrote: > > > > Good. I was not feeling so happy about this bug report, but now I > > can > > firmly just blame the gentoo compiler for having some shit-for- >

Re: 4.14.9 doesn't boot (regression)

В Пт, 29/12/2017 в 17:34 -0800, Linus Torvalds пишет: > On Fri, Dec 29, 2017 at 5:00 PM, Linus Torvalds > wrote: > > > > Good. I was not feeling so happy about this bug report, but now I > > can > > firmly just blame the gentoo compiler for having some shit-for- > > brains > > "feature". > >

Re: 4.14.9 doesn't boot (regression)

В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет: > On Fri, Dec 29, 2017 at 05:10:35PM -0700, Andy Lutomirski wrote: > > (Also, Josh, the oops code should have printed the contents of the > > struct pt_regs at the top of the DF stack.  Any idea why it > > didn't?) > > Looking at one of the

Re: 4.14.9 doesn't boot (regression)

В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет: > On Fri, Dec 29, 2017 at 05:10:35PM -0700, Andy Lutomirski wrote: > > (Also, Josh, the oops code should have printed the contents of the > > struct pt_regs at the top of the DF stack.  Any idea why it > > didn't?) > > Looking at one of the

Re: 4.14.9 doesn't boot (regression)

On 12/30/2017 01:10 AM, Andy Lutomirski wrote: > Toralf, can you send the complete output of: > > objdump -dr arch/x86/kernel/traps.o > > From the build tree of a nonworking kernel? I attached it. FWIW: tfoerste@t44 ~/devel/linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc

Re: 4.14.9 doesn't boot (regression)

On 12/30/2017 01:10 AM, Andy Lutomirski wrote: > Toralf, can you send the complete output of: > > objdump -dr arch/x86/kernel/traps.o > > From the build tree of a nonworking kernel? I attached it. FWIW: tfoerste@t44 ~/devel/linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc

Re: 4.14.9 doesn't boot (regression)

On Fri, Dec 29, 2017 at 05:10:35PM -0700, Andy Lutomirski wrote: > (Also, Josh, the oops code should have printed the contents of the > struct pt_regs at the top of the DF stack. Any idea why it didn't?) Looking at one of the dumps: [ 392.774879] NMI backtrace for cpu 0 [ 392.774881] CPU:

Re: 4.14.9 doesn't boot (regression)

On Fri, Dec 29, 2017 at 05:10:35PM -0700, Andy Lutomirski wrote: > (Also, Josh, the oops code should have printed the contents of the > struct pt_regs at the top of the DF stack. Any idea why it didn't?) Looking at one of the dumps: [ 392.774879] NMI backtrace for cpu 0 [ 392.774881] CPU:

Re: 4.14.9 doesn't boot (regression)

On Fri, Dec 29, 2017 at 5:00 PM, Linus Torvalds wrote: > > Good. I was not feeling so happy about this bug report, but now I can > firmly just blame the gentoo compiler for having some shit-for-brains > "feature". Looks like I can generate similar bad code with the

Re: 4.14.9 doesn't boot (regression)

On Fri, Dec 29, 2017 at 5:00 PM, Linus Torvalds wrote: > > Good. I was not feeling so happy about this bug report, but now I can > firmly just blame the gentoo compiler for having some shit-for-brains > "feature". Looks like I can generate similar bad code with the F26 version of gcc, it's just

Re: 4.14.9 doesn't boot (regression)

В Пт, 29/12/2017 в 17:10 -0700, Andy Lutomirski пишет: > > Also, you wouldn't happen to be using Gentoo perchance?  I already > have two reports of a Gentoo system miscompiling the vDSO due to > Gentoo enabling -fstack-check and GCC generating stack check code > that is highly suboptimal,

Re: 4.14.9 doesn't boot (regression)

В Пт, 29/12/2017 в 17:10 -0700, Andy Lutomirski пишет: > > Also, you wouldn't happen to be using Gentoo perchance?  I already > have two reports of a Gentoo system miscompiling the vDSO due to > Gentoo enabling -fstack-check and GCC generating stack check code > that is highly suboptimal,

Re: 4.14.9 doesn't boot (regression)

f On Fri, Dec 29, 2017 at 4:10 PM, Andy Lutomirski wrote: > > Double faults use IST, so a double fault that double faults will effectively > just start over rather than eventually running out of stack and triple > faulting. > > But check out the registers. We have RSP =

Re: 4.14.9 doesn't boot (regression)

f On Fri, Dec 29, 2017 at 4:10 PM, Andy Lutomirski wrote: > > Double faults use IST, so a double fault that double faults will effectively > just start over rather than eventually running out of stack and triple > faulting. > > But check out the registers. We have RSP = ...28fd8 and CR2 =

Re: 4.14.9 doesn't boot (regression)

> On Dec 29, 2017, at 3:53 PM, Linus Torvalds > wrote: > >> On Fri, Dec 29, 2017 at 2:30 PM, Toralf Förster >> wrote: >> >> The bad news - the issue is not solved with the changed cflags. >> The good news - I could compile eventually a

Re: 4.14.9 doesn't boot (regression)

> On Dec 29, 2017, at 3:53 PM, Linus Torvalds > wrote: > >> On Fri, Dec 29, 2017 at 2:30 PM, Toralf Förster >> wrote: >> >> The bad news - the issue is not solved with the changed cflags. >> The good news - I could compile eventually a working config for my desktop >> (works fine with

Re: 4.14.9 doesn't boot (regression)

On 12/29/2017 11:53 PM, Linus Torvalds wrote: > So just change the > > #ifdef CONFIG_X86_ESPFIX64 > > into a > > #if 0 > > and see if instead of the RCU stall after 20 seconds, you get an > immediate double fault error report instead? well, 3 IMG_20171230_0008* should show the results

Re: 4.14.9 doesn't boot (regression)

On 12/29/2017 11:53 PM, Linus Torvalds wrote: > So just change the > > #ifdef CONFIG_X86_ESPFIX64 > > into a > > #if 0 > > and see if instead of the RCU stall after 20 seconds, you get an > immediate double fault error report instead? well, 3 IMG_20171230_0008* should show the results

Re: 4.14.9 doesn't boot (regression)

On Fri, Dec 29, 2017 at 2:30 PM, Toralf Förster wrote: > > The bad news - the issue is not solved with the changed cflags. > The good news - I could compile eventually a working config for my desktop > (works fine with 4.14.10 with generic CPU) having a higher screen

Re: 4.14.9 doesn't boot (regression)

On Fri, Dec 29, 2017 at 2:30 PM, Toralf Förster wrote: > > The bad news - the issue is not solved with the changed cflags. > The good news - I could compile eventually a working config for my desktop > (works fine with 4.14.10 with generic CPU) having a higher screen resolution > during boot.

Re: 4.14.9 doesn't boot (regression)

On 12/29/2017 10:17 PM, Linus Torvalds wrote: > On Fri, Dec 29, 2017 at 1:02 PM, Toralf Förster > wrote: >> On 12/29/2017 09:12 PM, Linus Torvalds wrote: >>> instead, and see if that makes a difference, that would narrow down >>> the possible root cause of this problem.

Re: 4.14.9 doesn't boot (regression)

On 12/29/2017 10:17 PM, Linus Torvalds wrote: > On Fri, Dec 29, 2017 at 1:02 PM, Toralf Förster > wrote: >> On 12/29/2017 09:12 PM, Linus Torvalds wrote: >>> instead, and see if that makes a difference, that would narrow down >>> the possible root cause of this problem. >> >> not at this

Re: 4.14.9 doesn't boot (regression)

В Пт, 29/12/2017 в 13:39 -0800, Linus Torvalds пишет: > On Fri, Dec 29, 2017 at 1:17 PM, Linus Torvalds > wrote: > > > > Yeah, other reporters of this have used gcc-6.4.0 too. > > > > But there's been some muddying of the waters there too - changing > > compilers

Re: 4.14.9 doesn't boot (regression)

В Пт, 29/12/2017 в 13:39 -0800, Linus Torvalds пишет: > On Fri, Dec 29, 2017 at 1:17 PM, Linus Torvalds > wrote: > > > > Yeah, other reporters of this have used gcc-6.4.0 too. > > > > But there's been some muddying of the waters there too - changing > > compilers have fixed it for some cases,

Re: 4.14.9 doesn't boot (regression)

On Fri, Dec 29, 2017 at 1:17 PM, Linus Torvalds wrote: > > Yeah, other reporters of this have used gcc-6.4.0 too. > > But there's been some muddying of the waters there too - changing > compilers have fixed it for some cases, but there's at least one > report that a

Re: 4.14.9 doesn't boot (regression)

On Fri, Dec 29, 2017 at 1:17 PM, Linus Torvalds wrote: > > Yeah, other reporters of this have used gcc-6.4.0 too. > > But there's been some muddying of the waters there too - changing > compilers have fixed it for some cases, but there's at least one > report that a kernel build with gcc-7.2.0

Re: 4.14.9 doesn't boot (regression)

On Fri, Dec 29, 2017 at 1:02 PM, Toralf Förster wrote: > On 12/29/2017 09:12 PM, Linus Torvalds wrote: >> instead, and see if that makes a difference, that would narrow down >> the possible root cause of this problem. > > not at this ThinkPad T440s (didn't test at the

  1   2   3   >