[Haiku-commits] r33236 - in haiku/trunk: build/jam data/settings/kernel/drivers src/add-ons/kernel/bus_managers/acpi src/add-ons/kernel/bus_managers/acpi/include/platform

Philippe Houdoin philippe.houdoin at gmail.com
Thu Sep 24 12:23:05 CEST 2009


[Haiku-commits] r33236 - in haiku/trunk: build/jam
data/settings/kernel/drivers src/add-ons/kernel/bus_managers/acpi
src/add-ons/kernel/bus_managers/acpi/include/platform

Michael Lotz mmlr at mlotz.ch
> NULL pointer access in AcpiOsExecute. Since the only thing happening
> there is queuing a DPC call using the DPC module it means that the DPC
> module pointer is NULL.

Same conclusion.

> Can you check that the DPC module is linked in
> as a boot module in /boot/system/add-ons/kernel/boot. If not make a
> link there from /boot/system/add-ons/kernel/generic/dpc. Still, in case
> the DPC module initialization failed it must take actions to ensure
> that AcpiOsExecute won't be called. Checking the pointer would also
> make sense.

I guess what we have here is that, now that main bus manager
B_ACPI_MODULE does a more complete initialization, he needs do execute
some DPC.
But we still set up DPC queue only when ACPI_ROOT_MODULE is
registered, which I'll bet is now way too late, as AcpiOsExecute
seemms to be called during ACPI initialization process.

I'm for adding DPC to ACPI module dependency in acpi_module.c, and
create/delete the gDPCHandle dpc_queue not anymore in
acpi_module_init() (acpi_module.c) but directly in
acpi_std_ops(B_MODULE_INIT/UNINIT) (acpi_busman.c).

Bye,
  Philippe.



More information about the Haiku-commits mailing list