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 tes
В 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
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 shoul
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 th
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 := -Wa
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
--- a/Ma
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
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 v4.15-rc5-114-g27
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
В Пт, 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".
>
> Loo
В Пт, 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 dum
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
COLLECT_LTO_WRAPP
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:
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 n
В Пт, 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, actively
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 = ...2
> 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 4.1
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 http
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.
>
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 ThinkPad
В Пт, 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, bu
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 sti
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 server with an i7-3930).
>
>
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 server with an i7-3930).
Boot stops just at:
tsc: Refined TSC clocksource calibrat
* Linus Torvalds wrote:
> On Fri, Dec 29, 2017 at 3:14 AM, Toralf Förster
> wrote:
> >
> > For the server the attached .config works fine but switching from
> > CONFIG_GENERIC_CPU to CONFIG_MCORE2 legt them hang at boot w/op any
> > messages. Similar picture at the desktop.
>
> Ok, so there's
On Fri, Dec 29, 2017 at 3:14 AM, Toralf Förster wrote:
>
> For the server the attached .config works fine but switching from
> CONFIG_GENERIC_CPU to CONFIG_MCORE2 legt them hang at boot w/op any
> messages. Similar picture at the desktop.
Ok, so there's another thread ("4.14.9 with CONFIG_MCORE2
On 12/29/2017 04:48 PM, Alexander Tsoy wrote:
> В Пт, 29/12/2017 в 12:14 +0100, Toralf Förster пишет:
>> I can confirm now, that that kernel breaks both a desktop (an
>> ThinkPad T440s i5) and a headless server (i3930) setup. For the
>> server the attached .config works fine but switching from
>> C
В Пт, 29/12/2017 в 12:14 +0100, Toralf Förster пишет:
> I can confirm now, that that kernel breaks both a desktop (an
> ThinkPad T440s i5) and a headless server (i3930) setup. For the
> server the attached .config works fine but switching from
> CONFIG_GENERIC_CPU to CONFIG_MCORE2 legt them hang at
On Fri, Dec 29, 2017 at 3:38 PM, Toralf Förster wrote:
> On 12/29/2017 02:33 PM, Sebastian Gottschall wrote:
>> bootlog?
>>
> nothing in any logs, hang happens very early in the boot process
Does it have serial?
Does it use EFI?
You may try earlyprintk for EFI case or legacy UART.
There was sup
On 12/29/2017 02:33 PM, Sebastian Gottschall wrote:
> bootlog?
>
nothing in any logs, hang happens very early in the boot process
--
Toralf
PGP C4EACDDE 0076E94E
bootlog?
Am 29.12.2017 um 12:14 schrieb Toralf Förster:
I can confirm now, that that kernel breaks both a desktop (an ThinkPad T440s
i5) and a headless server (i3930) setup. For the server the attached .config
works fine but switching from CONFIG_GENERIC_CPU to CONFIG_MCORE2 legt them
hang at
I can confirm now, that that kernel breaks both a desktop (an ThinkPad T440s
i5) and a headless server (i3930) setup. For the server the attached .config
works fine but switching from CONFIG_GENERIC_CPU to CONFIG_MCORE2 legt them
hang at boot w/op any messages. Similar picture at the desktop.
Bo
32 matches
Mail list logo
