From: folkert <folkert@vanheusden.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: aconnect occasionally causes kernel oopses
Date: Mon, 2 Aug 2021 11:10:12 +0200 [thread overview]
Message-ID: <20210802091012.GR890690@belle.intranet.vanheusden.com> (raw)
In-Reply-To: <s5him0oz5zq.wl-tiwai@suse.de>
> > > 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@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@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.
[ma aug 2 11:05:13 2021] Call Trace:
[ma aug 2 11:05:13 2021] ? snd_seq_deliver_event+0x38/0x90 [snd_seq]
[ma aug 2 11:05:13 2021] ? snd_seq_kernel_client_dispatch+0x72/0x90 [snd_seq]
[ma aug 2 11:05:13 2021] kfree+0x3bc/0x3e0
[ma aug 2 11:05:13 2021] ? snd_seq_port_disconnect+0x10c/0x140 [snd_seq]
[ma aug 2 11:05:13 2021] snd_seq_port_disconnect+0x10c/0x140 [snd_seq]
[ma aug 2 11:05:13 2021] snd_seq_ioctl_unsubscribe_port+0xb9/0x180 [snd_seq]
[ma aug 2 11:05:13 2021] ? snd_seq_port_get_subscription+0xbb/0xd0 [snd_seq]
[ma aug 2 11:05:13 2021] ? __check_object_size.part.0+0x3a/0x150
[ma aug 2 11:05:13 2021] snd_seq_ioctl+0xe8/0x1b0 [snd_seq]
[ma aug 2 11:05:13 2021] __x64_sys_ioctl+0x91/0xc0
[ma aug 2 11:05:13 2021] do_syscall_64+0x38/0x90
[ma aug 2 11:05:13 2021] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Using:
fluidsynth 2.1.7-1
vmpk 0.7.2-1build1
On: 5.11.0-25-generic (ubuntu) on 2 cores, 2 threads/core cpu (64b).
next prev parent reply other threads:[~2021-08-02 9:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-01 18:27 aconnect occasionally causes kernel oopses folkert
2021-08-02 6:16 ` Takashi Iwai
2021-08-02 6:18 ` folkert
2021-08-02 6:59 ` Takashi Iwai
2021-08-02 9:10 ` folkert [this message]
2021-08-02 15:11 ` Takashi Iwai
2021-08-02 15:21 ` folkert
2021-08-02 17:12 ` Takashi Iwai
2021-08-02 19:53 ` folkert
2021-08-03 6:55 ` Takashi Iwai
2021-08-03 7:40 ` folkert
2021-08-03 7:43 ` Takashi Iwai
2021-08-03 7:44 ` folkert
2021-08-03 7:49 ` Takashi Iwai
2021-08-03 7:52 ` folkert
2021-08-03 10:12 ` folkert
2021-08-03 11:42 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210802091012.GR890690@belle.intranet.vanheusden.com \
--to=folkert@vanheusden.com \
--cc=alsa-devel@alsa-project.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.