* Re: linux-next: error while fetching the microblaze tree
From: Michal Simek @ 2016-01-07 7:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20160107093856.779af583@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
Hi,
On 6.1.2016 23:38, Stephen Rothwell wrote:
> Hi Michal,
>
> Fetching the microblaze tree
> (git://git.monstr.eu/linux-2.6-microblaze.git#next) produces this error.
>
> fatal: read error: Connection reset by peer
>
> I will use the previously fetched version for today.
git server in under maintenance. Hopefully it will be solved soon.
Sorry for trouble.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* linux-next: manual merge of the target-updates tree with the rdma tree
From: Stephen Rothwell @ 2016-01-07 5:42 UTC (permalink / raw)
To: Nicholas A. Bellinger, Doug Ledford
Cc: linux-next, linux-kernel, Christoph Hellwig, Sagi Grimberg,
Jenny Derzhavetz, Or Gerlitz
Hi Nicholas,
Today's linux-next merge of the target-updates tree got conflicts in:
drivers/infiniband/ulp/iser/iscsi_iser.h
drivers/infiniband/ulp/iser/iser_initiator.c
drivers/infiniband/ulp/iser/iser_memory.c
drivers/infiniband/ulp/iser/iser_verbs.c
drivers/infiniband/ulp/isert/ib_isert.c
between commits:
4a061b287b1e ("IB/ulps: Avoid calling ib_query_device")
cfeb91b375ad ("IB/iser: Convert to CQ abstraction")
2392a4cdcb8d ("IB/iser: constify iser_reg_ops structure")
422bd0acb062 ("IB/isert: Support the remote invalidation exception")
59caaed7a72a ("IB/iser: Support the remote invalidation exception")
from the rdma tree and commit:
ddca7d44ccd2 ("iser: Have initiator and target to share protocol structures and definitions")
6d2cb3ad4bc2 ("iser-target: Support the remote invalidation exception")
c37c810bae45 ("IB/iser: Increment the rkey when registering and not when invalidating")
9a4a71456262 ("IB/iser: Support the remote invalidation exception")
from the target-updates tree.
I fixed it up (hopefully - mainly taking one of the other side (usually
the rdma tree version, so please check the result when I release it)
and can carry the fix as necessary (no action is required).
Seom of these patches are very similar ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
^ permalink raw reply
* Re: linux-next: build failure after merge of the drm tree
From: Stephen Rothwell @ 2016-01-07 2:44 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-next, linux-kernel, Rex Zhu, Alex Deucher
In-Reply-To: <20151231213124.1973e995@canb.auug.org.au>
Hi all,
On Thu, 31 Dec 2015 21:31:24 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/tonga_thermal.c: In function 'tonga_fan_ctrl_get_fan_speed_percent':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/tonga_thermal.c:84:2: error: implicit declaration of function 'do_div' [-Werror=implicit-function-declaration]
> do_div(tmp64, duty100);
> ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_thermal.c: In function 'fiji_fan_ctrl_get_fan_speed_percent':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_thermal.c:78:2: error: implicit declaration of function 'do_div' [-Werror=implicit-function-declaration]
> do_div(tmp64, duty100);
> ^
>
> Caused by commit
>
> 1e4854e96c35 ("drm/amdgpu/powerplay: implement thermal control for tonga.")
>
> [I notice that that commit does not have a Signed-off-by from its
> committer (Alex)]
>
> I applied the following fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 31 Dec 2015 21:20:20 +1100
> Subject: [PATCH] drm/amdgpu/powerplay: include asm/div64.h for do_div()
>
> Fixes: 1e4854e96c35 ("drm/amdgpu/powerplay: implement thermal control for tonga.")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c | 2 +-
> drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> index def57d0675ed..e76a7de9aa32 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> @@ -20,7 +20,7 @@
> * OTHER DEALINGS IN THE SOFTWARE.
> *
> */
> -
> +#include <asm/div64.h>
> #include "fiji_thermal.h"
> #include "fiji_hwmgr.h"
> #include "fiji_smumgr.h"
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> index 2e159b003e71..a188174747c9 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> @@ -20,7 +20,7 @@
> * OTHER DEALINGS IN THE SOFTWARE.
> *
> */
> -
> +#include <asm/div64.h>
> #include "tonga_thermal.h"
> #include "tonga_hwmgr.h"
> #include "tonga_smumgr.h"
> --
> 2.6.4
Ping? I am still applying that patch ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
^ permalink raw reply
* Re: linux-next: build failure after merge of the vfs tree
From: Al Viro @ 2016-01-07 2:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Mike Marshall
In-Reply-To: <20160107114253.19d92b55@canb.auug.org.au>
On Thu, Jan 07, 2016 at 11:42:53AM +1100, Stephen Rothwell wrote:
> > This patch now looks like this (after changes to the orangefs tree):
> >
Guys, just set inode->i_link to ORANGEFS_I(dentry->d_inode)->link_target and
have ->get_link = simple_get_link. Killing orangefs_{follow,get}_link()
entirely.
^ permalink raw reply
* Re: linux-next: build failure after merge of the vfs tree
From: Stephen Rothwell @ 2016-01-07 0:42 UTC (permalink / raw)
To: Al Viro; +Cc: linux-next, linux-kernel, Mike Marshall
In-Reply-To: <20151221112301.56bcf3f1@canb.auug.org.au>
Hi all,
On Mon, 21 Dec 2015 11:23:01 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 10 Dec 2015 11:18:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > fs/orangefs/symlink.c:26:2: error: unknown field 'follow_link' specified in initializer
> > .follow_link = pvfs2_follow_link,
> > ^
> > fs/orangefs/symlink.c:26:17: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
> > .follow_link = pvfs2_follow_link,
> > ^
> > fs/orangefs/symlink.c:26:17: note: (near initialization for 'pvfs2_symlink_inode_operations.put_link')
> >
> > Caused by commit
> >
> > 6b2553918d8b ("replace ->follow_link() with new method that could stay in RCU mode")
> >
> > [I wish there was some way to stage these API changes :-(]
> >
> > I applied the following merge fix patch (which may need more work):
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 10 Dec 2015 11:12:36 +1100
> > Subject: [PATCH] orangfs: update for follow_link to get_link change
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > fs/orangefs/symlink.c | 12 +++++++++---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/orangefs/symlink.c b/fs/orangefs/symlink.c
> > index 2adfceff7730..dbf24a98a3c9 100644
> > --- a/fs/orangefs/symlink.c
> > +++ b/fs/orangefs/symlink.c
> > @@ -8,9 +8,15 @@
> > #include "pvfs2-kernel.h"
> > #include "pvfs2-bufmap.h"
> >
> > -static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
> > +static const char *pvfs2_get_link(struct dentry *dentry, struct inode *inode,
> > + void **cookie)
> > {
> > - char *target = PVFS2_I(dentry->d_inode)->link_target;
> > + char *target;
> > +
> > + if (!dentry)
> > + return ERR_PTR(-ECHILD);
> > +
> > + target = PVFS2_I(inode)->link_target;
> >
> > gossip_debug(GOSSIP_INODE_DEBUG,
> > "%s: called on %s (target is %p)\n",
> > @@ -23,7 +29,7 @@ static const char *pvfs2_follow_link(struct dentry *dentry, void **cookie)
> >
> > struct inode_operations pvfs2_symlink_inode_operations = {
> > .readlink = generic_readlink,
> > - .follow_link = pvfs2_follow_link,
> > + .get_link = pvfs2_get_link,
> > .setattr = pvfs2_setattr,
> > .getattr = pvfs2_getattr,
> > .listxattr = pvfs2_listxattr,
>
> This patch now looks like this (after changes to the orangefs tree):
>
> diff --git a/fs/orangefs/symlink.c b/fs/orangefs/symlink.c
> index 1b3ae63463dc..01977e88e95d 100644
> --- a/fs/orangefs/symlink.c
> +++ b/fs/orangefs/symlink.c
> @@ -8,9 +8,15 @@
> #include "orangefs-kernel.h"
> #include "orangefs-bufmap.h"
>
> -static const char *orangefs_follow_link(struct dentry *dentry, void **cookie)
> +static const char *orangefs_get_link(struct dentry *dentry, struct inode *inode,
> + void **cookie)
> {
> - char *target = ORANGEFS_I(dentry->d_inode)->link_target;
> + char *target;
> +
> + if (!dentry)
> + return ERR_PTR(-ECHILD);
> +
> + target = ORANGEFS_I(inode)->link_target;
>
> gossip_debug(GOSSIP_INODE_DEBUG,
> "%s: called on %s (target is %p)\n",
> @@ -23,7 +29,7 @@ static const char *orangefs_follow_link(struct dentry *dentry, void **cookie)
>
> struct inode_operations orangefs_symlink_inode_operations = {
> .readlink = generic_readlink,
> - .follow_link = orangefs_follow_link,
> + .get_link = orangefs_get_link,
> .setattr = orangefs_setattr,
> .getattr = orangefs_getattr,
> .listxattr = orangefs_listxattr,
This patch now looks like this (I think this is right):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 7 Jan 2016 11:37:17 +1100
Subject: [PATCH] orangfs: update for follow_link to get_link change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/orangefs/symlink.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/fs/orangefs/symlink.c b/fs/orangefs/symlink.c
index 1b3ae63463dc..a21083790fb8 100644
--- a/fs/orangefs/symlink.c
+++ b/fs/orangefs/symlink.c
@@ -8,22 +8,26 @@
#include "orangefs-kernel.h"
#include "orangefs-bufmap.h"
-static const char *orangefs_follow_link(struct dentry *dentry, void **cookie)
+static const char *orangefs_get_link(struct dentry *dentry, struct inode *inode,
+ struct delayed_call *done)
{
- char *target = ORANGEFS_I(dentry->d_inode)->link_target;
+ char *target;
+
+ if (!dentry)
+ return ERR_PTR(-ECHILD);
+
+ target = ORANGEFS_I(dentry->d_inode)->link_target;
gossip_debug(GOSSIP_INODE_DEBUG,
"%s: called on %s (target is %p)\n",
__func__, (char *)dentry->d_name.name, target);
- *cookie = target;
-
return target;
}
struct inode_operations orangefs_symlink_inode_operations = {
.readlink = generic_readlink,
- .follow_link = orangefs_follow_link,
+ .get_link = orangefs_get_link,
.setattr = orangefs_setattr,
.getattr = orangefs_getattr,
.listxattr = orangefs_listxattr,
--
2.6.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
^ permalink raw reply related
* linux-next: error while fetching the microblaze tree
From: Stephen Rothwell @ 2016-01-06 22:38 UTC (permalink / raw)
To: Michal Simek; +Cc: linux-next, linux-kernel
Hi Michal,
Fetching the microblaze tree
(git://git.monstr.eu/linux-2.6-microblaze.git#next) produces this error.
fatal: read error: Connection reset by peer
I will use the previously fetched version for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Doug Ledford @ 2016-01-06 17:54 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Or Gerlitz, Chuck Lever, J. Bruce Fields, Doug Ledford,
Stephen Rothwell, linux-next, linux-kernel, Weiny, Ira
In-Reply-To: <20160106122831.GA22044@lst.de>
[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]
> On Jan 6, 2016, at 7:28 AM, Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Jan 06, 2016 at 02:22:41PM +0200, Or Gerlitz wrote:
>> As I wrote here, the bits are already @ kernel.org
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
>
> Ok, that's a little confusing.
>
> Doug, any chance you could settle on one tree? I don't really care
> which one.
I use both, but for different things. For instance, when I had 9 out of 10 of Sagi’s patches for iSER applied and was waiting on the 10th patch to complete the set, I was willing to push that to my github tree so Sagi could check out how the first 9 had gone and double check my merge fixups while he rebased the 10th patch, but I didn’t want to push it to k.o. I don’t rebase on k.o, ever (something Linus was adamant about when I started doing this). But the github repo is released earlier and may be rebased. If it is a smooth merge window, there is little, if any, difference between the two. Only during merge windows when I am looking at different alternatives of controversial stuff does this seem to be an issue.
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for Jan 6 (clocksource/fsl_ftm_timer.c)
From: Randy Dunlap @ 2016-01-06 17:26 UTC (permalink / raw)
To: Stephen Rothwell, linux-next
Cc: linux-kernel, Thomas Gleixner, Daniel Lezcano, Xiubo Li
In-Reply-To: <20160106190119.3fb848fd@canb.auug.org.au>
On 01/06/16 00:01, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20160105:
>
on i386:
when CLKSRC_MMIO is not enabled:
drivers/built-in.o: In function `ftm_timer_init':
fsl_ftm_timer.c:(.init.text+0x6842): undefined reference to `clocksource_mmio_readl_up'
fsl_ftm_timer.c:(.init.text+0x6855): undefined reference to `clocksource_mmio_init'
Looks like FSL_FTM_TIMER needs to select CLKSRC_MMIO.
--
~Randy
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Or Gerlitz @ 2016-01-06 16:38 UTC (permalink / raw)
To: Chuck Lever
Cc: Christoph Hellwig, J. Bruce Fields, Doug Ledford,
Stephen Rothwell, linux-next, Ira Weiny, Anna Schumaker
In-Reply-To: <2118F38A-846F-4690-A6E8-0BA7A437D567@oracle.com>
On 1/6/2016 6:33 PM, Chuck Lever wrote:
> Anna was the only NFS maintainer listed, and linux-nfs was not included on that e-mail at all.
OK, will do better next time.
> Did Anna ever reply with an Acked-by ? I don't see that in either the archive or my own inbox.
as you wrote, the patch is mechanical, I didn't think there's a deep
need to desperately chase people for that ack
Or.
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Anna Schumaker @ 2016-01-06 16:48 UTC (permalink / raw)
To: Chuck Lever, Or Gerlitz
Cc: Christoph Hellwig, J. Bruce Fields, Doug Ledford,
Stephen Rothwell, linux-next, LKML Kernel, Ira Weiny
In-Reply-To: <2118F38A-846F-4690-A6E8-0BA7A437D567@oracle.com>
On 01/06/2016 11:33 AM, Chuck Lever wrote:
>
>> On Jan 6, 2016, at 10:52 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>>
>> On 1/6/2016 5:20 PM, Chuck Lever wrote:
>>>> Chuck,
>>>>>
>>>>> Lets be concrete... anything wrong with patch [1]?
>>> Yes. It is missing Acked-by: lines from the maintainers of
>>> those files.
>>>
>>> All changes to files under net/sunrpc need an Ack from one
>>> of the maintainers listed in MAINTAINERS for that directory,
>>> if the changes are going through another maintainer's tree.
>>>
>>> I have been personally asked to remind folks that the
>>> nfs-sunrpc maintainers do not read linux-rdma, so they
>>> must be contacted directly (and cc: linux-nfs) as part of
>>> proposing finished patches in that area.
>>
>> I did that!!
>>
>> I copied you and Anna on the patch [1].
>
> The marc.info archive does not preserve To: or Cc:
> fields on e-mail. I had to look in my own inbox to
> confirm who the recipients were.
>
> Anna was the only NFS maintainer listed, and
> linux-nfs was not included on that e-mail at all.
> Did Anna ever reply with an Acked-by ? I don't see
> that in either the archive or my own inbox.
I'm not sure if I ever replied to that one. This patch was part of an alternative to Christoph's deviceattr cleanup, right? The NFS client bits looked okay to me, but I held off on replying to see which version was accepted. Feel free to add my:
Acked-by: Anna Schumaker <Anna.Schumaker@netapp.com>
Anna
>
> Bruce needs to Ack the svc_rdma_transport.c hunks.
>
>
>> Again, lets be concrete, this very small cleanup was picked and merged, anything there
>> need to be fixed?
>
> I have rebased on Doug's current for-4.5, and will
> be testing today before submitting my for-4.5 patches
> again. Your changes are mechanical, so I don't expect
> to encounter a technical problem.
>
> However, I would be more comfortable if the missing
> Acks were fixed in Doug's tree (with Anna and Bruce's
> permission, of course) before Linus pulls.
>
>
>> Or.
>>
>> [1] http://marc.info/?l=linux-rdma&m=145042924110411&w=2
>>
>>
>>> Unfortunately I have not been able to review every patch
>>> that has come by on linux-rdma in the past 9 months to
>>> ensure the eyes are dotted and tees crossed. More than
>>> a few commits in the tree are missing the proper tags.
>>>
>>>
>>>> [1] commit e3e45b1 "xprtrdma: Avoid calling ib_query_device"
>>>>
>>>> in git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
>>>>
>>>> http://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-4.5&id=e3e45b1b43988b99007a9908ca0ba738b3fbd0ff
>>>>
>>
>
> --
> Chuck Lever
>
>
>
>
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Chuck Lever @ 2016-01-06 16:33 UTC (permalink / raw)
To: Or Gerlitz
Cc: Christoph Hellwig, J. Bruce Fields, Doug Ledford,
Stephen Rothwell, linux-next, LKML Kernel, Ira Weiny,
Anna Schumaker
In-Reply-To: <568D3838.7010606@mellanox.com>
> On Jan 6, 2016, at 10:52 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>
> On 1/6/2016 5:20 PM, Chuck Lever wrote:
>>> Chuck,
>>> >
>>> >Lets be concrete... anything wrong with patch [1]?
>> Yes. It is missing Acked-by: lines from the maintainers of
>> those files.
>>
>> All changes to files under net/sunrpc need an Ack from one
>> of the maintainers listed in MAINTAINERS for that directory,
>> if the changes are going through another maintainer's tree.
>>
>> I have been personally asked to remind folks that the
>> nfs-sunrpc maintainers do not read linux-rdma, so they
>> must be contacted directly (and cc: linux-nfs) as part of
>> proposing finished patches in that area.
>
> I did that!!
>
> I copied you and Anna on the patch [1].
The marc.info archive does not preserve To: or Cc:
fields on e-mail. I had to look in my own inbox to
confirm who the recipients were.
Anna was the only NFS maintainer listed, and
linux-nfs was not included on that e-mail at all.
Did Anna ever reply with an Acked-by ? I don't see
that in either the archive or my own inbox.
Bruce needs to Ack the svc_rdma_transport.c hunks.
> Again, lets be concrete, this very small cleanup was picked and merged, anything there
> need to be fixed?
I have rebased on Doug's current for-4.5, and will
be testing today before submitting my for-4.5 patches
again. Your changes are mechanical, so I don't expect
to encounter a technical problem.
However, I would be more comfortable if the missing
Acks were fixed in Doug's tree (with Anna and Bruce's
permission, of course) before Linus pulls.
> Or.
>
> [1] http://marc.info/?l=linux-rdma&m=145042924110411&w=2
>
>
>> Unfortunately I have not been able to review every patch
>> that has come by on linux-rdma in the past 9 months to
>> ensure the eyes are dotted and tees crossed. More than
>> a few commits in the tree are missing the proper tags.
>>
>>
>> >[1] commit e3e45b1 "xprtrdma: Avoid calling ib_query_device"
>> >
>> >in git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
>> >
>> >http://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-4.5&id=e3e45b1b43988b99007a9908ca0ba738b3fbd0ff
>> >
>
--
Chuck Lever
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: J. Bruce Fields @ 2016-01-06 16:25 UTC (permalink / raw)
To: Chuck Lever
Cc: Doug Ledford, Stephen Rothwell, linux-next, LKML Kernel,
Christoph Hellwig, Ira Weiny, Or Gerlitz
In-Reply-To: <24AC8112-95A2-4D7B-8048-3D7D50A78B90@oracle.com>
On Wed, Jan 06, 2016 at 07:01:14AM -0500, Chuck Lever wrote:
> Part of the plan was that Doug's tree would be merged before
> Bruce's. But the above problem description looks like the
> maintainer trees were merged into linux-next in the other order.
The order makes no difference.
The problem is that we had conflicting patches: I still had Christoph's
patch, but Doug's tree did something different.
(The only reason to care about merge order is that if I sent my pull
request to Linus first, it would look like "here's the nfsd changes for
4.5. Oh, plus a bunch of rdma changes from Doug which he can explain
later...". So it'd be best if the rdma changes were already in before I
sent a pull request based on them.)
> I'd like to make this simpler for everyone. Bruce, may I send
> my for-4.5 NFS/RDMA server patches to Doug with your Acked-by?
Sure, I'm fine with doing it either way. Feel free to add my Acked-by:
to the patches you sent me before if that would simplify things.
--b.
^ permalink raw reply
* Re: Widespread boot failures on ARM due to "mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()"
From: Steve Capper @ 2016-01-06 15:56 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Brown, Andrew Morton, linux-arm-kernel@lists.infradead.org,
Stephen Rothwell, Tony Luck, Russell King,
Kernel Build Reports Mailman List, Mel Gorman, Tyler Baker,
Dave Hansen, Kevin Hilman, linux-next, Kamezawa Hiroyuki,
Xishi Qiu, Taku Izumi, Matt Fleming
In-Reply-To: <CAPvkgC3w0oy53HTwDtqEXKoabL44i06hAXndno-Ms83L0Tm0CA@mail.gmail.com>
On 5 January 2016 at 19:59, Steve Capper <steve.capper@linaro.org> wrote:
> On 5 January 2016 at 12:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 05/01/16 11:45, Mark Brown wrote:
>>>
>>> On Mon, Jan 04, 2016 at 04:35:28PM -0800, Andrew Morton wrote:
>>>>
>>>> On Mon, 4 Jan 2016 23:55:12 +0000 Mark Brown <broonie@kernel.org> wrote:
>>>>>
>>>>> On Mon, Jan 04, 2016 at 03:09:46PM -0800, Andrew Morton wrote:
>>>
>>>
>>>>>> Thanks. That patch has rather a blooper if
>>>>>> CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
>>>
>>>
>>>>> Seems to be what's making a difference from a quick run through, yes.
>>>
>>>
>>>> OK, thanks.
>>>
>>>
>>> Seems like I was mistaken here somehow or there's some other problem -
>>> I've kicked off another bisect for today's -next:
>>>
>>>
>>> https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/137/console
>>>
>>> and will follow up with any results.
>>>
>>
>> With both patches applied(one already in today's -next), I am able to
>> boot on ARM64 platform but I get huge load(for each pfn) of below warning:
>>
>> -->8
>>
>> BUG: Bad page state in process swapper pfn:900000
>> page:ffffffbde4000000 count:0 mapcount:1 mapping: (null) index:0x0
>> flags: 0x0()
>> page dumped because: nonzero mapcount
>> Modules linked in:
>> Hardware name: ARM Juno development board (r0) (DT)
>> Call trace:
>> [<ffffffc000089830>] dump_backtrace+0x0/0x180
>> [<ffffffc0000899c4>] show_stack+0x14/0x20
>> [<ffffffc000335008>] dump_stack+0x90/0xc8
>> [<ffffffc0001531f8>] bad_page+0xd8/0x138
>> [<ffffffc000153470>] free_pages_prepare+0x218/0x290
>> [<ffffffc000154d4c>] __free_pages_ok+0x1c/0xb8
>> [<ffffffc000155638>] __free_pages+0x30/0x50
>> [<ffffffc00092fa9c>] __free_pages_bootmem+0xa0/0xa8
>> [<ffffffc0009321d0>] free_all_bootmem+0x11c/0x184
>> [<ffffffc000925264>] mem_init+0x48/0x1b4
>> [<ffffffc0009217e0>] start_kernel+0x224/0x3b4
>> [<0000000080663000>] 0x80663000
>> Disabling lock debugging due to kernel taint
>>
>> --
>
> I managed to get 904769ac82ebf60cb54f225f59ae7c064772a4d7 booting on
> an arm64 machine without errors with the following changes:
>
> =====================================
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index a8bb70d..0edb608 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5013,6 +5013,15 @@ static inline unsigned long __meminit
> zone_spanned_pages_in_node(int nid,
> unsigned long *zone_end_pfn,
> unsigned long *zones_size)
> {
> + unsigned int zone;
> +
> + *zone_start_pfn = node_start_pfn;
> + for (zone = 0; zone < zone_type; zone++) {
> + *zone_start_pfn += zones_size[zone];
> + }
> +
> + *zone_end_pfn = *zone_start_pfn + zones_size[zone_type];
> +
> return zones_size[zone_type];
> }
>
> @@ -5328,6 +5337,8 @@ void __paginginit free_area_init_node(int nid,
> unsigned long *zones_size,
> pr_info("Initmem setup node %d [mem %#018Lx-%#018Lx]\n", nid,
> (u64)start_pfn << PAGE_SHIFT,
> end_pfn ? ((u64)end_pfn << PAGE_SHIFT) - 1 : 0);
> +#else
> + start_pfn = node_start_pfn;
> #endif
> calculate_node_totalpages(pgdat, start_pfn, end_pfn,
> zones_size, zholes_size);
>
> =====================================
>
> My understanding is that 904769a ("mm/page_alloc.c: calculate
> zone_start_pfn at zone_spanned_pages_in_node()") inadvertently
> discards information when pgdat->node_start_pfn is removed from
> free_area_init_core (and zone_start_pfn is no longer updated by "size"
> in the loop inside free_area_init_core). This isn't an issue with
> systems where CONFIG_HAVE_MEMBLOCK_NODE_MAP is enabled as
> zone_start_pfn is set correctly. On systems without
> CONFIG_HAVE_MEMBLOCK_NODE_MAP, zone_start_pfn is always 0.
>
> When I ported the above fix to linux-next
> (8ef79cd05e6894c01ab9b41aa918a402fa8022a7) I was able to boot in a VM
> but not on my actual machine, I'll investigate that tomorrow.
I got 8ef79cd05e6894c01ab9b41aa918a402fa8022a7 working on my main
devboard with the fix above. (It turned out that I had a misconfigured
earlycon command line option and this became a problem with one of the
pl011 patches.)
Cheers,
--
Steve
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Or Gerlitz @ 2016-01-06 15:52 UTC (permalink / raw)
To: Chuck Lever
Cc: Christoph Hellwig, J. Bruce Fields, Doug Ledford,
Stephen Rothwell, linux-next, LKML Kernel, Ira Weiny,
Anna Schumaker
In-Reply-To: <3B1D726B-5225-40D5-8C94-CA87EF198D89@oracle.com>
On 1/6/2016 5:20 PM, Chuck Lever wrote:
>> Chuck,
>> >
>> >Lets be concrete... anything wrong with patch [1]?
> Yes. It is missing Acked-by: lines from the maintainers of
> those files.
>
> All changes to files under net/sunrpc need an Ack from one
> of the maintainers listed in MAINTAINERS for that directory,
> if the changes are going through another maintainer's tree.
>
> I have been personally asked to remind folks that the
> nfs-sunrpc maintainers do not read linux-rdma, so they
> must be contacted directly (and cc: linux-nfs) as part of
> proposing finished patches in that area.
I did that!!
I copied you and Anna on the patch [1].
Again, lets be concrete, this very small cleanup was picked and merged,
anything there
need to be fixed?
Or.
[1] http://marc.info/?l=linux-rdma&m=145042924110411&w=2
> Unfortunately I have not been able to review every patch
> that has come by on linux-rdma in the past 9 months to
> ensure the eyes are dotted and tees crossed. More than
> a few commits in the tree are missing the proper tags.
>
>
> >[1] commit e3e45b1 "xprtrdma: Avoid calling ib_query_device"
> >
> >in git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
> >
> >http://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-4.5&id=e3e45b1b43988b99007a9908ca0ba738b3fbd0ff
> >
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Chuck Lever @ 2016-01-06 15:20 UTC (permalink / raw)
To: Or Gerlitz
Cc: Christoph Hellwig, J. Bruce Fields, Doug Ledford,
Stephen Rothwell, linux-next, LKML Kernel, Ira Weiny
In-Reply-To: <568D28D2.4090507@mellanox.com>
> On Jan 6, 2016, at 9:46 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>
> On 1/6/2016 4:24 PM, Chuck Lever wrote:
>> Actually, one of Or's for-4.5 devattr patches doesn't appear to have the proper Ack's for the changes under net/sunrpc/xprtrdma either.
>
> Chuck,
>
> Lets be concrete... anything wrong with patch [1]?
Yes. It is missing Acked-by: lines from the maintainers of
those files.
All changes to files under net/sunrpc need an Ack from one
of the maintainers listed in MAINTAINERS for that directory,
if the changes are going through another maintainer's tree.
I have been personally asked to remind folks that the
nfs-sunrpc maintainers do not read linux-rdma, so they
must be contacted directly (and cc: linux-nfs) as part of
proposing finished patches in that area.
Unfortunately I have not been able to review every patch
that has come by on linux-rdma in the past 9 months to
ensure the eyes are dotted and tees crossed. More than
a few commits in the tree are missing the proper tags.
> Or.
>
> [1] commit e3e45b1 "xprtrdma: Avoid calling ib_query_device"
>
> in git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
>
> http://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-4.5&id=e3e45b1b43988b99007a9908ca0ba738b3fbd0ff
>
--
Chuck Lever
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Or Gerlitz @ 2016-01-06 14:46 UTC (permalink / raw)
To: Chuck Lever
Cc: Christoph Hellwig, J. Bruce Fields, Doug Ledford,
Stephen Rothwell, linux-next, LKML Kernel, Ira Weiny
In-Reply-To: <90E07B04-AAFD-45E9-85EA-44C659191180@oracle.com>
On 1/6/2016 4:24 PM, Chuck Lever wrote:
> Actually, one of Or's for-4.5 devattr patches doesn't appear to have the proper Ack's for the changes under net/sunrpc/xprtrdma either.
Chuck,
Lets be concrete... anything wrong with patch [1]?
Or.
[1] commit e3e45b1 "xprtrdma: Avoid calling ib_query_device"
in git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
k.o/for-4.5
http://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-4.5&id=e3e45b1b43988b99007a9908ca0ba738b3fbd0ff
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Chuck Lever @ 2016-01-06 14:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: J. Bruce Fields, Doug Ledford, Stephen Rothwell, linux-next,
LKML Kernel, Ira Weiny, Or Gerlitz
In-Reply-To: <20160106121529.GA21780@lst.de>
> On Jan 6, 2016, at 7:15 AM, Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Jan 06, 2016 at 07:01:14AM -0500, Chuck Lever wrote:
>> Part of the plan was that Doug's tree would be merged before
>> Bruce's. But the above problem description looks like the
>> maintainer trees were merged into linux-next in the other order.
>>
>> I'd like to make this simpler for everyone. Bruce, may I send
>> my for-4.5 NFS/RDMA server patches to Doug with your Acked-by?
>> That way, merge order won't matter.
>>
>> Doug, what is the URL for the branch I should rebase on?
>
> I'm not Doug, but all the recent for 4.5 work is in Dougs tree
> at
>
> https://github.com/dledford/linux rdma/k.o/for-4.5
>
> Bruce, can you ACK me local_dma_lkey patch as well which needs
> the same treatment as Chuck's patches? I have some RDMA work
> in that area planned for the nxt merge window, so it would be
> really helpful to get it in for 4.5.
Actually, one of Or's for-4.5 devattr patches doesn't
appear to have the proper Ack's for the changes under
net/sunrpc/xprtrdma either.
--
Chuck Lever
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Christoph Hellwig @ 2016-01-06 12:28 UTC (permalink / raw)
To: Or Gerlitz
Cc: Christoph Hellwig, Chuck Lever, J. Bruce Fields, Doug Ledford,
Stephen Rothwell, linux-next, LKML Kernel, Ira Weiny
In-Reply-To: <568D0711.5020607@mellanox.com>
On Wed, Jan 06, 2016 at 02:22:41PM +0200, Or Gerlitz wrote:
> As I wrote here, the bits are already @ kernel.org
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
Ok, that's a little confusing.
Doug, any chance you could settle on one tree? I don't really care
which one.
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Chuck Lever @ 2016-01-06 12:27 UTC (permalink / raw)
To: J. Bruce Fields, Doug Ledford
Cc: Stephen Rothwell, linux-next, LKML Kernel, Christoph Hellwig,
Ira Weiny, Or Gerlitz
In-Reply-To: <24AC8112-95A2-4D7B-8048-3D7D50A78B90@oracle.com>
> On Jan 6, 2016, at 7:01 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>
>
>> On Jan 4, 2016, at 2:36 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>>
>> On Sun, Jan 03, 2016 at 09:53:20PM -0500, Doug Ledford wrote:
>>> On 01/03/2016 08:44 PM, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> On Thu, 31 Dec 2015 13:30:22 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>>
>>>>> Hi Doug,
>>>>>
>>>>> Today's linux-next merge of the rdma tree got conflicts in a quite a
>>>>> few files between (mostly, I think) commit:
>>>>>
>>>>> 6c7b6d2d442c ("IB: merge struct ib_device_attr into struct ib_device")
>>>>>
>>>>> from the nfsd tree and various commits from the rdma tree.
>>>>>
>>>>> It would have taken me considerable time to fix the conflicts up, so I
>>>>> have dropped teh rdma tree for today (just because it was merged second).
>>>>> Please have a conversation and figure out how you are going to cooperate
>>>>> and get these conflicts fixed e.g. set up a stable branch with Christoph's
>>>>> commit (and any other conflicting commits) in it and merge that into
>>>>> both trees.
>>>>
>>>> So, on further inspection, it appears that there is a series of commits
>>>> in the rdma tree that does basically the same as that nfsd tree commit
>>>> above. So I have dropped the rdma tree again today. Please have a
>>>> conversation guys ...
>>>>
>>>
>>> The initial patchset was Christoph's. It was later replaced with a
>>> different patchset from Or Gerlitz. Bruce picked up some changes from
>>> Chuck Lever that were originally based on Christoph's work but now need
>>> to be rebased off of the current RDMA tree.
>>
>> OK. I'm assuming Chuck will want to do any necessary rebasing and
>> retesting himself, so for now I've just dropped those patches, and
>> expect to pick up new versions when Chuck gets back from the holidays.
>
> Part of the plan was that Doug's tree would be merged before
> Bruce's. But the above problem description looks like the
> maintainer trees were merged into linux-next in the other order.
>
> I'd like to make this simpler for everyone. Bruce, may I send
> my for-4.5 NFS/RDMA server patches to Doug with your Acked-by?
> That way, merge order won't matter.
Also, I see Dan Carpenter has posted a couple of clean-ups for
this series. I can include them with my upcoming repost if you
wish.
--
Chuck Lever
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Or Gerlitz @ 2016-01-06 12:22 UTC (permalink / raw)
To: Christoph Hellwig, Chuck Lever
Cc: J. Bruce Fields, Doug Ledford, Stephen Rothwell, linux-next,
LKML Kernel, Ira Weiny
In-Reply-To: <20160106121529.GA21780@lst.de>
On 1/6/2016 2:15 PM, Christoph Hellwig wrote:
> I'm not Doug, but all the recent for 4.5 work is in Dougs tree
> at
>
> https://github.com/dledford/linux rdma/k.o/for-4.5
Christoph,
As I wrote here, the bits are already @ kernel.org
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
Or.
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Christoph Hellwig @ 2016-01-06 12:15 UTC (permalink / raw)
To: Chuck Lever
Cc: J. Bruce Fields, Doug Ledford, Stephen Rothwell, linux-next,
LKML Kernel, Christoph Hellwig, Ira Weiny, Or Gerlitz
In-Reply-To: <24AC8112-95A2-4D7B-8048-3D7D50A78B90@oracle.com>
On Wed, Jan 06, 2016 at 07:01:14AM -0500, Chuck Lever wrote:
> Part of the plan was that Doug's tree would be merged before
> Bruce's. But the above problem description looks like the
> maintainer trees were merged into linux-next in the other order.
>
> I'd like to make this simpler for everyone. Bruce, may I send
> my for-4.5 NFS/RDMA server patches to Doug with your Acked-by?
> That way, merge order won't matter.
>
> Doug, what is the URL for the branch I should rebase on?
I'm not Doug, but all the recent for 4.5 work is in Dougs tree
at
https://github.com/dledford/linux rdma/k.o/for-4.5
Bruce, can you ACK me local_dma_lkey patch as well which needs
the same treatment as Chuck's patches? I have some RDMA work
in that area planned for the nxt merge window, so it would be
really helpful to get it in for 4.5.
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Or Gerlitz @ 2016-01-06 12:14 UTC (permalink / raw)
To: Chuck Lever, J. Bruce Fields, Doug Ledford
Cc: Stephen Rothwell, linux-next, LKML Kernel, Christoph Hellwig,
Ira Weiny
In-Reply-To: <24AC8112-95A2-4D7B-8048-3D7D50A78B90@oracle.com>
On 1/6/2016 2:01 PM, Chuck Lever wrote:
> what is the URL for the branch I should rebase on?
k.o/for-4.5 on Doug's kernel.org tree
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the nfsd tree
From: Chuck Lever @ 2016-01-06 12:01 UTC (permalink / raw)
To: J. Bruce Fields, Doug Ledford
Cc: Stephen Rothwell, linux-next, LKML Kernel, Christoph Hellwig,
Ira Weiny, Or Gerlitz
In-Reply-To: <20160104193616.GB30315@fieldses.org>
> On Jan 4, 2016, at 2:36 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>
> On Sun, Jan 03, 2016 at 09:53:20PM -0500, Doug Ledford wrote:
>> On 01/03/2016 08:44 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> On Thu, 31 Dec 2015 13:30:22 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>
>>>> Hi Doug,
>>>>
>>>> Today's linux-next merge of the rdma tree got conflicts in a quite a
>>>> few files between (mostly, I think) commit:
>>>>
>>>> 6c7b6d2d442c ("IB: merge struct ib_device_attr into struct ib_device")
>>>>
>>>> from the nfsd tree and various commits from the rdma tree.
>>>>
>>>> It would have taken me considerable time to fix the conflicts up, so I
>>>> have dropped teh rdma tree for today (just because it was merged second).
>>>> Please have a conversation and figure out how you are going to cooperate
>>>> and get these conflicts fixed e.g. set up a stable branch with Christoph's
>>>> commit (and any other conflicting commits) in it and merge that into
>>>> both trees.
>>>
>>> So, on further inspection, it appears that there is a series of commits
>>> in the rdma tree that does basically the same as that nfsd tree commit
>>> above. So I have dropped the rdma tree again today. Please have a
>>> conversation guys ...
>>>
>>
>> The initial patchset was Christoph's. It was later replaced with a
>> different patchset from Or Gerlitz. Bruce picked up some changes from
>> Chuck Lever that were originally based on Christoph's work but now need
>> to be rebased off of the current RDMA tree.
>
> OK. I'm assuming Chuck will want to do any necessary rebasing and
> retesting himself, so for now I've just dropped those patches, and
> expect to pick up new versions when Chuck gets back from the holidays.
Part of the plan was that Doug's tree would be merged before
Bruce's. But the above problem description looks like the
maintainer trees were merged into linux-next in the other order.
I'd like to make this simpler for everyone. Bruce, may I send
my for-4.5 NFS/RDMA server patches to Doug with your Acked-by?
That way, merge order won't matter.
Doug, what is the URL for the branch I should rebase on?
--
Chuck Lever
^ permalink raw reply
* next-20160106 build: 0 failures 13 warnings (next-20160106)
From: Build bot for Mark Brown @ 2016-01-06 11:45 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, linux-next
Tree/Branch: next-20160106
Git describe: next-20160106
Commit: 600690a892 Add linux-next specific files for 20160106
Build Time: 73 min 23 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 13
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
4 warnings 0 mismatches : arm64-allmodconfig
3 warnings 0 mismatches : arm-multi_v5_defconfig
7 warnings 0 mismatches : arm-multi_v7_defconfig
7 warnings 0 mismatches : arm-allmodconfig
1 warnings 0 mismatches : arm-allnoconfig
1 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 13
7 <stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
4 ../drivers/tty/serial/amba-pl011.c:190:27: warning: 'vendor_zte' defined but not used [-Wunused-variable]
2 ../fs/ext4/ioctl.c:426:1: warning: control reaches end of non-void function [-Wreturn-type]
1 arch/arm/configs/multi_v7_defconfig:435:warning: symbol value 'm' invalid for MFD_DA9063
1 ../net/bluetooth/mgmt.c:5493:8: warning: 'r192' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../net/bluetooth/mgmt.c:5493:8: warning: 'h192' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../fs/orangefs/symlink.c:32:2: warning: initialization from incompatible pointer type [enabled by default]
1 ../fs/orangefs/symlink.c:32:2: warning: (near initialization for 'orangefs_symlink_inode_operations.get_link') [enabled by default]
1 ../fs/orangefs/symlink.c:32:14: warning: initialization from incompatible pointer type
1 ../fs/orangefs/symlink.c:32:14: warning: (near initialization for 'orangefs_symlink_inode_operations.get_link')
1 ../drivers/gpu/drm/vc4/vc4_validate.c:864:4: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t' [-Wformat=]
1 ../drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h:382:5: warning: comparison of distinct pointer types lacks a cast [enabled by default]
1 ../crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than 1024 bytes [-Wframe-larger-than=]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
../fs/orangefs/symlink.c:32:14: warning: initialization from incompatible pointer type
../fs/orangefs/symlink.c:32:14: warning: (near initialization for 'orangefs_symlink_inode_operations.get_link')
../drivers/gpu/drm/vc4/vc4_validate.c:864:4: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t' [-Wformat=]
../drivers/tty/serial/amba-pl011.c:190:27: warning: 'vendor_zte' defined but not used [-Wunused-variable]
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
../fs/ext4/ioctl.c:426:1: warning: control reaches end of non-void function [-Wreturn-type]
<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 7 warnings, 0 section mismatches
Warnings:
arch/arm/configs/multi_v7_defconfig:435:warning: symbol value 'm' invalid for MFD_DA9063
<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
../fs/ext4/ioctl.c:426:1: warning: control reaches end of non-void function [-Wreturn-type]
../net/bluetooth/mgmt.c:5493:8: warning: 'r192' may be used uninitialized in this function [-Wmaybe-uninitialized]
../net/bluetooth/mgmt.c:5493:8: warning: 'h192' may be used uninitialized in this function [-Wmaybe-uninitialized]
../drivers/tty/serial/amba-pl011.c:190:27: warning: 'vendor_zte' defined but not used [-Wunused-variable]
<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 7 warnings, 0 section mismatches
Warnings:
<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
../crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../fs/orangefs/symlink.c:32:2: warning: initialization from incompatible pointer type [enabled by default]
../fs/orangefs/symlink.c:32:2: warning: (near initialization for 'orangefs_symlink_inode_operations.get_link') [enabled by default]
../drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h:382:5: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../drivers/tty/serial/amba-pl011.c:190:27: warning: 'vendor_zte' defined but not used [-Wunused-variable]
<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
-------------------------------------------------------------------------------
arm-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../drivers/tty/serial/amba-pl011.c:190:27: warning: 'vendor_zte' defined but not used [-Wunused-variable]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
x86_64-allnoconfig
arm64-allnoconfig
x86_64-defconfig
^ permalink raw reply
* Re: Widespread boot failures on ARM due to "mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()"
From: Sudeep Holla @ 2016-01-06 10:32 UTC (permalink / raw)
To: Steve Capper
Cc: Sudeep Holla, Mark Brown, Andrew Morton,
linux-arm-kernel@lists.infradead.org, Stephen Rothwell, Tony Luck,
Russell King, Kernel Build Reports Mailman List, Mel Gorman,
Tyler Baker, Dave Hansen, Kevin.Hilman, linux-next,
Kamezawa Hiroyuki, Xishi Qiu, Taku Izumi, Matt Fleming
In-Reply-To: <CAPvkgC3w0oy53HTwDtqEXKoabL44i06hAXndno-Ms83L0Tm0CA@mail.gmail.com>
On 05/01/16 19:59, Steve Capper wrote:
> On 5 January 2016 at 12:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 05/01/16 11:45, Mark Brown wrote:
>>>
>>> On Mon, Jan 04, 2016 at 04:35:28PM -0800, Andrew Morton wrote:
>>>>
>>>> On Mon, 4 Jan 2016 23:55:12 +0000 Mark Brown <broonie@kernel.org> wrote:
>>>>>
>>>>> On Mon, Jan 04, 2016 at 03:09:46PM -0800, Andrew Morton wrote:
>>>
>>>
>>>>>> Thanks. That patch has rather a blooper if
>>>>>> CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
>>>
>>>
>>>>> Seems to be what's making a difference from a quick run through, yes.
>>>
>>>
>>>> OK, thanks.
>>>
>>>
>>> Seems like I was mistaken here somehow or there's some other problem -
>>> I've kicked off another bisect for today's -next:
>>>
>>>
>>> https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/137/console
>>>
>>> and will follow up with any results.
>>>
>>
>> With both patches applied(one already in today's -next), I am able to
>> boot on ARM64 platform but I get huge load(for each pfn) of below warning:
>>
>> -->8
>>
>> BUG: Bad page state in process swapper pfn:900000
>> page:ffffffbde4000000 count:0 mapcount:1 mapping: (null) index:0x0
>> flags: 0x0()
>> page dumped because: nonzero mapcount
>> Modules linked in:
>> Hardware name: ARM Juno development board (r0) (DT)
>> Call trace:
>> [<ffffffc000089830>] dump_backtrace+0x0/0x180
>> [<ffffffc0000899c4>] show_stack+0x14/0x20
>> [<ffffffc000335008>] dump_stack+0x90/0xc8
>> [<ffffffc0001531f8>] bad_page+0xd8/0x138
>> [<ffffffc000153470>] free_pages_prepare+0x218/0x290
>> [<ffffffc000154d4c>] __free_pages_ok+0x1c/0xb8
>> [<ffffffc000155638>] __free_pages+0x30/0x50
>> [<ffffffc00092fa9c>] __free_pages_bootmem+0xa0/0xa8
>> [<ffffffc0009321d0>] free_all_bootmem+0x11c/0x184
>> [<ffffffc000925264>] mem_init+0x48/0x1b4
>> [<ffffffc0009217e0>] start_kernel+0x224/0x3b4
>> [<0000000080663000>] 0x80663000
>> Disabling lock debugging due to kernel taint
>>
>> --
>
> I managed to get 904769ac82ebf60cb54f225f59ae7c064772a4d7 booting on
> an arm64 machine without errors with the following changes:
>
> =====================================
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index a8bb70d..0edb608 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5013,6 +5013,15 @@ static inline unsigned long __meminit
> zone_spanned_pages_in_node(int nid,
> unsigned long *zone_end_pfn,
> unsigned long *zones_size)
> {
> + unsigned int zone;
> +
> + *zone_start_pfn = node_start_pfn;
> + for (zone = 0; zone < zone_type; zone++) {
> + *zone_start_pfn += zones_size[zone];
> + }
> +
> + *zone_end_pfn = *zone_start_pfn + zones_size[zone_type];
> +
> return zones_size[zone_type];
> }
>
> @@ -5328,6 +5337,8 @@ void __paginginit free_area_init_node(int nid,
> unsigned long *zones_size,
> pr_info("Initmem setup node %d [mem %#018Lx-%#018Lx]\n", nid,
> (u64)start_pfn << PAGE_SHIFT,
> end_pfn ? ((u64)end_pfn << PAGE_SHIFT) - 1 : 0);
> +#else
> + start_pfn = node_start_pfn;
> #endif
> calculate_node_totalpages(pgdat, start_pfn, end_pfn,
> zones_size, zholes_size);
>
> =====================================
>
> My understanding is that 904769a ("mm/page_alloc.c: calculate
> zone_start_pfn at zone_spanned_pages_in_node()") inadvertently
> discards information when pgdat->node_start_pfn is removed from
> free_area_init_core (and zone_start_pfn is no longer updated by "size"
> in the loop inside free_area_init_core). This isn't an issue with
> systems where CONFIG_HAVE_MEMBLOCK_NODE_MAP is enabled as
> zone_start_pfn is set correctly. On systems without
> CONFIG_HAVE_MEMBLOCK_NODE_MAP, zone_start_pfn is always 0.
>
> When I ported the above fix to linux-next
> (8ef79cd05e6894c01ab9b41aa918a402fa8022a7) I was able to boot in a VM
> but not on my actual machine, I'll investigate that tomorrow.
>
It fixes the issue on real hardware too(Juno).
--
Regards,
Sudeep
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox