On Thu, 2005-11-03 at 16:24 +0200, Giorgos Keramidas wrote: > 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. > > This is definitely something that is ACPI-related. I updated my > sources to the last commit before the start of the ACPI import: > > build_at_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. > Just tried reverting, and my problem reported in http://lists.freebsd.org/pipermail/freebsd-current/2005-November/057596.html is also ACPI-related. It also happens early on boot but panic is different (in devfs_populate_loop()). Don't know if it's related or a different bug introduced by the ACPI-CA import.Received on Thu Nov 03 2005 - 14:33:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:47 UTC