From owner-freebsd-acpi@FreeBSD.ORG Tue May 15 15:35:21 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 95376106564A; Tue, 15 May 2012 15:35:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 685598FC14; Tue, 15 May 2012 15:35:21 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CE30DB93E; Tue, 15 May 2012 11:35:20 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Tue, 15 May 2012 10:34:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <4FB0391D.3040501@cran.org.uk> <4FB135C1.4000505@FreeBSD.org> In-Reply-To: <4FB135C1.4000505@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205151034.13994.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 15 May 2012 11:35:20 -0400 (EDT) Cc: Bruce Cran , freebsd-current , Andriy Gapon 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: Tue, 15 May 2012 15:35:21 -0000 On Monday, May 14, 2012 12:41:37 pm Andriy Gapon wrote: > 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. Eh. This should not be true. The unit 0 is reserved when device_add_child() is called in the acpi_timer identify routine. The wildcard device will not be assigned a unit number until device_probe_child time. > The call chain is: > device_probe_child -> device_set_devclass -> devclass_add_device -> > devclass_alloc_unit. That is, the unit for the wildcard devices should still be -1 here and should not even get to this message. I wonder if this is related to the recent changes to set the unit number for CPUs? -- John Baldwin