You are not logged in.
Not very important part:
I used VirtualBox with x86 machine for ArchLinux. It was working well.
About 1-2 moths ago i did "pacman -Syu" and got dead system with kernel panic on boot. Solved by installing my old kernel.
Now i thought maybe problem was in kernel and i can upgrade now. I did "pacman -Syu" and got kernel panic on boot.
I downloaded "archlinux-2015.10.01-dual.iso" and attempted to boot from it, but got kernel panic.
I thought maybe my VirtualBox 4 is not good anymore and downloaded VirtualBox 5, but it is too buggy for me, impossible to use.
So i installed VMware 12, moved my machine there and got kernel panic too. Loaded from "archlinux-2015.10.01-dual.iso", got kernel panic. Loaded "archlinux-2015.09.01-dual.iso", got kernel panic.
Created new machine in VMware, loaded from .iso, got kernel panic.
*Need to say that loading ArchLinux x64 inside x86 machine in VMware is working great. But i don't understand why and how. And this is not what i need. In VirtualBox x86 machine there is no option to load x64 ArchLinux.
**Here is screenshot of kernel panic https://i.imgur.com/p18qZ5b.png
More important part:
Long story short, i found what is the reason. And here is steps to reproduce:
Host is AMD Phenom II X6 (6 cores) + Windows 7 x64 + VirtualBox 4.30.3 r101610
1)Open "Oracle VM VirtualBox Manager"
2)Create new ArchLinux x86 machine with default settings, but set CPU to 2 or more (in VMware i was using more than 1 core too)
3)Try to load i686 from "archlinux-2015.09.01-dual.iso" or "archlinux-2015.10.01-dual.iso" (didn't tested other)
4)It will kernel panic
I was using 4 cores for my machine, changed to 1 core and system successfully survived "pacman -Syu" and working, but with only 1 core.
But 1 core is too slow, how can i get back 4 cores?
Last edited by pico (2015-10-13 21:22:12)
Offline
https://forums.virtualbox.org/viewtopic.php?f=3&t=68991
Similar situation. Looks to be kernel related.
Offline
frank604,
I did "fixed" it once like that, but this is not okay i think. Some day some application will request newer kernel.
In URL you provided guy have exact same CPU that i have.
Can somebody reproduce kernel panic on other CPU? Or should i create thread in another place?
Offline
That sounds like https://bbs.archlinux.org/viewtopic.php?id=200290
Since kernel 4.1.x, an i686 system running on AMD multi cores crashes at boot.
This will be solved normally with kernel 4.3
See also : https://bugzilla.kernel.org/show_bug.cgi?id=101971
Moreover, the kernel-lts 4.2.x is also impacted.
Several mouths with a boot crash, It is fine, isn't it ?????
Offline
eburon, thank you very much. Will install 4.0 and wait for 4.3.
Offline
I see this log in the last changes on kernel 4.2.4 and 4.1.11 (lts)
commit ee2a52fc66229e0cd6213809bbba527759517ddf
Author: Borislav Petkov <bp@suse.de>
Date: Sat Aug 8 10:46:02 2015 +0200
cpu/cacheinfo: Fix teardown path
commit 2110d70c5e58326a10e93cfefdc0b3686e2ada12 upstream.
Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD
box. A fragment of the splat was enough to pinpoint the issue:
task: f58e0000 ti: f58e8000 task.ti: f58e800
EIP: 0060:[<c135a903>] EFLAGS: 00010206 CPU: 0
EIP is at free_cache_attributes+0x83/0xd0
EAX: 00000001 EBX: f589d46c ECX: 00000090 EDX: 360c2000
ESI: 00000000 EDI: c1724a80 EBP: f58e9ec0 ESP: f58e9ea0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: 000000ac CR3: 01731000 CR4: 000006d0
cache_shared_cpu_map_setup() did check sibling CPUs cacheinfo descriptor
while the respective teardown path cache_shared_cpu_map_remove() didn't.
Fix that.
>From tglx's version: to be on the safe side, move the cacheinfo
descriptor check to free_cache_attributes(), thus cleaning up the
hotplug path a little and making this even more robust.
Reported-and-tested-by: Philip Müller <philm@manjaro.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-kernel@vger.kernel.org
Cc: manjaro-dev@manjaro.org
Cc: Philip Müller <philm@manjaro.org>
Link: https://lkml.kernel.org/r/55B47BB8.6080202@manjaro.org
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>It seems that the issue with AMD multicore is fixed.
Wait and See
Offline