Bug 16292
| Summary: | on ia64 machine, sometimes, power can't be off when "shutdown -h 0" | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Bob Zhang (bob_zhang2004) |
| Component: | Power-Off | Assignee: | ykzhao (yakui.zhao) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | normal | CC: | 2004.zhang, acpi-bugzilla, rui.zhang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.27.19-5 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
shutdown info
booting information I enable "CONFIG_APCI_DEBUG" ,PRINT MORE MESSAGES. acpidump output |
||
My machine 's information is like this: Do you know what's the definite power sequence after setting ACPI chipset (acpi_enter_sleep_state()) . after acpi_enter_sleep_state, what need to do again ?? Any idea is welcome . thanks very much! from booting machien , we can see , 8 CPUs available, 16 CPUs total MCA related initialization done Virtual mem_map starts at 0xa07fffffff400000 my machine's cpu infomation is like this : cat /proc/cpuinfo processor : 0 vendor : GenuineIntel arch : IA-64 family : 32 model : 2 model name : Intel(R) Itanium(R) Processor 9310 revision : 4 archrev : 0 features : branchlong, 16-byte atomic ops, 0x8 cpu number : 0 cpu regs : 4 cpu MHz : 799.000 itc MHz : 797.989938 BogoMIPS : 3186.68 siblings : 4 physical id: 0 core id : 2 thread id : 0 processor : 1 vendor : GenuineIntel arch : IA-64 family : 32 model : 2 model name : Intel(R) Itanium(R) Processor 9310 revision : 4 archrev : 0 features : branchlong, 16-byte atomic ops, 0x8 cpu number : 0 cpu regs : 4 cpu MHz : 799.000 itc MHz : 797.989938 BogoMIPS : 3186.68 siblings : 4 physical id: 0 core id : 2 thread id : 1 processor : 2 vendor : GenuineIntel arch : IA-64 family : 32 model : 2 model name : Intel(R) Itanium(R) Processor 9310 revision : 4 archrev : 0 features : branchlong, 16-byte atomic ops, 0x8 cpu number : 0 cpu regs : 4 cpu MHz : 799.000 itc MHz : 797.989938 BogoMIPS : 3186.68 siblings : 4 physical id: 0 core id : 3 thread id : 0 processor : 3 vendor : GenuineIntel arch : IA-64 family : 32 model : 2 model name : Intel(R) Itanium(R) Processor 9310 revision : 4 archrev : 0 features : branchlong, 16-byte atomic ops, 0x8 cpu number : 0 cpu regs : 4 cpu MHz : 799.000 itc MHz : 797.989938 BogoMIPS : 3186.68 siblings : 4 physical id: 0 core id : 3 thread id : 1 processor : 4 vendor : GenuineIntel arch : IA-64 family : 32 model : 2 model name : Intel(R) Itanium(R) Processor 9310 revision : 4 archrev : 0 features : branchlong, 16-byte atomic ops, 0x8 cpu number : 0 cpu regs : 4 cpu MHz : 799.000 itc MHz : 797.989938 BogoMIPS : 3186.68 siblings : 4 physical id: 2 core id : 2 thread id : 0 processor : 5 vendor : GenuineIntel arch : IA-64 family : 32 model : 2 model name : Intel(R) Itanium(R) Processor 9310 revision : 4 archrev : 0 features : branchlong, 16-byte atomic ops, 0x8 cpu number : 0 cpu regs : 4 cpu MHz : 799.000 itc MHz : 797.989938 BogoMIPS : 3186.68 siblings : 4 physical id: 2 core id : 2 thread id : 1 processor : 6 vendor : GenuineIntel arch : IA-64 family : 32 model : 2 model name : Intel(R) Itanium(R) Processor 9310 revision : 4 archrev : 0 features : branchlong, 16-byte atomic ops, 0x8 cpu number : 0 cpu regs : 4 cpu MHz : 799.000 itc MHz : 797.989938 BogoMIPS : 3186.68 siblings : 4 physical id: 2 core id : 3 thread id : 0 processor : 7 vendor : GenuineIntel arch : IA-64 family : 32 model : 2 model name : Intel(R) Itanium(R) Processor 9310 revision : 4 archrev : 0 features : branchlong, 16-byte atomic ops, 0x8 cpu number : 0 cpu regs : 4 cpu MHz : 799.000 itc MHz : 797.989938 BogoMIPS : 3186.68 siblings : 4 physical id: 2 core id : 3 thread id : 1 Created attachment 26946 [details]
booting information
kernel booting information
Created attachment 26947 [details]
I enable "CONFIG_APCI_DEBUG" ,PRINT MORE MESSAGES.
more shutdown messages.
especially , I print some registers value .
for example :
PM1a_Control value.
===
hwregs-0481 [E000000182710000] [03] hw_register_read : ----Entry
hwregs-0785 [E000000182710000] [03] hw_low_level_read : Read: 00000001 width 16 from
0000000000000404 (SystemIO)
hwregs-0563 [E000000182710000] [03] hw_register_read : ----Exit- AE_OK
line 355: PM1Acontrol=0x1
hwsleep-0360 [E000000182710000] [02] enter_sleep_state : Entering sleep state [S5]
bobdebug: Entering sleep state S[5]
line 368: PM1Acontrol=0x1
acpi_gbl_sleep_type_a = 7 , acpi_gbl_sleep_type_b=7
line 381: PM1Acontrol=0x1c01
line 382: PM1Bcontrol=0x1c01
hwregs-0597 [E000000182710000] [03] hw_register_write : ----Entry
hwregs-0854 [E000000182710000] [03] hw_low_level_write : Wrote: 00001C01 width 16 to
0000000000000404 (SystemIO)
hwregs-0717 [E000000182710000] [03] hw_register_write : ----Exit- AE_OK
55555555555555555
hwregs-0597 [E000000182710000] [03] hw_register_write : ----Entry
hwregs-0717 [E000000182710000] [03] hw_register_write : ----Exit- AE_OK
666666666666666
after access_bit_mask
line 409: PM1Acontrol=0x3c01
line 410: PM1Bcontrol=0x3c01
77777777777777777
no defined CONFIG_XEN AND CONFIG_X86
acpi_gbl_sleep_type_a = 7 , acpi_gbl_sleep_type_b=7
will into acpi_hw_register_write()
hwregs-0597 [E000000182710000] [03] hw_register_write : ----Entry
*** Bug 16291 has been marked as a duplicate of this bug. *** please attach the acpidump output of this laptop (In reply to comment #5) > please attach the acpidump output of this laptop my machine is HP's Server rx2800-2 not laptop. Created attachment 26971 [details]
acpidump output
I finally found "S5" definition , details can got from my following reply.
Next step, I will send this information to firmware engineer to verify SSDT17.dsl is right for our sentosa. Because same values into registers every time, but got different hardware behaviors.
So we must doubt hardware and firmware design.
Now, from software point of view : acpi_enter_sleep_state() is the last function to run when shutdown machine , which write value into acpi registers to tell hardware to enter S5 (SLP_TYPx and SLP_EN) .Once written to these two registers, software task has been over. The left things are hardware is to work. So I think Linux kernel is good, this issue is from related with kernel,at acpi driver's logic is right. I have printed values which will be written to acpi registers , those values are the same every time, but hardware has different behaviors , so we need firmware engineer to help me check .
Maybe I need to ask firmware designer what is the meaning of this definition:
Where is {0x7,0x7} from ?? which datasheet ? which document ?
In "SSDT17.dsl" .
DefinitionBlock ("SSDT17.aml", "SSDT", 2, "HP ", "RX2800-2", 0x00000007)
{
Scope (\)
{
Name (\_S5, Package (0x03)
{
0x07,
0x07,
Zero
})
}
This is equal of that return from acpi_get_sleep_type_data(5,&type_a, &type_b)
Sometimes, sentosa can’t power off , about 2 times every 5 times, so very easily reproduced.
I also tried another sentosa machine : this issue is also reproduced easily ( tested 3 times, every time, can’t be power off when “shutdown –h 0”.
Through my debugging and tracing , Linux kernel’s code “acpi_enter_sleep_state() “ is the last function to run to control ACPI register named “PM1 controler”.
I know , from acpi spec4.0a , for entering S5 state, software only need to write values(state that will enter) into SLP_TYPx and SLP_EN(set 1) .
Now, every times, I write sames values into these registers , but sometimes power off failure, sometimes power off successed.
Same values into registers every time, but different hardware behavior occurred. I want to know the details after software writing registers. What will happen for hardware
and firmware ? especially , after SLP_EN bit has been set , what will firmware do next step ?
From SPEC, I know , the values written to SLP_TYPx is from \_S5 object . this value will be done some mixed, and then written into register.
I used acpidump to dump our sentosa ‘s acpi tables ,I got \_S5 object information:
DefinitionBlock ("SSDT17.aml", "SSDT", 2, "HP ", "RX2800-2", 0x00000007)
{
Scope (\)
{
Name (\_S5, Package (0x03)
{
0x07,
0x07,
Zero
})
}
}
1, Could you help me check “{0x7,0x7}” is right for sentosa ? I think maybe it should be {0x5,0x5}
2, Could you explain where is “{0x7,0x7} defined , which documents will specify them ?
3, Same values into registers every time, but different hardware behavior occurred. I want to know the details after software writing registers. What will happen for hardware
and firmware ? especially , after SLP_EN bit has been set , what will firmware do next step ?
, Good , I have tested your commands from EFI 7 times. I always successed.
This is my steps:
Shell>
Shell>
Shell> mm 400 -w 2 -io -n
IO 0x0000000000000400 : 0x0011
Shell> mm 404 1c01 -w 2 -io -n
Shell> mm 404 3c01 -w 2 -io -n
[ilo00237d445efc]</> hpiLO-> cm ###switch cm mode :
[ilo00237d445efc] CM:hpiLO-> ps
PS
For System Processor Status see the SS command.
System Power state : Off #this will indicate that power has been off.
System Power usage : 22 Watts used in Auxiliary Mode
Ambient temperature : 25 C
Temperature status : Normal
Power supplies State
--------------------------------------------------------------
Power Supply 1 Normal
Power Supply 2 Not Installed
Fans State
--------------------------------------------------------------
Fan Unit 1 Normal
Fan Unit 2 Normal
Fan Unit 3 Normal
Fan Unit 4 Normal
Fan Unit 5 Normal
Fan Unit 6 Normal
But I can’t use debug menu MFW to check bit 0 of the FPGA register . I am not familiar with hardware testing and debugging, could you give me some more details information ?thanks very much!
2, I also checked my driver (located in Linux kernel from Linux acpi group).
why your actions can result in power off, but for my code , sometimes successed, and sometimes failure ?
As you said , in this time, I must read bit 0 of FPGA to verify if FPGA worked well .
Attachment is kernel’s acpi code related shutdown named “acpi_enter_sleep_state() which control SLP_TYPx and SLP_EN” , if you are interested in it ,we can compare the actions my driver did with your actions from EFI command.
I think our core actions are basic same,
As ACPI spec, core actions should be :
- Write sleep type into SLP_TYPx bit of PM1Acontrol register and PM1Bcontrol register
- Write 1 to SLP_EN bit of PM1Acontrol register and PM1Bcontrol register
From your EFI command, it seems that, you didn’t differ PM1Acontrol and PM1Bcontrol , you only write a register address 0x400(it should be PM1Acontrol register).
Following is my writing register information:
all flow is :
1, disable Clear wake status
2, Clear all fixed and general purpose status bits #same with yours . after clear,then I read it again , 0x0000
3, will Disable/clear all GPES
4, will Enable all wakeup GPES -
5, assert SLP_TYPx and write into PM1A_CNT and PM1B_CNT #same with yours ,also 0x1c01
5, assert SLP_EN bit, and write into PM1A_CNT and PM1B_CNT #same with yours,also 0x3c01
6, After that, delay 10s to write 1 to PM1_CNT register ‘s SLP_EN bit (equal of step 5. Once again)
Welcome your comments for this comments from open source, for sentosa , do we need it ?? I don’t think ,we need it.
if (sleep_state > ACPI_STATE_S3) { //this code is not written by me , but from Linux-acpi open source group.
/*
* We wanted to sleep > S3, but it didn't happen (by virtue of the
* fact that we are still executing!)
*
* Wait ten seconds, then try again. This is to get S4/S5 to work on
* all machines.
*
* We wait so long to allow chipsets that poll this reg very slowly to
* still read the right value. Ideally, this block would go
* away entirely.
*/
acpi_os_stall(10000000); //delay 10 seconds.
// only set SLP_EN of PM1Control register.
status = acpi_hw_register_write(ACPI_REGISTER_PM1_CONTROL,
sleep_enable_reg_info->
access_bit_mask);
7, After that ,will be in a dead loop to check if ACPI_BITREG_WAKE_STATUS has been changed 1 by hardware. If set ok, break from the loop.
My question is that ：
4.7.3.2.1 PM1 Control Registers
Register Location: <PM1a_CNT_BLK / PM1b_CNT_BLK> System I/O or Memory Space
Default Value: 00h
Attribute: Read/Write
Size: PM1_CNT_LEN
The PM1 control registers contain the fixed hardware feature control bits. These bits can be split between
two registers: PM1a_CNT or PM1b_CNT. Each register grouping can be at a different 32-bit aligned
address and is pointed to by the PM1a_CNT_BLK or PM1b_CNT_BLK. The values for these pointers to
the register space are found in the FADT. Accesses to PM1 control registers are accessed through byte and
word accesses
For acpi , why differ PM1Acontrol and PM1B control ?
PM1AControl is enough ? I need to wirte the same value into PM1Bcontrol ?
Following is my registers controlling follow. Could you give me some comments ? thanks very much!
I explain the output format ,just like :
hwregs-0785 [E000000183320000] [05] hw_low_level_read : Read: 00000011 width 16 from 0000000000000400 (SystemIO)
it represents that ,from 0x400 address (system IO) ,read a value 0x11 , width 16,
just like your “mm 400 -w 2 -io -n”
Power down.
acpi_power_off called
hwsleep-0279 [E000000183320000] [02] enter_sleep_state : ----Entry
bobdebug: into function(acpi_enter_sleep_state) , in file (drivers/acpi/hardware/hwsleep.c) , line (281)
sleep_state=5
// -------------------------- disable Clear wake status -----------------------------------
hwregs-0331 [E000000183320000] [03] set_register : ----Entry 00000006
hwregs-0597 [E000000183320000] [04] hw_register_write : ----Entry
hwregs-0481 [E000000183320000] [05] hw_register_read : ----Entry
hwregs-0785 [E000000183320000] [05] hw_low_level_read : Read: 00000011 width 16 from 0000000000000400 (SystemIO)
hwregs-0563 [E000000183320000] [05] hw_register_read : ----Exit- AE_OK
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 00008000 width 16 to 0000000000000400 (SystemIO)
hwregs-0717 [E000000183320000] [04] hw_register_write : ----Exit- AE_OK
hwregs-0456 [E000000183320000] [03] set_register : Set bits: 00008000 actual 00000000 register 1
hwregs-0457 [E000000183320000] [03] set_register : ----Exit- AE_OK
// -------------------------Clear all fixed and general purpose status bits ------------------
hwregs-0070 [E000000183320000] [03] hw_clear_acpi_status : ----Entry
hwregs-0074 [E000000183320000] [03] hw_clear_acpi_status : About to write 8731 to 0400
hwregs-0597 [E000000183320000] [04] hw_register_write : ----Entry
hwregs-0481 [E000000183320000] [05] hw_register_read : ----Entry
hwregs-0785 [E000000183320000] [05] hw_low_level_read : Read: 00000011 width 16 from 0000000000000400 (SystemIO)
hwregs-0563 [E000000183320000] [05] hw_register_read : ----Exit- AE_OK
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 00008731 width 16 to 0000000000000400 (SystemIO)
//0x8731 (1000 0111 0011 0001) : bit[15]:1 , bit[8,9,10]:1 ,bit[4-5]:1 bit[0]:1
hwregs-0717 [E000000183320000] [04] hw_register_write : ----Exit- AE_OK
// Clear the GPE Bits in all GPE registers in all GPE blocks
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000420 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000421 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000422 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000423 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000424 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000425 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000426 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000427 (SystemIO)
hwregs-0101 [E000000183320000] [03] hw_clear_acpi_status : ----Exit- AE_OK
//after acpi_hw_clear_acpi_status()
hwregs-0481 [E000000183320000] [03] hw_register_read : ----Entry
hwregs-0785 [E000000183320000] [03] hw_low_level_read : Read: 00000000 width 16 from 0000000000000400 (SystemIO)
hwregs-0563 [E000000183320000] [03] hw_register_read : ----Exit- AE_OK
// ---------------------- will Disable/clear all GPES ---------------------------------
hwgpe-0428 [E000000183320000] [03] hw_disable_all_gpes : ----Entry
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 00000000 width 8 to 0000000000000428 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 00000000 width 8 to 0000000000000429 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 00000000 width 8 to 000000000000042A (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 00000000 width 8 to 000000000000042B (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 00000000 width 8 to 000000000000042C (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 00000000 width 8 to 000000000000042D (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 00000000 width 8 to 000000000000042E (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 00000000 width 8 to 000000000000042F (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000420 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000421 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000422 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000423 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000424 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000425 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000426 (SystemIO)
hwregs-0854 [E000000183320000] [04] hw_low_level_write : Wrote: 000000FF width 8 to 0000000000000427 (SystemIO)
hwgpe-0432 [E000000183320000] [03] hw_disable_all_gpes : ----Exit- AE_OK
/// -------------------------------------- will Enable all wakeup GPES ------------------------------
hwgpe-0473 [E000000183320000] [03] hw_enable_all_wakeup_g: ----Entry
hwgpe-0476 [E000000183320000] [03] hw_enable_all_wakeup_g: ----Exit- AE_OK
//------------------------------ Read old PM1AControl ------------
hwregs-0481 [E000000183320000] [03] hw_register_read : ----Entry
hwregs-0785 [E000000183320000] [03] hw_low_level_read : Read: 00000001 width 16 from 0000000000000404 (SystemIO)
hwregs-0563 [E000000183320000] [03] hw_register_read : ----Exit- AE_OK
line 371: PM1Acontrol=0x1
// ----------------- ---------------assert SLP_TYPx -----------------------
line 397: PM1Acontrol=0x1c01
line 398: PM1Bcontrol=0x1c01
hwregs-0597 [E000000183320000] [03] hw_register_write : ----Entry
hwregs-0854 [E000000183320000] [03] hw_low_level_write : Wrote: 00001C01 width 16 to 0000000000000404 (SystemIO)
hwregs-0717 [E000000183320000] [03] hw_register_write : ----Exit- AE_OK
hwregs-0597 [E000000183320000] [03] hw_register_write : ----Entry
hwregs-0717 [E000000183320000] [03] hw_register_write : ----Exit- AE_OK
// --------------- assert SLP_EN bit .
line 425: PM1Acontrol=0x3c01
line 426: PM1Bcontrol=0x3c01
// write 0x3c01 into PM1Acontrol and PM1Bcontrol
till now , printk can't work any longer.
yakui, will you please look at this poweroff issue please? Hi, Bob
Thanks for your detailed debug. The last step in course of poweroff is to write SLP_TYPE/SLP_EN into the PM1A control register. But from your test it seems that the system can't be powered off even after the SLP_TYPE/SLP_EN(0x3C01) is written into the PM1A control register(0x404).
Can the system be powered off by writing the 0x3C01 into 0x404 I/O port under EFI?
Will you please read the output of 0x430 I/O port?
Thanks
Yakui
bug closed as there is no response from the bug reporter for more than a month. please feel free to re-open it if the problem still exists in the latest upstream kernel. I am sorry , I have no response for this for long time . the final result is that this issue is not caused by kernel ,it is FW bug. what kernel needs to do is to control ACPI register to tell FW/HW to power off machine . but due to MFW design bug , the flow will be stuck. now the issue has been fixed by FW team. thanks for your attention. -Bob |
Created attachment 26945 [details] shutdown info Hi all, I found a amazing problem when debugging this issue. As ACPI spec4.0a , if we want to make the system into S5 (soft-off ) status, what we should do is like this: P85: The logic is controlled via two bit fields: Sleep Enable (SLP_EN) and Sleep Type (SLP_TYPx). The type of sleep state desired is programmed into the SLP_TYPx field and upon assertion of the SLP_EN the hardware will sequence the system into the defined sleeping state. OSPM gets values for the SLP_TYPx field from the \_Sx objects defined in the static definition block. If the object is missing OSPM assumes the hardware does not support that sleeping state. Prior to entering the desired sleeping state, OSPM will read the designated \_Sx object and place this value in the SLP_TYP field. One word , we should write a value to register SLP_TYP, afterwards , set SLP_EN bit, hardware will sequence the system into the defined sleeping state (for example S5). From this sentence " Each sleeping object contains two constant 3-bit values that OSPM will program into the SLP_TYPa and SLP_TYPb fields (in fixed register space)." We can simply get a conclusion : The value written to SLP_TYP should be different between S0~S5 ,moreover , this value is gotten from firmware , not controlled by us. But in debugging information, I can see that for S0~S5 , they have the same value by converting ,and then written to SLP_TYP. (see "acpi_enter_sleep_state() "). My debugging code: acpi_status acpi_enter_sleep_state_prep(u8 sleep_state) { acpi_status status; struct acpi_object_list arg_list; union acpi_object arg; ACPI_FUNCTION_TRACE(acpi_enter_sleep_state_prep); //added by Bob for checking all type_a and type_b values for different State(S0~S5), should be different. { int i=0; u8 bobtype_a; u8 bobtype_b; for(i=0;i<6;i++) { acpi_get_sleep_type_data(sleep_state, &bobtype_a, &bobtype_b); printk("for S[%d] status , type_a=%d, type_b=%d\n",sleep_state,bobtype_a,bobtype_b); } } //over. //this code is from kernel. Kernel (OSPM) will get this value from firmware ,and by somewhat converting, and then write it into SLP_TYP . /* * _PSW methods could be run here to enable wake-on keyboard, LAN, etc. */ status = acpi_get_sleep_type_data(sleep_state, &acpi_gbl_sleep_type_a, &acpi_gbl_sleep_type_b); if (ACPI_FAILURE(status)) { return_ACPI_STATUS(status); } Following is partial output information: We can see that, for S0~S4 ,they all have {128,7) , it apparently is wrong as ACPI 4.0a SPEC. For S5 , it is {7,7}. only test type value hwregs-0125 [E000000185900000] [02] get_sleep_type_data : ----Entry hwregs-0150 [E000000185900000] [02] get_sleep_type_data : AE_NOT_FOUND while evaluating SleepState [\_S0_] hwregs-0218 [E000000185900000] [02] get_sleep_type_data : ----Exit- ****Exception****: AE_NOT_FOUND for state S[0] , typea=128 , typeb=7 hwregs-0125 [E000000185900000] [02] get_sleep_type_data : ----Entry hwregs-0150 [E000000185900000] [02] get_sleep_type_data : AE_NOT_FOUND while evaluating SleepState [\_S1_] hwregs-0218 [E000000185900000] [02] get_sleep_type_data : ----Exit- ****Exception****: AE_NOT_FOUND for state S[1] , typea=128 , typeb=7 hwregs-0125 [E000000185900000] [02] get_sleep_type_data : ----Entry hwregs-0150 [E000000185900000] [02] get_sleep_type_data : AE_NOT_FOUND while evaluating SleepState [\_S2_] hwregs-0218 [E000000185900000] [02] get_sleep_type_data : ----Exit- ****Exception****: AE_NOT_FOUND for state S[2] , typea=128 , typeb=7 hwregs-0125 [E000000185900000] [02] get_sleep_type_data : ----Entry hwregs-0150 [E000000185900000] [02] get_sleep_type_data : AE_NOT_FOUND while evaluating SleepState [\_S3_] hwregs-0218 [E000000185900000] [02] get_sleep_type_data : ----Exit- ****Exception****: AE_NOT_FOUND for state S[3] , typea=128 , typeb=7 hwregs-0125 [E000000185900000] [02] get_sleep_type_data : ----Entry hwregs-0150 [E000000185900000] [02] get_sleep_type_data : AE_NOT_FOUND while evaluating SleepState [\_S4_] hwregs-0218 [E000000185900000] [02] get_sleep_type_data : ----Exit- ****Exception****: AE_NOT_FOUND for state S[4] , typea=128 , typeb=7 hwregs-0125 [E000000185900000] [02] get_sleep_type_data : ----Entry hwregs-0218 [E000000185900000] [02] get_sleep_type_data : ----Exit- AE_OK for state S[5] , typea=7 , typeb=7 hwsleep-0244 [E000000185900000] [01] enter_sleep_state_prep: ----Exit- AE_OK ====================== My machine 's information is like this: