Message-ID: <s5h61w9mzd7.wl%tiwai@suse.de>
Date:	Wed, 17 Jul 2013 09:15:00 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Lucas De Marchi <lucas.de.marchi@...il.com>,
	Philipp Hahn <pmhahn@...ahn.de>, alsa-devel@...a-project.org,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Lucas De Marchi <lucas.demarchi@...fusion.mobi>
Subject: Re: [alsa-devel] [BUG] 3.10.[01] modprobe snd-... hangs

At Wed, 17 Jul 2013 09:30:21 +0930,
Rusty Russell wrote:
> 
> Lucas De Marchi <lucas.de.marchi@...il.com> writes:
> > On Tue, Jul 16, 2013 at 5:28 AM, Philipp Hahn <pmhahn@...ahn.de> 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@...ahn.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@...tcorp.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.
> >
> > Then one possible explanation is that in 3.9.9 you don't have some of
> > the modules causing this 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.
> >>
> >>> I don't see anything to
> >>> blame in the changes for the past releases. Any chance a bad entry in
> >>> your .conf was added too? You may want to paste the output of modprobe
> >>> -c, at least until "# End of configuration files. Dumping indexes
> >>> now:"
> >>
> >> blacklist snd_pcsp
> >> blacklist arkfb
> >> blacklist aty128fb
> >> blacklist atyfb
> >> blacklist radeonfb
> >> blacklist cirrusfb
> >> blacklist cyber2000fb
> >> blacklist gx1fb
> >> blacklist gxfb
> >> blacklist kyrofb
> >> blacklist matroxfb_base
> >> blacklist mb862xxfb
> >> blacklist neofb
> >> blacklist nvidiafb
> >> blacklist pm2fb
> >> blacklist pm3fb
> >> blacklist s3fb
> >> blacklist savagefb
> >> blacklist sisfb
> >> blacklist tdfxfb
> >> blacklist tridentfb
> >> blacklist viafb
> >> blacklist vt8623fb
> >> blacklist garmin_gps
> >> blacklist nouveau
> >> install binfmt_0000 /bin/true
> >> install sound_slot_0 /sbin/modprobe snd-card-0
> >> install sound_slot_1 /sbin/modprobe snd-card-1
> >> install sound_slot_2 /sbin/modprobe snd-card-2
> >> install sound_slot_3 /sbin/modprobe snd-card-3
> >> install sound_slot_4 /sbin/modprobe snd-card-4
> >> install sound_slot_5 /sbin/modprobe snd-card-5
> >> install sound_slot_6 /sbin/modprobe snd-card-6
> >> install sound_slot_7 /sbin/modprobe snd-card-7
> >> install snd /sbin/modprobe --ignore-install snd && { /sbin/modprobe --quiet snd-ioctl32 ; /sbin/modprobe --quiet snd-seq ; : ; }
> >> install snd_rawmidi /sbin/modprobe --ignore-install snd-rawmidi && { /sbin/modprobe --quiet snd-seq-midi ; : ; }
> >> install snd_emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && { /sbin/modprobe --quiet snd-emu10k1-synth ; : ; }
> >> alias net_pf_16_proto_1 wire
> >> alias net_pf_16_proto_3 ip_queue
> >> alias net_pf_16_proto_8 scsi_transport_iscsi
> >> alias net_pf_16_proto_9 audit
> >> alias net_pf_16_proto_11 cn
> >> alias net_pf_16_proto_13 ip6_queue
> >> alias binfmt_204 binfmt_aout
> >> alias binfmt_263 binfmt_aout
> >> alias binfmt_264 binfmt_aout
> >> alias binfmt_267 binfmt_aout
> >> alias binfmt_387 binfmt_aout
> >> alias block_major_3_* ide_generic
> >> alias block_major_22_* ide_generic
> >> alias block_major_33_* ide_generic
> >> alias block_major_34_* ide_generic
> >> alias block_major_37_* ide_tape
> >> alias block_major_44_* ftl
> >> alias block_major_46_* pcd
> >> alias block_major_47_* pf
> >> alias block_major_56_* ide_generic
> >> alias block_major_57_* ide_generic
> >> alias block_major_58_* lvm_mod
> >> alias block_major_88_* ide_generic
> >> alias block_major_89_* ide_generic
> >> alias block_major_90_* ide_generic
> >> alias block_major_91_* ide_generic
> >> alias block_major_93_* nftl
> >> alias block_major_97_* pg
> >> alias char_major_10_1 psmouse
> >> alias char_major_10_139 openprom
> >> alias char_major_10_157 applicom
> >> alias char_major_10_181 toshiba
> >> alias char_major_10_183 hw_random
> >> alias char_major_10_187 irnet
> >> alias char_major_10_189 ussp
> >> alias char_major_10_250 hci_vhci
> >> alias char_major_13_0 joydev
> >> alias char_major_13_1 joydev
> >> alias char_major_13_2 joydev
> >> alias char_major_13_3 joydev
> >> alias char_major_13_32 mousedev
> >> alias char_major_13_33 mousedev
> >> alias char_major_13_34 mousedev
> >> alias char_major_13_35 mousedev
> >> alias char_major_13_63 mousedev
> >> alias char_major_13_64 evdev
> >> alias char_major_13_65 evdev
> >> alias char_major_13_66 evdev
> >> alias char_major_13_67 evdev
> >> alias char_major_19_* cyclades
> >> alias char_major_20_* cyclades
> >> alias char_major_22_* pcxx
> >> alias char_major_23_* pcxx
> >> alias char_major_27_* ftape
> >> alias char_major_34_* scc
> >> alias char_major_35_* tclmidi
> >> alias char_major_48_* riscom8
> >> alias char_major_49_* riscom8
> >> alias char_major_57_* esp
> >> alias char_major_58_* esp
> >> alias char_major_63_* kdebug
> >> alias char_major_67_* coda
> >> alias char_major_75_* specialix
> >> alias char_major_76_* specialix
> >> alias char_major_81_* videodev
> >> alias char_major_83_* vtx
> >> alias char_major_89_* i2c_dev
> >> alias char_major_90_* mtdchar
> >> alias char_major_96_* pt
> >> alias char_major_97_* pg
> >> alias char_major_107_* 3dfx
> >> alias char_major_109_* lvm_mod
> >> alias char_major_166_* cdc_acm
> >> alias char_major_171_0 raw1394
> >> alias char_major_171_1 video1394
> >> alias char_major_171_2 dv1394
> >> alias char_major_171_3 amdtp
> >> alias char_major_180_* usbcore
> >> alias char_major_195_* nvidia
> >> alias char_major_200_* vxspec
> >> alias char_major_202_* msr
> >> alias char_major_203_* cpuid
> >> alias char_major_206_* osst
> >> alias char_major_208_* ussp
> >> alias char_major_227_* tub3270
> >> alias bt_proto_7 avdtp
> >> alias cipcb0 cipcb
> >> alias cipcb1 cipcb
> >> alias cipcb2 cipcb
> >> alias cipcb3 cipcb
> >> alias dummy0 dummy
> >> alias dummy1 dummy
> >> alias plip0 plip
> >> alias plip1 plip
> >> alias slip0 slip
> >> alias slip1 slip
> >> alias tunl0 ipip
> >> alias gre0 ip_gre
> >> alias usbdevfs usbcore
> >> alias char_major_195* nvidia
> >> options snd_pcsp index=-2
> >> options snd_usb_audio index=-2
> >> options bt87x index=-2
> >> options cx88_alsa index=-2
> >> options snd_atiixp_modem index=-2
> >> options snd_intel8x0m index=-2
> >> options snd_via82xx_modem index=-2
> >> options snd_hda_intel model=6stack-dig index=0
> >> options snd_usb_audio index=1
> >> options dvb_ttpci adapter_nr=1
> >> options budget_ci adapter_nr=0
> >> options nbd max_part=15
> >> options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 NVreg_DeviceFileMode=0660
> >> options libata force=noncq
> >> options systemd log_target=kmsg
> >> softdep uhci_hcd pre: ehci-hcd
> >> softdep ohci_hcd pre: ehci-hcd
> >> softdep snd_pcm post: snd-pcm-oss
> >> softdep snd_mixer post: snd-mixer-oss
> >> softdep snd_seq post: snd-seq-midi snd-seq-oss
> >
> >
> > hum... it looks like a loop between the modprobe calls and the
> > request_module(), done in snd_seq's init. The request_module() call
> > will end up trying to load snd_seq again and it will remain waiting on
> > kernel/module.c:add_unformed_module().
> >
> > In kmod we don't trust a COMING state on sysfs to avoid calling
> > (f)init_module() because a) the previous call may fail and b) it's
> > racy.
> 
> Yes, add_unformed_module makes the same call.  I think the answer is
> simply "don't do that".
> 
> > Changing the request_module() in the module to be async would solve
> > the problem (what Takashi Iwai did)... but this has been a
> > little controversial in the past.  Rusty, what do you think? Maybe in
> > kmod we can take the COMING state into consideration for
> > *dependencies*? Or is moving that call to a worker acceptable?
> 
> I thought about adding a post_init() call for modules for this kind of
> thing, but it's actually pretty rare.  Open-coding it seems fine.

The conversion to async call would be a problem if it needs to change
the code flow largely.  In this particular case, however, it's no big
problem (as little as the patch size is), so I'm going to apply my
patch as is for now.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists