On Tuesday 21 February 2006 06:19, Andrew Morton wrote: > "Hesse, Christian" wrote: > > Hello everybody, > > > > since using kernel version 2.6.16-rc4 the hal daemon is in status D after > > resume. I use suspend2 2.2.0.1 for 2.6.16-rc3. Any hints what could be > > the problem? It worked perfectly with 2.6.15.x and suspend2 2.2. > > a) Look in the logs for any oopses, other nasties Nothing. > b) Do `echo t > /proc/sysrq-trigger', `dmesg -s 1000000 > foo' then find > the trace for `hald' in `foo', send it to this list. Ok, here it is: hald D E0B50480 0 7791 1 7797 10654 7609 (NOTLB) cc6cbccc e0b50480 000f4428 e0b50480 000f4428 c6c9605c c14dce00 c14dce00 e0b50480 000f4428 cc3df530 dff6e5c0 cc3df530 00000296 dff6e5c8 c046f202 00000001 cc3df530 c0115680 d7ea1ce0 dff6e5c8 00000003 00000001 00000000 Call Trace: [] __down+0x62/0xc0 [] default_wake_function+0x0/0x20 [] __down_failed+0x7/0xc [] .text.lock.osl+0x13/0x3c [] acpi_ex_system_wait_semaphore+0x34/0x48 [] acpi_ev_acquire_global_lock+0x67/0x6c [] acpi_ex_acquire_global_lock+0x14/0x3b [] acpi_ex_read_data_from_field+0x114/0x14b [] acpi_ex_resolve_node_to_value+0x123/0x1ac [] acpi_ex_resolve_to_value+0x5e/0x69 [] acpi_ex_resolve_operands+0x277/0x4dc [] acpi_ds_exec_end_op+0xab/0x36e [] acpi_ps_parse_loop+0x5ba/0x8bc [] acpi_ps_parse_aml+0x4e/0x1f9 [] acpi_ps_execute_pass+0x72/0x83 [] acpi_ps_execute_method+0x54/0x7d [] acpi_ns_execute_control_method+0x5a/0x67 [] acpi_ns_evaluate_by_handle+0x73/0x8a [] acpi_ns_evaluate_relative+0xaa/0xc6 [] acpi_evaluate_object+0x139/0x1fb [] copy_to_user+0x42/0x60 [] acpi_battery_get_status+0x6b/0x11c [] acpi_battery_read_state+0x52/0x185 [] seq_read+0xe8/0x2f0 [] vfs_read+0xaa/0x1a0 [] sys_read+0x51/0x80 [] sysenter_past_esp+0x54/0x75 This is with 2.6.16-rc4-git1 + suspend2 2.2.0.1. -- Christian