------------[ cut here ]------------ WARNING: CPU: 23 PID: 1 at drivers/pnp/pnpacpi/core.c:76 pnpacpi_set_resources+0x9a/0x134() Modules linked in: CPU: 23 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc7 #1 0000000000000000 ffff8808541cfc78 ffffffff814faf17 0000000000000000 ffff8808541cfcb0 ffffffff8105f239 ffffffff81302597 0000000000000000 ffff881052c80000 ffff88105ec1ae60 0000000000000000 ffff8808541cfcc0 Call Trace: [<ffffffff814faf17>] dump_stack+0x45/0x56 [<ffffffff8105f239>] warn_slowpath_common+0x7f/0x98 [<ffffffff81302597>] ? pnpacpi_set_resources+0x9a/0x134 [<ffffffff8105f300>] warn_slowpath_null+0x1a/0x1c [<ffffffff81302597>] pnpacpi_set_resources+0x9a/0x134 [<ffffffff813003ac>] pnp_start_dev+0x3d/0x76 [<ffffffff813009e5>] pnp_activate_dev+0x29/0x44 [<ffffffff812ff54e>] pnp_device_probe+0x47/0xa6 [<ffffffff81342f2f>] driver_probe_device+0x120/0x2f3 [<ffffffff8134319c>] __driver_attach+0x5d/0x7f [<ffffffff8134313f>] ? __device_attach+0x3d/0x3d [<ffffffff813413b0>] bus_for_each_dev+0x7b/0x85 [<ffffffff81342996>] driver_attach+0x1e/0x20 [<ffffffff8134260e>] bus_add_driver+0x12f/0x1f9 [<ffffffff813437a4>] driver_register+0x8e/0xca [<ffffffff812ff3e1>] pnp_register_driver+0x21/0x23 [<ffffffff81325d3d>] serial8250_pnp_init+0x15/0x17 [<ffffffff81b45773>] serial8250_init+0x60/0x143 [<ffffffff81b45713>] ? serial8250_console_init+0x19/0x19 [<ffffffff8100032d>] do_one_initcall+0xff/0x186 [<ffffffff81077ef1>] ? parse_args+0x280/0x373 [<ffffffff81b07fb0>] kernel_init_freeable+0x16f/0x1f4 [<ffffffff81b07719>] ? do_early_param+0x88/0x88 [<ffffffff814efbc5>] ? rest_init+0x79/0x79 [<ffffffff814efbd3>] kernel_init+0xe/0xdf [<ffffffff815004ec>] ret_from_fork+0x7c/0xb0 [<ffffffff814efbc5>] ? rest_init+0x79/0x79 ---[ end trace d664270ecffb7f3d ]--- This warning first appears in 3.14-rc1. This warning does not appear with 3.13.0.
The warning is introduced with this merge commit. commit 25d412d932fb3289ae5b510845d523330b80bb71 Merge: 98feb7c c713cd7 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Sun Jan 12 23:45:04 2014 +0100 Merge branch 'acpi-hotplug' * acpi-hotplug: ACPI / scan: ACPI device object sysfs attribute for _STA evaluation ACPI / hotplug / driver core: Handle containers in a special way ACPI / hotplug: Add demand_offline hotplug profile flag ACPI / bind: Move acpi_get_child() to drivers/ide/ide-acpi.c ACPI / bind: Pass struct acpi_device pointer to acpi_bind_one() ACPI / bind: Rework struct acpi_bus_type ACPI / bind: Redefine acpi_preset_companion() ACPI / bind: Redefine acpi_get_child() PCI / ACPI: Use acpi_find_child_device() for child devices lookup ACPI / bind: Simplify child device lookups ACPI / scan: Use direct recurrence for device hierarchy walks ACPI: Introduce acpi_set_device_status() ACPI / hotplug: Drop unfinished global notification handling routines ACPI / hotplug: Rework generic code to handle suprise removals ACPI / hotplug: Move container-specific code out of the core ACPI / hotplug: Make ACPI PCI root hotplug use common hotplug code ACPI / hotplug: Introduce common hotplug function acpi_device_hotplug() ACPI / hotplug: Do not fail bus and device checks for disabled hotplug ACPI / scan: Add acpi_device objects for all device nodes in the namespace ACPI / scan: Define non-empty device removal handler
Can you please check if you see this problem in 3.16-rc7?
The stack trace from comment #0 is from 3.16.0-rc7.
I bisected the warning to this commit. commit 202317a573b20d77a9abb7c16a3fd5b40cef3d9d Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Fri Nov 22 21:54:37 2013 +0100 ACPI / scan: Add acpi_device objects for all device nodes in the namespace Modify the ACPI namespace scanning code to register a struct acpi_device object for every namespace node representing a device, processor and so on, even if the device represented by that namespace node is reported to be not present and not functional by _STA. There are multiple reasons to do that. First of all, it avoids quite a lot of overhead when struct acpi_device objects are deleted every time acpi_bus_trim() is run and then added again by a subsequent acpi_bus_scan() for the same scope, although the namespace objects they correspond to stay in memory all the time (which always is the case on a vast majority of systems). Second, it will allow user space to see that there are namespace nodes representing devices that are not present at the moment and may be added to the system. It will also allow user space to evaluate _SUN for those nodes to check what physical slots the "missing" devices may be put into and it will make sense to add a sysfs attribute for _STA evaluation after this change (that will be useful for thermal management on some systems). Next, it will help to consolidate the ACPI hotplug handling among subsystems by making it possible to store hotplug-related information in struct acpi_device objects in a standard common way. Finally, it will help to avoid a race condition related to the deletion of ACPI namespace nodes. Namely, namespace nodes may be deleted as a result of a table unload triggered by _EJ0 or _DCK. If a hotplug notification for one of those nodes is triggered right before the deletion and it executes a hotplug callback via acpi_hotplug_execute(), the ACPI handle passed to that callback may be stale when the callback actually runs. One way to work around that is to always pass struct acpi_device pointers to hotplug callbacks after doing a get_device() on the objects in question which eliminates the use-after-free possibility (the ACPI handles in those objects are invalidated by acpi_scan_drop_device(), so they will trigger ACPICA errors on attempts to use them). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Patch: https://patchwork.kernel.org/patch/4643591/
It does not appear that the patch referenced in comment #5 is upstream. About the time this patch was proposed, another patch that removes acpi_pnp_match() went upstream. So it isn't immediately clear if this issue has been fixed upstream or not.
The problem is not present in the mainline kernel any more, because we changed the way PNP devices are enumerated altogether. We use an ACPI scan handler for that now and the code in question is not there any more.
Commit f1b1dc845cb1418b2b0de35491b0da87498ea6a8 (ACPI / PNP: do ACPI binding directly) is the one eliminating the issue along with the code in which it was present.