[lkml]   [2010]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: open() on /dev/tty takes 30 seconds on 2.6.36
On Wednesday 03 November 2010, Eli Billauer wrote:
> Arnd Bergmann wrote:
> > Ok, that's certainly modem-manager in the tty_release function, calling
> > uart_close, which has this code:
> >
> > if (port->closing_wait != ASYNC_CLOSING_WAIT_NONE) {
> > /*
> > * hack: open-coded tty_wait_until_sent to avoid
> > * recursive tty_lock
> > */
> > long timeout = msecs_to_jiffies(port->closing_wait);
> > if (wait_event_interruptible_timeout(tty->write_wait,
> > !tty_chars_in_buffer(tty), timeout) >= 0)
> > __uart_wait_until_sent(uport, timeout);
> > }
> >
> > port->closing_wait gets initialized to 30 seconds, which fits your
> > symptom.
> >
> I lost you here. Maybe my version is outdated? The most similar thing I
> have is this in tty_port.c, in tty_port_close_start():
> if (test_bit(ASYNCB_INITIALIZED, &port->flags) &&
> port->closing_wait != ASYNC_CLOSING_WAIT_NONE)
> tty_wait_until_sent(tty, port->closing_wait);

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.

Right. The uart_close() function does not call tty_wait_until_sent,
it calls __uart_wait_until_sent directly.

> > 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 that
we cannot just do tty_unlock/tty_lock around the sleeping call, because we
also 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 we
might be able to call uart_close without tty_lock() held in the first place.


 \ /
  Last update: 2010-11-03 04:33    [W:0.068 / U:6.768 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site