| Message ID | cc03ba18-4949-9244-639c-94f461f03361@huawei.com (mailing list archive) |
|---|---|
| State | Mainlined, archived |
| Headers | show |
| Series | [v2] ACPI: sysfs: Change ACPI_MASKABLE_GPE_MAX to 0x100 | expand |
On Thu, Nov 14, 2019 at 8:16 AM Yunfeng Ye <yeyunfeng@huawei.com> wrote: > > The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel > parameter cover all GPEs") says: > "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256 > GPEs can be masked" > > But the masking of GPE 0xFF it not supported and the check condition > "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is > u8. > > So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe > > ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for > acpi_mask_gpe parameter. > > Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") > Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> Applying as 5.5 material, thanks! > --- > v1 -> v2: > - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check > - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter > - update the commit comment > > Documentation/admin-guide/kernel-parameters.txt | 2 +- > drivers/acpi/sysfs.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index a84a83f8881e..87e27186dc69 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -113,7 +113,7 @@ > the GPE dispatcher. > This facility can be used to prevent such uncontrolled > GPE floodings. > - Format: <int> > + Format: <byte> > > acpi_no_auto_serialize [HW,ACPI] > Disable auto-serialization of AML methods > diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c > index 75948a3f1a20..0a83ce186bc4 100644 > --- a/drivers/acpi/sysfs.c > +++ b/drivers/acpi/sysfs.c > @@ -819,14 +819,14 @@ static ssize_t counter_set(struct kobject *kobj, > * interface: > * echo unmask > /sys/firmware/acpi/interrupts/gpe00 > */ > -#define ACPI_MASKABLE_GPE_MAX 0xFF > +#define ACPI_MASKABLE_GPE_MAX 0x100 > static DECLARE_BITMAP(acpi_masked_gpes_map, ACPI_MASKABLE_GPE_MAX) __initdata; > > static int __init acpi_gpe_set_masked_gpes(char *val) > { > u8 gpe; > > - if (kstrtou8(val, 0, &gpe) || gpe > ACPI_MASKABLE_GPE_MAX) > + if (kstrtou8(val, 0, &gpe)) > return -EINVAL; > set_bit(gpe, acpi_masked_gpes_map); > > -- > 2.7.4 >
On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <yeyunfeng@huawei.com> wrote: > > The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel > parameter cover all GPEs") says: > "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256 > GPEs can be masked" > > But the masking of GPE 0xFF it not supported and the check condition > "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is > u8. > > So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe > > ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for > acpi_mask_gpe parameter. > > Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") > Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> > --- > v1 -> v2: > - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check > - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter > - update the commit comment > > Documentation/admin-guide/kernel-parameters.txt | 2 +- > drivers/acpi/sysfs.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) Bisect flags commit eb09878e1301 "ACPI: sysfs: Change ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot regression in my qemu-kvm test environment. It spews: [ 1.456728] ACPI: Masking GPE 0x0. ... [ 161.721420] ACPI: Masking GPE 0x0. ...and then hangs. A straight revert gets the configuration back on its feet. qemu-system-x86_64 --version QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8)
On Sat, Nov 16, 2019 at 9:06 PM Dan Williams <dan.j.williams@intel.com> wrote: > > On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <yeyunfeng@huawei.com> wrote: > > > > The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel > > parameter cover all GPEs") says: > > "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256 > > GPEs can be masked" > > > > But the masking of GPE 0xFF it not supported and the check condition > > "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is > > u8. > > > > So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe > > > ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for > > acpi_mask_gpe parameter. > > > > Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") > > Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> > > --- > > v1 -> v2: > > - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check > > - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter > > - update the commit comment > > > > Documentation/admin-guide/kernel-parameters.txt | 2 +- > > drivers/acpi/sysfs.c | 4 ++-- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > Bisect flags commit eb09878e1301 "ACPI: sysfs: Change > ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot > regression in my qemu-kvm test environment. It spews: > > [ 1.456728] ACPI: Masking GPE 0x0. > ... > [ 161.721420] ACPI: Masking GPE 0x0. > > ...and then hangs. > > A straight revert gets the configuration back on its feet. > > qemu-system-x86_64 --version > QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8) OK, I'll drop it then, thanks!
On Mon, Nov 18, 2019 at 1:04 AM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Sat, Nov 16, 2019 at 9:06 PM Dan Williams <dan.j.williams@intel.com> wrote: > > > > On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <yeyunfeng@huawei.com> wrote: > > > > > > The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel > > > parameter cover all GPEs") says: > > > "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256 > > > GPEs can be masked" > > > > > > But the masking of GPE 0xFF it not supported and the check condition > > > "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is > > > u8. > > > > > > So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe > > > > ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for > > > acpi_mask_gpe parameter. > > > > > > Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") > > > Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> > > > --- > > > v1 -> v2: > > > - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check > > > - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter > > > - update the commit comment > > > > > > Documentation/admin-guide/kernel-parameters.txt | 2 +- > > > drivers/acpi/sysfs.c | 4 ++-- > > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > Bisect flags commit eb09878e1301 "ACPI: sysfs: Change > > ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot > > regression in my qemu-kvm test environment. It spews: > > > > [ 1.456728] ACPI: Masking GPE 0x0. > > ... > > [ 161.721420] ACPI: Masking GPE 0x0. > > > > ...and then hangs. > > > > A straight revert gets the configuration back on its feet. > > > > qemu-system-x86_64 --version > > QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8) > > OK, I'll drop it then, thanks! We're seeing the same issue wtih 5.4.0-rc7-next-20191118 on a Linux VM running on Hyper-V : [ 0.133029] ACPI: 1 ACPI AML tables successfully acquired and loaded [ 0.144023] ACPI: Interpreter enabled [ 0.145023] ACPI: (supports S0 S5) [ 0.146023] ACPI: Using IOAPIC for interrupt routing [ 0.147024] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.148031] ACPI: Masking GPE 0x0. ... [ 774.839023] ACPI: Masking GPE 0x0. [ 774.840023] ACPI: Masking GPE 0x0. I guess the patch is only tested on a physical machine and not on a VM... Thanks, Dexuan
On Mon, Nov 18, 2019 at 8:44 PM Dexuan-Linux Cui <dexuan.linux@gmail.com> wrote: > > On Mon, Nov 18, 2019 at 1:04 AM Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Sat, Nov 16, 2019 at 9:06 PM Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <yeyunfeng@huawei.com> wrote: > > > > > > > > The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel > > > > parameter cover all GPEs") says: > > > > "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256 > > > > GPEs can be masked" > > > > > > > > But the masking of GPE 0xFF it not supported and the check condition > > > > "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is > > > > u8. > > > > > > > > So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe > > > > > ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for > > > > acpi_mask_gpe parameter. > > > > > > > > Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") > > > > Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> > > > > --- > > > > v1 -> v2: > > > > - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check > > > > - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter > > > > - update the commit comment > > > > > > > > Documentation/admin-guide/kernel-parameters.txt | 2 +- > > > > drivers/acpi/sysfs.c | 4 ++-- > > > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > > > Bisect flags commit eb09878e1301 "ACPI: sysfs: Change > > > ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot > > > regression in my qemu-kvm test environment. It spews: > > > > > > [ 1.456728] ACPI: Masking GPE 0x0. > > > ... > > > [ 161.721420] ACPI: Masking GPE 0x0. > > > > > > ...and then hangs. > > > > > > A straight revert gets the configuration back on its feet. > > > > > > qemu-system-x86_64 --version > > > QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8) > > > > OK, I'll drop it then, thanks! > > We're seeing the same issue wtih 5.4.0-rc7-next-20191118 on a Linux VM > running on Hyper-V : > > [ 0.133029] ACPI: 1 ACPI AML tables successfully acquired and loaded > [ 0.144023] ACPI: Interpreter enabled > [ 0.145023] ACPI: (supports S0 S5) > [ 0.146023] ACPI: Using IOAPIC for interrupt routing > [ 0.147024] PCI: Using host bridge windows from ACPI; if necessary, > use "pci=nocrs" and report a bug > [ 0.148031] ACPI: Masking GPE 0x0. > ... > [ 774.839023] ACPI: Masking GPE 0x0. > [ 774.840023] ACPI: Masking GPE 0x0. > > I guess the patch is only tested on a physical machine and not on a VM... It looks like the patch hasn't been tested at all. Please try to change the data type of gpe in acpi_gpe_apply_masked_gpes() to u16 and see if that helps.
On 2019/11/19 5:15, Rafael J. Wysocki wrote: > On Mon, Nov 18, 2019 at 8:44 PM Dexuan-Linux Cui <dexuan.linux@gmail.com> wrote: >> >> On Mon, Nov 18, 2019 at 1:04 AM Rafael J. Wysocki <rafael@kernel.org> wrote: >>> >>> On Sat, Nov 16, 2019 at 9:06 PM Dan Williams <dan.j.williams@intel.com> wrote: >>>> >>>> On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <yeyunfeng@huawei.com> wrote: >>>>> >>>>> The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel >>>>> parameter cover all GPEs") says: >>>>> "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256 >>>>> GPEs can be masked" >>>>> >>>>> But the masking of GPE 0xFF it not supported and the check condition >>>>> "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is >>>>> u8. >>>>> >>>>> So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe > >>>>> ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for >>>>> acpi_mask_gpe parameter. >>>>> >>>>> Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") >>>>> Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> >>>>> --- >>>>> v1 -> v2: >>>>> - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check >>>>> - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter >>>>> - update the commit comment >>>>> >>>>> Documentation/admin-guide/kernel-parameters.txt | 2 +- >>>>> drivers/acpi/sysfs.c | 4 ++-- >>>>> 2 files changed, 3 insertions(+), 3 deletions(-) >>>> >>>> Bisect flags commit eb09878e1301 "ACPI: sysfs: Change >>>> ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot >>>> regression in my qemu-kvm test environment. It spews: >>>> >>>> [ 1.456728] ACPI: Masking GPE 0x0. >>>> ... >>>> [ 161.721420] ACPI: Masking GPE 0x0. >>>> >>>> ...and then hangs. >>>> >>>> A straight revert gets the configuration back on its feet. >>>> >>>> qemu-system-x86_64 --version >>>> QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8) >>> >>> OK, I'll drop it then, thanks! >> >> We're seeing the same issue wtih 5.4.0-rc7-next-20191118 on a Linux VM >> running on Hyper-V : >> >> [ 0.133029] ACPI: 1 ACPI AML tables successfully acquired and loaded >> [ 0.144023] ACPI: Interpreter enabled >> [ 0.145023] ACPI: (supports S0 S5) >> [ 0.146023] ACPI: Using IOAPIC for interrupt routing >> [ 0.147024] PCI: Using host bridge windows from ACPI; if necessary, >> use "pci=nocrs" and report a bug >> [ 0.148031] ACPI: Masking GPE 0x0. >> ... >> [ 774.839023] ACPI: Masking GPE 0x0. >> [ 774.840023] ACPI: Masking GPE 0x0. >> >> I guess the patch is only tested on a physical machine and not on a VM... > > It looks like the patch hasn't been tested at all. > > Please try to change the data type of gpe in > acpi_gpe_apply_masked_gpes() to u16 and see if that helps. > Sorry for this problem, I have no good test after modification according to inspection opinions. The first version patch is ok, the type of gpe is changed to u32. and I have test it before. thanks. > . >
On Tue, Nov 19, 2019 at 3:22 AM Yunfeng Ye <yeyunfeng@huawei.com> wrote: > > > > On 2019/11/19 5:15, Rafael J. Wysocki wrote: > > On Mon, Nov 18, 2019 at 8:44 PM Dexuan-Linux Cui <dexuan.linux@gmail.com> wrote: > >> > >> On Mon, Nov 18, 2019 at 1:04 AM Rafael J. Wysocki <rafael@kernel.org> wrote: > >>> > >>> On Sat, Nov 16, 2019 at 9:06 PM Dan Williams <dan.j.williams@intel.com> wrote: > >>>> > >>>> On Wed, Nov 13, 2019 at 11:17 PM Yunfeng Ye <yeyunfeng@huawei.com> wrote: > >>>>> > >>>>> The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel > >>>>> parameter cover all GPEs") says: > >>>>> "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256 > >>>>> GPEs can be masked" > >>>>> > >>>>> But the masking of GPE 0xFF it not supported and the check condition > >>>>> "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is > >>>>> u8. > >>>>> > >>>>> So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe > > >>>>> ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for > >>>>> acpi_mask_gpe parameter. > >>>>> > >>>>> Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") > >>>>> Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> > >>>>> --- > >>>>> v1 -> v2: > >>>>> - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check > >>>>> - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter > >>>>> - update the commit comment > >>>>> > >>>>> Documentation/admin-guide/kernel-parameters.txt | 2 +- > >>>>> drivers/acpi/sysfs.c | 4 ++-- > >>>>> 2 files changed, 3 insertions(+), 3 deletions(-) > >>>> > >>>> Bisect flags commit eb09878e1301 "ACPI: sysfs: Change > >>>> ACPI_MASKABLE_GPE_MAX to 0x100" in -next as the reason for a boot > >>>> regression in my qemu-kvm test environment. It spews: > >>>> > >>>> [ 1.456728] ACPI: Masking GPE 0x0. > >>>> ... > >>>> [ 161.721420] ACPI: Masking GPE 0x0. > >>>> > >>>> ...and then hangs. > >>>> > >>>> A straight revert gets the configuration back on its feet. > >>>> > >>>> qemu-system-x86_64 --version > >>>> QEMU emulator version 4.0.50 (v4.0.0-928-g49c6c6ac0cd8) > >>> > >>> OK, I'll drop it then, thanks! > >> > >> We're seeing the same issue wtih 5.4.0-rc7-next-20191118 on a Linux VM > >> running on Hyper-V : > >> > >> [ 0.133029] ACPI: 1 ACPI AML tables successfully acquired and loaded > >> [ 0.144023] ACPI: Interpreter enabled > >> [ 0.145023] ACPI: (supports S0 S5) > >> [ 0.146023] ACPI: Using IOAPIC for interrupt routing > >> [ 0.147024] PCI: Using host bridge windows from ACPI; if necessary, > >> use "pci=nocrs" and report a bug > >> [ 0.148031] ACPI: Masking GPE 0x0. > >> ... > >> [ 774.839023] ACPI: Masking GPE 0x0. > >> [ 774.840023] ACPI: Masking GPE 0x0. > >> > >> I guess the patch is only tested on a physical machine and not on a VM... > > > > It looks like the patch hasn't been tested at all. > > > > Please try to change the data type of gpe in > > acpi_gpe_apply_masked_gpes() to u16 and see if that helps. > > > Sorry for this problem, I have no good test after modification according to > inspection opinions. I see. Well, reviewers make mistakes too ... > The first version patch is ok, the type of gpe is changed to u32. and I have > test it before. OK So I have added the u8 -> u16 change for gpe in acpi_gpe_apply_masked_gpes() and applied it again, as that should work AFAICS.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a84a83f8881e..87e27186dc69 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -113,7 +113,7 @@ the GPE dispatcher. This facility can be used to prevent such uncontrolled GPE floodings. - Format: <int> + Format: <byte> acpi_no_auto_serialize [HW,ACPI] Disable auto-serialization of AML methods diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index 75948a3f1a20..0a83ce186bc4 100644 --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -819,14 +819,14 @@ static ssize_t counter_set(struct kobject *kobj, * interface: * echo unmask > /sys/firmware/acpi/interrupts/gpe00 */ -#define ACPI_MASKABLE_GPE_MAX 0xFF +#define ACPI_MASKABLE_GPE_MAX 0x100 static DECLARE_BITMAP(acpi_masked_gpes_map, ACPI_MASKABLE_GPE_MAX) __initdata; static int __init acpi_gpe_set_masked_gpes(char *val) { u8 gpe; - if (kstrtou8(val, 0, &gpe) || gpe > ACPI_MASKABLE_GPE_MAX) + if (kstrtou8(val, 0, &gpe)) return -EINVAL; set_bit(gpe, acpi_masked_gpes_map);
The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") says: "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256 GPEs can be masked" But the masking of GPE 0xFF it not supported and the check condition "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is u8. So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe > ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for acpi_mask_gpe parameter. Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> --- v1 -> v2: - drop the "gpe > ACPI_MASKABLE_GPE_MAX" check - update the docs "Format" from <int> to <byte> for acpi_mask_gpe parameter - update the commit comment Documentation/admin-guide/kernel-parameters.txt | 2 +- drivers/acpi/sysfs.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)