Date: Sun, 28 Jul 2013 09:24:03 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Dominic Fandrey <kamikaze@bsdforen.de> Cc: freebsd-stable@freebsd.org Subject: Re: stopping amd causes a freeze Message-ID: <20130728062403.GD4972@kib.kiev.ua> In-Reply-To: <51F385CE.1030606@bsdforen.de> References: <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> <51F0DA4B.3000809@bsdforen.de> <20130725100037.GM5991@kib.kiev.ua> <51F2AD8C.1000003@bsdforen.de> <51F385CE.1030606@bsdforen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--4zI0WCX1RcnW9Hbu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 27, 2013 at 10:33:18AM +0200, Dominic Fandrey wrote: > On 26/07/2013 19:10, Dominic Fandrey wrote: > > On 25/07/2013 12:00, Konstantin Belousov wrote: > >> On Thu, Jul 25, 2013 at 09:56:59AM +0200, Dominic Fandrey wrote: > >>> On 22/07/2013 12:07, Konstantin Belousov wrote: > >>>> On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote: > >>>>> ... > >>>>> > >>>>> I run amd through sysutils/automounter, which is a scripting soluti= on > >>>>> that generates an amd.map file based on encountered devices and devd > >>>>> events. The SIGHUP it sends to amd to tell it the map file was upda= ted > >>>>> does not cause problems, only a -SIGKILL- SIGTERM may cause the fre= eze. > >>>>> > >>>>> Nothing was mounted (by amd) during the last freeze. > >>>>> > >>>>> ... > >>>> > >>>> Are you sure that the machine did not paniced ? Do you have serial = console ? > >>>> > >>>> The amd(8) locks itself into memory, most likely due to the fear of > >>>> deadlock. There are some known issues with user wirings in stable/9. > >>>> If the problem you see is indeed due to wiring, you might try to app= ly > >>>> r253187-r253191. > >>> > >>> I tried that. Applying the diff was straightforward enough. But the > >>> resulting kernel paniced as soon as it tried to mount the root fs. > >> You did provided a useful info to diagnose the issue. > >> > >> Patch should keep KBI compatible, but, just in case, if you have any > >> third-party module, rebuild it. > >> > >>> > >>> So I'll wait for the MFC from someone who knows what he/she is doing. > >> > >> Patch below booted for me, and I run some sanity check tests for the > >> mlockall(2), which also did not resulted in misbehaviour. > >> > >=20 > > Your patch applied cleanly and the system booted with the resulting > > kernel. > >=20 > > Amd exhibits several very strange behaviours. ... >=20 > I can verify the whole thing with a clean world and kernel. >=20 > This time I'll concentrate on the first instance of amd: >=20 > # tail -n3 /var/log/messages > Jul 27 10:08:56 mobileKamikaze kernel: newnfs server pid5868@mobileKamika= ze:/var/run/automounter.amd.mnt: not responding > Jul 27 10:09:41 mobileKamikaze kernel: newnfs server pid5868@mobileKamika= ze:/var/run/automounter.amd.mnt: not responding > Jul 27 10:11:41 mobileKamikaze last message repeated 3 times >=20 > The process, it turns out, simply doesn't exist. There is another > process, though: > # ps auxww | grep -F sbin/amd > root 5869 0.0 0.1 12036 8020 ?? S 10:08am 0:00.01 /usr/= sbin/amd -r -p -a /var/run/automounter.amd -c 4 -w 2 /var/run/automounter.a= md.mnt /var/run/automounter.amd.map >=20 > # cat /var/run/automounter.amd.pid > 5868 >=20 > Here is what I think happens, amd forks a subprocess and the main > process, silently dies after it wrote its pidfile. Nothing dies silently. Either process was killed by signal, or it exited with the explicit call to exit(2). In the first case, default kernel settings of kern.logsigexit should make a record in the syslog. The machdep.uprintf_signal might be also useful, but not for daemons. If the process called exit(2), ktrace would show it. >=20 > For completeness: > # mount > /dev/ufs/5root on / (ufs, local, noatime, soft-updates) > devfs on /dev (devfs, local, multilabel) > /dev/ufs/5stor on /pool/5stor (ufs, local, noatime, soft-updates) > /pool/5stor/usr on /usr (nullfs, local, noatime) > /pool/5stor/var on /var (nullfs, local, noatime) > /usr/home/root on /root (nullfs, local, noatime) > tmpfs on /var/log (tmpfs, local) > tmpfs on /var/run (tmpfs, local) > tmpfs on /tmp (tmpfs, local) >=20 > Everything else seems to work. I'll revert your patch for now and > wait for the MFC. I was unable to get useful information from any of your posts. My current plan is to merge the revisions after the 9.2 freeze is over. --4zI0WCX1RcnW9Hbu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR9LkCAAoJEJDCuSvBvK1B/QYP/iyDVevCV8tkCBIkDbAZJ0Lb Lp2kHTAeu2hqwfzfzwiiEgO5toEHe7VeyJQ/3CxtkTQk4Y8d6hM5tpvrtOHM5SXJ faDE7v/kRwKuCblkZoUKVzuZA+4iR4SgvsCQDdGcYtAPwxLkBeEIslbp1eyC2cAy EzCbaw6wsDpzutLZyBxpZaPjnaayyL3rDLk46vZ67AgVL14z2+VcAH1sf/WuKdG6 e3B+HrUUC+f2cR/4l+R6ISe6BBynOVj2ZJ74FP2uj4sXUDW+fAue+imcnewm6PGA UOF7QL9+GuzuzmOuymIdBZtOik4JSJQxcpCubihPDCX18ho7wm2x1drxqrFjCGDe rrPf/aA19ilDiYbiZ2eEoAUhxuYx663wGJH5CrFhS5ELx0Mro6XaLhw+ES1iAyYN ki0zB7Kci3etcv3Bxnb789TpNCL35LO7neN2xOPnATLdJr20o+0RDtHLIKhV0s8x c0JGba/C02A9vL6JTmaSboIkc38CHKvggmYnpLHfge9WHfZI/1aCIKPSY9sIuTJq Sfns3PBMsbCfEYfOLVKWjhnfADo6335G73VVFBP5nhsc/5fPa4ohkw+mexCF/HCt 4ndlkcURK6uF6DHOxRyAUnWIV/CM9d1V6UxxnyH064q0X0UDzPnRJKD+zdFbNxEw z47noDqd2A+jE2sIwL2h =AK8D -----END PGP SIGNATURE----- --4zI0WCX1RcnW9Hbu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130728062403.GD4972>