Comment # 73 on bug 1188896 from Ihno Krumreich

Hi Rudi,

can you rety it with panic_on_taint=0x20 ?

(In reply to LTC BugProxy from comment #65)
> ------- 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 ...