| Summary: | system shutdown hangs unloading alsa if previously connected nfs server is down | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Brian Kroth <bpkroth> |
| Component: | [OLD] Unspecified | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | VERIFIED NEEDINFO | ||
| Severity: | minor | CC: | bbutscheidt, g2t, renatogallo |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
I've experienced the same problem under slightly different circumstances. In my case, a still-mounted sshfs-fuse mount will cause the hang. (Note: sshfs can hang occasionally during normal use, but in this case the connection is untroubled and no transfers are pending.) I can't say whether this is the 'fault' of alsasound, fuse or sshfs, but there is a fairly simple workaround for me: place a 'fusermount -u /name/of/mountpoint' command in /etc/conf.d/local.stop which will umount before the alsasound stop-script is run. (Of course, wrt my earlier point, if sshfs is 'jammed' this won't work either; I'm not sure if there is a way to force it) I suppose it would be good to see this implemented somewhere in init, as it probably catches people out now and again, but I don't know whether that can be justified as part of init's job (to wit: you mounted whatever-it-was, you take responsibility for cleanly umounting it before you shutdown). More likely, it should be in the spec of apps like NFS and fuse to more accurately report how safe it is to kill them: for example, an asynchronous connection might have transfers still to complete, and would be BAD to kill it now; but if it's just being held open with no transfers ongoing, it's safe. If fuser hangs, it's most likely a kernel issue. Is this still reproducible on the latest stable baselayout, Linux 2.6.18, with ALSA modules from the kernel (as opposed to media-sound/alsa-driver) I'm sorry, I haven't been able to test this lately on the machine that was having problems since its power supply died on me. I have not experienced the problem in any other machines lately (there are three others), so I suspect this problem has been fixed. When my new power supply arrives I'll try and see if it still happens. Marking as NEEDINFO for now (In reply to comment #5) > Marking as NEEDINFO for now > No problems here. I think this can be closed. I still have this issue. If someone knows an solution, I would be interested. Here is my PC-info (emerge --info): ==================================================================== Portage 2.1.5 (default-linux/amd64/2007.0, gcc-4.1.1, glibc-2.7-r2, 2.6.24-gentoo-r3 x86_64) ================================================================= System uname: 2.6.24-gentoo-r3 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3600+ Timestamp of tree: Sat, 17 May 2008 10:45:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.3-r4, 2.5.2-r3 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.3 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.62 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.25-r2 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ ftp://de-mirror.org/distro/gentoo/ " LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="" LINGUAS="en en_GB de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/own /usr/portage/local/layman/berkano /usr/portage/local/layman/sunrise /usr/portage/local/layman/vmware /usr/portage/local/layman/portato" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow acl alsa amd64 berkdb cdr cli cracklib crypt cups dga dri dvd fortran gdbm gpm iconv ipv6 isdnlog kde midi mmx mudflap ncurses nls nptl nptlonly openmp pam pcre perl pppd python qt3 readline reflection session spl sse sse2 ssl tcpd unicode xorg zlib" ALSA_CARDS="HDA NVidia" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB de" USERLAND="GNU" VIDEO_CARDS="mga nv nvidia nvidia%" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS I don't think this is a bug, as such. Accessing an NFS share while the server is down is meant to hang indefinitely in uninterruptible sleep, with default mount options. You may want to add "intr" and/or "soft" to the share's mount options in /etc/fstab. That should allow operations to be interrupted and allow recovery if the server dies. Take a look at "man 5 nfs" for details and other relevant options. (In reply to comment #8) > I don't think this is a bug, as such. Accessing an NFS share while the server > is down is meant to hang indefinitely in uninterruptible sleep, with default > mount options. > > You may want to add "intr" and/or "soft" to the share's mount options in > /etc/fstab. That should allow operations to be interrupted and allow recovery > if the server dies. Take a look at "man 5 nfs" for details and other relevant > options. > Same problem here "Unloading ALSA modules ..." until reset or power off with hardware switch. Reproducible after mount an NFS server and don't unmount before shutdown --> Server is not down. (In reply to comment #9) ... no sorry, at the moment every time at shutdown hangs the system. Now I have tested: /etc/init.d/alsasound stop --> system hangs with the same message: "* Unloading ALSA modules ..." ps ax show: 30799 pts/0 D+ 0:00 rmmod --wait snd_hda_codec_realtek lsmod show: Module Size Used by it87 26648 0 hwmon_vid 3488 1 it87 powernow_k8 17732 1 snd_hda_codec_realtek 251972 1 snd_hda_intel 26600 0 snd_hda_codec 59200 2 snd_hda_codec_realtek,snd_hda_intel nvidia 8114168 22 snd_hwdep 7880 1 snd_hda_codec snd_pcm 78632 2 snd_hda_intel,snd_hda_codec snd_timer 21616 1 snd_pcm i2c_nforce2 7328 0 snd 55048 6 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer i2c_core 23424 2 nvidia,i2c_nforce2 k8temp 5216 0 snd_page_alloc 9296 2 snd_hda_intel,snd_pcm hwmon 2856 2 it87,k8temp --> is "*_realtek" and "*_intel" possible at the same time? (In reply to comment #10) following command remove the deadlock: modprobe -r snd_hda_intel (In reply to comment #11) > (In reply to comment #10) > following command remove the deadlock: > modprobe -r snd_hda_intel > In my opinion the problem is located at init script "alsasound". The function "unload_modules_recursive()" don't unload really recursive. It start with the first entry from "lsmod". The right one should be the module with the lowest entry (or better zero) at "Used By field". This is the "snd_hda_intel". But script start with "snd_hda_codec_realtek". workarround: add "rmmod snd_hda_intel" before line 111: "lsmod |grep ..." Be aware: dont use "rmmod -f " this can make a kernel crash. (In reply to comment #12) Sorry again, all that above is described at bug #232875. Also a good solution for "topological unload". Can anyone check if this two bugs depend each other. Headline of bug#232875: System hangs at shutdown after message "Killing processes using ALSA" |
This is a rather silly thing, and to be honest I'm not even sure if its a bug or my fault, but I can't find any info on it so I thought I'd post it anyways, just in case. I have a machine that had mounted an NFS share. That server went down, manually BTW, while it was down I also told my client machine to reboot as well. The client machine did not manually unmount the NFS share beforehand. While it was going down it got stuck at "Unloading ALSA", and to be specific with this command: "fuser -k ${ossdevs} ${alsadevs} >& /dev/null". It stays there, without any error messages whatsoever (meaning none from ALSA, NFS, or anything else), until the server comes back up and the client is able to unmount the share. Obvious fix is don't reboot the server and the client at the same time, but all the same it seems like it should be able to handle that. It does not happen if the ALSA modules are loaded via coldplug rather than alsasound - it seems to be that fuser command not unloading modules themselves. I've tried this on two seperate client machines with the same results. Reproducible: Always Steps to Reproduce: 1. On client machine that has had "/etc/init.d/alsasound start" run, mount NFS share. 2. Shutdown NFS server. 3. Reboot client machine. Actual Results: Reboot/Shutdown get stuck at "Unloading ALSA" Expected Results: Rebooted without delay.