Re: [PATCH v2 1/6] TTY: serial, remove BTM from wait_until_sent

[Andreas Bombe]

On Wed, Aug 10, 2011 at 08:10:32PM +0200, Jiri Slaby wrote:
> On 08/10/2011 08:07 PM, Andreas Bombe wrote:
> > On Wed, Aug 10, 2011 at 04:43:19PM +0200, Jiri Slaby wrote:
> >> On 08/10/2011 03:09 AM, Andreas Bombe wrote:
> >>> I did my simple test on ttyS0 again: "stty -F /dev/ttyS0 crtscts" then
> >>> "echo >/dev/ttyS0". I attached the gzipped sysrq-t list in case you need
> >>> the complete output. This is just the process while it is trying to
> >>> close the device (bash's internal echo):
> >>
> >> Hmm, perhaps obvious question. What is the port connected with? And with
> >> what cable? Is it null modem cable? Or at least with DTR-CTS connected?
> > 
> > Nothing is connected. After all, the whole point of this exercise is to
> > give the driver data to send which it can't get out so I can see whether
> > it blocks all tty operations system wide while trying to do the flush on
> > close.
> 
> But according to the trace, it waits only in its queue...
> 
> Well, could you turn on lockdep and dump sysrq-d when your echo is
> closing the port?

Ok, it still appears to be holding the big_tty_mutex. I ran /bin/echo so
that it actually shows up as "echo" here:

[  962.365574] SysRq : Show Locks Held
[  962.365580] 
[  962.365581] Showing all locks held in the system:
[  962.365599] 1 lock held by Xorg/1881:
[  962.365601]  #0:  (big_tty_mutex){+.+.+.}, at: [<ffffffff813d0013>] tty_lock+0x12/0x14
[  962.365624] 1 lock held by getty/2732:
[  962.365626]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365637] 1 lock held by getty/2733:
[  962.365639]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365647] 1 lock held by getty/2734:
[  962.365649]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365658] 1 lock held by getty/2735:
[  962.365660]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365679] 1 lock held by bash/2994:
[  962.365681]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365691] 1 lock held by bash/3326:
[  962.365692]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365701] 1 lock held by bash/3444:
[  962.365703]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365713] 1 lock held by bash/3793:
[  962.365715]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365725] 1 lock held by less/3899:
[  962.365727]  #0:  (&tty->atomic_read_lock){+.+.+.}, at: [<ffffffff81254fff>] n_tty_read+0x188/0x681
[  962.365735] 2 locks held by echo/4162:
[  962.365737]  #0:  (big_tty_mutex){+.+.+.}, at: [<ffffffff813d0013>] tty_lock+0x12/0x14
[  962.365746]  #1:  (&port->mutex){+.+.+.}, at: [<ffffffff81268b46>] uart_close+0x6c/0x243
[  962.365754] 
[  962.365756] =============================================
[  962.365757] 


Also, can you not reproduce it? I thought the "enable hardware handshake
on unconnected port and send" dance should be universal enough to work
for everyone. Everyone with a serial port somewhere in the system, that
is.

-- 
Andreas Bombe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/