[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linaro-acpi
Subject:    [Linaro-acpi] ACPI/ACPI-combined switch 10AM BST 27th June
From:       al.stone () linaro ! org (Al Stone)
Date:       2013-06-28 15:36:31
Message-ID: 51CDAD7F.2030700 () linaro ! org
[Download RAW message or body]

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 :).
>>
>


-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone at linaro.org
-----------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]