kern/67940: acpi kernel trap on 4.10-release

Andriy Gapon avg at
Fri Jun 18 13:52:44 GMT 2004

I looked into the problem more carefully and thoughtfully and now I
understand that I was looking in a completely wrong place for a
completely wrong stuff.
There should not have been any parallel execution thanks to proper
splhigh() locking, *but there was*! And I think I know why. I added some
debugging printf-s and determined that tasks on taskqueue_swi were
executed while acpi_tz_thread "held" splhigh(), this led me to idea that
this kernel thread somewhere willingfully gave up its priority, like in
In my DSTD _TMP() accesses Winbond HWM chip to read current temperature
and its access routine has calls to Stall(). If I understand Intel
ACPICA code correctly this call is executed in AcpiExSystemDoStall()
function (/usr/src/sys/contrib/dev/acpica/exsystem.c).
Looking at the code present in 4.10 (file revision 75) it seems that it
is entirely backwards: it calls AcpiOsStall() for long delays and
AcpiOsSleep() for short delays, also incorrectly converts units for the
latter case, not speaking of the fact that ACPI standard commands that
Stall should not be used for delays longer than 100 microseconds and CPU
should not be given up.
I see that this function was made sane in the code imported in CURRENT
(file revision 80). I realize that this is a contributed, vendor code,
but I think AcpiExSystemDoStall() should be patched for STABLE too,
because the way it is now, it is outright buggy and dangerous.

Andriy Gapon

More information about the freebsd-bugs mailing list