Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932151Ab3GPK2Z (ORCPT ); Tue, 16 Jul 2013 06:28:25 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53499 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754858Ab3GPK2W (ORCPT ); Tue, 16 Jul 2013 06:28:22 -0400 Date: Tue, 16 Jul 2013 12:29:38 +0200 Message-ID: From: Takashi Iwai To: Philipp Hahn Cc: Rusty Russell , alsa-devel@alsa-project.org, Kernel Mailing List , "Lucas De Marchi" Subject: Re: [alsa-devel] [BUG] 3.10.[01] modprobe snd-... hangs In-Reply-To: <201307161028.03315.pmhahn@pmhahn.de> References: <20130715182010.GA4853@pmhahn.de> <87ppujysbk.fsf@rustcorp.com.au> <201307161028.03315.pmhahn@pmhahn.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5444 Lines: 156 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 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 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 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 Cc: Signed-off-by: Takashi Iwai --- 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 #include #include +#include /* * 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/