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):
> > …
> >
> >
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. Loo
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 wit
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 hint
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 migrate_disabl
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
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 (&qu
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
out.
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 fi
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 _
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 yo
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:
http://marc.info/?i=20180417150130.ga11...@ak-
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.
39114b7a743e6759bab4d96b7d96
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.
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 - ther
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,
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
lang 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
>> &g
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
(+ 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 for
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 reg
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 ch
+ 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
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 (tr
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:
>
> [
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
compiling
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 gene
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 exactly that
> > (https://patchwork.kernel.org/patch/100
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
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.
>
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 ag
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
Le 10/06/2015 20:17, Rob Herring a écrit :
On Wed, Jun 10, 2015 at 10:12 AM, leroy christophe
wrote:
Le 06/06/2015 17:32, Rob Herring a écrit :
On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy
wrote:
I've got a MPC8323 RDB evaluation platform from freescale
kernel 4.0 doesn't b
On Wed, Jun 10, 2015 at 10:12 AM, leroy christophe
wrote:
> Le 06/06/2015 17:32, Rob Herring a écrit :
>>
>> On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy
>> wrote:
>>>
>>> I've got a MPC8323 RDB evaluation platform from freescale
>>>
Le 06/06/2015 17:32, Rob Herring a écrit :
On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy
wrote:
I've got a MPC8323 RDB evaluation platform from freescale
kernel 4.0 doesn't boot
kernel 3.16 doesn't boot
kernel 3.15 boots ok
I disected the issue down to your commit "
Le 06/06/2015 17:32, Rob Herring a écrit :
On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy
wrote:
I've got a MPC8323 RDB evaluation platform from freescale
kernel 4.0 doesn't boot
kernel 3.16 doesn't boot
kernel 3.15 boots ok
I disected the issue down to your commit "
On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy
wrote:
> I've got a MPC8323 RDB evaluation platform from freescale
> kernel 4.0 doesn't boot
> kernel 3.16 doesn't boot
> kernel 3.15 boots ok
>
> I disected the issue down to your commit "of/fdt:
I've got a MPC8323 RDB evaluation platform from freescale
kernel 4.0 doesn't boot
kernel 3.16 doesn't boot
kernel 3.15 boots ok
I disected the issue down to your commit "of/fdt: Convert FDT functions
to use libfdt" (e6a6928c3ea1d0195ed75a091e345696b916c09b)
Do you
Hi!
Thanks for forwarding. There is a bug on redhat bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1155825
that might be related, but from what I can tell, the possible deadlock
reported there is only hypothetical.
/Thomas
On 10/24/2014 06:13 PM, Dmitry Torokhov wrote:
> Hi Steve,
>
> O
Kataria
Subject: Re: current mainline doesn't boot on VWware platform
Hi Steve,
On Sat, Oct 18, 2014 at 09:02:15PM -0500, Steve French wrote:
> Interesting to see that Fedora has similar problems with current
> kernel (I pulled mainline again a few hours ago).
>
> Fedora 20 x86_64 i
Hi Steve,
On Sat, Oct 18, 2014 at 09:02:15PM -0500, Steve French wrote:
> Interesting to see that Fedora has similar problems with current
> kernel (I pulled mainline again a few hours ago).
>
> Fedora 20 x86_64 in vmware boots to logon prompt but no mouse, no
> keyboard, system hung. Ctl-alt-f1
On Fri, 2014-10-17 at 18:52 -0500, Steve French wrote:
> This is vmware guest
Take this with a grain of salt, but you might need to manually update
their glue.
I was given a gratis copy of the thing with a license for a year. Not
being willing to pay to keep the license of a toy I have no real
Interesting to see that Fedora has similar problems with current
kernel (I pulled mainline again a few hours ago).
Fedora 20 x86_64 in vmware boots to logon prompt but no mouse, no
keyboard, system hung. Ctl-alt-f1 doesn't do anything. Even with
verbose on kernel boot line, the extra debug messa
Same thing happened after pulling newly updated mainline kernel
changes a few minutes ago.
Black screen on boot just when you would expect x to be starting.
Hung. Ctl-alt-F1 doesn't do anything.
arch is x86_64.
3.17.1 works. When I get time I will see if I can figure out more
useful info but th
This is vmware guest
sfrench@ubuntu:~/xfstests$ cat /proc/cpuinfo
processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 70
model name: Intel(R) Core(TM) i7-4750HQ CPU @ 2.00GHz
(and using 64 bit kernel build) ...
I don't have the Ubuntu config for their mainline kerne
Hi,
On Fri, Oct 17, 2014 at 05:44:02PM -0500, Steve French wrote:
> Anyone know a workaround for the problem booting current mainline?
> 3.17 works fine for me, but recent mainline since 3.17 goes to a black
> screen near the end of boot as X is about to start.
>
> I also tried the Ubuntu build o
Anyone know a workaround for the problem booting current mainline?
3.17 works fine for me, but recent mainline since 3.17 goes to a black
screen near the end of boot as X is about to start.
I also tried the Ubuntu build of the day (which also is based on
current mainline but with the Ubuntu config
Thanks for the pointers, guys. It took a while for me to figure out what
got wrong to foul up UML, but the bug and fix are trivial (posting now).
Some of the testing I thought had got done clearly wasn't done, since
PTRACE_SETREGS was 100% busticated for 32-bit processes calling ptrace on
x86_64 k
On Thu, Feb 21, 2008 at 06:20:23PM +0100, Miklos Szeredi wrote:
> Bisected it down to
>
> good e7b5e11eaaa8ef93a34e68016de51152d0d62911
> bad bde6f5f59c2b2b48a7a849c129d5b48838fe77ee
>
> I strongly suspect it's one of the ptrace cleanup patches. Roland,
> could you please have a look?
I agree.
> > > > - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any
> > > >other. Same guest boots fine on 2.6.24 host.
> > >
> > > What does it do?
> >
> > See below.
>
> This bug seems to have made it to mainlin
> > > - UML doesn't boot: guest is 2.6.24-mm1 also, haven't tried any
> > >other. Same guest boots fine on 2.6.24 host.
> >
> > What does it do?
>
> See below.
This bug seems to have made it to mainline as well, starting with
-rc1. Any ide
On Thu, 14 Feb 2008, Guennadi Liakhovetski wrote:
> 2.6.24.2 fails to boot on the above system with an Intel DQ35JO
> motherboard, as do Debian install kernels - both stock etch amd64 and
> updated image from Kenshi Muto (kmuto.jp). The only way to boot was with
> "acpi=off". Whereas ubuntu 7.1
Hi
2.6.24.2 fails to boot on the above system with an Intel DQ35JO
motherboard, as do Debian install kernels - both stock etch amd64 and
updated image from Kenshi Muto (kmuto.jp). The only way to boot was with
"acpi=off". Whereas ubuntu 7.10 amd64 2.6.22-based boot-CD boots without
problems. B
On Sat, 2008-02-09 at 19:39 +0100, Thomas Meyer wrote:
> H. Peter Anvin schrieb:
> > Thomas Meyer wrote:
> >> H. Peter Anvin schrieb:
> >>> Thomas Meyer wrote:
>
> I can not revert the commit
> e429795c68d3001ecae74f6465420c9f043b0ece. it gave me errors.
> but i'm also not sure
On Sat, 2008-02-09 at 19:39 +0100, Thomas Meyer wrote:
> H. Peter Anvin schrieb:
> > Thomas Meyer wrote:
> >> H. Peter Anvin schrieb:
> >>> Thomas Meyer wrote:
>
> I can not revert the commit
> e429795c68d3001ecae74f6465420c9f043b0ece. it gave me errors.
> but i'm also not sur
H. Peter Anvin schrieb:
Thomas Meyer wrote:
H. Peter Anvin schrieb:
Thomas Meyer wrote:
I can not revert the commit
e429795c68d3001ecae74f6465420c9f043b0ece. it gave me errors.
but i'm also not sure what could be wrong with this commit!
my first idea was that the commit
"[2215e69d2cf50246
Thomas Meyer wrote:
H. Peter Anvin schrieb:
Thomas Meyer wrote:
I can not revert the commit e429795c68d3001ecae74f6465420c9f043b0ece.
it gave me errors.
but i'm also not sure what could be wrong with this commit!
my first idea was that the commit
"[2215e69d2cf5024647f9a034807990590d25dd4e]
H. Peter Anvin schrieb:
Thomas Meyer wrote:
I can not revert the commit e429795c68d3001ecae74f6465420c9f043b0ece.
it gave me errors.
but i'm also not sure what could be wrong with this commit!
my first idea was that the commit
"[2215e69d2cf5024647f9a034807990590d25dd4e] x86 boot: use E820 m
Thomas Meyer wrote:
I can not revert the commit e429795c68d3001ecae74f6465420c9f043b0ece. it
gave me errors.
but i'm also not sure what could be wrong with this commit!
my first idea was that the commit
"[2215e69d2cf5024647f9a034807990590d25dd4e] x86 boot: use E820 memory
map on EFI 32 plat
H. Peter Anvin schrieb:
[EMAIL PROTECTED] wrote:
The latest linux kernel doesn't boot on my computer
(h=21511abd0a248a3f225d3b611cfabb93124605a7).
elilo hangs while booting this kernel. 2.6.24 works.
Wow, so we know it's affected with EFI, since you're using elilo.
You gave
Zitat von "H. Peter Anvin" <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
> > The latest linux kernel doesn't boot on my computer
> > (h=21511abd0a248a3f225d3b611cfabb93124605a7).
> >
> > elilo hangs while booting this kernel. 2.6.24 works.
&g
[EMAIL PROTECTED] wrote:
The latest linux kernel doesn't boot on my computer
(h=21511abd0a248a3f225d3b611cfabb93124605a7).
elilo hangs while booting this kernel. 2.6.24 works.
Wow, so we know it's affected with EFI, since you're using elilo.
You gave absolutely zero other in
The latest linux kernel doesn't boot on my computer
(h=21511abd0a248a3f225d3b611cfabb93124605a7).
elilo hangs while booting this kernel. 2.6.24 works.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More ma
On Wed, 17 Oct 2007 02:33:19 +0200 Rafael J. Wysocki wrote:
> Hi,
>
> As stated in the subject, I cannot boot the current -git (most recent commit
> 821f3eff7cdb9d6c7076effabd46c96c322daed1) using GRUB on x86-64 openSUSE 10.2.
>
> The GRUB says that the kernel image is too big and doesn't fit in
Hi,
As stated in the subject, I cannot boot the current -git (most recent commit
821f3eff7cdb9d6c7076effabd46c96c322daed1) using GRUB on x86-64 openSUSE 10.2.
The GRUB says that the kernel image is too big and doesn't fit into memory, but
the kernel has been built and installed in exactly the sam
* Oliver Bock <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> Thanks for your reply. I tried -rt12 and could successfully boot my system.
> However, now I find the following during boot:
>
> registering clocksource pit
these messages are fine - they are just for debugging.
Ingo
-
To unsubsc
Hi Ingo,
Thanks for your reply. I tried -rt12 and could successfully boot my system.
However, now I find the following during boot:
registering clocksource pit
[] clocksource_register+0x2f/0x130
[] sysdev_register+0xf4/0x100
[] init_pit_clocksource+0x60/0x70
[] init+0x8f/0x310
[] ret_from_fo
* Oliver Bock <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> I tried to boot a vanilla 2.6.19 kernel with your 2.6.19-rt11 patch
> but without success. However, the patch applied without a single error
> and the vanilla kernel (without the patch) works fine so far. As my
> screen just stays black
Hi Ingo,
I tried to boot a vanilla 2.6.19 kernel with your 2.6.19-rt11 patch but
without success. However, the patch applied without a single error and the
vanilla kernel (without the patch) works fine so far. As my screen just stays
black and as there's no HD activity after selecting the kerne
1 - 100 of 123 matches
Mail list logo
