Re: Panic during shutdown (cause identified)

From: Greg Rivers <gcr+freebsd-current_at_tharned.org>
Date: Thu, 2 Jul 2009 11:37:01 -0500 (CDT)
On Thu, 2 Jul 2009, Kostik Belousov wrote:

>>> Also, please describe the load on the machine,
>>>
>>
>> It happens regardless of the load.  For example, just booting 
>> multi-user and immediately running shutdown (either by logging in or 
>> pressing the ACPI power button) triggers the panic.
> No, it does not happen regardless of the load. The patch was tested on 
> the semi-standard set of programs run on the system, and all seen 
> accounting mistakes were fixed.
>

I don't know what patch you're referring to.  Are you saying this issue 
was seen before and thought to have been fixed?


> You have some process that does exhibit the behaviour causing error in 
> swap accounting. I think for start you could just show me ps auxww 
> output, in private, if you prefer.
>

I can save you the trouble of reading ps output.  Based on your insight 
that the problem is with a particular process, I eliminated variables from 
/etc/rc.conf by trial, and have determined that it's the amd(8) 
automounter that's causing the panic.  When I remove 'amd_enable="YES"', 
no more panic.


> > The panic message on the console does not show the process.  Can that 
> > be determined from kgdb?  If so, how?
> It does show the process, like
> KDB: enter: panic
> [thread pid 32021 tid 100598 ]
>

Yes, ordinarily such message is shown, but it is not shown for this panic. 
Also with this panic, about half the time the machine locks up hard just 
before, during, or after the core dump.


> BTW, did you saw the kernel messages like negative vmsize for uid = XXX ?
>

No, there have been none of those.


Please let me know if I can help with further testing/debugging. BTW, I 
did not customize the amd configuration; I was using the stock 
configuration from the base system.

-- 
Greg Rivers
Received on Thu Jul 02 2009 - 14:37:06 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:51 UTC