PM Event and Control registers and other ACPI fixed hardware features were not supported on ARM64 yet, so we need enable reduced hardware as described in ACPI 5.0.
I met a boot panic failure on the ARMv8 model,
[ 9.024370] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.024423] pgd = ffffffc00007d000 [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.024538] Internal error: Oops: 96000006 [#1] SMP [ 9.024577] Modules linked in: [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] pstate: 600003c5 .... [ 9.031956] Call trace: [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 [ 9.032472] [<ffffffc0002bffb4>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.032550] [<ffffffc000565220>] acpi_processor_power_init+0xac/0x138 [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- [ 9.033995] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Since PM control register is not exist on ARM64, It will cause such failure.
ACPICA provided a macro to enable reduced hardware feature, and functions deal with ACPI hardware will defined as empty when ACPI_REDUCED_HARDWARE is TRUE, so we can avoid panic when excute the ACPI driver code.
Signed-off-by: Hanjun Guo hanjun.guo@linaro.org --- include/acpi/acconfig.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 arch/arm64/boot/install.sh
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh old mode 100644 new mode 100755 diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index 14ceff7..cb80ea9 100644 --- a/include/acpi/acconfig.h +++ b/include/acpi/acconfig.h @@ -100,7 +100,7 @@ * ACPI PM timer * FACS table (Waking vectors and Global Lock) */ -#define ACPI_REDUCED_HARDWARE FALSE +#define ACPI_REDUCED_HARDWARE TRUE
/****************************************************************************** *
Hi Hanjun,
Excellent on tracking this down, but we need to set it conditionally as our build must not break current x86 machines.
Thanks
Graeme
On Fri, Jun 14, 2013 at 05:53:56PM +0800, Hanjun Guo wrote:
PM Event and Control registers and other ACPI fixed hardware features were not supported on ARM64 yet, so we need enable reduced hardware as described in ACPI 5.0.
I met a boot panic failure on the ARMv8 model,
[ 9.024370] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.024423] pgd = ffffffc00007d000 [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.024538] Internal error: Oops: 96000006 [#1] SMP [ 9.024577] Modules linked in: [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] pstate: 600003c5 .... [ 9.031956] Call trace: [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 [ 9.032472] [<ffffffc0002bffb4>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.032550] [<ffffffc000565220>] acpi_processor_power_init+0xac/0x138 [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- [ 9.033995] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Since PM control register is not exist on ARM64, It will cause such failure.
ACPICA provided a macro to enable reduced hardware feature, and functions deal with ACPI hardware will defined as empty when ACPI_REDUCED_HARDWARE is TRUE, so we can avoid panic when excute the ACPI driver code.
Signed-off-by: Hanjun Guo hanjun.guo@linaro.org
include/acpi/acconfig.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 arch/arm64/boot/install.sh
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh old mode 100644 new mode 100755 diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index 14ceff7..cb80ea9 100644 --- a/include/acpi/acconfig.h +++ b/include/acpi/acconfig.h @@ -100,7 +100,7 @@
ACPI PM timerFACS table (Waking vectors and Global Lock)*/ -#define ACPI_REDUCED_HARDWARE FALSE +#define ACPI_REDUCED_HARDWARE TRUE /******************************************************************************
-- 1.7.9.5
Linaro-acpi mailing list Linaro-acpi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-acpi
On 2013-6-14 18:03, Graeme Gregory wrote:
Hi Hanjun,
Excellent on tracking this down, but we need to set it conditionally as our build must not break current x86 machines.
That would be a hard choice for us. If we don't set ACPI_REDUCED_HARDWARE as TRUE on our ARM64 platform, we will meet panic issues, but will break current x86 machines if set TRUE.
ACPICA is a dependent code both for linux and windows, so I think ACPICA will not accept config option for reduced hardware.
I think we should introduce a config option in acpi driver, how about this solution?
Thanks Hanjun
Thanks
Graeme
On Fri, Jun 14, 2013 at 05:53:56PM +0800, Hanjun Guo wrote:
PM Event and Control registers and other ACPI fixed hardware features were not supported on ARM64 yet, so we need enable reduced hardware as described in ACPI 5.0.
I met a boot panic failure on the ARMv8 model,
[ 9.024370] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.024423] pgd = ffffffc00007d000 [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.024538] Internal error: Oops: 96000006 [#1] SMP [ 9.024577] Modules linked in: [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] pstate: 600003c5 .... [ 9.031956] Call trace: [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 [ 9.032472] [<ffffffc0002bffb4>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.032550] [<ffffffc000565220>] acpi_processor_power_init+0xac/0x138 [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- [ 9.033995] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Since PM control register is not exist on ARM64, It will cause such failure.
ACPICA provided a macro to enable reduced hardware feature, and functions deal with ACPI hardware will defined as empty when ACPI_REDUCED_HARDWARE is TRUE, so we can avoid panic when excute the ACPI driver code.
Signed-off-by: Hanjun Guo hanjun.guo@linaro.org
include/acpi/acconfig.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 arch/arm64/boot/install.sh
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh old mode 100644 new mode 100755 diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index 14ceff7..cb80ea9 100644 --- a/include/acpi/acconfig.h +++ b/include/acpi/acconfig.h @@ -100,7 +100,7 @@
ACPI PM timerFACS table (Waking vectors and Global Lock)*/ -#define ACPI_REDUCED_HARDWARE FALSE +#define ACPI_REDUCED_HARDWARE TRUE /******************************************************************************
-- 1.7.9.5
Linaro-acpi mailing list Linaro-acpi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-acpi
On Fri, Jun 14, 2013 at 08:42:47PM +0800, Hanjun Guo wrote:
On 2013-6-14 18:03, Graeme Gregory wrote:
Hi Hanjun,
Excellent on tracking this down, but we need to set it conditionally as our build must not break current x86 machines.
That would be a hard choice for us. If we don't set ACPI_REDUCED_HARDWARE as TRUE on our ARM64 platform, we will meet panic issues, but will break current x86 machines if set TRUE.
ACPICA is a dependent code both for linux and windows, so I think ACPICA will not accept config option for reduced hardware.
I think we should introduce a config option in acpi driver, how about this solution?
Is this acconfig.h actually part of the ACPICA release? If so we are going to have difficulty. If it is just a config file fed to ACPICA code then I think we are free to overide it per platform.
I do not know which files are fixed and which ones we are allowed to play with.
Al, Tomasz do you know the answer to this?
Graeme
On 06/14/2013 08:15 AM, Graeme Gregory wrote:
On Fri, Jun 14, 2013 at 08:42:47PM +0800, Hanjun Guo wrote:
On 2013-6-14 18:03, Graeme Gregory wrote:
Hi Hanjun,
Excellent on tracking this down, but we need to set it conditionally as our build must not break current x86 machines.
That would be a hard choice for us. If we don't set ACPI_REDUCED_HARDWARE as TRUE on our ARM64 platform, we will meet panic issues, but will break current x86 machines if set TRUE.
ACPICA is a dependent code both for linux and windows, so I think ACPICA will not accept config option for reduced hardware.
I think we should introduce a config option in acpi driver, how about this solution?
Is this acconfig.h actually part of the ACPICA release? If so we are going to have difficulty. If it is just a config file fed to ACPICA code then I think we are free to overide it per platform.
I do not know which files are fixed and which ones we are allowed to play with.
Al, Tomasz do you know the answer to this?
The rule of thumb is that if it is in drivers/acpi/acpica or in drivers/acpi/apei, don't touch it. Those are the ACPICA upstream files. Otherwise, feel free.
Do we have to set this in the source? IIRC, it's one of the options in one of the tables (FADT, maybe?) and I think we should be setting things up based on the flag in the table.
W dniu 14.06.2013 16:49, Al Stone pisze:
On 06/14/2013 08:15 AM, Graeme Gregory wrote:
On Fri, Jun 14, 2013 at 08:42:47PM +0800, Hanjun Guo wrote:
On 2013-6-14 18:03, Graeme Gregory wrote:
Hi Hanjun,
Excellent on tracking this down, but we need to set it conditionally as our build must not break current x86 machines.
That would be a hard choice for us. If we don't set ACPI_REDUCED_HARDWARE as TRUE on our ARM64 platform, we will meet panic issues, but will break current x86 machines if set TRUE.
ACPICA is a dependent code both for linux and windows, so I think ACPICA will not accept config option for reduced hardware.
I think we should introduce a config option in acpi driver, how about this solution?
Is this acconfig.h actually part of the ACPICA release? If so we are going to have difficulty. If it is just a config file fed to ACPICA code then I think we are free to overide it per platform.
I do not know which files are fixed and which ones we are allowed to play with.
Al, Tomasz do you know the answer to this?
The rule of thumb is that if it is in drivers/acpi/acpica or in drivers/acpi/apei, don't touch it. Those are the ACPICA upstream files. Otherwise, feel free.
Do we have to set this in the source? IIRC, it's one of the options in one of the tables (FADT, maybe?) and I think we should be setting things up based on the flag in the table.
Correct, whether we're using reduced mode or not should be decided based on HW_REDUCED_ACPI flag in FADT table. Right now it is turn on.
Tomasz
On Fri, Jun 14, 2013 at 04:57:50PM +0200, Tomasz Nowicki wrote:
W dniu 14.06.2013 16:49, Al Stone pisze:
On 06/14/2013 08:15 AM, Graeme Gregory wrote:
On Fri, Jun 14, 2013 at 08:42:47PM +0800, Hanjun Guo wrote:
On 2013-6-14 18:03, Graeme Gregory wrote:
Hi Hanjun,
Excellent on tracking this down, but we need to set it conditionally as our build must not break current x86 machines.
That would be a hard choice for us. If we don't set ACPI_REDUCED_HARDWARE as TRUE on our ARM64 platform, we will meet panic issues, but will break current x86 machines if set TRUE.
ACPICA is a dependent code both for linux and windows, so I think ACPICA will not accept config option for reduced hardware.
I think we should introduce a config option in acpi driver, how about this solution?
Is this acconfig.h actually part of the ACPICA release? If so we are going to have difficulty. If it is just a config file fed to ACPICA code then I think we are free to overide it per platform.
I do not know which files are fixed and which ones we are allowed to play with.
Al, Tomasz do you know the answer to this?
The rule of thumb is that if it is in drivers/acpi/acpica or in drivers/acpi/apei, don't touch it. Those are the ACPICA upstream files. Otherwise, feel free.
Do we have to set this in the source? IIRC, it's one of the options in one of the tables (FADT, maybe?) and I think we should be setting things up based on the flag in the table.
Correct, whether we're using reduced mode or not should be decided based on HW_REDUCED_ACPI flag in FADT table. Right now it is turn on.
Well I have stuck some debugging in fbfadt.c
acpi_gbl_reduced_hardware = FALSE; if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) { pr_err("ACPI: REDUCED HARDWARE MODE\n"); acpi_gbl_reduced_hardware = TRUE; }
And my dmesg contains.
[ 0.000000] ACPI: REDUCED HARDWARE MODE
So it looks like drivers/acpi doe not support HW_REDUCED_MODE properly yet. I guess thats another card to add.
Thanks
Graeme
Well spotted!
It is part of the early investigation done by Al last December/January when he mentioned there would be more work to add the right reduced hw support to Linux ACPI.
Let's add this card then and as many blueprints / subtasks as needed fixes.
On 2013-6-15 0:49, Graeme Gregory wrote:
On Fri, Jun 14, 2013 at 04:57:50PM +0200, Tomasz Nowicki wrote:
W dniu 14.06.2013 16:49, Al Stone pisze:
On 06/14/2013 08:15 AM, Graeme Gregory wrote:
On Fri, Jun 14, 2013 at 08:42:47PM +0800, Hanjun Guo wrote:
On 2013-6-14 18:03, Graeme Gregory wrote:
Hi Hanjun,
Excellent on tracking this down, but we need to set it conditionally as our build must not break current x86 machines.
That would be a hard choice for us. If we don't set ACPI_REDUCED_HARDWARE as TRUE on our ARM64 platform, we will meet panic issues, but will break current x86 machines if set TRUE.
ACPICA is a dependent code both for linux and windows, so I think ACPICA will not accept config option for reduced hardware.
I think we should introduce a config option in acpi driver, how about this solution?
Is this acconfig.h actually part of the ACPICA release? If so we are going to have difficulty. If it is just a config file fed to ACPICA code then I think we are free to overide it per platform.
I do not know which files are fixed and which ones we are allowed to play with.
Al, Tomasz do you know the answer to this?
The rule of thumb is that if it is in drivers/acpi/acpica or in drivers/acpi/apei, don't touch it. Those are the ACPICA upstream files. Otherwise, feel free.
Do we have to set this in the source? IIRC, it's one of the options in one of the tables (FADT, maybe?) and I think we should be setting things up based on the flag in the table.
Correct, whether we're using reduced mode or not should be decided based on HW_REDUCED_ACPI flag in FADT table. Right now it is turn on.
Yes, you guys are right! Thanks for pointing this out.
Well I have stuck some debugging in fbfadt.c
acpi_gbl_reduced_hardware = FALSE; if (acpi_gbl_FADT.flags & ACPI_FADT_HW_REDUCED) { pr_err("ACPI: REDUCED HARDWARE MODE\n"); acpi_gbl_reduced_hardware = TRUE; }
And my dmesg contains.
[ 0.000000] ACPI: REDUCED HARDWARE MODE
So it looks like drivers/acpi doe not support HW_REDUCED_MODE properly yet. I guess thats another card to add.
Agreed. use HW_REDUCED_ACPI flag will be a good solution and will be easily accepted by upstream.
Thanks
Graeme
Linaro-acpi mailing list Linaro-acpi@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-acpi .
W dniu 14.06.2013 11:53, Hanjun Guo pisze:
PM Event and Control registers and other ACPI fixed hardware features were not supported on ARM64 yet, so we need enable reduced hardware as described in ACPI 5.0.
I met a boot panic failure on the ARMv8 model,
[ 9.024370] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.024423] pgd = ffffffc00007d000 [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.024538] Internal error: Oops: 96000006 [#1] SMP [ 9.024577] Modules linked in: [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] pstate: 600003c5 .... [ 9.031956] Call trace: [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 [ 9.032472] [<ffffffc0002bffb4>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.032550] [<ffffffc000565220>] acpi_processor_power_init+0xac/0x138 [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- [ 9.033995] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Since PM control register is not exist on ARM64, It will cause such failure.
Does PM control register exist on ARM?
ACPICA provided a macro to enable reduced hardware feature, and functions deal with ACPI hardware will defined as empty when ACPI_REDUCED_HARDWARE is TRUE, so we can avoid panic when excute the ACPI driver code.
Signed-off-by: Hanjun Guo hanjun.guo@linaro.org
include/acpi/acconfig.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 arch/arm64/boot/install.sh
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh old mode 100644 new mode 100755 diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index 14ceff7..cb80ea9 100644 --- a/include/acpi/acconfig.h +++ b/include/acpi/acconfig.h @@ -100,7 +100,7 @@
ACPI PM timerFACS table (Waking vectors and Global Lock)*/ -#define ACPI_REDUCED_HARDWARE FALSE +#define ACPI_REDUCED_HARDWARE TRUE
/******************************************************************************
On 2013-6-14 20:23, Tomasz Nowicki wrote:
W dniu 14.06.2013 11:53, Hanjun Guo pisze:
PM Event and Control registers and other ACPI fixed hardware features were not supported on ARM64 yet, so we need enable reduced hardware as described in ACPI 5.0.
I met a boot panic failure on the ARMv8 model,
[ 9.024370] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.024423] pgd = ffffffc00007d000 [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.024538] Internal error: Oops: 96000006 [#1] SMP [ 9.024577] Modules linked in: [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] pstate: 600003c5 .... [ 9.031956] Call trace: [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 [ 9.032472] [<ffffffc0002bffb4>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.032550] [<ffffffc000565220>] acpi_processor_power_init+0xac/0x138 [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- [ 9.033995] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Since PM control register is not exist on ARM64, It will cause such failure.
Does PM control register exist on ARM?
PM control registers here are ACPI PM control registers, which described in ACPI5.0 section 4.8, so I think they are not exist on ARM at present.
Thanks Hanjun
ACPICA provided a macro to enable reduced hardware feature, and functions deal with ACPI hardware will defined as empty when ACPI_REDUCED_HARDWARE is TRUE, so we can avoid panic when excute the ACPI driver code.
Signed-off-by: Hanjun Guo hanjun.guo@linaro.org
include/acpi/acconfig.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 arch/arm64/boot/install.sh
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh old mode 100644 new mode 100755 diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index 14ceff7..cb80ea9 100644 --- a/include/acpi/acconfig.h +++ b/include/acpi/acconfig.h @@ -100,7 +100,7 @@
ACPI PM timerFACS table (Waking vectors and Global Lock)*/ -#define ACPI_REDUCED_HARDWARE FALSE +#define ACPI_REDUCED_HARDWARE TRUE
/******************************************************************************
W dniu 14.06.2013 15:08, Hanjun Guo pisze:
On 2013-6-14 20:23, Tomasz Nowicki wrote:
W dniu 14.06.2013 11:53, Hanjun Guo pisze:
PM Event and Control registers and other ACPI fixed hardware features were not supported on ARM64 yet, so we need enable reduced hardware as described in ACPI 5.0.
I met a boot panic failure on the ARMv8 model,
[ 9.024370] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.024423] pgd = ffffffc00007d000 [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.024538] Internal error: Oops: 96000006 [#1] SMP [ 9.024577] Modules linked in: [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] pstate: 600003c5 .... [ 9.031956] Call trace: [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 [ 9.032472] [<ffffffc0002bffb4>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.032550] [<ffffffc000565220>] acpi_processor_power_init+0xac/0x138 [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- [ 9.033995] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Since PM control register is not exist on ARM64, It will cause such failure.
Does PM control register exist on ARM?
PM control registers here are ACPI PM control registers, which described in ACPI5.0 section 4.8, so I think they are not exist on ARM at present.
How it is possible it didn't crash on Arndale? I suppose we have the same functionality for Arndale as for Foundation model.
Thanks Hanjun
ACPICA provided a macro to enable reduced hardware feature, and functions deal with ACPI hardware will defined as empty when ACPI_REDUCED_HARDWARE is TRUE, so we can avoid panic when excute the ACPI driver code.
Signed-off-by: Hanjun Guo hanjun.guo@linaro.org
include/acpi/acconfig.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 arch/arm64/boot/install.sh
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh old mode 100644 new mode 100755 diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index 14ceff7..cb80ea9 100644 --- a/include/acpi/acconfig.h +++ b/include/acpi/acconfig.h @@ -100,7 +100,7 @@ * ACPI PM timer * FACS table (Waking vectors and Global Lock) */ -#define ACPI_REDUCED_HARDWARE FALSE +#define ACPI_REDUCED_HARDWARE TRUE
/****************************************************************************** *
On 2013-6-14 21:17, Tomasz Nowicki wrote:
W dniu 14.06.2013 15:08, Hanjun Guo pisze:
On 2013-6-14 20:23, Tomasz Nowicki wrote:
W dniu 14.06.2013 11:53, Hanjun Guo pisze:
PM Event and Control registers and other ACPI fixed hardware features were not supported on ARM64 yet, so we need enable reduced hardware as described in ACPI 5.0.
I met a boot panic failure on the ARMv8 model,
[ 9.024370] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.024423] pgd = ffffffc00007d000 [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.024538] Internal error: Oops: 96000006 [#1] SMP [ 9.024577] Modules linked in: [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] pstate: 600003c5 .... [ 9.031956] Call trace: [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 [ 9.032472] [<ffffffc0002bffb4>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.032550] [<ffffffc000565220>] acpi_processor_power_init+0xac/0x138 [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- [ 9.033995] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Since PM control register is not exist on ARM64, It will cause such failure.
Does PM control register exist on ARM?
PM control registers here are ACPI PM control registers, which described in ACPI5.0 section 4.8, so I think they are not exist on ARM at present.
How it is possible it didn't crash on Arndale? I suppose we have the same functionality for Arndale as for Foundation model.
Good question. To tell the truth, I not sure why it is not happened on Arndale, and even on Graeme's ARMv8 foundation model, we have the same version of foundation model, the same kernel code and the config file, but it not happened on Graeme's model. (odd, right? )
I guess on my armv8 model, we lucky hit the bug that it access the virtual address which not exist, but on Graeme's model, the virtual address is available.
I'm not sure of this, I will ask some guy who is a expert on memory management next Monday.
Thanks Hanjun
Thanks Hanjun
ACPICA provided a macro to enable reduced hardware feature, and functions deal with ACPI hardware will defined as empty when ACPI_REDUCED_HARDWARE is TRUE, so we can avoid panic when excute the ACPI driver code.
Signed-off-by: Hanjun Guo hanjun.guo@linaro.org
include/acpi/acconfig.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 arch/arm64/boot/install.sh
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh old mode 100644 new mode 100755 diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index 14ceff7..cb80ea9 100644 --- a/include/acpi/acconfig.h +++ b/include/acpi/acconfig.h @@ -100,7 +100,7 @@ * ACPI PM timer * FACS table (Waking vectors and Global Lock) */ -#define ACPI_REDUCED_HARDWARE FALSE +#define ACPI_REDUCED_HARDWARE TRUE
/******************************************************************************
*
On 2013-6-15 15:55, Hanjun Guo wrote:
On 2013-6-14 21:17, Tomasz Nowicki wrote:
W dniu 14.06.2013 15:08, Hanjun Guo pisze:
On 2013-6-14 20:23, Tomasz Nowicki wrote:
W dniu 14.06.2013 11:53, Hanjun Guo pisze:
PM Event and Control registers and other ACPI fixed hardware features were not supported on ARM64 yet, so we need enable reduced hardware as described in ACPI 5.0.
I met a boot panic failure on the ARMv8 model,
[ 9.024370] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.024423] pgd = ffffffc00007d000 [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.024538] Internal error: Oops: 96000006 [#1] SMP [ 9.024577] Modules linked in: [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] pstate: 600003c5 .... [ 9.031956] Call trace: [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 [ 9.032472] [<ffffffc0002bffb4>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.032550] [<ffffffc000565220>] acpi_processor_power_init+0xac/0x138 [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- [ 9.033995] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Since PM control register is not exist on ARM64, It will cause such failure.
Does PM control register exist on ARM?
PM control registers here are ACPI PM control registers, which described in ACPI5.0 section 4.8, so I think they are not exist on ARM at present.
How it is possible it didn't crash on Arndale? I suppose we have the same functionality for Arndale as for Foundation model.
Good question. To tell the truth, I not sure why it is not happened on Arndale, and even on Graeme's ARMv8 foundation model, we have the same version of foundation model, the same kernel code and the config file, but it not happened on Graeme's model. (odd, right? )
I guess on my armv8 model, we lucky hit the bug that it access the virtual address which not exist, but on Graeme's model, the virtual address is available.
I'm not sure of this, I will ask some guy who is a expert on memory management next Monday.
but this bug (not a bug really, an feature not supported on ARM) do exist on ARM, we should add a cards to enhance the ACPI driver to support reduced hardware as Graeme and Andrea suggested.
Thanks Hanjun
Thanks Hanjun
ACPICA provided a macro to enable reduced hardware feature, and functions deal with ACPI hardware will defined as empty when ACPI_REDUCED_HARDWARE is TRUE, so we can avoid panic when excute the ACPI driver code.
Signed-off-by: Hanjun Guo hanjun.guo@linaro.org
include/acpi/acconfig.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 arch/arm64/boot/install.sh
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh old mode 100644 new mode 100755 diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h index 14ceff7..cb80ea9 100644 --- a/include/acpi/acconfig.h +++ b/include/acpi/acconfig.h @@ -100,7 +100,7 @@ * ACPI PM timer * FACS table (Waking vectors and Global Lock) */ -#define ACPI_REDUCED_HARDWARE FALSE +#define ACPI_REDUCED_HARDWARE TRUE
/******************************************************************************
*
On 2013-6-15 15:55, Hanjun Guo wrote:
On 2013-6-14 21:17, Tomasz Nowicki wrote:
W dniu 14.06.2013 15:08, Hanjun Guo pisze:
On 2013-6-14 20:23, Tomasz Nowicki wrote:
W dniu 14.06.2013 11:53, Hanjun Guo pisze:
PM Event and Control registers and other ACPI fixed hardware features were not supported on ARM64 yet, so we need enable reduced hardware as described in ACPI 5.0.
I met a boot panic failure on the ARMv8 model,
[ 9.024370] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.024423] pgd = ffffffc00007d000 [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.024538] Internal error: Oops: 96000006 [#1] SMP [ 9.024577] Modules linked in: [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] pstate: 600003c5 .... [ 9.031956] Call trace: [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 [ 9.032472] [<ffffffc0002bffb4>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.032550] [<ffffffc000565220>] acpi_processor_power_init+0xac/0x138 [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- [ 9.033995] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Since PM control register is not exist on ARM64, It will cause such failure.
Does PM control register exist on ARM?
PM control registers here are ACPI PM control registers, which described in ACPI5.0 section 4.8, so I think they are not exist on ARM at present.
How it is possible it didn't crash on Arndale? I suppose we have the same functionality for Arndale as for Foundation model.
Good question. To tell the truth, I not sure why it is not happened on Arndale, and even on Graeme's ARMv8 foundation model, we have the same version of foundation model, the same kernel code and the config file, but it not happened on Graeme's model. (odd, right? )
I guess on my armv8 model, we lucky hit the bug that it access the virtual address which not exist, but on Graeme's model, the virtual address is available.
I'm not sure of this, I will ask some guy who is a expert on memory management next Monday.
Ok, I have tracked this problem down, and I will explain why this is not happened on Arndale and armv8 model with more than one core booted.
Let's go back to drivers/acpi/processor_driver.c, acpi_processor_start() will be called in acpi_processor_add() when need_hotplug_init flag is 0, when the system booted, the need_hotplug_init flag should be 0, but on the system with multi cpu booted on arm:
acpi_processor_add()
acpi_processor_get_info()
acpi_get_cpuid() if cpu is hot-added, will return -1 but on ARM platform, map gic id to cpu id is not implemented, so acpi_get_cpuid() will always return -1 on arm.
acpi_processor_hotadd_init() will be called, and set need_hotplug_init to 1
acpi_processor_start() will not called, and the bug will not triggered.
On the UP sytem: acpi_processor_hotadd_init() will not be called, so the need_hotplug_init flag is zero. and acpi_processor_start() will called with bug happened.
Arndale board has two cpu cores, so this is not happened on Arndale, if you want to trigger this bug, boot the acpi kernel on armv8 model with --cores=1.
I will fix this in cpu topology cards, and enhance hardware reduced for acpi driver is also needed.
Thanks Hanjun
On Tue, Jun 18, 2013 at 12:04:51PM +0800, Hanjun Guo wrote:
On 2013-6-15 15:55, Hanjun Guo wrote:
On 2013-6-14 21:17, Tomasz Nowicki wrote:
W dniu 14.06.2013 15:08, Hanjun Guo pisze:
On 2013-6-14 20:23, Tomasz Nowicki wrote:
W dniu 14.06.2013 11:53, Hanjun Guo pisze:
PM Event and Control registers and other ACPI fixed hardware features were not supported on ARM64 yet, so we need enable reduced hardware as described in ACPI 5.0.
I met a boot panic failure on the ARMv8 model,
[ 9.024370] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.024423] pgd = ffffffc00007d000 [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.024538] Internal error: Oops: 96000006 [#1] SMP [ 9.024577] Modules linked in: [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] pstate: 600003c5 .... [ 9.031956] Call trace: [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 [ 9.032472] [<ffffffc0002bffb4>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.032550] [<ffffffc000565220>] acpi_processor_power_init+0xac/0x138 [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- [ 9.033995] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Since PM control register is not exist on ARM64, It will cause such failure.
Does PM control register exist on ARM?
PM control registers here are ACPI PM control registers, which described in ACPI5.0 section 4.8, so I think they are not exist on ARM at present.
How it is possible it didn't crash on Arndale? I suppose we have the same functionality for Arndale as for Foundation model.
Good question. To tell the truth, I not sure why it is not happened on Arndale, and even on Graeme's ARMv8 foundation model, we have the same version of foundation model, the same kernel code and the config file, but it not happened on Graeme's model. (odd, right? )
I guess on my armv8 model, we lucky hit the bug that it access the virtual address which not exist, but on Graeme's model, the virtual address is available.
I'm not sure of this, I will ask some guy who is a expert on memory management next Monday.
Ok, I have tracked this problem down, and I will explain why this is not happened on Arndale and armv8 model with more than one core booted.
Let's go back to drivers/acpi/processor_driver.c, acpi_processor_start() will be called in acpi_processor_add() when need_hotplug_init flag is 0, when the system booted, the need_hotplug_init flag should be 0, but on the system with multi cpu booted on arm:
acpi_processor_add()
acpi_processor_get_info()
acpi_get_cpuid() if cpu is hot-added, will return -1 but on ARM platform, map gic id to cpu id is not implemented, so acpi_get_cpuid() will always return -1 on arm. acpi_processor_hotadd_init() will be called, and set need_hotplug_init to 1acpi_processor_start() will not called, and the bug will not triggered.
On the UP sytem: acpi_processor_hotadd_init() will not be called, so the need_hotplug_init flag is zero. and acpi_processor_start() will called with bug happened.
Arndale board has two cpu cores, so this is not happened on Arndale, if you want to trigger this bug, boot the acpi kernel on armv8 model with --cores=1.
I will fix this in cpu topology cards, and enhance hardware reduced for acpi driver is also needed.
Hi Hanjun,
excellent peice of investigation, I never even considered to ask how many cores people were starting with. I had --cores=4.
Thanks
Graeme
On 2013-6-18 15:57, Graeme Gregory wrote:
On Tue, Jun 18, 2013 at 12:04:51PM +0800, Hanjun Guo wrote:
On 2013-6-15 15:55, Hanjun Guo wrote:
On 2013-6-14 21:17, Tomasz Nowicki wrote:
W dniu 14.06.2013 15:08, Hanjun Guo pisze:
On 2013-6-14 20:23, Tomasz Nowicki wrote:
W dniu 14.06.2013 11:53, Hanjun Guo pisze: > PM Event and Control registers and other ACPI fixed hardware features > were not supported on ARM64 yet, so we need enable reduced hardware > as described in ACPI 5.0. > > I met a boot panic failure on the ARMv8 model, > > [ 9.024370] Unable to handle kernel paging request at virtual > address ffffffbffbe00001 > [ 9.024423] pgd = ffffffc00007d000 > [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, > *pmd=0000000000000000 > [ 9.024538] Internal error: Oops: 96000006 [#1] SMP > [ 9.024577] Modules linked in: > [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) > [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 > [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 > [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] > pstate: 600003c5 > .... > [ 9.031956] Call trace: > [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 > [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 > [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 > [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 > [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 > [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 > [ 9.032472] [<ffffffc0002bffb4>] > acpi_processor_get_power_info+0x6c4/0x748 > [ 9.032550] [<ffffffc000565220>] > acpi_processor_power_init+0xac/0x138 > [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 > [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 > [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 > [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 > [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 > [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c > [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 > [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 > [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 > [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 > [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 > [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 > [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc > [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc > [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) > [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- > [ 9.033995] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x0000000b > > Since PM control register is not exist on ARM64, It will cause such > failure. Does PM control register exist on ARM?
PM control registers here are ACPI PM control registers, which described in ACPI5.0 section 4.8, so I think they are not exist on ARM at present.
How it is possible it didn't crash on Arndale? I suppose we have the same functionality for Arndale as for Foundation model.
Good question. To tell the truth, I not sure why it is not happened on Arndale, and even on Graeme's ARMv8 foundation model, we have the same version of foundation model, the same kernel code and the config file, but it not happened on Graeme's model. (odd, right? )
I guess on my armv8 model, we lucky hit the bug that it access the virtual address which not exist, but on Graeme's model, the virtual address is available.
I'm not sure of this, I will ask some guy who is a expert on memory management next Monday.
Ok, I have tracked this problem down, and I will explain why this is not happened on Arndale and armv8 model with more than one core booted.
Let's go back to drivers/acpi/processor_driver.c, acpi_processor_start() will be called in acpi_processor_add() when need_hotplug_init flag is 0, when the system booted, the need_hotplug_init flag should be 0, but on the system with multi cpu booted on arm:
acpi_processor_add()
acpi_processor_get_info()
acpi_get_cpuid() if cpu is hot-added, will return -1 but on ARM platform, map gic id to cpu id is not implemented, so acpi_get_cpuid() will always return -1 on arm. acpi_processor_hotadd_init() will be called, and set need_hotplug_init to 1acpi_processor_start() will not called, and the bug will not triggered.
On the UP sytem: acpi_processor_hotadd_init() will not be called, so the need_hotplug_init flag is zero. and acpi_processor_start() will called with bug happened.
Arndale board has two cpu cores, so this is not happened on Arndale, if you want to trigger this bug, boot the acpi kernel on armv8 model with --cores=1.
I will fix this in cpu topology cards, and enhance hardware reduced for acpi driver is also needed.
Hi Hanjun,
excellent peice of investigation, I never even considered to ask how many cores people were starting with. I had --cores=4.
I missed this too until I happened to boot the kernel ok when --cores=2, so I reviewed the code carefully, and found out why.
Happy to find this out, it makes me understand the cpu topology and the status of HW-reduced ACPI driver clearer.
Thanks
Graeme
On 06/18/2013 05:31 AM, Hanjun Guo wrote:
On 2013-6-18 15:57, Graeme Gregory wrote:
On Tue, Jun 18, 2013 at 12:04:51PM +0800, Hanjun Guo wrote:
On 2013-6-15 15:55, Hanjun Guo wrote:
On 2013-6-14 21:17, Tomasz Nowicki wrote:
W dniu 14.06.2013 15:08, Hanjun Guo pisze:
On 2013-6-14 20:23, Tomasz Nowicki wrote: > W dniu 14.06.2013 11:53, Hanjun Guo pisze: >> PM Event and Control registers and other ACPI fixed hardware features >> were not supported on ARM64 yet, so we need enable reduced hardware >> as described in ACPI 5.0. >> >> I met a boot panic failure on the ARMv8 model, >> >> [ 9.024370] Unable to handle kernel paging request at virtual >> address ffffffbffbe00001 >> [ 9.024423] pgd = ffffffc00007d000 >> [ 9.024468] [ffffffbffbe00001] *pgd=000000008007f003, >> *pmd=0000000000000000 >> [ 9.024538] Internal error: Oops: 96000006 [#1] SMP >> [ 9.024577] Modules linked in: >> [ 9.024627] CPU: 0 Not tainted (3.9.0+ #3) >> [ 9.024691] PC is at acpi_os_read_port+0x58/0xc8 >> [ 9.024753] LR is at acpi_hw_read_port+0x4c/0xc4 >> [ 9.024810] pc : [<ffffffc0002810cc>] lr : [<ffffffc0002a4fc4>] >> pstate: 600003c5 >> .... >> [ 9.031956] Call trace: >> [ 9.032021] [<ffffffc0002810cc>] acpi_os_read_port+0x58/0xc8 >> [ 9.032094] [<ffffffc0002a4fc4>] acpi_hw_read_port+0x4c/0xc4 >> [ 9.032165] [<ffffffc0002a4198>] acpi_hw_read+0x6c/0x100 >> [ 9.032237] [<ffffffc0002a4250>] acpi_hw_read_multiple+0x24/0x70 >> [ 9.032312] [<ffffffc0002a457c>] acpi_hw_register_read+0xa8/0x164 >> [ 9.032386] [<ffffffc0002a52dc>] acpi_write_bit_register+0x9c/0x194 >> [ 9.032472] [<ffffffc0002bffb4>] >> acpi_processor_get_power_info+0x6c4/0x748 >> [ 9.032550] [<ffffffc000565220>] >> acpi_processor_power_init+0xac/0x138 >> [ 9.032630] [<ffffffc0003f3c00>] acpi_processor_start+0x48/0x138 >> [ 9.032704] [<ffffffc000565118>] acpi_processor_add+0x43c/0x498 >> [ 9.032784] [<ffffffc000283a74>] acpi_device_probe+0x3c/0x198 >> [ 9.032862] [<ffffffc0002ef0fc>] driver_probe_device+0x90/0x348 >> [ 9.032940] [<ffffffc0002ef450>] __driver_attach+0x9c/0xa0 >> [ 9.033015] [<ffffffc0002ed40c>] bus_for_each_dev+0x4c/0x8c >> [ 9.033090] [<ffffffc0002eeb98>] driver_attach+0x20/0x28 >> [ 9.033166] [<ffffffc0002ee6e0>] bus_add_driver+0xfc/0x254 >> [ 9.033244] [<ffffffc0002ef8b0>] driver_register+0x6c/0x184 >> [ 9.033325] [<ffffffc000284894>] acpi_bus_register_driver+0x34/0x44 >> [ 9.033400] [<ffffffc000559c60>] acpi_processor_init+0x28/0x40 >> [ 9.033469] [<ffffffc000081438>] do_one_initcall+0x100/0x138 >> [ 9.033544] [<ffffffc0005448c8>] kernel_init_freeable+0x128/0x1cc >> [ 9.033620] [<ffffffc0003f2f90>] kernel_init+0x10/0xcc >> [ 9.033700] Code: d2bf7c02 f2dff7e2 f2ffffe2 8b020000 (79400000) >> [ 9.033843] ---[ end trace 64376967e6bc20a9 ]--- >> [ 9.033995] Kernel panic - not syncing: Attempted to kill init! >> exitcode=0x0000000b >> >> Since PM control register is not exist on ARM64, It will cause such >> failure. > Does PM control register exist on ARM?
PM control registers here are ACPI PM control registers, which described in ACPI5.0 section 4.8, so I think they are not exist on ARM at present.
How it is possible it didn't crash on Arndale? I suppose we have the same functionality for Arndale as for Foundation model.
Good question. To tell the truth, I not sure why it is not happened on Arndale, and even on Graeme's ARMv8 foundation model, we have the same version of foundation model, the same kernel code and the config file, but it not happened on Graeme's model. (odd, right? )
I guess on my armv8 model, we lucky hit the bug that it access the virtual address which not exist, but on Graeme's model, the virtual address is available.
I'm not sure of this, I will ask some guy who is a expert on memory management next Monday.
Ok, I have tracked this problem down, and I will explain why this is not happened on Arndale and armv8 model with more than one core booted.
Let's go back to drivers/acpi/processor_driver.c, acpi_processor_start() will be called in acpi_processor_add() when need_hotplug_init flag is 0, when the system booted, the need_hotplug_init flag should be 0, but on the system with multi cpu booted on arm:
acpi_processor_add()
acpi_processor_get_info()
acpi_get_cpuid() if cpu is hot-added, will return -1 but on ARM platform, map gic id to cpu id is not implemented, so acpi_get_cpuid() will always return -1 on arm. acpi_processor_hotadd_init() will be called, and set need_hotplug_init to 1acpi_processor_start() will not called, and the bug will not triggered.
On the UP sytem: acpi_processor_hotadd_init() will not be called, so the need_hotplug_init flag is zero. and acpi_processor_start() will called with bug happened.
Arndale board has two cpu cores, so this is not happened on Arndale, if you want to trigger this bug, boot the acpi kernel on armv8 model with --cores=1.
I will fix this in cpu topology cards, and enhance hardware reduced for acpi driver is also needed.
Hi Hanjun,
excellent peice of investigation, I never even considered to ask how many cores people were starting with. I had --cores=4.
I missed this too until I happened to boot the kernel ok when --cores=2, so I reviewed the code carefully, and found out why.
Happy to find this out, it makes me understand the cpu topology and the status of HW-reduced ACPI driver clearer.
Nicely done. I had not changed the default Foundation model configuration so it was set to --cores=1.
-
Al Stone -
Andrea Gallo -
Graeme Gregory -
Hanjun Guo -
Tomasz Nowicki