aconnect occasionally causes kernel oopses
Takashi Iwai
tiwai at suse.de
Mon Aug 2 17:11:21 CEST 2021
On Mon, 02 Aug 2021 11:10:12 +0200,
folkert wrote:
>
> > > > In which situation?
> > >
> > > I was testing something that listens for alsa events and for that I ran
> > > a continuous loop that did:
> > >
> > > while true
> > > do
> > > aconnect 128:1 14:0
> > > aconnect -d 128:1 14:0
> > > aconnect -d 128:2 128:1
> > > aconnect 128:2 128:1
> > > done
> > >
> > > I ran 5 instances in parallel.
> > >
> > > 14 is midi through
> > > 128 is rtpmidi
> >
> > So rtpmidi process keeps running during the loop, that is, it's only
> > about connection and disconnection, right?
> > Also, you're listening to an event during that -- but how?
>
> I tried it again but with a simpler setup:
>
> I've got these devices:
>
> root at lappiemctopface:~# aplaymidi -l
> Port Client name Port name
> 14:0 Midi Through Midi Through Port-0
> 130:0 FLUID Synth (17032) Synth input port (17032:0)
> 131:0 VMPK Input in
> root at lappiemctopface:~# arecordmidi -l
> Port Client name Port name
> 14:0 Midi Through Midi Through Port-0
> 132:0 VMPK Output out
>
> I run this in 3x parallel:
>
> while true
> do
> aconnect 132:0 130:0
> aconnect -d 132:0 130:0
> done
>
> and then in less than a minute I get a backtrace.
OK, thanks. That's more promising.
Does this happen if you do reconnect of kernel sequencer client?
You can use snd-virmidi as well as snd-dummy.
I'm asking it because it'll simplify the test a lot, which will be
almost self-contained.
Takashi
More information about the Alsa-devel
mailing list