Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Jul 2013 19:10:36 +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:  <51F2AD8C.1000003@bsdforen.de>
In-Reply-To: <20130725100037.GM5991@kib.kiev.ua>
References:  <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> <51F0DA4B.3000809@bsdforen.de> <20130725100037.GM5991@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

a)
During the first start it writes the wrong PID into the pidfile,
it however still reacts to SIGTERM.

b)
After starting it again, it no longer reacts to SIGTERM.

c)
It appear to be no longer reacting to SIGHUP, which is required to
tell it that the amd.map was updated.

d)
It doesn't work at all, I only get:
# cd /media/ufs/FreeBSD_Install
/media/ufs/FreeBSD_Install: Too many levels of symbolic links.

e)
A SIGKILL without load will terminate the process. A SIGKILL while
there is heavy file system load panics the system.

I'll try a clean buildworld buildkernel and repeat.

-- 
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?51F2AD8C.1000003>