You are not logged in.
@ukhippo
it's already done
I used for the first time a live cd and " chroot " to downgrade the kernel .
It was also a good time to install linux- lts ...
Thank you
Offline
UKhippo - thanks again. I have the lts kernel in the cache. and had it installed, but had no entry for syslinux.
My instinct is to wait, but in an emergency I had load lts.
This is not my original post, so I will NOT mark it as SOLVED
Offline
Merging Threads
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Attempted to upgrade to linux-4.1.4-1. Kernel panic persists.
Had to move back to linux-lts and nvidia-lts
Offline
Same problem here on a AMD Phenom II X4 965 Processor.
I tried linux-4.1.4-1 but kernel panic persists.
I use 4.0.7-2 which works fine.
Offline
Do the kernel people even know about this and are they working on a fix? Two or three upgrades to the kernel already happened with no fix, that's pretty pathetic on their end.
"An it harm none, do what thou wilt"
Offline
Do the kernel people even know about this and are they working on a fix? Two or three upgrades to the kernel already happened with no fix, that's pretty pathetic on their end.
Do you have a link to the bug report you filed?
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Kernel bug report: https://bugzilla.kernel.org/show_bug.cgi?id=101971
I also have this issue (Phenom II X4 965 processor)
If I code something, it's probably at https://github.com/kellcodes
Do **NOT** expect a response from me.
Offline
To fix this, simply apply the patch. For more detail follow my initial bug report and my bisect project on that matter.
Offline
I think I'm getting the same kernel panic, but it's showing up errors in my RAID array (resyncs and checks show no problems).
This is on an AMD 64 bit processor (but not a Phenom).
Aug 06 03:52:08 server kernel: BUG: unable to handle kernel NULL pointer dereference at (null)
Aug 06 03:52:08 server kernel: IP: [<ffffffffa06dcb91>] get_free_stripe+0x31/0xf0 [raid456]
Aug 06 03:52:08 server kernel: PGD 18729067 PUD 18720067 PMD 0
Aug 06 03:52:08 server kernel: Oops: 0000 [#1] PREEMPT SMP
Aug 06 03:52:08 server kernel: Modules linked in: raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx amdkfd amd_iommu_v2 radeon raid6_pq
Aug 06 03:52:08 server kernel: CPU: 0 PID: 7733 Comm: miniserv.pl Not tainted 4.1.4-1-ARCH #1
Aug 06 03:52:08 server kernel: Hardware name: HP ProLiant MicroServer, BIOS O41 01/17/2011
Aug 06 03:52:08 server kernel: task: ffff8801a4531460 ti: ffff880018784000 task.ti: ffff880018784000
Aug 06 03:52:08 server kernel: RIP: 0010:[<ffffffffa06dcb91>] [<ffffffffa06dcb91>] get_free_stripe+0x31/0xf0 [raid456]
Aug 06 03:52:08 server kernel: RSP: 0018:ffff880018787868 EFLAGS: 00010082
Aug 06 03:52:08 server kernel: RAX: fffffffffffffff0 RBX: 0000000000000000 RCX: 00000000000000ff
Aug 06 03:52:08 server kernel: RDX: 0000000100100001 RSI: 00000000ffffffff RDI: ffff8800d78cf800
Aug 06 03:52:08 server kernel: RBP: ffff880018787898 R08: ffff880214ae5340 R09: ffff880214ae4d00
Aug 06 03:52:08 server kernel: R10: ffffea0006e1c000 R11: 0000000000019d48 R12: ffff8800d78cf800
Aug 06 03:52:08 server kernel: R13: ffff8800d78cf806 R14: ffff8800d78cf968 R15: 0000000000000080
Aug 06 03:52:08 server kernel: FS: 00007f5e4e944700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
Aug 06 03:52:08 server kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Aug 06 03:52:08 server kernel: CR2: 0000000000000000 CR3: 0000000018773000 CR4: 00000000000007f0
Aug 06 03:52:08 server kernel: Stack:
Aug 06 03:52:08 server kernel: ffff880018787898 00000000ffffffff ffff8800d78cf800 ffff8800d78cf806
Aug 06 03:52:08 server kernel: 0000000000001600 0000000000000080 ffff8800187878c8 ffffffffa06e1784
Aug 06 03:52:08 server kernel: ffff8800187878c8 0000000000000077 ffff880018787990 ffff8800d78cf800
Aug 06 03:52:08 server kernel: Call Trace:
Aug 06 03:52:08 server kernel: [<ffffffffa06e1784>] drop_one_stripe+0x44/0xb0 [raid456]
Aug 06 03:52:08 server kernel: [<ffffffffa06e1835>] raid5_cache_scan+0x45/0x60 [raid456]
Aug 06 03:52:08 server kernel: [<ffffffff81179219>] shrink_slab+0x229/0x440
Aug 06 03:52:08 server kernel: [<ffffffff8118ec00>] ? compaction_suitable+0xe0/0x150
Aug 06 03:52:08 server kernel: [<ffffffff8117cb3a>] shrink_zone+0x2ca/0x2e0
Aug 06 03:52:08 server kernel: [<ffffffff8117ccc3>] do_try_to_free_pages+0x173/0x410
Aug 06 03:52:08 server kernel: [<ffffffff8117d007>] try_to_free_pages+0xa7/0x1a0
Aug 06 03:52:08 server kernel: [<ffffffff8116fc3f>] __alloc_pages_nodemask+0x5ff/0x9e0
Aug 06 03:52:08 server kernel: [<ffffffff811b8823>] alloc_pages_vma+0x1f3/0x270
Aug 06 03:52:08 server kernel: [<ffffffff811cf68b>] do_huge_pmd_wp_page+0x63b/0xb30
Aug 06 03:52:08 server kernel: [<ffffffff8119548e>] ? do_wp_page+0x12e/0x630
Aug 06 03:52:08 server kernel: [<ffffffff81197a75>] handle_mm_fault+0x2b5/0x18c0
Aug 06 03:52:08 server kernel: [<ffffffff81066bef>] ? __do_page_fault+0x18f/0x4b0
Aug 06 03:52:08 server kernel: [<ffffffff81066bd2>] __do_page_fault+0x172/0x4b0
Aug 06 03:52:08 server kernel: [<ffffffff81066f32>] do_page_fault+0x22/0x30
Aug 06 03:52:08 server kernel: [<ffffffff8158de28>] page_fault+0x28/0x30
Aug 06 03:52:08 server kernel: Code: 48 63 c6 48 c1 e0 04 48 89 e5 41 57 41 56 4c 8d b4 07 78 01 00 00 41 55 41 54 53 48 83 ec 08 49 8b 1e 49 39 de 0f 84 b7
Aug 06 03:52:08 server kernel: RIP [<ffffffffa06dcb91>] get_free_stripe+0x31/0xf0 [raid456]
Aug 06 03:52:09 server kernel: RSP <ffff880018787868>
Aug 06 03:52:09 server kernel: CR2: 0000000000000000
Aug 06 03:52:09 server kernel: ---[ end trace 6cd3e57ddc32c798 ]---
A downgrade to 4.0.X fixed it as well.
Offline
Any news? What about linux 4.1.5-1? Has anybody tried it? Unfortunately I've no time for new troubles in these days
Offline
Well, according to this link posted on the bug report (bug 101971), the fix might not be out until 4.3-rc1:
https://lists.manjaro.org/pipermail/man … 00579.html
Can anyone confirm? Is archlinux going to apply the patch internally? I'm not very familiar with how they handle this stuff
Last edited by kev717 (2015-08-19 16:20:23)
If I code something, it's probably at https://github.com/kellcodes
Do **NOT** expect a response from me.
Offline
Just tried 4.1.5... Still same problem.
Offline
Following the suggestion of philm, I copied the patch and looked for the ./drivers/base/cacheinfo in /usr/lib/modules/4.1.4-1-ARCH/kernel/drivers/base
and do not find the file cacheinfo in base to patch.
Since I have never patched a kernel before, I may be looking in the wrong place. The directions for the patch command are clear enough. Any suggestions would be appreciated.
Offline
4.1.6: still doesn't work.
If I code something, it's probably at https://github.com/kellcodes
Do **NOT** expect a response from me.
Offline
I had this same problem with 4.1.6-1 with Arch installed as a guest in a Virtualbox VM, using encrypted partitions and LVM.
Installing the linux-lts kernel works for me, so there's some regression in 4.1.6.
Offline
linux 4.2.1-1?? Has anybody tried with it?
Offline
linux 4.2.1-1... Still same problem.
Offline
Version 4.2.1-1 still seems to have this issue. This is the slowest response to a kernel bug I've ever seen...
Also, bad news for anyone who fixed this by installing the LTS version of the kernel: this bug is present in Linux-LTS version 4.1.8 currently available on the arch repos.
Last edited by kev717 (2015-09-29 16:42:59)
If I code something, it's probably at https://github.com/kellcodes
Do **NOT** expect a response from me.
Offline
linux 4.2.3-1... Still not fixed.
Offline
So, we must probably wait for linux 4.3. I hope the whole system won't encounter any problem with the old 4.0.7 kernel.
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
My friend had similar problem with kernel panic on linux-lts 4.1.10-2. Problem occured when he switched to lzop compression in mkinitcpio.conf. I'm using lzop on two Arch powered machines, but I had no problems myself. In the end changing back to default gzip solved problem for him.
His CPU is Intel i5-4210U
Last edited by Rethil (2015-10-24 10:30:18)
Offline
I can confirm that linux-lts 4.1.11-1 fixes the issue. I have not yet tried the non-LTS kernel.
If I code something, it's probably at https://github.com/kellcodes
Do **NOT** expect a response from me.
Offline
linux 4.2.4-1 is fixed... Although, I see it's already marked as out of date, and 4.2.5-1 is in testing.
I'm not sure if this thread should be marked as SOLVED - or who's responsible for that -there've been several thread merges to date.
Offline