Messages in this thread | | | From | Peter Geis <> | Date | Fri, 10 Jun 2022 11:34:47 -0400 | Subject | Re: [BUG] Threaded printk breaks early debugging |
| |
On Fri, Jun 10, 2022 at 11:05 AM John Ogness <john.ogness@linutronix.de> wrote: > > Hi Peter, > > On 2022-06-10, Peter Geis <pgwipeout@gmail.com> wrote: > > However I've run into an issue debugging early boot issues. Anything > > that causes the kernel threading system to die (for example here, a > > NPE) causes the boot console to halt before it outputs the error. > > A null pointer exception should trigger a panic, which will cause printk > to enter direct mode for the oops. It should be just as effective as > before introducing the printing kthreads.
This might be a side effect of the fact that this is on a low powered arm64 board. I noticed with threading enabled during large bursts the console drops an excessive amount of messages. It's especially apparent during the handover from earlycon to the normal console.
> > Can you please provide a test case or patch that will trigger the > problem you refer to?
Unfortunately no, unless you have a Rockchip rk356x device with both DSI and HDMI. We're working on adding DSI support to the new video output driver, and when both are enabled it tosses a NPE.
> > > Would it be possible to have both a kconfig option and a runtime > > option to toggle printk_fallback_preferred_direct()? Currently I've > > had to force it at all times while debugging. > > It would be trivial to provide a boot parameter for this behavior, but I > think we first need to see a real problem and also see if we can fix > that problem. > > John Ogness
| |