Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 May 2012 19:41:37 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Bruce Cran <bruce@cran.org.uk>
Cc:        freebsd-acpi@FreeBSD.org, freebsd-current <freebsd-current@FreeBSD.org>, Jung-uk Kim <jkim@FreeBSD.org>
Subject:   Re: ACPI 'driver bug: Unable to set devclass'
Message-ID:  <4FB135C1.4000505@FreeBSD.org>
In-Reply-To: <4FB0391D.3040501@cran.org.uk>
References:  <4FAF7343.8010808@cran.org.uk> <4FB01437.6030608@FreeBSD.org> <4FB0391D.3040501@cran.org.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <ACPI CPU> 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: <ACPI CPU> on acpi0
> acpi_sysresource: acpi_sysresource1 already exists; skipping it
> driver bug: Unable to set devclass (class: acpi_sysresource devname: (unknown))
> cpu1: <ACPI CPU> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FB135C1.4000505>