Date: Wed, 16 May 2012 10:50:35 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-acpi@freebsd.org Cc: Bruce Cran <bruce@cran.org.uk>, freebsd-current <freebsd-current@freebsd.org>, Andriy Gapon <avg@freebsd.org> Subject: Re: ACPI 'driver bug: Unable to set devclass' Message-ID: <201205161050.35759.jhb@freebsd.org> In-Reply-To: <4FB285C0.1090905@FreeBSD.org> References: <4FAF7343.8010808@cran.org.uk> <201205151034.13994.jhb@freebsd.org> <4FB285C0.1090905@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > on 15/05/2012 17:34 John Baldwin said the following: > > 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: <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. > > > > 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. > > Not sure what you disagree with... > First, the wildcard device is added to the child list during the walk. > Then, the unit 0 device is added to the list when acpi_timer identify is executed. > Then, the wildcard device is probed and gets unit number of zero. > Then, the fixed device is being probed and the unit number conflict arises. > > Am I misunderstanding something? Yes. The third step will see that unit 0 is already in use and shouldn't reuse unit 0. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201205161050.35759.jhb>