kernel trap with ACPI on 4.10-release
Moore, Robert
robert.moore at intel.com
Fri Jun 18 14:44:04 GMT 2004
This has been fixed for some number of months. What version of ACPI CA
are you using?
Bob
> -----Original Message-----
> From: owner-freebsd-acpi at freebsd.org [mailto:owner-freebsd-
> acpi at freebsd.org] On Behalf Of Andriy Gapon
> Sent: Friday, June 18, 2004 6:50 AM
> To: freebsd-acpi at freebsd.org
> Subject: Re: kernel trap with ACPI on 4.10-release
>
> on 11.06.2004 15:20 Andriy Gapon said the following:
> >
> ...
> > Having no knowledge in ACPI internals and very little knowledge in
> > kernel internals I can not dare suggest what would be most
appropriate
> > to do. Nevertheless, it seems that (1) would be too intrusive and
> > global; (3) is complex and might not be too reliable; (2) seems to
be
> > the easiest, one line change from "taskqueue_swi" to
"taskqueue_thread"
> > in OsdSchedule.c
> >
> > I hope my investigation has something helpful in it, and any
feedback
> > would also be very helpful for my self-education on kernel matters.
>
> 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
> tsleep().
> 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
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to
"freebsd-acpi-unsubscribe at freebsd.org"
More information about the freebsd-acpi
mailing list