Re: ACPI 'driver bug: Unable to set devclass'

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