В Пт, 29/12/2017 в 17:04 -0800, Dave Hansen пишет:
> On 12/29/2017 10:46 AM, Alexander Tsoy wrote:
> > В Пт, 29/12/2017 в 09:32 -0800, Dave Hansen пишет:
> > > Does anyone have the results of build that they can
> > > share? (vmlinux,
> > > vmlinuz/bzImage, System.map, .config). That, plus a
> >
В Пт, 29/12/2017 в 17:04 -0800, Dave Hansen пишет:
> On 12/29/2017 10:46 AM, Alexander Tsoy wrote:
> > В Пт, 29/12/2017 в 09:32 -0800, Dave Hansen пишет:
> > > Does anyone have the results of build that they can
> > > share? (vmlinux,
> > > vmlinuz/bzImage, System.map, .config). That, plus a
> >
On 12/29/2017 10:46 AM, Alexander Tsoy wrote:
> В Пт, 29/12/2017 в 09:32 -0800, Dave Hansen пишет:
>> Does anyone have the results of build that they can share? (vmlinux,
>> vmlinuz/bzImage, System.map, .config). That, plus a corresponding
>> serial log with an oops would be helpful.
>
> Here
On 12/29/2017 10:46 AM, Alexander Tsoy wrote:
> В Пт, 29/12/2017 в 09:32 -0800, Dave Hansen пишет:
>> Does anyone have the results of build that they can share? (vmlinux,
>> vmlinuz/bzImage, System.map, .config). That, plus a corresponding
>> serial log with an oops would be helpful.
>
> Here
On Fri, Dec 29, 2017 at 3:15 PM, Alexander Tsoy wrote:
> В Пт, 29/12/2017 в 14:09 -0800, Linus Torvalds пишет:
>>
>> What happens if you take a failing kernel, and then in
>> arch/x86/kernel/traps.c do_double_fault(), you change the
>>
>> #ifdef CONFIG_X86_ESPFIX64
>>
>> to
On Fri, Dec 29, 2017 at 3:15 PM, Alexander Tsoy wrote:
> В Пт, 29/12/2017 в 14:09 -0800, Linus Torvalds пишет:
>>
>> What happens if you take a failing kernel, and then in
>> arch/x86/kernel/traps.c do_double_fault(), you change the
>>
>> #ifdef CONFIG_X86_ESPFIX64
>>
>> to just a
>>
>> #if 0
В Пт, 29/12/2017 в 14:09 -0800, Linus Torvalds пишет:
>
...
> The fact that double faults seem to be implicated does make me want
> to
> try to disable that ESPFIX64 code in the #DF handler.
>
> What happens if you take a failing kernel, and then in
> arch/x86/kernel/traps.c do_double_fault(),
В Пт, 29/12/2017 в 14:09 -0800, Linus Torvalds пишет:
>
...
> The fact that double faults seem to be implicated does make me want
> to
> try to disable that ESPFIX64 code in the #DF handler.
>
> What happens if you take a failing kernel, and then in
> arch/x86/kernel/traps.c do_double_fault(),
On Fri, Dec 29, 2017 at 1:50 PM, Alexander Tsoy wrote:
>>
>> Ho humm. What happens if you change the "-march=core2" to
>> "-mtune=core2"? Does it still boot?
>
> That's interesting. Compiled with -mtune=core2, the kernel fails to
> boot.
[ Insert "twilight zone" theme music ]
On Fri, Dec 29, 2017 at 1:50 PM, Alexander Tsoy wrote:
>>
>> Ho humm. What happens if you change the "-march=core2" to
>> "-mtune=core2"? Does it still boot?
>
> That's interesting. Compiled with -mtune=core2, the kernel fails to
> boot.
[ Insert "twilight zone" theme music ]
Damn. I was hoping
В Пт, 29/12/2017 в 12:34 -0800, Linus Torvalds пишет:
> On Fri, Dec 29, 2017 at 12:22 PM, Alexander Tsoy
> wrote:
> > > But double-checking that "-march=core2" case is definitely worth
> > > looking into. Especially since there are clear indications that
> > > it's
> > > gcc
В Пт, 29/12/2017 в 12:34 -0800, Linus Torvalds пишет:
> On Fri, Dec 29, 2017 at 12:22 PM, Alexander Tsoy
> wrote:
> > > But double-checking that "-march=core2" case is definitely worth
> > > looking into. Especially since there are clear indications that
> > > it's
> > > gcc version-dependent
On Fri, Dec 29, 2017 at 12:22 PM, Alexander Tsoy wrote:
>> But double-checking that "-march=core2" case is definitely worth
>> looking into. Especially since there are clear indications that it's
>> gcc version-dependent anyway. Alexander?
>
> Yes, the change suggested by Dave
On Fri, Dec 29, 2017 at 12:22 PM, Alexander Tsoy wrote:
>> But double-checking that "-march=core2" case is definitely worth
>> looking into. Especially since there are clear indications that it's
>> gcc version-dependent anyway. Alexander?
>
> Yes, the change suggested by Dave makes the problem
В Пт, 29/12/2017 в 11:31 -0800, Linus Torvalds пишет:
> On Fri, Dec 29, 2017 at 9:32 AM, Dave Hansen
>
--->%---
> >
> > MCORE2 seems to get one oddball compiler flag (-march=core2):
> >
> > > cflags-$(CONFIG_MCORE2) += \
> > >
В Пт, 29/12/2017 в 11:31 -0800, Linus Torvalds пишет:
> On Fri, Dec 29, 2017 at 9:32 AM, Dave Hansen
>
--->%---
> >
> > MCORE2 seems to get one oddball compiler flag (-march=core2):
> >
> > > cflags-$(CONFIG_MCORE2) += \
> > > $(call
On Fri, Dec 29, 2017 at 9:32 AM, Dave Hansen wrote:
>
> From the various oopses, it looks like this happens when getting a
> double fault while trying to go idle. The CPU gets is probably trying
> to return from the double fault, but it didn't do anything useful in the
>
On Fri, Dec 29, 2017 at 9:32 AM, Dave Hansen wrote:
>
> From the various oopses, it looks like this happens when getting a
> double fault while trying to go idle. The CPU gets is probably trying
> to return from the double fault, but it didn't do anything useful in the
> fault handler so it just
В Пт, 29/12/2017 в 09:32 -0800, Dave Hansen пишет:
> Does anyone have the results of build that they can share? (vmlinux,
> vmlinuz/bzImage, System.map, .config). That, plus a corresponding
> serial log with an oops would be helpful.
Here you are:
В Пт, 29/12/2017 в 09:32 -0800, Dave Hansen пишет:
> Does anyone have the results of build that they can share? (vmlinux,
> vmlinuz/bzImage, System.map, .config). That, plus a corresponding
> serial log with an oops would be helpful.
Here you are:
Does anyone have the results of build that they can share? (vmlinux,
vmlinuz/bzImage, System.map, .config). That, plus a corresponding
serial log with an oops would be helpful.
I tried just adding MCORE2=y to my normal config but it didn't reproduce
this.
If you can't send the entire build
Does anyone have the results of build that they can share? (vmlinux,
vmlinuz/bzImage, System.map, .config). That, plus a corresponding
serial log with an oops would be helpful.
I tried just adding MCORE2=y to my normal config but it didn't reproduce
this.
If you can't send the entire build
В Пт, 29/12/2017 в 17:11 +0100, Thomas Gleixner пишет:
> On Fri, 29 Dec 2017, Alexander Tsoy wrote:
> > > Just tested Linus's master branch and it have the same problem.
> > > All I
> > > can catch with a serial console is the following:
> > >
>
> So for completeness sake:
>
>
В Пт, 29/12/2017 в 17:11 +0100, Thomas Gleixner пишет:
> On Fri, 29 Dec 2017, Alexander Tsoy wrote:
> > > Just tested Linus's master branch and it have the same problem.
> > > All I
> > > can catch with a serial console is the following:
> > >
>
> So for completeness sake:
>
>
On Fri, 29 Dec 2017, Alexander Tsoy wrote:
> > Just tested Linus's master branch and it have the same problem. All I
> > can catch with a serial console is the following:
> >
So for completeness sake:
MCORE2=y MCORE2=n
GCC5.xworks works
GCC6.xfail works
On Fri, 29 Dec 2017, Alexander Tsoy wrote:
> > Just tested Linus's master branch and it have the same problem. All I
> > can catch with a serial console is the following:
> >
So for completeness sake:
MCORE2=y MCORE2=n
GCC5.xworks works
GCC6.xfail works
В Пт, 29/12/2017 в 17:31 +0300, Alexander Tsoy пишет:
> В Пт, 29/12/2017 в 10:17 +0100, Greg KH пишет:
> > On Thu, Dec 28, 2017 at 12:33:22PM +0300, Alexander Tsoy wrote:
> > > Hello,
> > >
> > > 4.14.9 fails to boot if CONFIG_MCORE2 is enabled and when
&
В Пт, 29/12/2017 в 17:31 +0300, Alexander Tsoy пишет:
> В Пт, 29/12/2017 в 10:17 +0100, Greg KH пишет:
> > On Thu, Dec 28, 2017 at 12:33:22PM +0300, Alexander Tsoy wrote:
> > > Hello,
> > >
> > > 4.14.9 fails to boot if CONFIG_MCORE2 is enabled and when
&
В Пт, 29/12/2017 в 10:17 +0100, Greg KH пишет:
> On Thu, Dec 28, 2017 at 12:33:22PM +0300, Alexander Tsoy wrote:
> > Hello,
> >
> > 4.14.9 fails to boot if CONFIG_MCORE2 is enabled and when compiled
> > with
> > gcc 6+. More details in the following bug reports
В Пт, 29/12/2017 в 10:17 +0100, Greg KH пишет:
> On Thu, Dec 28, 2017 at 12:33:22PM +0300, Alexander Tsoy wrote:
> > Hello,
> >
> > 4.14.9 fails to boot if CONFIG_MCORE2 is enabled and when compiled
> > with
> > gcc 6+. More details in the following bug reports
On Thu, Dec 28, 2017 at 12:33:22PM +0300, Alexander Tsoy wrote:
> Hello,
>
> 4.14.9 fails to boot if CONFIG_MCORE2 is enabled and when compiled with
> gcc 6+. More details in the following bug reports:
> https://bugzilla.kernel.org/show_bug.cgi?id=198263
> https://bugs.gentoo
On Thu, Dec 28, 2017 at 12:33:22PM +0300, Alexander Tsoy wrote:
> Hello,
>
> 4.14.9 fails to boot if CONFIG_MCORE2 is enabled and when compiled with
> gcc 6+. More details in the following bug reports:
> https://bugzilla.kernel.org/show_bug.cgi?id=198263
> https://bugs.gentoo
Hello,
4.14.9 fails to boot if CONFIG_MCORE2 is enabled and when compiled with
gcc 6+. More details in the following bug reports:
https://bugzilla.kernel.org/show_bug.cgi?id=198263
https://bugs.gentoo.org/642268
I bisected it to the commit below:
$ git bisect good
Hello,
4.14.9 fails to boot if CONFIG_MCORE2 is enabled and when compiled with
gcc 6+. More details in the following bug reports:
https://bugzilla.kernel.org/show_bug.cgi?id=198263
https://bugs.gentoo.org/642268
I bisected it to the commit below:
$ git bisect good
34 matches
Mail list logo