Kernel panic with ACPI enabled

John Baldwin jhb at freebsd.org
Tue Feb 7 12:52:33 PST 2006


On Tuesday 07 February 2006 15:13, Donald J. O'Neill wrote:
> On Tuesday 07 February 2006 13:04, John Baldwin wrote:
> > On Tuesday 07 February 2006 13:37, Donald J. O'Neill wrote:
> > > On Tuesday 07 February 2006 09:48, John Baldwin wrote:
> > >
> > >
> > > 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.
>
> Hi John,
>
> It seems to me that eisa was an extension to isa and that most modern
> computers don't have an isa bus but have eisa bus instead, In fact I
> have a Gateway Computer (500Mhz PIII) that has an eisa slot on the MB.
> Actually most modern computers don't physically have a slot for either
> isa or eisa. Quite possibly either one would work. I have 'device eisa'
> in my conf, it's also 'device eisa' in the GENERIC conf which is why I
> mentioned it.

No, EISA is completely different from ISA.  Older devices like PS/2 keyboards, 
the RTC, and 8259A PICs now usually all reside inside the soutbridge on a bus 
called LCP (low pin count) which looks like ISA (but isn't technically).  ISA 
had no type of enumeration (unless you count ISA PnP), whereas EISA does 
provide a method for querying the slots to find out what devices are present, 
etc.

> I also have a memory of APM and ACPI being incompatible - I think that
> was from the early 5.x days, not sure, could be from earlier. But
> commenting out "device apm' certainly wouldn't hurt since he's probably
> going to have to rebuild anyway.

Yes, early 5.x days.  Back before 5.0 was released sys/kern/subr_power.c was 
added which was the first step in making the two play nice, and later in 5.x 
I added the legacy0 device which was only used if acpi0 didn't attach (either 
not present or disabled) and moved apm0 so that it was a child of legacy0.

> I think I would also ask: is he trying to do a custom kernel with 6.0
> release sources or 6.0 stable sources? When I went from release to
> stable things worked.

For some issues, that would be better yes.

> Other things can affect what he's trying to do and cause him to think he
> has an ACPI problem. I had a bad USB mouse that was causing problems on
> one of my computers, in fact anything USB on that computer caused a
> problem with ACPI (it had to be disabled to allow the computer to
> boot-up) if that mouse was plugged in, until I found the mouse was bad
> and switched it with one that was ok. On another computer, I could only
> boot-up if I either disabled ACPI or had the USB mouse unplugged. After
> it was up, the mouse could be plugged back in and it would work, ACPI
> would work, but I would be left wondering about the situation. I
> finally decided to just use a PS-2 mouse and wait a while. That works
> fine, although I hate ball mice.

Actually, in his case I'm fairly sure MAXMEM is the problem.  Several people 
have had problems trying to use the tunable equivalent (hw.physmem=3g and the 
like) because if the new maxmem value is greater than the highest memory 
address we found, we just extend the last segment of physical memory.  
However, in the case of modern machines with SMAPs, this extension can result 
in including memory that was specifically marked as unavailable (because it 
was in use by the BIOS to store the ACPI tables) suddenly being used by the 
kernel.  As part of this process, the kernel does test writes to each page, 
so it would corrupt the ACPI tables and eventually lead to issues such as 
this.

-- 
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