Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Nov 2005 16:24:46 +0200
From:      Giorgos Keramidas <keramida@freebsd.org>
To:        Nate Lawson <nate@root.org>
Cc:        freebsd-acpi@freebsd.org, freebsd-current@freebsd.org, robert.moore@intel.com, jkim@freebsd.org
Subject:   Re: Panic on boot with new ACPI-CA
Message-ID:  <20051103142446.GA1787@flame.pc>
In-Reply-To: <20051103014740.GA1586@flame.pc>
References:  <971FCB6690CD0E4898387DBF7552B90E0346CAFB@orsmsx403.amr.corp.intel.com> <20051103.094643.74756456.haro@h4.dion.ne.jp> <436961FD.3040605@root.org> <20051103014740.GA1586@flame.pc>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2005-11-03 03:47, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
>On 2005-11-02 17:03, Nate Lawson <nate@root.org> wrote:
>> As I mentioned to Jung-uk, the problem is likely an error in
>> acpi-ca modifying memory after it has freed it.  The way to
>> track this down is to enable memguard(9).  See the man page for
>> info.  You need to add options DEBUG_MEMGUARD to your kernel,
>> set the malloc type to watch to M_ACPICA, and rebuild your
>> kernel and modules.  Memguard sets page permissions so we can
>> catch the culprit who is modifying the memory.
>
> This is exactly the messgae printed on my console at panic time
> -- of memory modified after free.  I'm building a kernel with
> MEMGUARD now, but it's probably going to be a bit hard to get a
> kernel dump, because the panic happens before disks are
> available and I don't have a serial console here.

This is definitely something that is ACPI-related.  I updated my
sources to the last commit before the start of the ACPI import:

    build@flame:/home/build/src$ cvs -qR up -APd -D '2005/11/01 22:00:00 UTC'

Rebuilt everything and I see no panics now.

I'll use the watchpoint trick Nate posted when I have a new build
to test.

- Giorgos




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