Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Jul 2013 14:35:37 +0200
From:      "Ronald Klop" <ronald-freebsd8@klop.yi.org>
To:        "Konstantin Belousov" <kostikbel@gmail.com>, "Dominic Fandrey" <kamikaze@bsdforen.de>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: stopping amd causes a freeze
Message-ID:  <op.w0milnfa8527sy@ronaldradial.versatec.local>
In-Reply-To: <51ED2360.2060104@bsdforen.de>
References:  <51ED0060.2050502@bsdforen.de> <20130722100720.GI5991@kib.kiev.ua> <51ED2360.2060104@bsdforen.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Jul 2013 14:19:44 +0200, Dominic Fandrey <kamikaze@bsdforen.de>  
wrote:

> On 22/07/2013 12:07, Konstantin Belousov wrote:
>> On Mon, Jul 22, 2013 at 11:50:24AM +0200, Dominic Fandrey wrote:
>>> Occasionally stopping amd freezes my system. It's a rare occurrence,
>>> and I haven't found a reliable way to reproduce it.
>>>
>>> It's also a real freeze, so there's no way to get into the debugger
>>> or grab a core dump. I only can perform the 4 seconds hard shutdown to
>>> revive the system.
>>>
>>> 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 may cause the freeze.
>>>
>>> Nothing was mounted (by amd) during the last freeze.
>>>
>>> I don't see any angle to tackle this, but I'm throwing it out here
>>> any way, in the hopes that someone actually has an idea how to approach
>>> the issue.
>>
>> Are you sure that the machine did not paniced ?  Do you have serial  
>> console ?
>
> No, I don't have one. All that I can tell is that everything freezes
> (i.e. Xorg screen and mouse). ACPI events like shutdown don't cause a
> reaction. And the system doesn't respond to ICMP queries.
>
>> 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.
>
> From head? That may be worth a try. It would be better for testing if I
> managed to reproduce the problem reliably, before I test patches.
>
> I see it's scheduled for MFC, soon.
>

Did you try a run with the INVARIANTS, etc. options in the kernel? That  
enables more sanity checking for locks which is too slow for production.

Ronald.



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