Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Jul 2013 10:33:18 +0200
From:      Dominic Fandrey <kamikaze@bsdforen.de>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: stopping amd causes a freeze
Message-ID:  <51F385CE.1030606@bsdforen.de>
In-Reply-To: <51F2AD8C.1000003@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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 solution
>>>>> 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 updated
>>>>> does not cause problems, only a -SIGKILL- SIGTERM may cause the freeze.
>>>>>
>>>>> 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 apply
>>>> 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.
>>
> 
> Your patch applied cleanly and the system booted with the resulting
> kernel.
> 
> Amd exhibits several very strange behaviours. ...

I can verify the whole thing with a clean world and kernel.

This time I'll concentrate on the first instance of amd:

# tail -n3 /var/log/messages
Jul 27 10:08:56 mobileKamikaze kernel: newnfs server pid5868@mobileKamikaze:/var/run/automounter.amd.mnt: not responding
Jul 27 10:09:41 mobileKamikaze kernel: newnfs server pid5868@mobileKamikaze:/var/run/automounter.amd.mnt: not responding
Jul 27 10:11:41 mobileKamikaze last message repeated 3 times

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.amd.mnt /var/run/automounter.amd.map

# cat /var/run/automounter.amd.pid
5868

Here is what I think happens, amd forks a subprocess and the main
process, silently dies after it wrote its pidfile.

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)

Everything else seems to work. I'll revert your patch for now and
wait for the MFC.

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51F385CE.1030606>