Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 20 Jun 2022 08:48:29 -0500 | Subject | Re: Boot stall regression from "printk for 5.19" merge |
| |
On Mon, Jun 20, 2022 at 6:44 AM Petr Mladek <pmladek@suse.com> wrote: > > Both early console and proper console driver has its own kthread. > > > 1.166486] f0512000.serial: ttyS0 at MMIO 0xf0512000 (irq = 22, base_baud = 12500000) is a 16550A > > The line is malformed. I wonder if both early console and proper > console used the same port in parallel.
Honestly, I get the feeling that we need to just revert the whole "console from thread" thing.
Because:
> So, it looks like that con->write() code is not correctly serialized > between the early and normal console. > [ ... ] > I am going to check the driver...
We really cannot be in the situation that some random driver that used to work no longer does, and causes oopses and/or memory corruption just because it's now entered differently from how it traditionally has been.
The traditional console write code has always been very careful to get exclusive access, and it sounds like that is just plain broken now.
So I don't think this is a "driver is broken". Even if you find a fix for it that makes that particular configuration happy, it sounds like there is a much more fundamental issue at hand: the new printk code just doesn't work well, and does things that are against the way console printing has always worked in the past.
I realize that people have wanted to do printing from proper thread context for ages and ages.
But maybe people should also just admit that "I wanted this" was not "this was actually a good idea".
Linus
| |