Distribution: SuSE SLES 9 Hardware Environment: Toshiab Satellite M20 Software Environment: vanila kernel 2.6.5 with suspend_resume_4g4g.patch Problem Description: When I try to change fan state between D0 and D3, debug message said that the method execution failed, but proc file ( /proc/acpi/ fan/FAN0/state ) said it suceeded. Steps to reproduce: #cd /proc/acpi/fan/FAN0/ #cat state status: off #dmesg ... Execute Method: [\_TZ_.PFA0._STA] (Node cdf5f828) exregion-0294 [568] ex_system_io_space_han: system_iO 0 (32 width) Address=00000 00000001010 acpi_utils-0267 [551] acpi_evaluate_integer : Return value [0] acpi_power-0148 [550] acpi_power_get_state : Resource [PFA0] is off acpi_power-0185 [549] acpi_power_get_list_st: Resource list is off acpi_bus-0173 [547] acpi_bus_get_power : Device [FAN0] power state is D3 #echo 0 > state #dmesg ... Execute Method: [\_TZ_.PFA0._ON_] (Node cdf5f728) exregion-0294 [570] ex_system_io_space_han: system_iO 0 (32 width) Address=00000 00000001010 exregion-0294 [571] ex_system_io_space_han: system_iO 1 (8 width) Address=000000 00000000B3 exregion-0294 [571] ex_system_io_space_han: system_iO 1 (8 width) Address=000000 00000000B2 exoparg2-0120 [562] ex_opcode_2A_0T_0R : Unexpected notify object type [Scope ] psparse-1133: *** Error: Method execution failed [\_TZ_.PFA0._ON_] (Node cdf5f7 28), AE_AML_OPERAND_TYPE acpi_power-0392 [552] acpi_power_transition : Error transitioning device [FAN0] to D0 acpi_bus-0258 [551] acpi_bus_set_power : Error transitioning device [FAN0] to D0 #cat state status: on #dmesg ... Execute Method: [\_TZ_.PFA0._STA] (Node cdf5f828) exregion-0294 [592] ex_system_io_space_han: system_iO 0 (32 width) Address=00000 00000001010 acpi_utils-0267 [575] acpi_evaluate_integer : Return value [1] acpi_power-0148 [574] acpi_power_get_state : Resource [PFA0] is on acpi_power-0185 [573] acpi_power_get_list_st: Resource list is on acpi_bus-0173 [571] acpi_bus_get_power : Device [FAN0] power state is D0 Changing between D0 and D3 with fan's state interface, the result is same.
Created attachment 2596 [details] lspci -v
Created attachment 2597 [details] dsdt.dsl
The _TZ object apparently does not have the correct type (ThermalZone). It is one of the "predefined" types, so we can fix this in the ACPI CA core.
Try this: In utglobal.c: /****************************************************************************** * * Namespace globals * ******************************************************************************/ /* * Predefined ACPI Names (Built-in to the Interpreter) * * NOTES: * 1) _SB_ is defined to be a device to allow \_SB_._INI to be run * during the initialization sequence. */ const struct acpi_predefined_names acpi_gbl_pre_defined_names[] = { {"_GPE", ACPI_TYPE_LOCAL_SCOPE, NULL}, {"_PR_", ACPI_TYPE_LOCAL_SCOPE, NULL}, {"_SB_", ACPI_TYPE_DEVICE, NULL}, {"_SI_", ACPI_TYPE_LOCAL_SCOPE, NULL}, - {"_TZ_", ACPI_TYPE_LOCAL_SCOPE, NULL}, + {"_TZ_", ACPI_TYPE_THERMAL, NULL}, {"_REV", ACPI_TYPE_INTEGER, "2"}, {"_OS_", ACPI_TYPE_STRING, ACPI_OS_NAME}, {"_GL_", ACPI_TYPE_MUTEX, "0"}, #if !defined (ACPI_NO_METHOD_EXECUTION) || defined (ACPI_CONSTANT_EVAL_ONLY) {"_OSI", ACPI_TYPE_METHOD, "1"}, #endif {NULL, ACPI_TYPE_ANY, NULL} /* Table terminator */ };
Interestingly, I don't think that this is valid code: Notify (\_TZ, 0x80) Because in the ACPI spec, _TZ is NOT defined as a ThermalZone object. Even if we allow this behavior in ACPI CA, I should point out that it is almost certain that no unix or linux code has implemented support for this in the thermal driver. I.e., nobody is listening for the notify. Bob
Yes. After set "\_TZ" with ACPI_TYPE_THEMAL, no notify handler for that. Execute Method: [\_TZ_.PFA0._OFF] (Node cdf5f628) exregion-0294 [76] ex_system_io_space_han: system_iO 0 (32 width) Address=0000000000001010 exregion-0294 [77] ex_system_io_space_han: system_iO 1 (8 width) Address=00000000000000B3 exregion-0294 [77] ex_system_io_space_han: system_iO 1 (8 width) Address=00000000000000B2 evmisc-0135 [68] ev_queue_notify_reques: Dispatching Notify(80) on node cdfc78a8 evmisc-0143 [68] ev_queue_notify_reques: notify value: 0x2.2_x **Device Specific** evmisc-0200 [68] ev_queue_notify_reques: No notify handler for [_TZ_] node cdfc78a8
I've tried two ways. 1. modify DSDT, change Notify (\_TZ, 0x80) into Notify (\_TZ.THZN, 0x80) This lets thermal resource called when event arrives, then \_TZ.THZN._TMP will be called. 2. add default handler to Scope TZ object. It is just a debug patch, add new global object which behave like acpi_gbl_root_node, and catch notify event(now do nothing). This is for test only.
Created attachment 2823 [details] scope_tz_handler.patch
The patch should not have to touch the core ACPI CA code. Bob
Is this BIOS bug on this particular system, or do multiple systems have this problem?
re-opening -- debug patch only. need patch to thermal.c to register notify handler on _TZ May also need ACPI spec update here to match common practice.
ACPI spec defines no notifications to _TZ scope, moreover notification with value 0x80 defined as follows: Thermal Zone Status Changed. Used to notify OSPM that the thermal zone temperature has changed. so, it should be sent to one particular thermal zone. Also, I naven't seen any similar issues, so this problem is a BIOS bug. Rejecting.