BUG: unable to handle kernel paging request at 00023fa8

josephg

i have had this a few random times since i upgraded to 4.14 earlier this month.
never seen this on 4.9 kernels used before

eccerr0r · Posted: Sat Sep 22, 2018 6:39 am Post subject:

Unfortunately this dump would be quite hard to make heads or tails from.

Can you replicate the bug with a kernel that has CONFIG_KALLSYMS turned on, else you will need to get ksymoops run on this data with your System.map...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

josephg · Posted: Sat Sep 22, 2018 8:37 am Post subject:

Initially, I thought it might be caused by CONFIG_PGTABLE_MAPPING. So I unset it and recompiled this kernel. I guess that was not the cause, as I got it again.

Unfortunately, I don't know what causes this bug and when it happens. I've had it a few times, but not everyday or every time I do something. I don't know how to replicate it.

CONFIG_KALLSYMS is not turned on this kernel. I need to recompile this kernel, after I'm able to replicate this BUG.

I don't know how to use ksymoops. But I found a redhat man page. Not sure I can get my head around it.

And I can't find ksymoops in gentoo repos. But I found this:

NeddySeagoon · Posted: Sat Sep 22, 2018 9:27 am Post subject:

josephg,

Try 4.18.x, see if its fixed there. That's the gentoo testing kernel.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

josephg · Posted: Sat Sep 22, 2018 3:36 pm Post subject:

eccerr0r · Posted: Sat Sep 22, 2018 7:12 pm Post subject:

At this point, since the problem isn't easily repeatable and ksymoops may not be readily accessible, might well just build a new kernel with the debug symbols built in, ready for the next event.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

josephg · Posted: Sun Sep 23, 2018 1:56 am Post subject:

can i ask how/where did you get your ksymoops?

should i rebuild my kernel with debug symbols for normal runtime all the time, or just for catching bugs?

this bug hasn't happened all day today either. so i'm not really sure when it will happen again. i know when it happens though, because this laptop kinda hangs for a brief while and then comes back to life again like everything's ok.
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey

eccerr0r · Posted: Sun Sep 23, 2018 3:48 am Post subject:

I haven't used ksymoops for ages, got tired of keeping track of System.map -- all my kernels are built with the symbols -- makes oops/panics much easier to debug, and never have to deal with raw oops especially if it's not logged (e.g., "Not Syncing" or if failure happens before syslogd/journald starts).

Try https://mirrors.edge.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

josephg · Posted: Fri Sep 28, 2018 9:10 am Post subject:

Looking back, I think I got them after I started playing with nftables. I didn't get any further kernel bugs in my dmesg, after I removed all nftables from kernel and my system. I wonder if these could be linked. Perhaps not? So I enabled the nftables modules again in my kernel. And I caught this bug again yesterday, and the following one today

eccerr0r · Posted: Fri Sep 28, 2018 2:14 pm Post subject:

Interesting. This would indicate some problem with the memory manager / control groups and has no hints of network related issues. Whether it's a side effect of what you're using in your kernel has yet to be determined. The fact it's repeatable indicates your machine is building the kernel the same way.

Now I'd agree with Neddy and suggest trying a newer kernel, might be a bug in the particular kernel you're using that's being triggered by testing with nftables.

I wonder if it has something to do with the backpatch of PTI... :-( I have not been able to trigger this oops yet though I see some fairly similar oops on the goog.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

josephg · Posted: Sat Sep 29, 2018 11:41 am Post subject:

eccerr0r · Posted: Sat Sep 29, 2018 6:56 pm Post subject:

You can't disable the memory manager, it's a fundamental part of the OS. Disabling control groups will break new init software, so that would cause problems too.

User mode software should NOT trigger oops, so that shouldn't be an issue to use ccache unless it was causing it to build wrong. Worth trying if you think a build problem caused the bad code sequence.

You need to have backups in any case. I'd suggest copy your storage to another unit and try it with 4.18. I figure someday the upgrade will be forced.

BTW, how close are you to running out of RAM? In terms of this question, include cache and buffer memory as "used" memory (report "free" as-is without subtracting out anything...)

As I have yet to exhibit this bug I don't know how to trigger it...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

josephg · Posted: Sat Sep 29, 2018 11:10 pm Post subject:

eccerr0r · Posted: Sun Sep 30, 2018 6:30 am Post subject:

Then you may be okay to disable... thought that both openrc and systemd used cgroups to control resources during startup, maybe not.
It also will affect containers and if you're using it for portage, apparently. But it's not been needed (with consequences thereof) for years.

Well, the thing about the memory...how much memory is it using when the oops occurs, perhaps that is harder to gauge. Perhaps filling cache/buffers up can trigger the issue faster...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

josephg · Posted: Sun Oct 07, 2018 2:30 pm Post subject:

josephg · Posted: Mon Oct 08, 2018 12:46 am Post subject:

btw i have had none of these problems on 4.9 series. i've gone back to my backup kernel 4.9.122 and no issue. i've thrown everything at it, including nftables, android-studio, sdk, etc. and all together too. no hiccups. it had iptables which i've removed now. maybe i'll stay with 4.9 a bit longer. it's not like i have the latest hardware, and since last month i feel like i have been road testing bleeding-edge and troubleshooting all the time. i actually wondered if something wrong with my hardware.

same config for 4.9 and 4.14 kernels from gentoo-sources. no extra use-flags either.