On 06/27/2013 03:22 AM, Graeme Gregory wrote:

Done

On 26/06/13 17:25, Graeme Gregory wrote:

...

Hi Guys,

Discussed this with Al and I think everyone is finished with 3.9 work now! I am going to switch the acpi branch to be the contents of the acpi-combined branch at 10AM tomorrow my local time!

The two branches will initially be :-

acpi - our work branch now based off 3.10-rcX kernel (and will track mainline releases/rc releases) acpi-ltfixes - is the acpi branch + some needed fixes from Samsung landing team for Arndale prototyping.

We can of course create more short term branches for demos, prototyping as needed.

Thanks

Graeme

Oh, someone please tell me I'm doing something stupid....

I've compiled this branch [0] with the Linaro AArch64 cross-compilers and followed Naresh's wonderful instructions. Does this version of the kernel get to a command line for anyone else? What I see is this:

.... [ 9.014270] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.014324] pgd = ffffffc00007d000 [ 9.014370] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.014443] Internal error: Oops: 96000006 [#1] SMP [ 9.014483] Modules linked in: [ 9.014545] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc6+ #2 [ 9.014610] task: ffffffc87fc58000 ti: ffffffc87fc60000 task.ti: ffffffc87fc60000 [ 9.014676] PC is at acpi_os_read_port+0x58/0xc8 [ 9.014734] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.014792] pc : [<ffffffc000261360>] lr : [<ffffffc000286300>] pstate: 600003c5 [ 9.014845] sp : ffffffc87fc61930 ....

And the stack looks like this:

[ 9.022038] Call trace: [ 9.022097] [<ffffffc000261360>] acpi_os_read_port+0x58/0xc8 [ 9.022165] [<ffffffc000286300>] acpi_hw_read_port+0x4c/0xc4 [ 9.022246] [<ffffffc0002854c4>] acpi_hw_read+0x6c/0x100 [ 9.022329] [<ffffffc00028557c>] acpi_hw_read_multiple+0x24/0x70 [ 9.022414] [<ffffffc0002858a8>] acpi_hw_register_read+0xa8/0x164 [ 9.022484] [<ffffffc000286618>] acpi_write_bit_register+0x9c/0x194 [ 9.022567] [<ffffffc0002a0d2c>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.022644] [<ffffffc000526528>] acpi_processor_power_init+0xac/0x130 [ 9.022724] [<ffffffc0003c3444>] acpi_processor_start+0x48/0x138 [ 9.022798] [<ffffffc000526420>] acpi_processor_add+0x458/0x4b4 [ 9.022873] [<ffffffc000264364>] acpi_device_probe+0x3c/0x18c [ 9.022950] [<ffffffc0002d35bc>] driver_probe_device+0x90/0x348 [ 9.023027] [<ffffffc0002d3910>] __driver_attach+0x9c/0xa0 [ 9.023099] [<ffffffc0002d186c>] bus_for_each_dev+0x4c/0x8c [ 9.023175] [<ffffffc0002d3054>] driver_attach+0x20/0x28 [ 9.023248] [<ffffffc0002d2ba4>] bus_add_driver+0xf8/0x248 [ 9.023325] [<ffffffc0002d3d70>] driver_register+0x6c/0x184 [ 9.023401] [<ffffffc0002657b0>] acpi_bus_register_driver+0x34/0x44 [ 9.023473] [<ffffffc00051a870>] acpi_processor_init+0x28/0x40 [ 9.023544] [<ffffffc000081430>] do_one_initcall+0xd0/0x154 [ 9.023620] [<ffffffc0005068e0>] kernel_init_freeable+0x128/0x1cc [ 9.023696] [<ffffffc0003c27f4>] kernel_init+0x10/0xcc

Or, is this expected until all of Hanjun's patches are in [1]?

Thanks.

[0] The most recent acpi branch, a fresh clone of the repo, and the last commit was 48423e574af2ea1e91ed9646eeffe3908227c047

[1] Don't get me wrong -- I _like_ seeing all the ACPI calls in the stack, it's just the oops part I'm wondering about :).

On 06/27/2013 09:25 PM, Hanjun Guo wrote:

On 2013-6-28 6:18, Al Stone wrote:

...

On 06/27/2013 03:22 AM, Graeme Gregory wrote:

...

Done

On 26/06/13 17:25, Graeme Gregory wrote:

...

Hi Guys,

Discussed this with Al and I think everyone is finished with 3.9 work now! I am going to switch the acpi branch to be the contents of the acpi-combined branch at 10AM tomorrow my local time!

The two branches will initially be :-

acpi - our work branch now based off 3.10-rcX kernel (and will track mainline releases/rc releases) acpi-ltfixes - is the acpi branch + some needed fixes from Samsung landing team for Arndale prototyping.

We can of course create more short term branches for demos, prototyping as needed.

Thanks

Graeme

Oh, someone please tell me I'm doing something stupid....

I've compiled this branch [0] with the Linaro AArch64 cross-compilers and followed Naresh's wonderful instructions. Does this version of the kernel get to a command line for anyone else? What I see is this:

.... [ 9.014270] Unable to handle kernel paging request at virtual address ffffffbffbe00001 [ 9.014324] pgd = ffffffc00007d000 [ 9.014370] [ffffffbffbe00001] *pgd=000000008007f003, *pmd=0000000000000000 [ 9.014443] Internal error: Oops: 96000006 [#1] SMP [ 9.014483] Modules linked in: [ 9.014545] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc6+ #2 [ 9.014610] task: ffffffc87fc58000 ti: ffffffc87fc60000 task.ti: ffffffc87fc60000 [ 9.014676] PC is at acpi_os_read_port+0x58/0xc8 [ 9.014734] LR is at acpi_hw_read_port+0x4c/0xc4 [ 9.014792] pc : [<ffffffc000261360>] lr : [<ffffffc000286300>] pstate: 600003c5 [ 9.014845] sp : ffffffc87fc61930 ....

And the stack looks like this:

[ 9.022038] Call trace: [ 9.022097] [<ffffffc000261360>] acpi_os_read_port+0x58/0xc8 [ 9.022165] [<ffffffc000286300>] acpi_hw_read_port+0x4c/0xc4 [ 9.022246] [<ffffffc0002854c4>] acpi_hw_read+0x6c/0x100 [ 9.022329] [<ffffffc00028557c>] acpi_hw_read_multiple+0x24/0x70 [ 9.022414] [<ffffffc0002858a8>] acpi_hw_register_read+0xa8/0x164 [ 9.022484] [<ffffffc000286618>] acpi_write_bit_register+0x9c/0x194 [ 9.022567] [<ffffffc0002a0d2c>] acpi_processor_get_power_info+0x6c4/0x748 [ 9.022644] [<ffffffc000526528>] acpi_processor_power_init+0xac/0x130 [ 9.022724] [<ffffffc0003c3444>] acpi_processor_start+0x48/0x138 [ 9.022798] [<ffffffc000526420>] acpi_processor_add+0x458/0x4b4 [ 9.022873] [<ffffffc000264364>] acpi_device_probe+0x3c/0x18c [ 9.022950] [<ffffffc0002d35bc>] driver_probe_device+0x90/0x348 [ 9.023027] [<ffffffc0002d3910>] __driver_attach+0x9c/0xa0 [ 9.023099] [<ffffffc0002d186c>] bus_for_each_dev+0x4c/0x8c [ 9.023175] [<ffffffc0002d3054>] driver_attach+0x20/0x28 [ 9.023248] [<ffffffc0002d2ba4>] bus_add_driver+0xf8/0x248 [ 9.023325] [<ffffffc0002d3d70>] driver_register+0x6c/0x184 [ 9.023401] [<ffffffc0002657b0>] acpi_bus_register_driver+0x34/0x44 [ 9.023473] [<ffffffc00051a870>] acpi_processor_init+0x28/0x40 [ 9.023544] [<ffffffc000081430>] do_one_initcall+0xd0/0x154 [ 9.023620] [<ffffffc0005068e0>] kernel_init_freeable+0x128/0x1cc [ 9.023696] [<ffffffc0003c27f4>] kernel_init+0x10/0xcc

Or, is this expected until all of Hanjun's patches are in [1]?

Please boot armv8 foundation model with --cores=4 (or --cores=2, --cores=3), never boot with the ACPI kernel with default configure or --cores=1.

I met this problem before, and sent out a patch: [PATCH 1/1] Set macro ACPI_REDUCED_HARDWARE as TRUE for reduced hardware paltform

It turns out that the ACPI driver doesn't support hardware reduced ACPI, and by accident this bug will not triggered with more than one cpu booted.

This problem will fade away after we enhance the ACPI driver for hardware reduced ACPI.

Aha! I *knew* I was doing something stupid! I forgot all about this. Sigh. My brain's full; I need another one.

...

Thanks.

[0] The most recent acpi branch, a fresh clone of the repo, and the last commit was 48423e574af2ea1e91ed9646eeffe3908227c047

[1] Don't get me wrong -- I _like_ seeing all the ACPI calls in the stack, it's just the oops part I'm wondering about :).