On 07/06/06, Michal Piotrowski <michal.k.k.piotrowski@xxxxxxxxx> wrote:
orphan pointer 0xf7ea1654 (size 40): c015208c: <kmem_cache_alloc> c01eb6c2: <acpi_os_acquire_object> c02010f7: <acpi_ut_allocate_object_desc_dbg> c0200f8b: <acpi_ut_create_internal_object_dbg> c01ef310: <acpi_ev_execute_reg_method> c01ef908: <acpi_ev_reg_run> c01fa4c3: <acpi_ns_walk_namespace> c01ef8c9: <acpi_ev_execute_reg_methods> c01ef293: <acpi_ev_initialize_op_regions> c02000d4: <acpi_initialize_objects> c03a0a37: <acpi_bus_init> c03a0ada: <acpi_init> c038e871: <do_initcalls> c038e91e: <do_basic_setup> c0100367: <init>
I didn't manage to track this problem completely. It looks to me like a real leak - two objects are allocated in acpi_ev_execute_reg_method but, when returning from acpi_ns_evaluate_by_handle(), params[1] has the reference_count = 2 (params[0] has this set to 1) and therefore not released via acpi_ut_remove_reference(). -- Catalin - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
