Hi, On (09/04/18 20:01), Hans de Goede wrote: > Commit 375899cddcbb ("printk: make sure to print log on console."), moved > the checking of the loglevel of messages from flush time to the actual > log time. > > This introduces one problem, some early boot messages are printed before > parse_early_param() gets called and thus before kernel commandline options > such as quiet, loglevel and ignore_loglevel are parsed.
Do you use earlycon? > This causes e.g. the following messages to get printed on x86 systems, > despite the presence of the "quiet" option: > > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable > ... > [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000874ffffff] usable > > This commit fixes this by setting a new LOG_CHK_LEVEL on early boot > messages and doing the loglevel check for these while flushing as before. > Hmm, OK, chances are we need to re-think 375899cddcbb. It might be the case that we sort of broke CON_PRINTBUFFER handling. console_loglevel = CONSOLE_LOGLEVEL_MOTORMOUTH register CON_PRINTBUFFER console -> no debug output So I think that when console_unlock() re-flushes already seen logbuf messages to a newly registered exclusive [CON_PRINTBUFFER] console we probably need to look at the current console_loglevel in console_unlock() loop. -ss