History

Please upload (or send me privately) gzip'ed /var/run/dmesg.boot
from boot -v (drop into the boot loader and type `boot -v').
Do you experience the same panic with a UP kernel and ACPI driver
without 'CFLAGS="-DSMP=1"'?

:SMP dmesg uploaded to the bug-tracker.
:
:The dirty filesystem is from a lazy press of the reset button and has nothi=
:ng to
:do with this bug.
:
:I'll try to check with a UP kernel soon.
:
:-Thanks,
:-Floid

Hmm. ACPI is probably calling AcpiOsReleaseObject() twice for the same
object sometime prior to the call to AcpiOsDeleteCache().

Lets see if we can catch it in the act. Try this patch and get a
backtrace when you get the (hopefully new) panic.

If we can catch it in the act earlier and get a good backtrace we may
have enough information to fix the bug or, if messing with the contrib
code is too messy, just ignore the error instead of panicing.

:Joe "Floid" Kanowitz <jkanowitz@snet.net> added the comment:
:
:Looks like the patch was a winner; what you've won, I'm not experienced (or
:awake) enough to figure out.
:
:http://bugs.dragonflybsd.org/file213/Patch_Panic_1.png and
:http://bugs.dragonflybsd.org/file214/Patch_Panic_2.png ,
:
:hopefully the PNGs are less eye-searingly blurry than the JPGs were, and
:hopefully I'll have a working serial header within a week or two.
:
:-Floid

Yah. It looks like a reference count problem in the ACPI contrib code,
and it doesn't look like it will be easy to find.

The ACPI code is clearly reusing freed memory so it may panic in
other ways, but we can try just letting this error slide and see if
that stops your panics. Here's a patch to try.

Can you try attached patch? AcpiUtUpdateObjectReference() can leave
Object->CommonNotify.SystemNotify or Object->CommonNotify.DeviceNotify
non-NULL after they are (eventually) released by AcpiUtDeleteObjectDesc().
AcpiUtDeleteObjectDesc() can leak the object if it's not of type
ACPI_OPERAND_OBJECT, so it also may have to be converted to accept
(ACPI_OPERAND_OBJECT **).

Since Tomokazu's patch showed up before I could test, I still haven't tried
yours and will do so next just to prove it. This bug obviously sucks for anyone
with a need to reboot remotely, but FWIW, #566 -- the NATA/SB600/?? problem --
is a much bigger annoyance to someone at the console.

I was under the impression that just going to single-user mode and
type `reboot' could trigger the panic, no?

Unfortunately I can't reproduce the same panic on both UP and SMP kernels
here. Can you try attached patch? This is a slightly modified version of
Matt's patch but can print the function and the line number of the previous
caller of AcpiOsReleaseCache(). To build the acpi driver, revert previous
patches, then
$ export ACPI_DEBUG=yes ACPI_DEBUG_CACHE=yes
(for SMP kernel, you also need "export CFLAGS='-O -pipe -DSMP=1'")
$ cd /sys/dev/acpica5
$ make cleandir; make cleandir
$ make -s obj && make -s depend && make -s
$ su
# make install && reboot

You don't need to try this for both UP and SMP kernels, as either of them
can trigger the panic. Note that this patch avoids the double-free panic
so you need to use `shutdown -p' or `shutdown -h' instead of `reboot'
(unless dmesg survives across reboot).