[alsa-devel] [BUG] 3.10.[01] modprobe snd-... hangs

[Takashi Iwai]

At Tue, 16 Jul 2013 10:28:02 +0200,
Philipp Hahn wrote:
> 
> Hello,
> 
> Am Dienstag 16 Juli 2013, 08:43:36 schrieb Takashi Iwai:
> > At Tue, 16 Jul 2013 15:11:51 +0930, Rusty Russell wrote:
> > > Philipp Matthias Hahn <pmhahn at pmhahn.de> writes:
> > > > My x86_64 systems has some trouble loading some ALSA snd-* modules since
> > > > the upgrade to 3.10.[01]: Several automatic modprobe calls hang, but
> > > > loading snd-intel-hda and snd-audio-usb by hand still works.
> > > 
> > > Not a known problem to me, at least.  Perhaps it's a dep loop somehow.
> > 
> > I remember that someone reported it being Debian specific snd-seq-oss
> > loading stuff.
> 
> FYI: "oss-compat" is installed.
> 
> > > > ...
> > > >  1071 ?        S      0:00 sh -c /sbin/modprobe --ignore-install snd && { /sbin/modprobe --quiet snd
> > > >  1080 ?        D      0:00  \_ /sbin/modprobe --quiet snd-seq
> > > 
> > > This was first, and it's waiting.  Which means it must be doing
> > > something weird, because snd_seq_oss is loading now:
> > > 
> > > > snd_seq_oss 33717 1 - Loading 0xffffffffa041b000
> > > 
> > > Perhaps in the tangle of modprobe install commands somewhere this gets
> > > invoked?
> > 
> > Likely, but I wonder what triggered a bug suddenly on 3.10.
> > There is absolutely no change in sound/core/seq/*, and through a quick
> > look, I couldn't find any suspicious change in kernel/module.c that
> > may lead to this problem between 3.9 and 3.10.
> > 
> > Philipp, can you get a sysrq-T trace while the stall?
> 
> I've finally been able to reducte the number of processes to get a full trace; see attached file.
> 
> Please note that in this case the proprietary "nvidia" module was loaded, since I currently onyl have remove access to the machine.
> The original trace from yesterday happend without the nvidia module ever being loaded.
> 
> Am Dienstag 16 Juli 2013, 08:42:35 schrieb Lucas De Marchi:
> > On Tue, Jul 16, 2013 at 2:41 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> > First thing to check is the /etc/modprobe.d/*.conf file that contains
> > these install commands. Did they change besides the kernel upgrade?
> 
> Not that I know of: Booting 3.9.9 works fine, 3.10.x shows the problem.
> 
> ...
> > Philipp, which kernel are you upgrading from?
> I just upgraded from 3.9.9 to 3.10.0; also tried 3.10.1 which did not improve the situation.

Could you check the patch below?  It makes the code path involving
with request_module asynchronous.


thanks,

Takashi

---
From: Takashi Iwai <tiwai at suse.de>
Subject: [PATCH] ALSA: seq-oss: Initialize MIDI clients asynchronously

The recent report showed that the initial registration of OSS
sequencer clients stuck at loading the sound modules, which involves
with request_module() at the init phase.  As a workaround, call the
registration part asynchronously.  (And, this is a better approache
irrespective of the hang fix.)

Reported-by: Philipp Matthias Hahn <pmhahn at pmhahn.de>
Cc: <stable at vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 sound/core/seq/oss/seq_oss_init.c | 16 +++++++++++++---
 sound/core/seq/oss/seq_oss_midi.c |  2 +-
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/sound/core/seq/oss/seq_oss_init.c b/sound/core/seq/oss/seq_oss_init.c
index e3cb46f..b3f39b5 100644
--- a/sound/core/seq/oss/seq_oss_init.c
+++ b/sound/core/seq/oss/seq_oss_init.c
@@ -31,6 +31,7 @@
 #include <linux/export.h>
 #include <linux/moduleparam.h>
 #include <linux/slab.h>
+#include <linux/workqueue.h>
 
 /*
  * common variables
@@ -60,6 +61,14 @@ static void free_devinfo(void *private);
 #define call_ctl(type,rec) snd_seq_kernel_client_ctl(system_client, type, rec)
 
 
+/* call snd_seq_oss_midi_lookup_ports() asynchronously */
+static void async_call_lookup_ports(struct work_struct *work)
+{
+	snd_seq_oss_midi_lookup_ports(system_client);
+}
+
+static DECLARE_WORK(async_lookup_work, async_call_lookup_ports);
+
 /*
  * create sequencer client for OSS sequencer
  */
@@ -85,9 +94,6 @@ snd_seq_oss_create_client(void)
 	system_client = rc;
 	debug_printk(("new client = %d\n", rc));
 
-	/* look up midi devices */
-	snd_seq_oss_midi_lookup_ports(system_client);
-
 	/* create annoucement receiver port */
 	memset(port, 0, sizeof(*port));
 	strcpy(port->name, "Receiver");
@@ -115,6 +121,9 @@ snd_seq_oss_create_client(void)
 	}
 	rc = 0;
 
+	/* look up midi devices */
+	schedule_work(&async_lookup_work);
+
  __error:
 	kfree(port);
 	return rc;
@@ -160,6 +169,7 @@ receive_announce(struct snd_seq_event *ev, int direct, void *private, int atomic
 int
 snd_seq_oss_delete_client(void)
 {
+	cancel_work_sync(&async_lookup_work);
 	if (system_client >= 0)
 		snd_seq_delete_kernel_client(system_client);
 
diff --git a/sound/core/seq/oss/seq_oss_midi.c b/sound/core/seq/oss/seq_oss_midi.c
index 677dc84..862d8489 100644
--- a/sound/core/seq/oss/seq_oss_midi.c
+++ b/sound/core/seq/oss/seq_oss_midi.c
@@ -72,7 +72,7 @@ static int send_midi_event(struct seq_oss_devinfo *dp, struct snd_seq_event *ev,
  * look up the existing ports
  * this looks a very exhausting job.
  */
-int __init
+int
 snd_seq_oss_midi_lookup_ports(int client)
 {
 	struct snd_seq_client_info *clinfo;
-- 
1.8.3.1