https://bugzilla.suse.com/show_bug.cgi?id=1188896 https://bugzilla.suse.com/show_bug.cgi?id=1188896#c65 --- Comment #65 from LTC BugProxy <bugproxy@us.ibm.com> --- ------- Comment From geraldsc@de.ibm.com 2022-02-18 09:58 EDT------- (In reply to comment #61)

...

This should not be a problem when we have a dump with panic_on_taint setting, as that would immediately stop the system at the interesting part, and not have all the follow-on messages.

well, as you can see in the buildlog file, panic_on_taint=5 is set in the kernel commandline, it just did not have any effect.

Sorry, after looking more closely to the kernel code, TAINT_BAD_PAGE has bit number 5, but the panic_on_taint parameter has to be the "Hexadecimal bitmask representing the set of TAINT flags that will cause the kernel to panic". So that would mean that we need a "panic_on_taint=0x20" parameter instead. BTW, the buildlog also shows a "panic=1" parameter, which would add a 1 sec delay before panic. Since we want to be as close as possible to the detection of "Bad page", you might want to remove that. Is there a reason for setting this timeout? Also, buildlog shows that the "Bad page" did occur, again before all the rest went wrong. It also shows this: [ 84s] Increasing log level from now on... [ 84s] [ 27.967679][ T383] sysrq: Changing Loglevel [ 84s] [ 27.967746][ T383] sysrq: Loglevel set to 4 Would it be possible to set the loglevel to 8, or at least 5, so that you would also see KERN_WARNING messages? All the interesting stuff after "Bad page" will be printed with KERN_WARNING, only the "Bad page" line itself is printed with KERN_ALERT, which is why we only see this line in the buildlog. Given that you seem to have such troubles accessing the kernel message log, I would recommend to permanently change the loglevel to at least 5, better 8, to catch them all in your buildlog. Not sure where you'd need to change that, as it seems to be set during run-time and not by kernel parameter. Or add "ignore_loglevel" kernel parameter, but not entirely sure if run-time setting might override this again. OTOH, you probably have reasons to reduce loglevel, but at least using 5 instead of 4 would give so much more useful kernel messages printed with KERN_WARNING ... -- You are receiving this mail because: You are the assignee for the bug.