From owner-freebsd-bugs@FreeBSD.ORG Fri Jun 18 14:00:59 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC1F416A4CE for ; Fri, 18 Jun 2004 14:00:59 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B51B643D1F for ; Fri, 18 Jun 2004 14:00:59 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i5IE0gQC004932 for ; Fri, 18 Jun 2004 14:00:42 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i5IE0gac004931; Fri, 18 Jun 2004 14:00:42 GMT (envelope-from gnats) Date: Fri, 18 Jun 2004 14:00:42 GMT Message-Id: <200406181400.i5IE0gac004931@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Andriy Gapon Subject: Re: kern/67940: acpi kernel trap on 4.10-release X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andriy Gapon List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2004 14:00:59 -0000 The following reply was made to PR kern/67940; it has been noted by GNATS. From: Andriy Gapon To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/67940: acpi kernel trap on 4.10-release Date: Fri, 18 Jun 2004 16:52:01 +0300 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