Kernel panic with ACPI enabled

John Baldwin jhb at freebsd.org
Tue Feb 7 07:53:14 PST 2006


On Tuesday 07 February 2006 10:12, Przemysław Celej wrote:
> John Baldwin wrote:
> > On Monday 06 February 2006 17:45, Przemysław Celej wrote:
> >> Hi,
> >>
> >> Since I'm using FreeBSD 5.X and 6.X I've got seriously problem with
> >> ACPI. When I setup ACPI as module, I've got panic soon after kernel
> >> recognize processor:
> >> pmap_mapdev: Couldn't alloc kernel virtual memory
> >>
> >> *but* on GENERIC kernel ACPI works without any problems. I'm convinced
> >> that, this problem is depending on hardware (actually only on
> >> motherboard).
> >>
> >> Please help me, I need ACPI enabled.
> >>
> >> Environment:
> >> System version: FreeBSD-6.0 (but this problem steps out on FreeBSD 5.X
> >> also) Motherboard: Abit NF7-S (on nforce2 chipset)
> >> Memory: 512MB DDR (333Mhz)
> >> Hard drive: Seagate V 60GB/ATA100
> >> Processor: AMD Athlon2500+/333Mhz
> >
> > What kernel are you using that breaks?  Is it a custom kernel config?
>
> Yes, here is the config (currently I'm using FreeBSD 6.0):
> http://80.50.250.246/siano/forum/SYS-acpi-as-module.txt
>
> When I compile acpi directly into the kernel, I've got panic with the
> same message as above (pmap_mapdev...).
> Unfortunately I can't do backtrace, because kernel didn't mount disk
> *before* panic, I will try to move function responsible for mounting
> root device before pmap_mapdev().

You can get a backtrace if you include DDB in your kernel and use 'tr' at the 
db> prompt after the panic.  It might be easier to capture it if you can 
setup a serial console.

Also, you probably don't want the NO_MEMORY_HOLE (only applies to K6 CPUs, you 
have an Athlon (K8)),  CPU_UPGRADE_HW_CACHE (only applies to PC-98 machines 
in Japan), CPU_FASTER_5X86_FPU (only applies to Cyrix 5x86 CPUs), or 
CPU_SUSP_HLT (only applies to Cyrix CPUs) options.  You probably don't want 
the CPU_ATHLON_SSE_HACK unless you really need it as well, though it won't 
hurt.  Also, try removing the 'MAXMEM' option and letting the kernel figure 
out the mappings from the BIOS.  This might actually be the source of the 
panic since the kernel might be corrupting the ACPI tables due to the MAXMEM 
option.

> Sorry, if my english is terrible, but I come from Poland.
> Regards.

It's not terrible at all. :)

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-acpi mailing list