| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1226083019.20569.9.camel@localhost.localdomain> Date: Fri, 07 Nov 2008 10:36:59 -0800 From: Fernando Lopez-Lezcano <nando@...ma.Stanford.EDU> To: Clemens Ladisch <clemens@...isch.de> Cc: Takashi Iwai <tiwai@...e.de>, Ingo Molnar <mingo@...e.hu>, alsa-devel@...a-project.org, linux-kernel@...r.kernel.org Subject: Re: [alsa-devel] 2.6.26.[6|7]-rt11, alsa rawmidi, seq hang On Fri, 2008-11-07 at 10:12 -0800, Fernando Lopez-Lezcano wrote: > On Fri, 2008-11-07 at 10:12 +0100, Clemens Ladisch wrote: > > Fernando Lopez-Lezcano wrote: > > > I'm seeing a realtime patch related hard hang in the kernel alsa > > > subsystem (MIDI input/output). In a nutshell: > > > > > > - alsa rawmidi works (ie: "rawmidi -v -i hw:0" outputs a stream of > > > messages when pointed to a midi capable card that has an external > > > keyboard connected). > > > > > > - the alsa sequencer interface works (ie: aplaymidi connected to > > > aseqdump transfers data just fine). > > > > > > - BOTH combined do NOT work (ie: use aconnect to connect the port that > > > corresponds to the external midi interface to aseqdump: aseqdump hangs > > > forever after transferring the first message and the only way out is a > > > reboot). > > > > Please try the snd-virmidi driver, then we'd have a test case that does > > not require MIDI hardware. > > > > > ... including the output of a "echo t >/proc/sysrq-trigger" that > > > should show where aseqdump currently hangs (or so I think). > > > > It hangs in tasklet_kill(), which gets called while it tries to close > > the rawmidi port. > > > > The rawmidi framework uses this tasklet to notify the sequencer that new > > MIDI data is available. The handler function is > > snd_rawmidi_input_event_tasklet() in sound/core/rawmidi.c; the sequencer > > callback that gets called from there is snd_midi_input_event() in > > core/seq/seq_midi.c. > > > > You say that the first event gets delivered, so it might be Nope, different this time. Maybe this one points closer to the culprit? (BTW, snd_midi_input_event only gets called _once_, I added a few more printk's there): -------- Nov 7 10:34:51 host kernel: aseqdump S [f15ce070] f7910d70 0 5341 5247 Nov 7 10:34:51 host kernel: f3691bd4 00000086 f3691b88 f7910d70 00000001 f15ce070 f15ce304 c4852700 Nov 7 10:34:51 host kernel: 00000002 c4852700 9a9894aa 0000002c c484f054 00000000 fffeb4bf 00000246 Nov 7 10:34:51 host kernel: f35cf274 00000000 00000000 00000000 ffffffff 00000000 7fffffff f3691e98 Nov 7 10:34:51 host kernel: Call Trace: Nov 7 10:34:51 host kernel: [<c0643ba5>] schedule+0xbf/0xd8 Nov 7 10:34:51 host kernel: [<c0643c72>] schedule_timeout+0x17/0xbc Nov 7 10:34:51 host kernel: [<c0496c8f>] ? __pollwait+0xad/0xb6 Nov 7 10:34:51 host kernel: [<f893cb34>] ? snd_seq_fifo_poll_wait +0x18/0x25 [snd_seq] Nov 7 10:34:51 host kernel: [<f8939fad>] ? snd_seq_poll+0x4d/0x9f [snd_seq] Nov 7 10:34:51 host kernel: [<c0495d92>] do_sys_poll+0x292/0x348 Nov 7 10:34:51 host kernel: [<c0496be2>] ? __pollwait+0x0/0xb6 Nov 7 10:34:51 host kernel: [<c0425c81>] ? default_wake_function +0x0/0x12 Nov 7 10:34:51 host kernel: [<c0645736>] ? rt_spin_lock+0x38/0x3b Nov 7 10:34:51 host kernel: [<c04752f7>] ? page_address+0x88/0xaa Nov 7 10:34:51 host kernel: [<c047596d>] ? kmap_high+0x421/0x42a Nov 7 10:34:51 host kernel: [<c04ff574>] ? radix_valid_always+0x0/0xa Nov 7 10:34:51 host kernel: [<c046430b>] ? __rcu_read_unlock+0x6d/0x72 Nov 7 10:34:51 host kernel: [<c04699ec>] ? find_get_page+0xfa/0x120 Nov 7 10:34:51 host kernel: [<c06456c1>] ? __rt_spin_lock+0x24/0x61 Nov 7 10:34:51 host kernel: [<c0645736>] ? rt_spin_lock+0x38/0x3b Nov 7 10:34:51 host kernel: [<c0420afc>] ? __enqueue_entity+0xe3/0xeb Nov 7 10:34:51 host kernel: [<c041f87b>] ? task_rq_lock+0x44/0x6e Nov 7 10:34:51 host kernel: [<c0425c76>] ? try_to_wake_up+0x212/0x21d Nov 7 10:34:51 host kernel: [<c0425c91>] ? default_wake_function +0x10/0x12 Nov 7 10:34:51 host kernel: [<c041ddd8>] ? __wake_up_common+0x35/0x5b Nov 7 10:34:51 host kernel: [<c0423172>] ? __wake_up+0x28/0x32 Nov 7 10:34:51 host kernel: [<c0554f2e>] ? n_tty_receive_buf +0xfa9/0xff7 Nov 7 10:34:51 host kernel: [<c0554f2e>] ? n_tty_receive_buf +0xfa9/0xff7 Nov 7 10:34:51 host kernel: [<c0447cef>] ? rt_mutex_up_read+0x1b7/0x25d Nov 7 10:34:51 host kernel: [<c0448f40>] ? rt_up_read+0x8/0xa Nov 7 10:34:51 host kernel: [<c0647c26>] ? do_page_fault+0x45f/0x7d8 Nov 7 10:34:51 host kernel: [<c043e441>] ? hrtimer_start+0x133/0x162 Nov 7 10:34:51 host kernel: [<c04249d0>] ? hrtick_set+0x97/0xe5 Nov 7 10:34:51 host kernel: [<c06456c1>] ? __rt_spin_lock+0x24/0x61 Nov 7 10:34:51 host kernel: [<c0645736>] ? rt_spin_lock+0x38/0x3b Nov 7 10:34:51 host kernel: [<f893cc46>] ? snd_seq_fifo_cell_out +0x47/0xee [snd_seq] Nov 7 10:34:51 host kernel: [<c0425c81>] ? default_wake_function +0x0/0x12 Nov 7 10:34:51 host kernel: [<f893a041>] ? snd_seq_read+0x0/0x1d8 [snd_seq] Nov 7 10:34:51 host kernel: [<f893a11e>] ? snd_seq_read+0xdd/0x1d8 [snd_seq] Nov 7 10:34:51 host kernel: [<c04d73d3>] ? security_file_permission +0xf/0x11 Nov 7 10:34:51 host kernel: [<c045e231>] ? audit_syscall_entry +0xf9/0x123 Nov 7 10:34:51 host kernel: [<c049606a>] sys_poll+0x3a/0x6a Nov 7 10:34:51 host kernel: [<c0404be6>] syscall_call+0x7/0xb Nov 7 10:34:51 host kernel: ======================= -------- -- Fernando -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists