From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Toshi Kani <toshi.kani@hp.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
rafael.j.wysocki@intel.com, vasilis.liaskovitis@profitbricks.com,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
tangchen@cn.fujitsu.com, wency@cn.fujitsu.com
Subject: Re: Cannot hot remove a memory device
Date: Sat, 03 Aug 2013 01:43:31 +0200 [thread overview]
Message-ID: <2124016.41i4c3lbD4@vostro.rjw.lan> (raw)
In-Reply-To: <1375479975.10300.105.camel@misato.fc.hp.com>
On Friday, August 02, 2013 03:46:15 PM Toshi Kani wrote:
> On Thu, 2013-08-01 at 23:43 +0200, Rafael J. Wysocki wrote:
> > Hi,
> >
> > Thanks for your report.
> >
> > On Thursday, August 01, 2013 05:37:21 PM Yasuaki Ishimatsu wrote:
> > > By following commit, I cannot hot remove a memory device.
> > >
> > > ACPI / memhotplug: Bind removable memory blocks to ACPI device nodes
> > > commit e2ff39400d81233374e780b133496a2296643d7d
> > >
> > > Details are follows:
> > > When I add a memory device, acpi_memory_enable_device() always fails
> > > as follows:
> > >
> > > ...
> > > [ 1271.114116] [ffffea121c400000-ffffea121c7fffff] PMD -> [ffff880813c00000-ffff880813ffffff] on node 3
> > > [ 1271.128682] [ffffea121c800000-ffffea121cbfffff] PMD -> [ffff880813800000-ffff880813bfffff] on node 3
> > > [ 1271.143298] [ffffea121cc00000-ffffea121cffffff] PMD -> [ffff880813000000-ffff8808133fffff] on node 3
> > > [ 1271.157799] [ffffea121d000000-ffffea121d3fffff] PMD -> [ffff880812c00000-ffff880812ffffff] on node 3
> > > [ 1271.172341] [ffffea121d400000-ffffea121d7fffff] PMD -> [ffff880812800000-ffff880812bfffff] on node 3
> > > [ 1271.186872] [ffffea121d800000-ffffea121dbfffff] PMD -> [ffff880812400000-ffff8808127fffff] on node 3
> > > [ 1271.201481] [ffffea121dc00000-ffffea121dffffff] PMD -> [ffff880812000000-ffff8808123fffff] on node 3
> > > [ 1271.216041] [ffffea121e000000-ffffea121e3fffff] PMD -> [ffff880811c00000-ffff880811ffffff] on node 3
> > > [ 1271.230623] [ffffea121e400000-ffffea121e7fffff] PMD -> [ffff880811800000-ffff880811bfffff] on node 3
> > > [ 1271.245148] [ffffea121e800000-ffffea121ebfffff] PMD -> [ffff880811400000-ffff8808117fffff] on node 3
> > > [ 1271.259683] [ffffea121ec00000-ffffea121effffff] PMD -> [ffff880811000000-ffff8808113fffff] on node 3
> > > [ 1271.274194] [ffffea121f000000-ffffea121f3fffff] PMD -> [ffff880810c00000-ffff880810ffffff] on node 3
> > > [ 1271.288764] [ffffea121f400000-ffffea121f7fffff] PMD -> [ffff880810800000-ffff880810bfffff] on node 3
>
> It appears that each memory object only has 64MB of memory. This is
> less than the memory block size, which is 128MB. This means that a
> single memory block associates with two ACPI memory device objects.
That'd be bad.
How did that work before if that indeed is the case?
> > > ...
> > > [ 1271.325841] acpi PNP0C80:03: acpi_memory_enable_device() error
> >
> > Well, the only new way acpi_memory_enable_device() can fail after that commit
> > is a failure in acpi_bind_memory_blocks().
>
> Agreed.
>
> > This means that either handle is NULL, which I think we can exclude, because
> > acpi_memory_enable_device() wouldn't be called at all if that were the case, or
> > there's a more subtle error in acpi_bind_one().
> >
> > One that comes to mind is that we may be calling acpi_bind_one() twice for the
> > same memory region, in which it will trigger -EINVAL from the sanity check in
> > there.
>
> I think it fails with -EINVAL at the place with dev_warn(dev, "ACPI
> handle is already set\n"). When two ACPI memory objects associate with
> a same memory block, the bind procedure of the 2nd ACPI memory object
> sees that ACPI_HANDLE(dev) is already set to the 1st ACPI memory object.
That sound's plausible, but I wonder how we can fix that?
There's no way for a single physical device to have two different ACPI
"companions". It looks like the memory blocks should be 64 M each in that
case. Or we need to create two child devices for each memory block and
associate each of them with an ACPI object. That would lead to complications
in the user space interface, though.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
next prev parent reply other threads:[~2013-08-02 23:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 8:37 Yasuaki Ishimatsu
2013-08-01 21:43 ` Rafael J. Wysocki
2013-08-02 21:46 ` Toshi Kani
2013-08-02 23:43 ` Rafael J. Wysocki [this message]
2013-08-03 0:04 ` Toshi Kani
2013-08-03 1:01 ` Rafael J. Wysocki
2013-08-04 0:37 ` Toshi Kani
2013-08-04 14:12 ` Rafael J. Wysocki
2013-08-05 4:00 ` Yasuaki Ishimatsu
2013-08-05 7:59 ` Yasuaki Ishimatsu
2013-08-05 13:14 ` Cannot hot remove a memory device (patch) Rafael J. Wysocki
2013-08-05 23:19 ` Toshi Kani
2013-08-06 0:15 ` Cannot hot remove a memory device (patch, updated) Rafael J. Wysocki
2013-08-06 2:12 ` Yasuaki Ishimatsu
2013-08-06 14:17 ` Rafael J. Wysocki
2013-08-06 15:28 ` Toshi Kani
2013-08-08 17:15 ` Cannot hot remove a memory device Toshi Kani
2013-08-08 22:12 ` Rafael J. Wysocki
2013-08-08 22:50 ` Toshi Kani
2013-08-08 23:14 ` Rafael J. Wysocki
2013-08-08 23:35 ` Toshi Kani
2013-08-11 21:13 ` Rafael J. Wysocki
2013-08-12 20:40 ` Toshi Kani
2013-08-13 0:45 ` Rafael J. Wysocki
2013-08-13 1:02 ` Toshi Kani
2013-08-13 12:02 ` Rafael J. Wysocki
2013-08-13 17:14 ` Toshi Kani
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=2124016.41i4c3lbD4@vostro.rjw.lan \
--to=rjw@sisk.pl \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=tangchen@cn.fujitsu.com \
--cc=toshi.kani@hp.com \
--cc=vasilis.liaskovitis@profitbricks.com \
--cc=wency@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®