On Wed, Aug 10, 2011 at 08:10:32PM +0200, Jiri Slaby wrote:

On 08/10/2011 08:07 PM, Andreas Bombe wrote:

quoted

On Wed, Aug 10, 2011 at 04:43:19PM +0200, Jiri Slaby wrote:

quoted

On 08/10/2011 03:09 AM, Andreas Bombe wrote:

quoted

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