The code I quoted is from uart_close() in drivers/serial/serial_core.c

> I put a printk on invocations of tty_wait_until_sent(), which was called > like crazy during bootup on behalf of tty1, and then never again after > boot was completed. I should point out, that during this session, all I > did was to wait a few minutes and then reboot the computer from the GUI > login console. So I never logged in. Anyhow, the ttySx ports were opened > and closed, the same 30 seconds delays, but no call to > tty_wait_until_sent() until kernel logging was stopped.

> > What does "lspci -vvx" show about the> > port? > It turns out, that the device, to which ttyS1-ttyS3 are attached is a > soft modem, which doesn't even have drivers for a 64 bits system. There > is no /dev/ttyS4, which is consistent with the "Couldn't register serial > port 0000:05:04.0: -28" message. Anyhow, I can't say I understand why > any serial port was allocated to this modem. But it's not like I > understand how it should work.> > 05:04.0 Modem: ALi Corporation SmartLink SmartPCI563 56K Modem (prog-if > 00 [Generic])

It should actually be covered by the intel8x0m.c driver as far as I can tell,but it's missing from the PCI IDs in that driver...

As Alan said, we need to sort out the locking though. One problem is thatwe cannot just do tty_unlock/tty_lock around the sleeping call, because wealso hold &port->mutex there, which nests inside of tty_lock().

I hope Alan can figure out if it's either safe to drop both here, or if wemight be able to call uart_close without tty_lock() held in the first place.