Dominik Brodowski wrote: > Hi, > > On Tue, Feb 20, 2007 at 09:24:36PM +0300, Alexey Starikovskiy wrote: > >>> On Mon, Feb 19, 2007 at 08:44:31AM -0500, Dominik Brodowski wrote: >>> >>> >>>> On Fri, Feb 16, 2007 at 12:54:55PM -0500, Len Brown wrote: >>>> >>>> >>>>>>> acpi_ec_transaction >>>>>>> acpi_ec_read >>>>>>> acpi_ec_space_handler >>>>>>> acpi_ev_address_space_dispatch >>>>>>> acpi_ex_access_region >>>>>>> acpi_ex_field_datum_ >>>>>>> acpi_ex_extract_from_field >>>>>>> ... >>>>>>> acpi_ex_ns_evaluate >>>>>>> acpi_ev_execute_reg_method >>>>>>> acpi_ev_reg_run >>>>>>> acpi_ns_walk_namespace >>>>>>> acpi_ev_execute_reg_methods >>>>>>> acpi_install_address_space_handler >>>>>>> acpi_ec_start >>>>>>> acpi_start_single_object >>>>>>> acpi_device_probe >>>>>>> really_probe >>>>>>> ... >>>>>>> bus_add_driver >>>>>>> ... >>>>>>> acpi_ec_init >>>>>>> >>>>>>> >>>>> Alexey, >>>>> Thanks for the fix -- it is applied. >>>>> >>>>> Dominik, >>>>> Did this fix help, or is the problem elsehwere? >>>>> >>>>> >>>> Unfortunately, this doesn't solve the issue for me -- now I get a panic >>>> with >>>> EIP at __list_add+0x2d/0x60, with the call trace being >>>> >>>> ... >>>> die >>>> do_page_fault >>>> error_code >>>> __mutex_lock_slowpath >>>> mutex_lock >>>> acpi_ec_transaction >>>> >>>> and then the same as above... Will try it out with lockdep disabled. >>>> >>>> >>> No, doesn't seem to be lockdep-related; same issue continues. "acpi=off" >>> fixes the issue, though, of course... >>> >>> Thanks, >>> Dominik >>> >>> >> Dominik, >> Could you send your acpidump and full dmesg please? >> > > http://userweb.kernel.org/~brodo/acpidump.binary > http://userweb.kernel.org/~brodo/acpidump.txt > http://userweb.kernel.org/~brodo/acpi-dmsg.txt > > Hope this helps, > Dominik > Thanks. I start to think, that ec is either not fully initialized or freed by the time acpi_ec_start is called... Please try if the following patch changes something. Alex.