From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 5 17:07:34 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD0AAEE1; Mon, 5 Nov 2012 17:07:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F14928FC0A; Mon, 5 Nov 2012 17:07:32 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA07201; Mon, 05 Nov 2012 19:07:25 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5097F24D.7040206@FreeBSD.org> Date: Mon, 05 Nov 2012 19:07:25 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tom Lislegaard Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource References: <509172F6.2040400@FreeBSD.org> <5092F209.7090803@FreeBSD.org> <50979BCD.3060000@FreeBSD.org> <5097CB27.8040802@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:07:34 -0000 on 05/11/2012 16:52 Tom Lislegaard said the following: > > >> -----Original Message----- >> From: Andriy Gapon [mailto:avg@FreeBSD.org] >> Sent: 5. november 2012 15:21 >> To: Tom Lislegaard >> Cc: freebsd-stable@FreeBSD.org; freebsd-acpi@FreeBSD.org >> Subject: Re: 9-Stable panic: resource_list_unreserve: can't find resource >> >> on 05/11/2012 15:54 Tom Lislegaard said the following: >>> Here's the distribution from running devd over 40 minutes >>> >>> 589 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU0 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU1 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU2 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU3 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU4 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU5 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU6 notify=0x81' >>> 590 Processing event '!system=ACPI subsystem=PROCESSOR type=\\_PR_.CPU7 notify=0x81' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=dsp4.1' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=pts/2' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=CREATE cdev=vboxdrv0' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=dsp4.1' >>> 1 Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=vboxdrv0' >>> >>> Any use in running it over a longer period of time? >> >> Very interesting. >> So the processors get _CST change notifications rather frequently, but there is no obvious >> source/cause for them... >> >> Could you please send to me acpidump -dt output or upload it somewhere and post a link? > > Here you go > > https://dl.dropbox.com/u/13263820/acpidump.txt So, ACPI platform on your machine sends 0x81 notification for processors objects each time "_PSR" method of AC Adapter / Power Source device is queried. There could be a number of reason to invoke the method - either AC line status queries from userland (some battery / line monitoring program/applet) or internal ACPI notifications. Are you willing to go as far as recompiling your kernel with 'options ACPI_DEBUG' to get to the bottom of this issue? If yes, then please do that and also add the following lines to loader.conf: debug.acpi.layer="ACPI_EVENTS ACPI_AC_ADAPTER" debug.acpi.level="ACPI_LV_INFO" I would be interested in all periodically occurring ACPI debug messages (after boot is finished). I suspect that the ACPI platform and/or embedded controller send too many notifications when they are not strictly necessary. Maybe there is a BIOS update for your machine? In any case, I am starting to work on a patch that should fix this problem without resorting to any special configuration. -- Andriy Gapon