From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: Toshi Kani <toshi.kani@hp.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Subject: Re: [Bug report] Warning when hot-add an ACPI0004 device.
Date: Wed, 25 Sep 2013 18:31:09 +0800 [thread overview]
Message-ID: <5242BB6D.3060504@cn.fujitsu.com> (raw)
In-Reply-To: <1378998712.12538.18.camel@misato.fc.hp.com>
Hi Toshi,
On 09/12/2013 11:11 PM, Toshi Kani wrote:
> On Thu, 2013-09-12 at 13:00 +0800, Tang Chen wrote:
>> Hi Rafael, Toshi,
>>
>> When we hot-add an ACPI0004 device, we got the following warning:
>>
>> acpi ACPI0004:01: Attempt to re-insert
>>
>> The ACPI0004 device is a System Board in Fujitsu server, which has two
>> numa nodes (processors and memory).
>>
>> It seems that we reserved the ACPI_NOTIFY_DEVICE_CHECK event twice in
>> acpi_hotplug_notify_cb().
>>
>>
>> According to bisect, this happens after the following commit:
>>
>> From 68a67f6c78b80525d9b3c6672e7782de95e56a83 Mon Sep 17 00:00:00 2001
>> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
>> Date: Sun, 3 Mar 2013 23:05:55 +0100
>> Subject: [PATCH 1/1] ACPI / container: Use common hotplug code
>>
>> Switch the ACPI container driver to using common device hotplug code
>> introduced previously. This reduces the driver down to a trivial
>> definition and registration of a struct acpi_scan_handler object.
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Acked-by: Toshi Kani <toshi.kani@hp.com>
>> Tested-by: Toshi Kani <toshi.kani@hp.com>
>> ---
>> drivers/acpi/container.c | 146
>> ++++-------------------------------------------
>> 1 file changed, 10 insertions(+), 136 deletions(-)
>>
>>
>> I'm now investigating this problem. If you have any idea about why this
>> happens, please let me know.
>
> With the above change, container devices use the common notify handler,
> which logs the warning message in question when it receives device check
> twice on a same device. Before the change, the container-specific
> notify handler did not log this message in the same case (but considered
> it as an eject request).
>
> So, I suspect that you are getting device check twice regardless of the
> kernel change. Can you check KERN_DEBUG messages to see if that is the
> case? The notify handler logs all events with KERN_DEBUG.
Follow your suggestion, we confirm that it really received ACPI_NOTIFY_
DEVICE_CHECK event*twice*, but the original ACPI container driver only
received once, does the common device hotplug code introduce another device
check? any idea?
Container uses common device hotplug code:
[ 142.937724] IPv6: ADDRCONF(NETDEV_CHANGE): eth8: link becomes ready
[ 674.975575] ACPI: \_SB_.LSB1: ACPI_NOTIFY_DEVICE_CHECK event <<<<
[ 674.991604] ACPI: \_SB_.LSB1: ACPI_NOTIFY_DEVICE_CHECK event <<<<
[ 675.613990] ACPI: PCI Root Bridge [UNC2] (domain 0000 [bus fd])
[ 675.684970] acpi PNP0A03:01: ACPI _OSC support notification failed, disabling PCIe ASPM
[ 675.780957] acpi PNP0A03:01: Unable to request _OSC control (_OSC support mask: 0x08)
[ 675.874806] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 675.949005] pci_bus 0000:fd: Allocating resources
[ 675.960145] ACPI: PCI Root Bridge [UNC3] (domain 0000 [bus fc])
[ 676.031176] acpi PNP0A03:02: ACPI _OSC support notification failed, disabling PCIe ASPM
[ 676.127129] acpi PNP0A03:02: Unable to request _OSC control (_OSC support mask: 0x08)
[ 676.220943] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 676.295019] pci_bus 0000:fc: Allocating resources
Original ACPI container driver:
[ 1526.122933] Container driver received ACPI_NOTIFY_DEVICE_CHECK event <<<<
[ 1526.800646] ACPI: PCI Root Bridge [UNC2] (domain 0000 [bus fd])
[ 1526.871682] acpi PNP0A03:01: ACPI _OSC support notification failed, disabling PCIe ASPM
[ 1526.967878] acpi PNP0A03:01: Unable to request _OSC control (_OSC support mask: 0x08)
[ 1527.061891] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 1527.136036] pci_bus 0000:fd: Allocating resources
[ 1527.150747] ACPI: PCI Root Bridge [UNC3] (domain 0000 [bus fc])
[ 1527.221821] acpi PNP0A03:02: ACPI _OSC support notification failed, disabling PCIe ASPM
[ 1527.317738] acpi PNP0A03:02: Unable to request _OSC control (_OSC support mask: 0x08)
[ 1527.411795] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 1527.485917] pci_bus 0000:fc: Allocating resources
Thanks,
Gu
>
> Thanks,
> -Toshi
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2013-09-25 10:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-12 5:00 [Bug report] Warning when hot-add an ACPI0004 device Tang Chen
2013-09-12 15:11 ` Toshi Kani
2013-09-25 10:31 ` Gu Zheng [this message]
2013-09-25 14:36 ` Rafael J. Wysocki
2013-09-26 2:33 ` Gu Zheng
2013-09-25 22:24 ` Toshi Kani
2013-09-26 2:33 ` Gu Zheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5242BB6D.3060504@cn.fujitsu.com \
--to=guz.fnst@cn.fujitsu.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=tangchen@cn.fujitsu.com \
--cc=toshi.kani@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.