Re: ACPI 'driver bug: Unable to set devclass'
On Thursday, May 17, 2012 11:33:56 am Andriy Gapon wrote: > on 17/05/2012 17:05 John Baldwin said the following: > > On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: > >> Oh, whoops. Actually, the right way to do this I think is > >> bus_hint_device_unit() > >> (and/or, not make the unit number in cpuX mean anything at all, but use a > >> separate > >> ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I > >> think > >> the last approach is really the right way to fix this. > > > > I haven't been able to try this yet, but I have a first cut at > > www.freebsd.org/~jhb/patches/acpi_cpu.patch > > > > The patch has not been compile-tested? :) I've updated it with a run-tested version. -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI 'driver bug: Unable to set devclass'
On Thursday, May 17, 2012 11:33:56 am Andriy Gapon wrote: > on 17/05/2012 17:05 John Baldwin said the following: > > On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: > >> Oh, whoops. Actually, the right way to do this I think is > >> bus_hint_device_unit() > >> (and/or, not make the unit number in cpuX mean anything at all, but use a > >> separate > >> ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I > >> think > >> the last approach is really the right way to fix this. > > > > I haven't been able to try this yet, but I have a first cut at > > www.freebsd.org/~jhb/patches/acpi_cpu.patch > > > > The patch has not been compile-tested? :) Not yet. I'll try to test it later today unless someone beats me to it. :-P -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI 'driver bug: Unable to set devclass'
on 17/05/2012 17:05 John Baldwin said the following: > On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: >> Oh, whoops. Actually, the right way to do this I think is >> bus_hint_device_unit() >> (and/or, not make the unit number in cpuX mean anything at all, but use a >> separate >> ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I >> think >> the last approach is really the right way to fix this. > > I haven't been able to try this yet, but I have a first cut at > www.freebsd.org/~jhb/patches/acpi_cpu.patch > The patch has not been compile-tested? :) -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI 'driver bug: Unable to set devclass'
On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: > On Wednesday, May 16, 2012 12:18:25 pm Andriy Gapon wrote: > > on 16/05/2012 17:50 John Baldwin said the following: > > > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > > >> 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. > > > > > > > Looks like I missed the call to devclass_add_device() in make_device(). > > > > Your guess: > > > I wonder if this is related to the recent changes to set the unit number > > > for CPUs? > > > > seems to be true. > > > > The device_t-s created for CPUs have NULL driver name / devclass, but a > > non-wildcard unit number. So when such a device with unit number 0 is > > probed by > > acpi_timer we get a unit number conflict with acpi_timer0 pre-created via > > the > > identify. > > Similarly we get conflicts for acpi_sysresource driver, because we do an > > early > > probe-and-attach for this driver and the attached devices get some unit > > numbers > > (0, 1, etc). So when during the normal probe pass the "CPU" devices with > > matching > > unit numbers are passed to the driver the conflict results. > > > > I guess that it is an unorthodox use of newbus to specify a unit number > > without > > specifying a driver name... It's like saying "this device must be unit N > > whatever > > driver claims it (be it kbdN or diskN) just because I say so". Not sure if > > this > > ever makes sense and maybe we should prohibit such a combination (reject it > > earlier). > > I guess that in this particular case we already know that the devices are > > really > > CPU devices and are going to be claimed by acpi cpu driver. So we should > > pass > > "cpu" as the name. > > Oh, whoops. Actually, the right way to do this I think is > bus_hint_device_unit() > (and/or, not make the unit number in cpuX mean anything at all, but use a > separate > ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I > think > the last approach is really the right way to fix this. I haven't been able to try this yet, but I have a first cut at www.freebsd.org/~jhb/patches/acpi_cpu.patch -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI 'driver bug: Unable to set devclass'
On Wednesday, May 16, 2012 12:18:25 pm Andriy Gapon wrote: > on 16/05/2012 17:50 John Baldwin said the following: > > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: > >> 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. > > > > Looks like I missed the call to devclass_add_device() in make_device(). > > Your guess: > > I wonder if this is related to the recent changes to set the unit number > > for CPUs? > > seems to be true. > > The device_t-s created for CPUs have NULL driver name / devclass, but a > non-wildcard unit number. So when such a device with unit number 0 is probed > by > acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the > identify. > Similarly we get conflicts for acpi_sysresource driver, because we do an early > probe-and-attach for this driver and the attached devices get some unit > numbers > (0, 1, etc). So when during the normal probe pass the "CPU" devices with > matching > unit numbers are passed to the driver the conflict results. > > I guess that it is an unorthodox use of newbus to specify a unit number > without > specifying a driver name... It's like saying "this device must be unit N > whatever > driver claims it (be it kbdN or diskN) just because I say so". Not sure if > this > ever makes sense and maybe we should prohibit such a combination (reject it > earlier). > I guess that in this particular case we already know that the devices are > really > CPU devices and are going to be claimed by acpi cpu driver. So we should pass > "cpu" as the name. Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() (and/or, not make the unit number in cpuX mean anything at all, but use a separate ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think the last approach is really the right way to fix this. -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI 'driver bug: Unable to set devclass'
on 16/05/2012 17:50 John Baldwin said the following: > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: >> 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. > Looks like I missed the call to devclass_add_device() in make_device(). Your guess: > I wonder if this is related to the recent changes to set the unit number for > CPUs? seems to be true. The device_t-s created for CPUs have NULL driver name / devclass, but a non-wildcard unit number. So when such a device with unit number 0 is probed by acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the identify. Similarly we get conflicts for acpi_sysresource driver, because we do an early probe-and-attach for this driver and the attached devices get some unit numbers (0, 1, etc). So when during the normal probe pass the "CPU" devices with matching unit numbers are passed to the driver the conflict results. I guess that it is an unorthodox use of newbus to specify a unit number without specifying a driver name... It's like saying "this device must be unit N whatever driver claims it (be it kbdN or diskN) just because I say so". Not sure if this ever makes sense and maybe we should prohibit such a combination (reject it earlier). I guess that in this particular case we already know that the devices are really CPU devices and are going to be claimed by acpi cpu driver. So we should pass "cpu" as the name. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
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 fee0, 1000 (3) failed > >>> acpi0: reservation of 0, a (3) failed > >>> acpi0: reservation of 10, bbf0 (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 0011 INTL 20051117) > >>> ACPI: Dynamic OEM Table Load: > >>> ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117) > >>> ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 3001 INTL 20051117) > >>> ACPI: Dynamic OEM Table Load: > >>> ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 3001 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. > > 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 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI 'driver bug: Unable to set devclass'
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 fee0, 1000 (3) failed >>> acpi0: reservation of 0, a (3) failed >>> acpi0: reservation of 10, bbf0 (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 0011 INTL 20051117) >>> ACPI: Dynamic OEM Table Load: >>> ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117) >>> ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 3001 INTL 20051117) >>> ACPI: Dynamic OEM Table Load: >>> ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 3001 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. 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? -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI 'driver bug: Unable to set devclass'
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 fee0, 1000 (3) failed > > acpi0: reservation of 0, a (3) failed > > acpi0: reservation of 10, bbf0 (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 0011 INTL 20051117) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117) > > ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 3001 INTL 20051117) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 3001 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 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI 'driver bug: Unable to set devclass'
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 fee0, 1000 (3) failed > acpi0: reservation of 0, a (3) failed > acpi0: reservation of 10, bbf0 (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 0011 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117) > ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 3001 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 3001 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 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI 'driver bug: Unable to set devclass'
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 fee0, 1000 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bbf0 (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 0011 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 01340 (v01 DpgPmm P001Ist 0011 INTL 20051117) ACPI: SSDT 0xbb791430 004F4 (v01 PmRef P001Cst 3001 INTL 20051117) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 004F4 (v01 PmRef P001Cst 3001 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)) -- Bruce Cran ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: ACPI 'driver bug: Unable to set devclass'
on 13/05/2012 11:39 Bruce Cran said the following: > I've just updated to -current and noticed the following errors in dmesg: > > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi0: reservation of fee0, 1000 (3) failed > acpi0: reservation of 0, a (3) failed > acpi0: reservation of 10, bbf0 (3) failed > driver bug: Unable to set devclass (class: acpi_sysresource devname: > (unknown)) > 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) > driver bug: Unable to set devclass (class: acpi_sysresource devname: > (unknown)) > cpu2: on acpi0 > driver bug: Unable to set devclass (class: acpi_sysresource devname: > (unknown)) > cpu1: on acpi0 > driver bug: Unable to set devclass (class: acpi_sysresource devname: > (unknown)) > Can you produce an equivalent snippet with verbose logging enabled? I have a suspicion that these messages are a byproduct from r231161. -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
