Description of problem: Trying to get a Rosegarden tutorial Additional info: reporter: libreport-2.1.10 [ INFO: possible recursive locking detected ] 3.12.6-200.fc19.x86_64.debug #1 Not tainted --------------------------------------------- rosegarden/2935 is trying to acquire lock: (&grp->list_mutex){++++..}, at: [<ffffffffa03c5502>] snd_seq_deliver_event+0xd2/0x240 [snd_seq] but task is already holding lock: (&grp->list_mutex){++++..}, at: [<ffffffffa03c5502>] snd_seq_deliver_event+0xd2/0x240 [snd_seq] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&grp->list_mutex); lock(&grp->list_mutex); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by rosegarden/2935: #0: (&grp->list_mutex){++++..}, at: [<ffffffffa03c5502>] snd_seq_deliver_event+0xd2/0x240 [snd_seq] stack backtrace: CPU: 3 PID: 2935 Comm: rosegarden Not tainted 3.12.6-200.fc19.x86_64.debug #1 Hardware name: TOSHIBA Qosmio X770/PGRAA, BIOS 1.60 12/22/2011 ffffffff825b6e60 ffff8801ef17bb08 ffffffff81744be1 ffffffff825b6e60 ffff8801ef17bbc8 ffffffff810f447a ffffffff810b9408 ffffffff825800b0 ffff8801ef17bb38 ffffffff81021b13 ffff880100000000 0000000000ad856c Call Trace: [<ffffffff81744be1>] dump_stack+0x54/0x74 [<ffffffff810f447a>] __lock_acquire+0x1b7a/0x1c10 [<ffffffff810b9408>] ? sched_clock_cpu+0xa8/0x100 [<ffffffff81021b13>] ? native_sched_clock+0x13/0x80 [<ffffffff810b9408>] ? sched_clock_cpu+0xa8/0x100 [<ffffffff810eecbd>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff810f4d02>] lock_acquire+0xa2/0x1f0 [<ffffffffa03c5502>] ? snd_seq_deliver_event+0xd2/0x240 [snd_seq] [<ffffffff8174ab21>] down_read+0x51/0xa0 [<ffffffffa03c5502>] ? snd_seq_deliver_event+0xd2/0x240 [snd_seq] [<ffffffffa03c5502>] snd_seq_deliver_event+0xd2/0x240 [snd_seq] [<ffffffff810f24c5>] ? trace_hardirqs_on_caller+0x105/0x1d0 [<ffffffffa03c5bb9>] snd_seq_kernel_client_dispatch+0x79/0xa0 [snd_seq] [<ffffffffa085c14b>] dummy_input+0x6b/0x90 [snd_seq_dummy] [<ffffffffa03c5358>] snd_seq_deliver_single_event.constprop.9+0x168/0x240 [snd_seq] [<ffffffffa03c553a>] snd_seq_deliver_event+0x10a/0x240 [snd_seq] [<ffffffffa03c574d>] snd_seq_client_enqueue_event+0xdd/0x140 [snd_seq] [<ffffffffa03c58ac>] snd_seq_write+0xfc/0x270 [snd_seq] [<ffffffff811f7910>] vfs_write+0xc0/0x1f0 [<ffffffff812178b9>] ? fget_light+0xf9/0x510 [<ffffffff811f838c>] SyS_write+0x4c/0xa0 [<ffffffff81757f29>] system_call_fastpath+0x16/0x1b
Created attachment 842359 [details] File: dmesg
Description of problem: Started qjackctl. Selected Connect. On connections screen, selected ALSA. Clicked on MIDI-through on left and right. Clicked on Connect at bottom. A connection was displayed. Clicked Disconnect. Connect line remained displayed. No resopnse to further clicks in this window. When I clicked on the upper-right X. I got a message saying the program wasn't responding. Clicking on Yes stopped the program and also gave me this bug report. Version-Release number of selected component: kernel Additional info: reporter: libreport-2.1.10 cmdline: BOOT_IMAGE=/vmlinuz-3.12.7-200.fc19.x86_64.debug root=UUID=97b56aa1-31fa-4813-92de-b72621f0e326 ro rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=us rd.luks=0 vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=fr_FR.utf8 kernel: 3.12.7-200.fc19.x86_64.debug runlevel: N 5 type: Kerneloops Truncated backtrace: [ INFO: possible recursive locking detected ] 3.12.7-200.fc19.x86_64.debug #1 Not tainted --------------------------------------------- qjackctl/19913 is trying to acquire lock: (&grp->list_mutex){++++..}, at: [<ffffffffa043d502>] snd_seq_deliver_event+0xd2/0x240 [snd_seq] but task is already holding lock: (&grp->list_mutex){++++..}, at: [<ffffffffa0442ce6>] snd_seq_port_disconnect+0x46/0x180 [snd_seq] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&grp->list_mutex); lock(&grp->list_mutex); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by qjackctl/19913: #0: (&grp->list_mutex){++++..}, at: [<ffffffffa0442ce6>] snd_seq_port_disconnect+0x46/0x180 [snd_seq] #1: (&grp->list_mutex/1){+.+...}, at: [<ffffffffa0442d00>] snd_seq_port_disconnect+0x60/0x180 [snd_seq] stack backtrace: CPU: 1 PID: 19913 Comm: qjackctl Not tainted 3.12.7-200.fc19.x86_64.debug #1 Hardware name: TOSHIBA Qosmio X770/PGRAA, BIOS 1.60 12/22/2011 ffffffff825b96a0 ffff88022b48dae8 ffffffff81749e8b ffffffff825b96a0 ffff88022b48dbb0 ffffffff810f451a ffffffff00000002 ffff880200000002 ffffffff825b9a00 ffff88022b48db20 ffffffff00000000 00000015a0ad2568 Call Trace: [<ffffffff81749e8b>] dump_stack+0x54/0x74 [<ffffffff810f451a>] __lock_acquire+0x1b7a/0x1c10 [<ffffffff810b92ad>] ? sched_clock_local+0x1d/0x80 [<ffffffff810b9438>] ? sched_clock_cpu+0xa8/0x100 [<ffffffff810eed5d>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff810f4da2>] lock_acquire+0xa2/0x1f0 [<ffffffffa043d502>] ? snd_seq_deliver_event+0xd2/0x240 [snd_seq] [<ffffffff8174fd61>] down_read+0x51/0xa0 [<ffffffffa043d502>] ? snd_seq_deliver_event+0xd2/0x240 [snd_seq] [<ffffffffa043d502>] snd_seq_deliver_event+0xd2/0x240 [snd_seq] [<ffffffff8175311b>] ? _raw_spin_unlock_irqrestore+0x3b/0x70 [<ffffffffa043dbb9>] snd_seq_kernel_client_dispatch+0x79/0xa0 [snd_seq] [<ffffffffa085408e>] dummy_unuse+0x7e/0xd0 [snd_seq_dummy] [<ffffffffa0441da4>] unsubscribe_port.isra.0+0x54/0xc0 [snd_seq] [<ffffffffa0442dda>] snd_seq_port_disconnect+0x13a/0x180 [snd_seq] [<ffffffffa043dedd>] snd_seq_ioctl_unsubscribe_port+0xed/0x180 [snd_seq] [<ffffffffa043bd86>] snd_seq_do_ioctl+0x106/0x110 [snd_seq] [<ffffffffa043be3a>] snd_seq_ioctl+0x1a/0x40 [snd_seq] [<ffffffff8120c1f5>] do_vfs_ioctl+0x305/0x530 [<ffffffff81217dc9>] ? fget_light+0xf9/0x510 [<ffffffff81217d0c>] ? fget_light+0x3c/0x510 [<ffffffff8120c4a1>] SyS_ioctl+0x81/0xa0 [<ffffffff8175d169>] system_call_fastpath+0x16/0x1b
In comment 2, I said the program had stopped because its windows had closed. However, typing Enter at the command line where I had started the program did not give me a command prompt. I had to type CTRL-C to get the command prompt.
Created attachment 852003 [details] Output of ps -flu jones Comment 2 is incorrect. Hitting CTRL-C or CTRL-Z have no apparent effect. I openend another tab and did a "ps -flu jones" to get this attachment. Note the following: "0 S jones 5543 2240 0 80 0 - 29136 wait 09:06 pts/1 00:00:00 bash 0 D jones 19913 5543 0 80 0 - 209999 call_r 09:18 pts/1 00:00:00 qjackctl" Trying to close the original terminal tab gave a message that a process was still running. "kill -9 5543" in the second tab closed the first and got rid of qjackctl.
Created attachment 852027 [details] /var/log/messages When I tried to shut down, I got a message saying the session manager was not in an idle state. The same thing happened when I tried to logout. I might have done something else (don't remember), and then the system shut down. I am attaching /var/log/messages. Note the qjackctl lockup messages starting at about line 1500: "1499 Jan 18 09:17:39 mariehe dbus[516]: [system] Successfully activated service 'org.freedesktop .PackageKit' 1500 Jan 18 09:18:06 mariehe systemd-udevd[279]: specified group 'input' unknown 1501 Jan 18 09:18:31 mariehe kernel: [ 1240.929048] 1502 Jan 18 09:18:31 mariehe kernel: [ 1240.929054] ============================================ = 1503 Jan 18 09:18:31 mariehe kernel: [ 1240.929055] [ INFO: possible recursive locking detected ] 1504 Jan 18 09:18:31 mariehe kernel: [ 1240.929058] 3.12.7-200.fc19.x86_64.debug #1 Not tainted 1505 Jan 18 09:18:31 mariehe kernel: [ 1240.929060] -------------------------------------------- - 1506 Jan 18 09:18:31 mariehe kernel: [ 1240.929062] qjackctl/19913 is trying to acquire lock: 1507 Jan 18 09:18:31 mariehe kernel: [ 1240.929064] (&grp->list_mutex){++++..}, at: [<ffffffffa 043d502>] snd_seq_deliver_event+0xd2/0x240 [snd_seq] 1508 Jan 18 09:18:31 mariehe kernel: [ 1240.929075] 1509 Jan 18 09:18:31 mariehe kernel: [ 1240.929075] but task is already holding lock: 1510 Jan 18 09:18:31 mariehe kernel: [ 1240.929077] (&grp->list_mutex){++++..}, at: [<ffffffffa 0442ce6>] snd_seq_port_disconnect+0x46/0x180 [snd_seq] 1511 Jan 18 09:18:31 mariehe kernel: [ 1240.929085] 1512 Jan 18 09:18:31 mariehe kernel: [ 1240.929085] other info that might help us debug this: 1513 Jan 18 09:18:31 mariehe kernel: [ 1240.929087] Possible unsafe locking scenario: 1514 Jan 18 09:18:31 mariehe kernel: [ 1240.929087] 1515 Jan 18 09:18:31 mariehe kernel: [ 1240.929089] CPU0 1516 Jan 18 09:18:31 mariehe kernel: [ 1240.929090] ---- 1517 Jan 18 09:18:31 mariehe kernel: [ 1240.929091] lock(&grp->list_mutex); ..."
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.13.5-100.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.