Messages in this thread | | | From | Andy Shevchenko <> | Date | Sat, 4 Jul 2020 14:37:14 +0300 | Subject | Re: UART/TTY console deadlock |
| |
On Fri, Jul 3, 2020 at 1:53 PM Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote: > > On (20/07/02 11:20), Andy Shevchenko wrote: > > > > I didn't look into this deeply, but my understanding that this is something for > > special case when you have several UART ports sharing the IRQ (multi-port card) > > and IRQ even maybe undesirable b/c it will confuse real IRQ handler. I don't > > remember details, but AFAIR IRQ handler does a busyloop to service as much as > > possible and in between it may release the lock (again, multi-port UART cards), > > that's why we better avoid IRQ event in the first place. > > But it's my pure speculation. > > Hmm. Would different IRQ handlers use different UART port structures? ->irq > might be the only thing they share. Even if they use the same port, we > keep IRQs disabled on local CPU, and UART port locked. To unlock the UART > port during IRQ, the handler (on another CPU) first needs to acquire the > port->lock, which is locked by serial8250_do_startup().
It appears to be a RT kernel related. Don't know the state of affairs in RT nowadays, but maybe still relevant. See the commit 768aec0b5bcc ("serial: 8250: fix shared interrupts issues with SMP and RT kernels").
-- With Best Regards, Andy Shevchenko
| |