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