linux-kernel - Re: [alsa-devel] 2.6.26.[6|7]-rt11, alsa rawmidi, seq hang

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1226106884.7647.25.camel@localhost.localdomain>
Date:	Fri, 07 Nov 2008 17:14:44 -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, Steven Rostedt <rostedt@...dmis.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 16:48 -0800, Fernando Lopez-Lezcano wrote:
> On Fri, 2008-11-07 at 15:12 -0800, Fernando Lopez-Lezcano wrote:
> > 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?
> 
> I normally use rtirq to tune realtime priorities for realtime kernel
> processes, as I looked around and noticed tasklets seem to be related to
> (or are) software interrupts and those have priorities, so I disabled
> rtirq and rebooted (which leaves the default priority of 50 for all
> realtime kernel processes). 
> 
> Now I get __two__ midi bytes instead of one (active sensing messages
> from the keyboard) and the whole thing stalls as before. 

This is repeatable. 

> ??
> So is this a priority inversion problem?

And for that matter, what _should_ be the priority order of all the
realtime little tasks of rt kernels?? Names have changed and there's a
lot more of those...

(I can readily hang the whole machine if I change the wrong one to a
higher priority!)

Any help appreciated...
-- 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/