Re: 2.6.23-rc8-git2 possible recursive locking when running screen
On Wednesday, 3 October 2007 11:24, Pekka Pietikainen wrote: > Seen this a few times lately on a machine running rawhide when running > screen (and doing "something", it's not automatic. And box works just fine). > I think I saw this a few weeks back, so it's not a new regression. Did it happen with 2.6.22? Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc8-git2 possible recursive locking when running screen
On Wednesday, 3 October 2007 11:24, Pekka Pietikainen wrote: Seen this a few times lately on a machine running rawhide when running screen (and doing something, it's not automatic. And box works just fine). I think I saw this a few weeks back, so it's not a new regression. Did it happen with 2.6.22? Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc8-git2 possible recursive locking when running screen
Seen this a few times lately on a machine running rawhide when running
screen (and doing "something", it's not automatic. And box works just fine).
I think I saw this a few weeks back, so it's not a new regression.
=
[ INFO: possible recursive locking detected ]
2.6.23-0.211.rc8.git2.fc8 #1
-
screen/32227 is trying to acquire lock:
(>lock){++..}, at: [] __wake_up+0x15/0x42
but task is already holding lock:
(>lock){++..}, at: [] __wake_up+0x15/0x42
other info that might help us debug this:
2 locks held by screen/32227:
#0: (>atomic_read_lock){--..}, at: [] read_chan+0x1a1/0x5af
#1: (>lock){++..}, at: [] __wake_up+0x15/0x42
stack backtrace:
[] show_trace_log_lvl+0x1a/0x2f
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __lock_acquire+0x189/0xc67
[] lock_acquire+0x7b/0x9e
[] _spin_lock_irqsave+0x4a/0x77
[] __wake_up+0x15/0x42
[] ep_poll_safewake+0x86/0xa8
[] ep_poll_callback+0x9f/0xaa
[] __wake_up_common+0x32/0x55
[] __wake_up+0x31/0x42
[] tty_wakeup+0x4f/0x54
[] pty_unthrottle+0x15/0x21
[] check_unthrottle+0x2e/0x30
[] read_chan+0x4ac/0x5af
[] tty_read+0x66/0xac
[] vfs_read+0xad/0x167
[] sys_read+0x3d/0x61
[] syscall_call+0x7/0xb
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc8-git2 possible recursive locking when running screen
Seen this a few times lately on a machine running rawhide when running
screen (and doing something, it's not automatic. And box works just fine).
I think I saw this a few weeks back, so it's not a new regression.
=
[ INFO: possible recursive locking detected ]
2.6.23-0.211.rc8.git2.fc8 #1
-
screen/32227 is trying to acquire lock:
(q-lock){++..}, at: [c0426703] __wake_up+0x15/0x42
but task is already holding lock:
(q-lock){++..}, at: [c0426703] __wake_up+0x15/0x42
other info that might help us debug this:
2 locks held by screen/32227:
#0: (tty-atomic_read_lock){--..}, at: [c0554ca2] read_chan+0x1a1/0x5af
#1: (q-lock){++..}, at: [c0426703] __wake_up+0x15/0x42
stack backtrace:
[c0406463] show_trace_log_lvl+0x1a/0x2f
[c0406e4d] show_trace+0x12/0x14
[c0406e65] dump_stack+0x16/0x18
[c0449c3a] __lock_acquire+0x189/0xc67
[c044ab92] lock_acquire+0x7b/0x9e
[c06334fa] _spin_lock_irqsave+0x4a/0x77
[c0426703] __wake_up+0x15/0x42
[c04aece2] ep_poll_safewake+0x86/0xa8
[c04af969] ep_poll_callback+0x9f/0xaa
[c042483e] __wake_up_common+0x32/0x55
[c042671f] __wake_up+0x31/0x42
[c054f864] tty_wakeup+0x4f/0x54
[c0555e9b] pty_unthrottle+0x15/0x21
[c055301b] check_unthrottle+0x2e/0x30
[c0554fad] read_chan+0x4ac/0x5af
[c0551c99] tty_read+0x66/0xac
[c0489fee] vfs_read+0xad/0x167
[c048a482] sys_read+0x3d/0x61
[c040522e] syscall_call+0x7/0xb
===
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
