On 2005-11-03 03:47, Giorgos Keramidas <keramida_at_ceid.upatras.gr> wrote: > On 2005-11-02 17:03, Nate Lawson <nate_at_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. Does the following look ok for using memguard(9) with M_ACPICA? %%% begin acpica-memguard.patch Index: kern/kern_malloc.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v retrieving revision 1.148 diff -u -r1.148 kern_malloc.c --- kern/kern_malloc.c 20 Oct 2005 21:28:31 -0000 1.148 +++ kern/kern_malloc.c 3 Nov 2005 02:04:02 -0000 _at__at_ -62,6 +62,8 _at__at_ #include <vm/uma_int.h> #include <vm/uma_dbg.h> +MALLOC_DECLARE(M_ACPICA); + #ifdef DEBUG_MEMGUARD #include <vm/memguard.h> #endif _at__at_ -305,7 +307,7 _at__at_ #ifdef DEBUG_MEMGUARD /* XXX CHANGEME! */ - if (mtp == M_SUBPROC) + if (mtp == M_ACPICA) return memguard_alloc(size, flags); #endif %%% end acpica-memguard.patchReceived on Thu Nov 03 2005 - 01:09:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:47 UTC