[rafael-pm:bleeding-edge] BUILD SUCCESS 8158a90cbe6c549c0b816ac2d747b787f2bec5ef
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 8158a90cbe6c549c0b816ac2d747b787f2bec5ef Merge branch 'thermal-core' into linux-next
elapsed time: 728m
configs tested: 53
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
9 months, 1 week
[rafael-pm:bleeding-edge] BUILD SUCCESS 61ac432725e851b95d0e7e253816c2237c3f0295
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 61ac432725e851b95d0e7e253816c2237c3f0295 Merge branch 'thermal-core' into bleeding-edge
elapsed time: 746m
configs tested: 53
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
9 months, 1 week
[rafael-pm:bleeding-edge] BUILD SUCCESS c00ddaa2e79ed178db8f6c06a77ddc41adc06d9e
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: c00ddaa2e79ed178db8f6c06a77ddc41adc06d9e Merge branch 'thermal-int340x' into bleeding-edge
elapsed time: 924m
configs tested: 95
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211105
m68k hp300_defconfig
arm qcom_defconfig
ia64 tiger_defconfig
s390 allmodconfig
arm versatile_defconfig
mips lemote2f_defconfig
powerpc walnut_defconfig
riscv allyesconfig
sh se7712_defconfig
powerpc asp8347_defconfig
arm mmp2_defconfig
sh sh7770_generic_defconfig
arm oxnas_v6_defconfig
sh sh7757lcr_defconfig
arm vt8500_v6_v7_defconfig
sh r7785rp_defconfig
arm cerfcube_defconfig
mips maltasmvp_defconfig
arm randconfig-c002-20211105
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a012-20211105
x86_64 randconfig-a016-20211105
x86_64 randconfig-a015-20211105
x86_64 randconfig-a013-20211105
x86_64 randconfig-a011-20211105
x86_64 randconfig-a014-20211105
i386 randconfig-a016-20211105
i386 randconfig-a014-20211105
i386 randconfig-a015-20211105
i386 randconfig-a013-20211105
i386 randconfig-a011-20211105
i386 randconfig-a012-20211105
arc randconfig-r043-20211105
riscv randconfig-r042-20211105
s390 randconfig-r044-20211105
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20211105
i386 randconfig-a005-20211105
i386 randconfig-a001-20211105
i386 randconfig-a003-20211105
i386 randconfig-a004-20211105
i386 randconfig-a006-20211105
i386 randconfig-a002-20211105
hexagon randconfig-r041-20211105
hexagon randconfig-r045-20211105
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
9 months, 1 week
[rafael-pm:bleeding-edge] BUILD SUCCESS c983c327442e1d67cccb9e2c73589d7cafd2514c
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: c983c327442e1d67cccb9e2c73589d7cafd2514c Merge branch 'acpi-video' into bleeding-edge
elapsed time: 1154m
configs tested: 118
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211103
mips loongson1b_defconfig
powerpc cm5200_defconfig
mips mpc30x_defconfig
powerpc icon_defconfig
sh se7721_defconfig
powerpc mpc837x_rdb_defconfig
nios2 3c120_defconfig
nds32 defconfig
powerpc mpc8540_ads_defconfig
arm neponset_defconfig
powerpc tqm8560_defconfig
arm collie_defconfig
sh rts7751r2d1_defconfig
sh kfr2r09-romimage_defconfig
m68k m5249evb_defconfig
m68k bvme6000_defconfig
sparc sparc32_defconfig
powerpc ps3_defconfig
mips bmips_stb_defconfig
arm mvebu_v7_defconfig
arm dove_defconfig
arm multi_v4t_defconfig
powerpc tqm8540_defconfig
arm randconfig-c002-20211103
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a012-20211103
x86_64 randconfig-a015-20211103
i386 randconfig-a014-20211103
i386 randconfig-a016-20211103
i386 randconfig-a013-20211103
i386 randconfig-a015-20211103
i386 randconfig-a011-20211103
i386 randconfig-a012-20211103
arc randconfig-r043-20211103
riscv randconfig-r042-20211103
s390 randconfig-r044-20211103
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
mips randconfig-c004-20211103
arm randconfig-c002-20211103
i386 randconfig-c001-20211103
s390 randconfig-c005-20211103
powerpc randconfig-c003-20211103
mips randconfig-c004-20211104
i386 randconfig-c001-20211104
arm randconfig-c002-20211104
s390 randconfig-c005-20211104
riscv randconfig-c006-20211104
powerpc randconfig-c003-20211104
x86_64 randconfig-c007-20211104
i386 randconfig-a005-20211103
i386 randconfig-a003-20211103
i386 randconfig-a001-20211103
i386 randconfig-a004-20211103
i386 randconfig-a006-20211103
i386 randconfig-a002-20211103
x86_64 randconfig-a012-20211104
x86_64 randconfig-a016-20211104
x86_64 randconfig-a015-20211104
x86_64 randconfig-a013-20211104
x86_64 randconfig-a011-20211104
x86_64 randconfig-a014-20211104
x86_64 randconfig-a006-20211103
x86_64 randconfig-a004-20211103
x86_64 randconfig-a001-20211103
x86_64 randconfig-a002-20211103
x86_64 randconfig-a005-20211103
x86_64 randconfig-a003-20211103
hexagon randconfig-r041-20211103
hexagon randconfig-r045-20211103
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
9 months, 1 week
Re: [PATCH] ACPI: Add AEST in ACPI Table Definitions
by Rafael J. Wysocki
On Thu, Nov 4, 2021 at 8:14 AM ishii.shuuichir(a)fujitsu.com
<ishii.shuuichir(a)fujitsu.com> wrote:
>
> ping?
>
> P.S.
> We should have added the maintainer of ACPI FOR ARM64 (ACPI/arm64) first,
> but since AEST is an arm-spec ACPI table, added the concerned persons
> as new e-mail addresses.
Please resend the patch, then, with all of the requisite addresses
present in the CC list.
> > -----Original Message-----
> > From: Shuuichirou Ishii <ishii.shuuichir(a)fujitsu.com>
> > Sent: Tuesday, October 26, 2021 4:53 PM
> > To: rjw(a)rjwysocki.net; lenb(a)kernel.org; linux-acpi(a)vger.kernel.org;
> > linux-kernel(a)vger.kernel.org; robert.moore(a)intel.com; erik.kaneda(a)intel.com;
> > rafael.j.wysocki(a)intel.com; devel(a)acpica.org
> > Cc: Ishii, Shuuichirou/石井 周一郎 <ishii.shuuichir(a)fujitsu.com>
> > Subject: [PATCH] ACPI: Add AEST in ACPI Table Definitions
> >
> > When We added AEST using the Upgrading ACPI tables via initrd function, the
> > kernel could not recognize the AEST, so We added AEST the ACPI table definition.
> >
> > Signed-off-by: Shuuichirou Ishii <ishii.shuuichir(a)fujitsu.com>
> > ---
> > drivers/acpi/tables.c | 2 +-
> > include/acpi/actbl2.h | 1 +
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index
> > f9383736fa0f..ab0fb4c33e07 100644
> > --- a/drivers/acpi/tables.c
> > +++ b/drivers/acpi/tables.c
> > @@ -499,7 +499,7 @@ static const char table_sigs[][ACPI_NAMESEG_SIZE]
> > __initconst = {
> > ACPI_SIG_WDDT, ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT,
> > ACPI_SIG_PSDT, ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT,
> > ACPI_SIG_IORT, ACPI_SIG_NFIT, ACPI_SIG_HMAT, ACPI_SIG_PPTT,
> > - ACPI_SIG_NHLT };
> > + ACPI_SIG_NHLT, ACPI_SIG_AEST };
> >
> > #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
> >
> > diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index
> > a47b32a5cbde..b586e40d4b86 100644
> > --- a/include/acpi/actbl2.h
> > +++ b/include/acpi/actbl2.h
> > @@ -48,6 +48,7 @@
> > #define ACPI_SIG_SDEV "SDEV" /* Secure Devices table */
> > #define ACPI_SIG_NHLT "NHLT" /* Non-HDAudio Link Table
> > */
> > #define ACPI_SIG_SVKL "SVKL" /* Storage Volume Key
> > Location Table */
> > +#define ACPI_SIG_AEST "AEST" /* Arm Error Source Table */
> >
> > /*
> > * All tables must be byte-packed to match the ACPI specification, since
> > --
> > 2.27.0
>
9 months, 1 week
Re: [PATCH v2] Revert "ACPI: Add memory semantics to acpi_os_map_memory()"
by Lorenzo Pieralisi
On Tue, Sep 28, 2021 at 07:26:52PM +0200, Rafael J. Wysocki wrote:
> On 9/24/2021 11:04 AM, Lorenzo Pieralisi wrote:
> > On Thu, Sep 23, 2021 at 02:54:52PM +0200, Rafael J. Wysocki wrote:
> > > On Thu, Sep 23, 2021 at 2:26 PM Mark Kettenis <mark.kettenis(a)xs4all.nl> wrote:
> > > > > From: "Rafael J. Wysocki" <rafael(a)kernel.org>
> > > > > Date: Thu, 23 Sep 2021 13:05:05 +0200
> > > > >
> > > > > On Thu, Sep 23, 2021 at 11:40 AM Lorenzo Pieralisi
> > > > > <lorenzo.pieralisi(a)arm.com> wrote:
> > > > > > On Thu, Sep 23, 2021 at 01:09:58AM +0200, Mark Kettenis wrote:
> > > > > > > > Date: Wed, 22 Sep 2021 17:33:36 +0100
> > > > > > > > From: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
> > > > > > > >
> > > > > > > > On Fri, Sep 10, 2021 at 10:32:23PM +0800, Jia He wrote:
> > > > > > > > > This reverts commit 437b38c51162f8b87beb28a833c4d5dc85fa864e.
> > > > > > > > >
> > > > > > > > > After this commit, a boot panic is alway hit on an Ampere EMAG server
> > > > > > > > > with call trace as follows:
> > > > > > > > > Internal error: synchronous external abort: 96000410 [#1] SMP
> > > > > > > > > Modules linked in:
> > > > > > > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+ #462
> > > > > > > > > Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 0.14 02/22/2019
> > > > > > > > > pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > > > > > [...snip...]
> > > > > > > > > Call trace:
> > > > > > > > > acpi_ex_system_memory_space_handler+0x26c/0x2c8
> > > > > > > > > acpi_ev_address_space_dispatch+0x228/0x2c4
> > > > > > > > > acpi_ex_access_region+0x114/0x268
> > > > > > > > > acpi_ex_field_datum_io+0x128/0x1b8
> > > > > > > > > acpi_ex_extract_from_field+0x14c/0x2ac
> > > > > > > > > acpi_ex_read_data_from_field+0x190/0x1b8
> > > > > > > > > acpi_ex_resolve_node_to_value+0x1ec/0x288
> > > > > > > > > acpi_ex_resolve_to_value+0x250/0x274
> > > > > > > > > acpi_ds_evaluate_name_path+0xac/0x124
> > > > > > > > > acpi_ds_exec_end_op+0x90/0x410
> > > > > > > > > acpi_ps_parse_loop+0x4ac/0x5d8
> > > > > > > > > acpi_ps_parse_aml+0xe0/0x2c8
> > > > > > > > > acpi_ps_execute_method+0x19c/0x1ac
> > > > > > > > > acpi_ns_evaluate+0x1f8/0x26c
> > > > > > > > > acpi_ns_init_one_device+0x104/0x140
> > > > > > > > > acpi_ns_walk_namespace+0x158/0x1d0
> > > > > > > > > acpi_ns_initialize_devices+0x194/0x218
> > > > > > > > > acpi_initialize_objects+0x48/0x50
> > > > > > > > > acpi_init+0xe0/0x498
> > > > > > > > >
> > > > > > > > > As mentioned by Lorenzo:
> > > > > > > > > "We are forcing memory semantics mappings to PROT_NORMAL_NC, which
> > > > > > > > > eMAG does not like at all and I'd need to understand why. It looks
> > > > > > > > > like the issue happen in SystemMemory Opregion handler."
> > > > > > > > >
> > > > > > > > > Hence just revert it before everything is clear.
> > > > > > > > >
> > > > > > > > > Fixes: 437b38c51162 ("ACPI: Add memory semantics to acpi_os_map_memory()")
> > > > > > > > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
> > > > > > > > > Cc: Ard Biesheuvel <ardb(a)kernel.org>
> > > > > > > > > Cc: Hanjun Guo <guohanjun(a)huawei.com>
> > > > > > > > > Cc: Catalin Marinas <catalin.marinas(a)arm.com>
> > > > > > > > > Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
> > > > > > > > > Cc: Harb Abdulhamid <harb(a)amperecomputing.com>
> > > > > > > > >
> > > > > > > > > Signed-off-by: Jia He <justin.he(a)arm.com>
> > > > > > > > Rewrote the commit log, please take the patch below and repost
> > > > > > > > it as a v3.
> > > > > > > >
> > > > > > > > It would still be great if Ampere can help us understand why
> > > > > > > > the NormalNC attributes trigger a sync abort on the opregion
> > > > > > > > before merging it.
> > > > > > > To be honest, I don't think you really need an explanation from Ampere
> > > > > > > here. Mapping a part of the address space that doesn't provide memory
> > > > > > > semantics with NormalNC attributes is wrong and triggering a sync
> > > > > > > abort in that case is way better than silently ignoring the access.
> > > > > > That's understood and that's what I explained in the revert commit
> > > > > > log, no question about it.
> > > > > >
> > > > > > I was just asking to confirm if that's what's actually happening.
> > > > > >
> > > > > > > Putting my OpenBSD hat on (where we have our own ACPI OSPM
> > > > > > > implementation) I must say that we always interpreted SystemMemory as
> > > > > > > memory mapped IO and I think that is a logical choice as SystemIO is
> > > > > > > used for (non-memory mapped) IO. And I'd say that the ACPI OSPM code
> > > > > > > should make sure that it uses properly aligned access to any Field
> > > > > > > object that doesn't use AnyAcc as its access type. Even on x86! And
> > > > > > > I'd say that AML that uses AnyAcc fields for SystemMemory OpRegions on
> > > > > > > arm64 is buggy.
> > > > > > >
> > > > > > > But maybe relaxing this when the EFI memory map indicates that the
> > > > > > > address space in question does provide memory semantics does make
> > > > > > > sense. That should defenitely be documented in the ACPI standard
> > > > > > > though.
> > > > > > Mapping SystemMemory Opregions as "memory" does not make sense
> > > > > > at all to me. Still, that's what Linux ACPICA code does (*if*
> > > > > > that's what acpi_os_map_memory() is supposed to mean).
> > > > > >
> > > > > > https://lore.kernel.org/linux-acpi/[email protected]
> > > > > It doesn't need to do that, though, if there are good enough arguments
> > > > > to change the current behavior (and the argument here is that it may
> > > > > be an MMIO region, so mapping it as memory doesn't really work, but it
> > > > > also may be a region in memory - there is no rule in the spec by which
> > > > > SystemMemory Opregions cannot be "memory" AFAICS) and if that change
> > > > > doesn't introduce regressions in the installed base.
> > > > >
> > > > > > Where do we go from here, to be defined, we still have a bug
> > > > > > to fix after the revert is applied.
> > > > > >
> > > > > > drivers/acpi/sysfs.c
> > > > > >
> > > > > > maps BERT error regions with acpi_os_map_memory().
> > > > > That mechanism is basically used for exporting ACPI tables to user
> > > > > space and they are known to reside in memory. Whether or not BERT
> > > > > regions should be mapped in the same way is a good question.
> > > > It is not inconceivable that BERT regions actually live in memory of
> > > > the BMC that is exposed over a bus that doesn't implement memory
> > > > semantics is it?
> > > No, it isn't, which is why I think that mapping them as RAM may not be
> > > a good idea in general.
> > Should I patch acpi_data_show() to map BERT error regions (well, that's
> > what acpi_data_show() is used on at the moment) as MMIO and use the
> > related memcpy routine to read them then :) ?
>
> It actually would be good to clean it up so it is clear that this is
> only used for BERT.
I could, I wonder what's best to do that though.
Maybe making acpi_table_data_init() acpi_table_bert_data_init() and
remove the infrastructure built on top of acpi_data_obj ?
I wonder whether adding a bin_attribute.read() pointer in the
acpi_data_obj struct (that would make it table specific) would be the
most elegant solution (even though the whole infrastructure has been
used only for BERT for quite a while).
Lorenzo
9 months, 2 weeks