Summary: | =sys-kernel/gentoo-sources-4.15.0: BUG: unable to handle kernel NULL pointer dereference at (null) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Sergeyev <sergeev917> |
Component: | Current packages | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jstein, viklevin2 |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cbd7b8a76b79a2ff6112ef2e77031b694843b8a1 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
null pointer dereference screen
multi calltrace screen freeze screen (no kallsyms) kernel configuration patch, suitable for epatch() on 4.15 |
Description
Alexander Sergeyev
2018-02-02 19:32:08 UTC
Created attachment 517610 [details]
null pointer dereference screen
Created attachment 517612 [details]
multi calltrace screen
Created attachment 517614 [details]
freeze screen (no kallsyms)
Created attachment 517616 [details]
kernel configuration
Note: configuration includes efi stub and compiled-in cmdline (redacted out).
I will soon try to bisect the bug using the linux-stable repository. I've started doing so a day ago, but failed to get through with it due to unsufficient time available. Though, strange things happened shortly after the unsuccessfull kernel upgrade. I rolled back to a known-good 4.14.12 kernel and experienced another issue (didn't happen before): waking up from the suspend-to-ram state, my machine instantly rebooted (consequently reproduced). BIOS settings interface gave me unusual freezes couple of times (long freezes, like a minute or so), but after switching POST diagnostic mode from minimal to thorough -- I can no longer reproduce the problem with suspend-to-ram. Having all that said, I'm not really sure that bisecting will be reliable -- since it appears that some state is preserved during kernel switches. I mean I already have a previosly reliable kernel giving me a new problem (reboots during wakeups). It might be an irrelevant hardware failure, but it sure seems like too big of a coincidence to me. Anyway, I would really appreciate some guidance here. Upstream patch (not merged so far): https://patchwork.kernel.org/patch/10194287/ Also see https://lkml.org/lkml/2018/2/3/113 I rebased the patch for 4.15, it's attached. Created attachment 517766 [details, diff]
patch, suitable for epatch() on 4.15
The patch is merged into mainline: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cbd7b8a76b79a2ff6112ef2e77031b694843b8a1 thanks patch upstreamed in 4.15.7 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.7 still not upstream added in gentoo-sources-4.15.7 There is a bug in genpatches-4.15.8.base 2901_allocate_buffer_on_heap_rather_than_globally.patch Make 4.15.7 kernel fail with drivers/platform/x86/dell-laptop.c: In function ‘dell_rfkill_set’: drivers/platform/x86/dell-laptop.c:441:2: error: implicit declaration of function ‘dell_fill_request’; did you mean ‘dell_send_request’? [-Werror=implicit-function-declaration] dell_fill_request(&buffer, 0, 0, 0, 0); > There is a bug in genpatches-4.15.8.base
In the original patch (the function is renamed):
17 -static void dell_set_arguments(u32 arg0, u32 arg1, u32 arg2, u32 arg3)
18 +static void dell_fill_request(struct calling_interface_buffer *buffer,
19 + u32 arg0, u32 arg1, u32 arg2, u32 arg3)
In 2901_allocate_buffer_on_heap_rather_than_globally.patch:
15 -void dell_set_arguments(u32 arg0, u32 arg1, u32 arg2, u32 arg3)
16 +void dell_set_arguments(struct calling_interface_buffer *buffer,
17 + u32 arg0, u32 arg1, u32 arg2, u32 arg3)
oh, i missed that. I will add a revision in some hour. added, someone can confirm me that it work ? > can confirm me that it work?
Well, it definitely works on 4.15.2 since I'm using the exact same patch via epatch. The only changed file is dell-laptop.c and it haven't been touched between 4.15.2 and 4.15.7. So, everything should be fine. I will be able to try 4.15.7-r1 when egencache is completed, it takes some time.
> I will be able to try 4.15.7-r1
Compiled and running without problems.
ok so we can close this |