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 possible that the tasklet never finishes executing. Please check whether the call to snd_seq_kernel_client_dispatch() in snd_midi_input_event() ever returns.
I added a printk before and after the call, it looks like it gets called and it returns (but only _once_... aseqdump hangs in an unkillable state as before).
Just in case, the tasklet keeps getting called as long as midi bytes are received. So the tasklet runs once, snd_midi_input_event gets called once and the tasklet keeps running again and again, but nobody runs snd_midi_input_event. Who should?
-- Fernando