Re: [Devel] [PATCH v5 12/14] arm64, acpi, numa: NUMA support based on SRAT and SLIT
by Hanjun Guo
Hi Dennis, David,
Sorry for the late reply, please see my comments below.
On 2016/4/27 9:14, David Daney wrote:
> On 04/21/2016 03:06 AM, Dennis Chen wrote:
>> On 20 April 2016 at 09:40, David Daney <ddaney.cavm(a)gmail.com> wrote:
> [...]
>>> +/* Callback for Proximity Domain -> ACPI processor UID mapping */
>>> +void __init acpi_numa_gicc_affinity_init(struct
>>> acpi_srat_gicc_affinity *pa)
>>> +{
>>> + int pxm, node;
>>> + u64 mpidr;
>>> +
>>> + if (srat_disabled())
>>> + return;
>>> +
>>> + if (pa->header.length < sizeof(struct
>>> acpi_srat_gicc_affinity)) {
>>> + pr_err("SRAT: Invalid SRAT header length: %d\n",
>>> + pa->header.length);
>>> + bad_srat();
>>> + return;
>>> + }
>>> +
>>> + if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
>>> + return;
>>> +
>>> + if (cpus_in_srat >= NR_CPUS) {
>>> + pr_warn_once("SRAT: cpu_to_node_map[%d] is too small,
>>> may not be able to use all cpus\n",
>>> + NR_CPUS);
>>> + return;
>>> + }
>>> +
>>> + pxm = pa->proximity_domain;
>>> + node = acpi_map_pxm_to_node(pxm);
>>> +
>>> + if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
>>> + pr_err("SRAT: Too many proximity domains %d\n", pxm);
>>> + bad_srat();
>>> + return;
>>> + }
>>> +
>>> + if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
>>> + pr_err("SRAT: PXM %d with ACPI ID %d has no valid
>>> MPIDR in MADT\n",
>>> + pxm, pa->acpi_processor_uid);
>>> + bad_srat();
>>> + return;
>>> + }
>>> +
>>> + early_node_cpu_hwid[cpus_in_srat].node_id = node;
>>> + early_node_cpu_hwid[cpus_in_srat].cpu_hwid = mpidr;
>>> + node_set(node, numa_nodes_parsed);
>>> + cpus_in_srat++;
>>> + pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
>>> + pxm, mpidr, node, cpus_in_srat);
>>> +}
>>
>> What does the *cpu* means in above pr_info function? If it's the
>> logical processor ID or ACPI processor UID, then I suggest to use
>> pa->acpi_processor_uid instead of cpus_in_srat, I understand the
I think print cpus_in_srat is pointless here, as the logic cpu number
is allocated by OS when initializing SMP by scanning MADT table. As
Dennis said, it's just a count number, not a number mapping to MPIDR.
ACPI processor UID is the key value to connect MADT, SRAT, DSDT.
For MADT, it will have MPIDR and ACPI processor UID, and OS will
create mappings to MPIDR and cpu logical number,
ACPI processor UID <------> MPIDR <------> CPU logical number
In SRAT, there is ACPI processor UID represented, mappings will be
ACPI processor UID <------> PXM <------> NUMA node logical number
So we can use ACPI processor UID to get the MPIDR by scanning the
MADT, then we can map NUMA node logical number to cpu logical
number later.
>> cpus_in_srat is just a count number of the entries of GICC Affinity
>> Struct instance in SRAT, correct me if I am wrong. So at least it sees
>> to me, the above pr_info will output message looks like:
>> SRAT: PXM 0 -> MPIDR 0x100 -> Node 0 cpu 1
>> SRAT: PXM 0 -> MPIDR 0x101 -> Node 0 cpu 2
>> SRAT: PXM 0 -> MPIDR 0x102 -> Node 0 cpu 3
>>
>
> Yes, that is correct, and for my system seems to be what we want as the
> names in /sys/devices/system/cpu/ and /proc/cpu_info agree with the
> sequential numbering (0..95) with 48 CPUs on each node.
That's because you place CPUs in the same order both in MADT and SRAT :)
if not, that will be not match.
>
> If I make the change you suggest, I get :
> .
> .
> .
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x0 -> Node 0 cpu 0
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1 -> Node 0 cpu 1
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x2 -> Node 0 cpu 2
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x3 -> Node 0 cpu 3
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x4 -> Node 0 cpu 4
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x5 -> Node 0 cpu 5
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x6 -> Node 0 cpu 6
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x7 -> Node 0 cpu 7
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x8 -> Node 0 cpu 8
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x9 -> Node 0 cpu 9
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xa -> Node 0 cpu 10
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xb -> Node 0 cpu 11
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xc -> Node 0 cpu 12
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xd -> Node 0 cpu 13
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xe -> Node 0 cpu 14
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0xf -> Node 0 cpu 15
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x100 -> Node 0 cpu 256
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x101 -> Node 0 cpu 257
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x102 -> Node 0 cpu 258
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x103 -> Node 0 cpu 259
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x104 -> Node 0 cpu 260
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x105 -> Node 0 cpu 261
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x106 -> Node 0 cpu 262
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x107 -> Node 0 cpu 263
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x108 -> Node 0 cpu 264
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x109 -> Node 0 cpu 265
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x10a -> Node 0 cpu 266
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x10b -> Node 0 cpu 267
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x10c -> Node 0 cpu 268
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x10d -> Node 0 cpu 269
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x10e -> Node 0 cpu 270
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x10f -> Node 0 cpu 271
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x200 -> Node 0 cpu 512
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x201 -> Node 0 cpu 513
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x202 -> Node 0 cpu 514
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x203 -> Node 0 cpu 515
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x204 -> Node 0 cpu 516
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x205 -> Node 0 cpu 517
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x206 -> Node 0 cpu 518
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x207 -> Node 0 cpu 519
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x208 -> Node 0 cpu 520
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x209 -> Node 0 cpu 521
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x20a -> Node 0 cpu 522
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x20b -> Node 0 cpu 523
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x20c -> Node 0 cpu 524
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x20d -> Node 0 cpu 525
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x20e -> Node 0 cpu 526
> [ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x20f -> Node 0 cpu 527
> [ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10000 -> Node 1 cpu 65536
> [ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10001 -> Node 1 cpu 65537
> [ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10002 -> Node 1 cpu 65538
> [ 0.000000] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x10003 -> Node 1 cpu 65539
> .
> .
> .
>
> Not really what I would want.
How about remove the print for "cpu"? it's not the right value we want,
and we can get such mapping information under in sysfs.
>
>
>> While the /sys/devices/system/cpu will use the ACPI processor UID to
>> generate the index of the cpu, like:
>> cpu0 cpu1 cpu2 ...
>>
>> As the GICC Affinity Struct indicated, the ps->proximity_domain is the
>> domain to which the logical processor belongs...
Yes, we can get such information in /sys/devices/system/node, I think
we can only print:
ACPI: NUMA: SRAT: PXM x -> MPIDR y -> Node z
Thanks
Hanjun
5 years
Re: [Devel] [PATCH v5 00/14] ACPI NUMA support for ARM64
by Hanjun Guo
Hi Will,
On 2016/4/26 21:35, Will Deacon wrote:
> On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote:
>> On 2016/4/26 20:15, Will Deacon wrote:
>>> On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote:
>>>> On 2016/4/26 0:47, David Daney wrote:
>>>>> On 04/25/2016 04:13 AM, Will Deacon wrote:
>>>>>> On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote:
>>>>>>> From: David Daney <david.daney(a)cavium.com>
>>>>>>>
>>>>>>> Based on v16 of device-tree NUMA patch set for arm64 [1],this patch
>>>>>>> set introduce the ACPI based configuration to provide NUMA
>>>>>>> information.
>>>>>>>
>>>>>>> ACPI 5.1 already introduced NUMA support for ARM64, which can get the
>>>>>>> NUMA domain information from SRAT and SLIT table, so parse those two
>>>>>>> tables to get mappings from cpu/mem to numa node configuration and
>>>>>>> system locality.
>>>>>>
>>>>>> Whilst I've queued the main NUMA series for arm64, I'd really like to
>>>>>> see more movement on the generic header file cleanups that you posted
>>>>>> separately:
>>>>>>
>>>>>> http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gm...
>>>>>>
>>>>>
>>>>> FWIW: Those patches should still apply. I am carrying them in my
>>>>> development trees, and have not changed them in any way.
>>>
>>> What's your plan for getting them merged?
>>
>> This patch set touches lots of ACPI related file in arch/x86,
>> arch/ia64, and drivers/acpi/ (also arch/arm64), I think it can be
>> merged via ACPI tree by Rafael with your ack to ARM64 code, does
>> it make sense?
>
> It doesn't touch anything in drivers/acpi/... are you following the link
> above?
Sorry, my bad, I though you were talking about this ACPI NUMA support
for ARM64 patch set.
>
>>>>>> Given that this ACPI series already requires some significant cross-arch
>>>>>> interaction (which is actually good!), perhaps extending the clean-up
>>>>>> patches to encompass some of the ACPI bits might make sense, and we can
>>>>>> get that queued as a pre-requisite.
>>>>>
>>>>> The cleanup patches you mention above are really independent of the ACPI
>>>>> things. I have applied them both before and after the ACPI patches, and
>>>>> both seem to work. With a quick perusal of the ACPI patches nothing
>>>>> jumps out at me as being a candidate for inclusion in the header file
>>>>> cleanup series.
>>>>
>>>> I agree. My patch set is ACPI related enablement, cleanups and
>>>> consolidations, it would be good to merge as a single patch set
>>>> as it's self-contained.
>>>
>>> Up to you. I just thought you might want to avoid having two sets of
>>> cross-arch changes and the associated merging headaches that go with
>>> that.
>>
>> Good point, as I suggested above, it can go with ACPI tree if it's ok
>> to you and Rafael. The problem we have now is that dt based core NUMA
>> support for ARM64 is queued in your tree, that would be the headache.
>
> Sorry, but if you wanted me *not* to queue the patches, then you should
> have said so (similarly, if you wanted a stable branch). I'm not rebasing
> our for-next/core branch now.
I misread the message above, I'm really sorry if I did something
offending you, I didn't mean that.
How about this patch set? We only get few comments on it, your
comments on it are appreciated.
Thanks
Hanjun
5 years
Re: [Devel] [PATCH v5 00/14] ACPI NUMA support for ARM64
by Hanjun Guo
On 2016/4/26 20:15, Will Deacon wrote:
> On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote:
>> On 2016/4/26 0:47, David Daney wrote:
>>> On 04/25/2016 04:13 AM, Will Deacon wrote:
>>>> On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote:
>>>>> From: David Daney <david.daney(a)cavium.com>
>>>>>
>>>>> Based on v16 of device-tree NUMA patch set for arm64 [1],this patch
>>>>> set introduce the ACPI based configuration to provide NUMA
>>>>> information.
>>>>>
>>>>> ACPI 5.1 already introduced NUMA support for ARM64, which can get the
>>>>> NUMA domain information from SRAT and SLIT table, so parse those two
>>>>> tables to get mappings from cpu/mem to numa node configuration and
>>>>> system locality.
>>>>
>>>> Whilst I've queued the main NUMA series for arm64, I'd really like to
>>>> see more movement on the generic header file cleanups that you posted
>>>> separately:
>>>>
>>>> http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gm...
>>>>
>>>
>>> FWIW: Those patches should still apply. I am carrying them in my
>>> development trees, and have not changed them in any way.
>
> What's your plan for getting them merged?
This patch set touches lots of ACPI related file in arch/x86,
arch/ia64, and drivers/acpi/ (also arch/arm64), I think it can be
merged via ACPI tree by Rafael with your ack to ARM64 code, does
it make sense?
>
>>>> Given that this ACPI series already requires some significant cross-arch
>>>> interaction (which is actually good!), perhaps extending the clean-up
>>>> patches to encompass some of the ACPI bits might make sense, and we can
>>>> get that queued as a pre-requisite.
>>>
>>> The cleanup patches you mention above are really independent of the ACPI
>>> things. I have applied them both before and after the ACPI patches, and
>>> both seem to work. With a quick perusal of the ACPI patches nothing
>>> jumps out at me as being a candidate for inclusion in the header file
>>> cleanup series.
>>
>> I agree. My patch set is ACPI related enablement, cleanups and
>> consolidations, it would be good to merge as a single patch set
>> as it's self-contained.
>
> Up to you. I just thought you might want to avoid having two sets of
> cross-arch changes and the associated merging headaches that go with
> that.
Good point, as I suggested above, it can go with ACPI tree if it's ok
to you and Rafael. The problem we have now is that dt based core NUMA
support for ARM64 is queued in your tree, that would be the headache.
Thanks
Hanjun
5 years
Re: [Devel] [PATCH v5 00/14] ACPI NUMA support for ARM64
by Hanjun Guo
Hi Will, David,
On 2016/4/26 0:47, David Daney wrote:
> On 04/25/2016 04:13 AM, Will Deacon wrote:
>> Hi David,
>>
>> On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote:
>>> From: David Daney <david.daney(a)cavium.com>
>>>
>>> Based on v16 of device-tree NUMA patch set for arm64 [1],this patch
>>> set introduce the ACPI based configuration to provide NUMA
>>> information.
>>>
>>> ACPI 5.1 already introduced NUMA support for ARM64, which can get the
>>> NUMA domain information from SRAT and SLIT table, so parse those two
>>> tables to get mappings from cpu/mem to numa node configuration and
>>> system locality.
>>
>> Whilst I've queued the main NUMA series for arm64, I'd really like to
>> see more movement on the generic header file cleanups that you posted
>> separately:
>>
>> http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gm...
>>
>
> FWIW: Those patches should still apply. I am carrying them in my
> development trees, and have not changed them in any way.
>
>>
>> Given that this ACPI series already requires some significant cross-arch
>> interaction (which is actually good!), perhaps extending the clean-up
>> patches to encompass some of the ACPI bits might make sense, and we can
>> get that queued as a pre-requisite.
>
> The cleanup patches you mention above are really independent of the ACPI
> things. I have applied them both before and after the ACPI patches, and
> both seem to work. With a quick perusal of the ACPI patches nothing
> jumps out at me as being a candidate for inclusion in the header file
> cleanup series.
I agree. My patch set is ACPI related enablement, cleanups and
consolidations, it would be good to merge as a single patch set
as it's self-contained.
Thanks
Hanjun
5 years
Re: [Devel] [PATCH v5 04/14] acpi, numa: Move acpi_numa_arch_fixup() to ia64 only
by Hanjun Guo
On 2016/4/20 9:40, David Daney wrote:
> From: Robert Richter <rrichter(a)cavium.com>
>
> Since acpi_numa_arch_fixup() is only used in arch ia64, move it there
> to make a generic interface easier. This avoids empty function stubs
> or some complex kconfig options for x86 and arm64.
>
> Signed-off-by: Robert Richter <rrichter(a)cavium.com>
> Signed-off-by: David Daney <david.daney(a)cavium.com>
> ---
> arch/ia64/include/asm/acpi.h | 3 +++
> arch/ia64/kernel/acpi.c | 2 +-
> arch/ia64/kernel/setup.c | 1 +
> arch/x86/mm/srat.c | 2 --
> drivers/acpi/numa.c | 2 --
> include/linux/acpi.h | 1 -
> 6 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
> index aa0fdf1..a3d0211 100644
> --- a/arch/ia64/include/asm/acpi.h
> +++ b/arch/ia64/include/asm/acpi.h
> @@ -140,6 +140,9 @@ static inline void per_cpu_scan_finalize(int min_cpus, int reserve_cpus)
> }
> }
> }
> +
> +extern void acpi_numa_fixup(void);
> +
> #endif /* CONFIG_ACPI_NUMA */
>
> #endif /*__KERNEL__*/
> diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
> index b1698bc..92b7bc9 100644
> --- a/arch/ia64/kernel/acpi.c
> +++ b/arch/ia64/kernel/acpi.c
> @@ -524,7 +524,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> return 0;
> }
>
> -void __init acpi_numa_arch_fixup(void)
> +void __init acpi_numa_fixup(void)
> {
> int i, j, node_from, node_to;
>
> diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
> index 2029a38..afddb3e 100644
> --- a/arch/ia64/kernel/setup.c
> +++ b/arch/ia64/kernel/setup.c
> @@ -552,6 +552,7 @@ setup_arch (char **cmdline_p)
> early_acpi_boot_init();
> # ifdef CONFIG_ACPI_NUMA
> acpi_numa_init();
> + acpi_numa_fixup();
> # ifdef CONFIG_ACPI_HOTPLUG_CPU
> prefill_possible_map();
> # endif
> diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
> index b5f8218..90b6ed9 100644
> --- a/arch/x86/mm/srat.c
> +++ b/arch/x86/mm/srat.c
> @@ -212,8 +212,6 @@ out_err:
> return -1;
> }
>
> -void __init acpi_numa_arch_fixup(void) {}
> -
> int __init x86_acpi_numa_init(void)
> {
> int ret;
> diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> index 2de6068..f41f06b 100644
> --- a/drivers/acpi/numa.c
> +++ b/drivers/acpi/numa.c
> @@ -316,8 +316,6 @@ int __init acpi_numa_init(void)
> /* SLIT: System Locality Information Table */
> acpi_table_parse(ACPI_SIG_SLIT, acpi_parse_slit);
>
> - acpi_numa_arch_fixup();
> -
> if (cnt < 0)
> return cnt;
> else if (!parsed_numa_memblks)
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 06ed7e5..ab6fd96 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -244,7 +244,6 @@ void acpi_numa_slit_init (struct acpi_table_slit *slit);
> void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
> void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
> int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
> -void acpi_numa_arch_fixup(void);
>
> #ifndef PHYS_CPUID_INVALID
> typedef u32 phys_cpuid_t;
Reviewed-by: Hanjun Guo <hanjun.guo(a)linaro.org>
Thanks
Hanjun
5 years
ACPICA version 20160422 released
by Moore, Robert
22 April 2016. Summary of changes for version 20160422:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Fixed a regression in the GAS (generic address structure) arbitrary bit support in AcpiHwRead/AcpiHwWrite. Problem could cause incorrect behavior and incorrect return values. Lv Zheng. ACPICA BZ 1270.
ACPI 6.0: Added support for new/renamed resource macros. One new argument was added to each of these macros, and the original name has been deprecated. The AML disassembler will always disassemble to the new names. Support for the new macros was added to iASL, disassembler, resource manager, and the acpihelp utility. ACPICA BZ 1274.
I2cSerialBus -> I2cSerialBusV2
SpiSerialBus -> SpiSerialBusV2
UartSerialBus -> UartSerialBusV2
ACPI 6.0: Added support for a new integer field that was appended to the package object returned by the _BIX method. This adds iASL compile-time and AML runtime error checking. ACPICA BZ 1273.
ACPI 6.1: Added support for a new PCCT subtable, "HW-Reduced Comm Subspace Type2" (Headers, Disassembler, and data table compiler).
Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 9.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size.
Current Release:
Non-Debug Version: 137.4K Code, 52.6K Data, 190.0K Total
Debug Version: 201.5K Code, 82.2K Data, 283.7K Total
Previous Release:
Non-Debug Version: 137.1K Code, 51.5K Data, 188.6K Total
Debug Version: 201.0K Code, 82.0K Data, 283.0K Total
2) iASL Compiler/Disassembler and Tools:
iASL: Implemented an ASL grammar extension to allow/enable executable "module-level code" to be created and executed under the various operators that create new scopes. This type of AML code is already supported in all known AML interpreters, and the grammar change will appear in the next version of the ACPI specification. Simplifies the conditional runtime creation of named objects under these object types:
Device
PowerResource
Processor
Scope
ThermalZone
iASL: Implemented a new ASL extension, a "For" loop macro to add greater ease-of-use to the ASL language. The syntax is similar to the corresponding C operator, and is implemented with the existing AML While opcode -- thus requiring no changes to existing AML interpreters.
For (Initialize, Predicate, Update) {TermList}
Grammar:
ForTerm :=
For (
Initializer // Nothing | TermArg => ComputationalData
Predicate // Nothing | TermArg => ComputationalData
Update // Nothing | TermArg => ComputationalData
) {TermList}
iASL: The _HID/_ADR detection and validation has been enhanced to search under conditionals in order to allow these objects to be conditionally created at runtime.
iASL: Fixed several issues with the constant folding feature. The improvement allows better detection and resolution of statements that can be folded at compile time. ACPICA BZ 1266.
iASL/Disassembler: Fixed a couple issues with the Else{If{}...} conversion to the ASL ElseIf operator where incorrect ASL code could be generated.
iASL/Disassembler: Fixed a problem with the ASL+ code disassembly where sometimes an extra (and extraneous) set of parentheses were emitted for some combinations of operators. Although this did not cause any problems with recompilation of the disassembled code, it made the code more difficult to read. David Box. ACPICA BZ 1231.
iASL: Changed to ignore the unreferenced detection for predefined names of resource descriptor elements, when the resource descriptor is created/defined within a control method.
iASL: Disassembler: Fix a possible fault with externally declared Buffer objects.
5 years
[PATCH] acpixtract: use %u format specifier on unsigned int Gbl_TableCount
by Colin King
From: Colin Ian King <colin.king(a)canonical.com>
Minor issue, Gbl_TableCount is an unsigned int, so we should be using
a %u format specifier instead of %d.
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
---
source/tools/acpixtract/acpixtract.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/source/tools/acpixtract/acpixtract.c b/source/tools/acpixtract/acpixtract.c
index 3da6637..bb937a9 100644
--- a/source/tools/acpixtract/acpixtract.c
+++ b/source/tools/acpixtract/acpixtract.c
@@ -311,7 +311,7 @@ CleanupAndExit:
if (Gbl_TableCount > 1)
{
- printf ("\n%d binary ACPI tables extracted\n",
+ printf ("\n%u binary ACPI tables extracted\n",
Gbl_TableCount);
}
@@ -455,7 +455,7 @@ CleanupAndExit:
ThisSignature, ThisTableBytesWritten, Gbl_OutputFilename);
}
- printf ("\n%d binary ACPI tables extracted and written to %s (%u bytes)\n",
+ printf ("\n%u binary ACPI tables extracted and written to %s (%u bytes)\n",
Gbl_TableCount, Gbl_OutputFilename, TotalBytesWritten);
fclose (InputFile);
--
2.7.4
5 years
[PATCH] tools/acpi: fix inverted logic when closing fd
by Colin King
From: Colin Ian King <colin.king(a)canonical.com>
The current close on fd only occurs when fd is -ve, it should
actually be closing the file if it a valid fd. Fix the inverted logic.
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
---
tools/power/acpi/tools/acpidbg/acpidbg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/power/acpi/tools/acpidbg/acpidbg.c b/tools/power/acpi/tools/acpidbg/acpidbg.c
index d070fcc..ebe44dd 100644
--- a/tools/power/acpi/tools/acpidbg/acpidbg.c
+++ b/tools/power/acpi/tools/acpidbg/acpidbg.c
@@ -430,7 +430,7 @@ int main(int argc, char **argv)
acpi_aml_loop(fd);
exit:
- if (fd < 0)
+ if (fd >= 0)
close(fd);
if (acpi_aml_batch_cmd)
free(acpi_aml_batch_cmd);
--
2.7.4
5 years
Re: [Devel] [PATCH] acpi/acpica: fix Thunderbolt hotplug
by Moore, Robert
Internal discussion.
Given the urgency, we've decided to take the patch.
Bob
> -----Original Message-----
> From: Prarit Bhargava [mailto:prarit@redhat.com]
> Sent: Friday, April 15, 2016 10:03 AM
> To: Moore, Robert; Mika Westerberg
> Cc: linux-kernel(a)vger.kernel.org; Zheng, Lv; Wysocki, Rafael J; Len Brown;
> linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> Subject: Re: [PATCH] acpi/acpica: fix Thunderbolt hotplug
>
>
>
> On 04/15/2016 12:21 PM, Moore, Robert wrote:
> > Lv is looking at it. He has already commented that this might not be the
> best solution, so he is continuing to investigate.
> >
>
> /me scratches head
>
> Where was that comment made?
>
> P.
5 years
Re: [Devel] [PATCH] acpi/acpica: fix Thunderbolt hotplug
by Moore, Robert
Lv is looking at it. He has already commented that this might not be the best solution, so he is continuing to investigate.
> -----Original Message-----
> From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com]
> Sent: Friday, April 15, 2016 12:40 AM
> To: Prarit Bhargava
> Cc: linux-kernel(a)vger.kernel.org; Moore, Robert; Zheng, Lv; Wysocki,
> Rafael J; Len Brown; linux-acpi(a)vger.kernel.org; devel(a)acpica.org
> Subject: Re: [PATCH] acpi/acpica: fix Thunderbolt hotplug
>
> Bob, Rafael, any comments about this?
>
> This seems to solve a real issue with Thunderbolt hotplug on Dell XPS
> laptops. I do not know ACPICA that well to tell if this is 100% correct
> fix but many reporters say it fixes the problem they are facing:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=115121
>
> On Tue, Mar 29, 2016 at 06:45:40PM -0400, Prarit Bhargava wrote:
> > The following hung task trace is seen when hotplugging an ethernet
> > dongle in a Thunderbolt port on Linux.
> >
> > INFO: task kworker/0:4:1468 blocked for more than 120 seconds.
> > Tainted: G W 4.6.0-rc1+ #1
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
> message.
> > kworker/0:4 D ffff8802a265ba38 13344 1468 2 0x00000000
> > Workqueue: kacpid acpi_os_execute_deferred
> > ffff8802a265ba38 ffff8802a265ba00 ffffffff81130200 ffffffff81e0d580
> > ffff88029e5eb340 ffff8802a265c000 ffff88029d69d000 ffff88029e5eb340
> > ffffffff818c1b8d ffff8802b64e8758 ffff8802a265ba50 ffffffff818bdfcc
> > Call Trace:
> > [<ffffffff81130200>] ? test_callback+0x10/0x30 [<ffffffff818c1b8d>]
> > ? __down_timeout+0x5d/0xd0 [<ffffffff818bdfcc>] schedule+0x3c/0x90
> > [<ffffffff818c2d60>] schedule_timeout+0x210/0x360
> > [<ffffffff8103fc89>] ? sched_clock+0x9/0x10 [<ffffffff810ee51c>] ?
> > local_clock+0x1c/0x20 [<ffffffff81110c16>] ?
> > mark_held_locks+0x76/0xa0 [<ffffffff818c3cfc>] ?
> > _raw_spin_unlock_irq+0x2c/0x40 [<ffffffff818c1b8d>] ?
> > __down_timeout+0x5d/0xd0 [<ffffffff81110d35>] ?
> > trace_hardirqs_on_caller+0xf5/0x1b0
> > [<ffffffff818c1b8d>] ? __down_timeout+0x5d/0xd0 [<ffffffff818c1bac>]
> > __down_timeout+0x7c/0xd0 [<ffffffff818c44b2>] ?
> > _raw_spin_lock_irqsave+0x82/0x90 [<ffffffff8110b87c>]
> > down_timeout+0x4c/0x60 [<ffffffff814e3a9c>]
> > acpi_os_wait_semaphore+0xaa/0x16a [<ffffffff81510f37>]
> > acpi_ex_system_wait_mutex+0x81/0xfa
> > [<ffffffff814f8796>] acpi_ds_begin_method_execution+0x25a/0x373
> > [<ffffffff814f8cea>] acpi_ds_call_control_method+0x107/0x2e0
> > [<ffffffff8151ed60>] acpi_ps_parse_aml+0x177/0x495
> > [<ffffffff8151fa46>] acpi_ps_execute_method+0x1f7/0x2b9
> > [<ffffffff81516c9a>] acpi_ns_evaluate+0x2ee/0x435
> > [<ffffffff814ff84a>] acpi_ev_asynch_execute_gpe_method+0xbd/0x159
> > [<ffffffff814e2a69>] acpi_os_execute_deferred+0x17/0x23
> > [<ffffffff810d1fc2>] process_one_work+0x242/0x700
> > [<ffffffff810d1f3a>] ? process_one_work+0x1ba/0x700
> > [<ffffffff810d24ce>] worker_thread+0x4e/0x490 [<ffffffff810d2480>] ?
> > process_one_work+0x700/0x700 [<ffffffff810d2480>] ?
> > process_one_work+0x700/0x700 [<ffffffff810d98b1>] kthread+0x101/0x120
> > [<ffffffff81110d35>] ? trace_hardirqs_on_caller+0xf5/0x1b0
> > [<ffffffff818c4832>] ret_from_fork+0x22/0x50 [<ffffffff810d97b0>] ?
> > kthread_create_on_node+0x250/0x250
> > 2 locks held by kworker/0:4/1468:
> > #0: ("kacpid"){.+.+.+}, at: [<ffffffff810d1f3a>]
> > process_one_work+0x1ba/0x700
> > #1: ((&dpc->work)){+.+.+.}, at: [<ffffffff810d1f3a>]
> > process_one_work+0x1ba/0x700
> >
> > The issue appears to be that the kworker thread attempts to acquire
> > the
> > _E42 method's mutex twice when executing acpi_ps_execute_method() and
> > recursing through the entry method.
> >
> > The current code does take the possiblity of this recursion into
> > account, however, it is only for the case where the walk_state has been
> populated.
> >
> > This can be fixed by setting the thread id in the !walk_state case to
> > allow for recursion.
> >
> > Cc: Robert Moore <robert.moore(a)intel.com>
> > Cc: Lv Zheng <lv.zheng(a)intel.com>
> > Cc: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
> > Cc: Len Brown <lenb(a)kernel.org>
> > Cc: linux-acpi(a)vger.kernel.org
> > Cc: devel(a)acpica.org
> > Signed-off-by: Prarit Bhargava <prarit(a)redhat.com>
> > ---
> > drivers/acpi/acpica/dsmethod.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/acpi/acpica/dsmethod.c
> > b/drivers/acpi/acpica/dsmethod.c index 1982310..93799db 100644
> > --- a/drivers/acpi/acpica/dsmethod.c
> > +++ b/drivers/acpi/acpica/dsmethod.c
> > @@ -428,6 +428,9 @@ acpi_ds_begin_method_execution(struct
> acpi_namespace_node *method_node,
> > obj_desc->method.mutex->mutex.
> > original_sync_level =
> > obj_desc->method.mutex->mutex.sync_level;
> > +
> > + obj_desc->method.mutex->mutex.thread_id =
> > + acpi_os_get_thread_id();
> > }
> > }
> >
> > --
> > 1.7.9.3
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > in the body of a message to majordomo(a)vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
5 years