[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <01000167adac3130-02698b6b-48d9-4496-9ce5-ee5316f5f82c-000000@email.amazonses.com>
Date: Fri, 14 Dec 2018 17:03:22 +0000
From: Jeremy Cline <jeremy@...ine.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org
Cc: stable@...r.kernel.org, Jean-Marc Lenoir <archlinux@...emel.com>,
Erik Schmauss <erik.schmauss@...el.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Jean Delvare <jdelvare@...e.de>,
Michael J Gruber <mjg@...oraproject.org>
Subject: Re: [PATCH 4.19 061/110] ACPICA: AML interpreter: add region
addresses in global list during initialization
Hi folks,
On 11/29/18 9:12 AM, Greg Kroah-Hartman wrote:
> 4.19-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Erik Schmauss <erik.schmauss@...el.com>
>
> commit 4abb951b73ff0a8a979113ef185651aa3c8da19b upstream.
>
> The table load process omitted adding the operation region address
> range to the global list. This omission is problematic because the OS
> queries the global list to check for address range conflicts before
> deciding which drivers to load. This commit may result in warning
> messages that look like the following:
>
> [ 7.871761] ACPI Warning: system_IO range 0x00000428-0x0000042F conflicts with op_region 0x00000400-0x0000047F (\PMIO) (20180531/utaddress-213)
> [ 7.871769] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
>
> However, these messages do not signify regressions. It is a result of
> properly adding address ranges within the global address list>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011
> Tested-by: Jean-Marc Lenoir <archlinux@...emel.com>
> Signed-off-by: Erik Schmauss <erik.schmauss@...el.com>
> Cc: All applicable <stable@...r.kernel.org>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> Cc: Jean Delvare <jdelvare@...e.de>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>
> ---
> drivers/acpi/acpica/dsopcode.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> --- a/drivers/acpi/acpica/dsopcode.c
> +++ b/drivers/acpi/acpica/dsopcode.c
> @@ -417,6 +417,10 @@ acpi_ds_eval_region_operands(struct acpi
> ACPI_FORMAT_UINT64(obj_desc->region.address),
> obj_desc->region.length));
>
> + status = acpi_ut_add_address_range(obj_desc->region.space_id,
> + obj_desc->region.address,
> + obj_desc->region.length, node);
> +
> /* Now the address and length are valid for this opregion */
>
> obj_desc->region.flags |= AOPOBJ_DATA_VALID;
>
>
Fedora has received a couple of reports[0] of boot failures on v4.19
kernels:
kernel: BUG: unable to handle kernel paging request at 00000036000000b6
kernel: PGD 0 P4D 0
kernel: Oops: 0000 [#1] SMP NOPTI
kernel: CPU: 0 PID: 108 Comm: kworker/0:3 Not tainted
4.19.8-300.fc29.x86_64 #1
kernel: Hardware name: Hewlett-Packard HP Compaq 6715b/30C2, BIOS 68YTT
Ver. F.07 07/16/2007
kernel: Workqueue: events work_for_cpu_fn
kernel: RIP: 0010:acpi_ns_build_normalized_path+0x76/0x108
kernel: Code: 31 c0 48 85 ff 74 de 31 d2 49 89 f8 31 c0 4c 39 05 ff 5b
57 01 74 61 4c 39 c7 74 0e 39 c2 76 08 41 89 c1 42 c6 04 0e 2e ff c0
<45> 8b 48 0c 41 89 ca 44 89 4c 24 04 45 31 c9 46 8a 5c 0c 07 45 84
kernel: RSP: 0018:ffffb68740a1fce0 EFLAGS: 00010207
kernel: RAX: 000000000000000a RBX: 0000000000000001 RCX: 0000000000000001
kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9dd2360e7168
kernel: RBP: 0000000000000000 R08: 00000036000000aa R09: fffffffffffffffc
kernel: R10: 0000000000000000 R11: 00000000000000d2 R12: 0000000000008200
kernel: R13: ffff9dd2360e7168 R14: ffff9dd2706980c0 R15: 0000000000000001
kernel: FS: 0000000000000000(0000) GS:ffff9dd275c00000(0000)
knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 00000036000000b6 CR3: 000000007137e000 CR4: 00000000000006f0
kernel: Call Trace:
kernel: acpi_ns_get_normalized_pathname+0x1f/0x6d
kernel: acpi_ut_check_address_range+0x8f/0x118
kernel: acpi_check_address_range+0x40/0x59
kernel: acpi_check_resource_conflict+0x3a/0x50
kernel: acpi_check_region+0x61/0x80
kernel: piix4_probe+0x144/0x658 [i2c_piix4]
kernel: local_pci_probe+0x41/0x90
kernel: work_for_cpu_fn+0x16/0x20
kernel: process_one_work+0x1a1/0x3a0
kernel: worker_thread+0x30/0x380
kernel: ? pwq_unbound_release_workfn+0xd0/0xd0
kernel: kthread+0x112/0x130
kernel: ? kthread_create_worker_on_cpu+0x70/0x70
kernel: ret_from_fork+0x35/0x40
kernel: Modules linked in: i2c_piix4(+) parport_pc wmi tpm_infineon
parport ssb hp_accel lis3lv02d mmc_core input_polldev video radeon
i2c_algo_bit drm_kms_helper ttm drm firewire_ohci firewire_core
ata_generic serio_raw pata_acpi yenta_socket crc_itu_t pata_atiixp
kernel: CR2: 00000036000000b6
kernel: ---[ end trace 9c88eedaaeca7db0 ]---
I reverted this patch on v4.19.8 and at least one user (Michael, Cc'd)
reported that fixed the regression.
This patch appears to have been included in v4.19.2 (commit
22083c028d0b), reverted in v4.19.3 (commit 8ef305fbc50d), and finally
included again here in v4.19.6 (commit 87403e35bc56). I couldn't find
a discussion about bringing it back, so maybe it happened accidentally?
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1659225
Thanks,
Jeremy
Powered by blists - more mailing lists