From owner-freebsd-acpi@FreeBSD.ORG Mon May 14 16:41:42 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 197A7106566B; Mon, 14 May 2012 16:41:42 +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 DDD968FC12; Mon, 14 May 2012 16:41:40 +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 TAA26869; Mon, 14 May 2012 19:41:38 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FB135C1.4000505@FreeBSD.org> Date: Mon, 14 May 2012 19:41:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bruce Cran References: <4FAF7343.8010808@cran.org.uk> <4FB01437.6030608@FreeBSD.org> <4FB0391D.3040501@cran.org.uk> In-Reply-To: <4FB0391D.3040501@cran.org.uk> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current , Jung-uk Kim Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 16:41:42 -0000 on 14/05/2012 01:43 Bruce Cran said the following: > On 13/05/2012 21:06, Andriy Gapon wrote: >> Can you produce an equivalent snippet with verbose logging enabled? I have a >> suspicion that these messages are a byproduct from r231161. > > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bbf00000 (3) failed > acpi_sysresource: acpi_sysresource0 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > acpi_timer: acpi_timer0 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_timer devname: (unknown)) > cpu0: on acpi0 > ACPI Warning: Incorrect checksum in table [OEMB] - 0x45, should be 0x44 > (20120420/tbutils-293) > ACPI: SSDT 0xbb7900f0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 00000011 INTL 20051117) > ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 00003001 INTL 20051117) > acpi_sysresource: acpi_sysresource2 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > cpu2: on acpi0 > acpi_sysresource: acpi_sysresource1 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > cpu1: on acpi0 > acpi_sysresource: acpi_sysresource3 already exists; skipping it > driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown)) > I think that the following is what happens here in the acpi_timer case. Previously one acpi_timer device_t was added with an order of zero and a fixed unit number of zero in acpi_timer_identify(). Then, another acpi_timer device_t could be added when walking the ACPI device tree, that device would always have a later order and a wildcard unit number (-1). Now both the "hardwired" device and "auto-probed" device are added with the same order of 2 and it also so happens that the hardwired device is after the auto-probed in the device list. So first the auto-probed device just takes the unit number of zero because it is free and then the hardwired device fails to claim the same unit number. The call chain is: device_probe_child -> device_set_devclass -> devclass_add_device -> devclass_alloc_unit. BTW, it seems that acpi_timer_probe is hardcoded to succeed only for the hardwired device, so I am not if we should just skip creating an auto-probed device. In any case, setting any special properties for the auto-probed device (like the order) seems to be completely pointless. I am not really sure what happens for the acpi_sysresource devices. -- Andriy Gapon