Kernel panic with ACPI enabled

[John Baldwin]

On Tuesday 07 February 2006 13:37, Donald J. O'Neill wrote:
> On Tuesday 07 February 2006 09:48, John Baldwin wrote:
> > 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. :)
>
> I have a few things. Is there a reason you have 'device apm'? Are you
> trying to use APM and ACPI at the same time? Why do you have 'device
> isa' rather than 'device eisa'? Where you, by any chance, just re-using
> your conf file from 5.x? It kind of looks that way. Have you looked at
> i386/conf/NOTES? There is some more information in there.

device isa is normal, and he probably just commented out eisa since modern 
systems don't have EISA slots.  The apm thing won't hurt, though it probably 
adds a small bit of bloat to the kernel.  If you have both apm and acpi then 
acpi will be used if it is present, otherwise if acpi is not present (or is 
disabled) then apm will be used.

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