kernel trap with ACPI on 4.10-release
robert.moore at intel.com
Fri Jun 18 14:48:30 GMT 2004
29 October 2003. Summary of changes for version 20031029:
Updated the implementation of the Stall() operator to only call
AcpiOsStall(), and also return an error if the operand is larger than
255. This preserves the required behavior of not relinquishing the
processor, as would happen if AcpiOsSleep() was called for "long
> -----Original Message-----
> From: Moore, Robert
> Sent: Friday, June 18, 2004 7:43 AM
> To: 'Andriy Gapon'; freebsd-acpi at freebsd.org
> Subject: RE: kernel trap with ACPI on 4.10-release
> This has been fixed for some number of months. What version of ACPI
> are you using?
> > -----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
> > > 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
> > > the easiest, one line change from "taskqueue_swi" to
> > > in OsdSchedule.c
> > >
> > > I hope my investigation has something helpful in it, and any
> > > would also be very helpful for my self-education on kernel
> > 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
> > debugging printf-s and determined that tasks on taskqueue_swi were
> > executed while acpi_tz_thread "held" splhigh(), this led me to idea
> > this kernel thread somewhere willingfully gave up its priority, like
> > tsleep().
> > In my DSTD _TMP() accesses Winbond HWM chip to read current
> > 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
> > is entirely backwards: it calls AcpiOsStall() for long delays and
> > AcpiOsSleep() for short delays, also incorrectly converts units for
> > latter case, not speaking of the fact that ACPI standard commands
> > Stall should not be used for delays longer than 100 microseconds and
> > should not be given up.
> > I see that this function was made sane in the code imported in
> > (file revision 80). I realize that this is a contributed, vendor
> > 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