* Re: linux-next: PowerPC boot failures in next-20120521
From: Stephen Rothwell @ 2012-05-22 3:25 UTC (permalink / raw)
To: David Rientjes
Cc: LKML, linux-next, ppc-dev, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn, Linus
In-Reply-To: <20120522130354.fdb335eb294f4206b4b2fed5@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]
On Tue, 22 May 2012 13:03:54 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 21 May 2012 18:53:37 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
> >
> > Yeah, it's sched/numa since that's what introduced numa_init(). It does
> > for_each_node() for each node and does a kmalloc_node() even though that
> > node may not be online. Slub ends up passing this node to the page
> > allocator through alloc_pages_exact_node(). CONFIG_DEBUG_VM would have
> > caught this and your config confirms its not enabled.
> >
> > sched/numa either needs a memory hotplug notifier or it needs to pass
> > NUMA_NO_NODE for nodes that aren't online. Until we get the former, the
> > following should fix it.
> >
> >
> > sched, numa: Allocate node_queue on any node for offline nodes
> >
> > struct node_queue must be allocated with NUMA_NO_NODE for nodes that are
> > not (yet) online, otherwise the page allocator has a bad zonelist.
> >
> > Signed-off-by: David Rientjes <rientjes@google.com>
>
> Thanks, that fixes it.
>
> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
And I will put that patch in linux-next until it (or something better)
appears.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Michael Neuling @ 2012-05-22 3:12 UTC (permalink / raw)
To: David Rientjes
Cc: Stephen Rothwell, LKML, linux-next, ppc-dev, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn,
Linus
In-Reply-To: <alpine.DEB.2.00.1205211954340.13522@chino.kir.corp.google.com>
David Rientjes <rientjes@google.com> wrote:
> On Tue, 22 May 2012, Michael Neuling wrote:
>
> > Sorry, got it... CONFIG_DEBUG_VM enabled below...
> >
> > pid_max: default: 32768 minimum: 301
> > Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
> > Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
> > Mount-cache hash table entries: 4096
> > Initializing cgroup subsys cpuacct
> > Initializing cgroup subsys devices
> > Initializing cgroup subsys freezer
> > POWER7 performance monitor hardware support registered
> > ------------[ cut here ]------------
> > kernel BUG at /scratch/mikey/src/linux-next/include/linux/gfp.h:318!
>
> Yeah, this is what I was expecting, it's tripping on
>
> VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid));
>
> and slub won't pass nid < 0. You're sure my patch is applied? :)
I did have your patch applied but at "b4cdf91 sched/numa: Implement numa
balancer" (where git bisect spotted the fail).
If I apply your patch on the full next-20120521 it does fix the problem.
Sorry for the confusion.
Thanks!
Mikey
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Stephen Rothwell @ 2012-05-22 3:03 UTC (permalink / raw)
To: David Rientjes
Cc: LKML, linux-next, ppc-dev, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn, Linus
In-Reply-To: <alpine.DEB.2.00.1205211846120.20916@chino.kir.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
Hi David,
On Mon, 21 May 2012 18:53:37 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
>
> Yeah, it's sched/numa since that's what introduced numa_init(). It does
> for_each_node() for each node and does a kmalloc_node() even though that
> node may not be online. Slub ends up passing this node to the page
> allocator through alloc_pages_exact_node(). CONFIG_DEBUG_VM would have
> caught this and your config confirms its not enabled.
>
> sched/numa either needs a memory hotplug notifier or it needs to pass
> NUMA_NO_NODE for nodes that aren't online. Until we get the former, the
> following should fix it.
>
>
> sched, numa: Allocate node_queue on any node for offline nodes
>
> struct node_queue must be allocated with NUMA_NO_NODE for nodes that are
> not (yet) online, otherwise the page allocator has a bad zonelist.
>
> Signed-off-by: David Rientjes <rientjes@google.com>
Thanks, that fixes it.
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: David Rientjes @ 2012-05-22 2:58 UTC (permalink / raw)
To: Michael Neuling
Cc: Stephen Rothwell, LKML, linux-next, ppc-dev, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn,
Linus
In-Reply-To: <3120.1337655100@neuling.org>
On Tue, 22 May 2012, Michael Neuling wrote:
> Sorry, got it... CONFIG_DEBUG_VM enabled below...
>
> pid_max: default: 32768 minimum: 301
> Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
> Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
> Mount-cache hash table entries: 4096
> Initializing cgroup subsys cpuacct
> Initializing cgroup subsys devices
> Initializing cgroup subsys freezer
> POWER7 performance monitor hardware support registered
> ------------[ cut here ]------------
> kernel BUG at /scratch/mikey/src/linux-next/include/linux/gfp.h:318!
Yeah, this is what I was expecting, it's tripping on
VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid));
and slub won't pass nid < 0. You're sure my patch is applied? :)
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Michael Neuling @ 2012-05-22 2:51 UTC (permalink / raw)
To: David Rientjes
Cc: Stephen Rothwell, LKML, linux-next, ppc-dev, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn,
Linus
In-Reply-To: <alpine.DEB.2.00.1205211942540.29814@chino.kir.corp.google.com>
David Rientjes <rientjes@google.com> wrote:
> On Tue, 22 May 2012, Michael Neuling wrote:
>
> > > > > Trying David's patch just posted doesn't fix it.
> > > > >
> > > >
> > > > Hmm, what does CONFIG_DEBUG_VM say?
> > >
> > > No set.
> >
> > Sorry, should have read "Not set"
> >
>
> I mean if it's set, what does it emit to the kernel log with my patch
> applied?
>
> I made CONFIG_DEBUG_VM catch !node_online(node) about six months ago, so I
> was thinking it would have caught this if either you or Stephen enable it.
Sorry, got it... CONFIG_DEBUG_VM enabled below...
pid_max: default: 32768 minimum: 301
Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys cpuacct
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
POWER7 performance monitor hardware support registered
------------[ cut here ]------------
kernel BUG at /scratch/mikey/src/linux-next/include/linux/gfp.h:318!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in:
NIP: c000000000199164 LR: c0000000001993e0 CTR: c0000000000b6b70
REGS: c00000007e583830 TRAP: 0700 Tainted: G W (3.4.0-rc6-mikey)
MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 28004028 XER: 02000000
SOFTE: 1
CFAR: c0000000001993c4
TASK = c00000007e560000[1] 'swapper/0' THREAD: c00000007e580000 CPU: 0
GPR00: 0000000000000001 c00000007e583ab0 c000000000c035a0 00000000000012d0
GPR04: 0000000000000000 0000000000000001 c000000000e14900 0005055500000001
GPR08: 0000000000000001 00000000000012d0 c000000000c6f398 0000000000000001
GPR12: 0000000028004022 c00000000ff20000 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000001380 0000000000000000
GPR20: 0000000000000001 c000000000e14900 c000000000e148f0 0000000000210d00
GPR24: 0000000000000001 00000000000000d0 00000000000002aa 0000000000000000
GPR28: 00000000000000d0 0000000000000001 c000000000b58fc8 c00000007e021200
NIP [c000000000199164] .new_slab+0xb4/0x440
LR [c0000000001993e0] .new_slab+0x330/0x440
Call Trace:
[c00000007e583ab0] [c0000000001993e0] .new_slab+0x330/0x440 (unreliable)
[c00000007e583b60] [c00000000072ce84] .__slab_alloc+0x3bc/0x52c
[c00000007e583ca0] [c000000000199b08] .kmem_cache_alloc_node_trace+0x98/0x280
[c00000007e583d60] [c000000000a5a440] .numa_init+0x9c/0x188
[c00000007e583e00] [c00000000000aa30] .do_one_initcall+0x60/0x1e0
[c00000007e583ec0] [c000000000a40b60] .kernel_init+0x128/0x294
[c00000007e583f90] [c000000000020788] .kernel_thread+0x54/0x70
Instruction dump:
7b5b8402 7f6407b4 7c1ce378 7d29e038 7b990020 61291200 79230020 419202b8
2b9d00ff 78840020 38000001 409d0240 <0b000000> e95e8140 792977e2 7bab1f24
---[ end trace 31fd0ba7d8756002 ]---
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: David Rientjes @ 2012-05-22 2:44 UTC (permalink / raw)
To: Michael Neuling
Cc: Stephen Rothwell, LKML, linux-next, ppc-dev, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn,
Linus
In-Reply-To: <2246.1337654423@neuling.org>
On Tue, 22 May 2012, Michael Neuling wrote:
> > > > Trying David's patch just posted doesn't fix it.
> > > >
> > >
> > > Hmm, what does CONFIG_DEBUG_VM say?
> >
> > No set.
>
> Sorry, should have read "Not set"
>
I mean if it's set, what does it emit to the kernel log with my patch
applied?
I made CONFIG_DEBUG_VM catch !node_online(node) about six months ago, so I
was thinking it would have caught this if either you or Stephen enable it.
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Michael Neuling @ 2012-05-22 2:40 UTC (permalink / raw)
To: David Rientjes
Cc: Stephen Rothwell, LKML, linux-next, ppc-dev, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn,
Linus
In-Reply-To: <2182.1337654352@neuling.org>
Michael Neuling <mikey@neuling.org> wrote:
> > > Trying David's patch just posted doesn't fix it.
> > >
> >
> > Hmm, what does CONFIG_DEBUG_VM say?
>
> No set.
Sorry, should have read "Not set"
mikey
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Michael Neuling @ 2012-05-22 2:39 UTC (permalink / raw)
To: David Rientjes
Cc: Stephen Rothwell, LKML, linux-next, ppc-dev, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn,
Linus
In-Reply-To: <alpine.DEB.2.00.1205211924390.13682@chino.kir.corp.google.com>
> > Trying David's patch just posted doesn't fix it.
> >
>
> Hmm, what does CONFIG_DEBUG_VM say?
No set.
Mikey
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: David Rientjes @ 2012-05-22 2:25 UTC (permalink / raw)
To: Michael Neuling
Cc: Stephen Rothwell, LKML, linux-next, ppc-dev, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn,
Linus
In-Reply-To: <328.1337652722@neuling.org>
On Tue, 22 May 2012, Michael Neuling wrote:
> console [tty0] enabled
> console [hvc0] enabled
> pid_max: default: 32768 minimum: 301
> Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
> Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
> Mount-cache hash table entries: 4096
> Initializing cgroup subsys cpuacct
> Initializing cgroup subsys devices
> Initializing cgroup subsys freezer
> POWER7 performance monitor hardware support registered
> Unable to handle kernel paging request for data at address 0x00001388
> Faulting instruction address: 0xc00000000014a070
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in:
> NIP: c00000000014a070 LR: c0000000001978cc CTR: c0000000000b6870
> REGS: c00000007e5836b0 TRAP: 0300 Tainted: G W (3.4.0-rc6-mikey)
> MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 28004022 XER: 02000000
> SOFTE: 1
> CFAR: 00000000000050fc
> DAR: 0000000000001388, DSISR: 40000000
> TASK = c00000007e560000[1] 'swapper/0' THREAD: c00000007e580000 CPU: 0
> GPR00: 0000000000000000 c00000007e583930 c000000000c034d8 00000000000012d0
> GPR04: 0000000000000000 0000000000001380 0000000000000000 0000000000000001
> GPR08: c00000007e0dff60 0000000000000000 c000000000ca05a0 0000000000000000
> GPR12: 0000000028004024 c00000000ff20000 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000001 0000000000001380
> GPR20: 0000000000000001 c000000000e14900 c000000000e148f0 0000000000000001
> GPR24: c000000000c6f378 0000000000000000 0000000000001380 00000000000002aa
> GPR28: 0000000000000000 0000000000000000 c000000000b576b0 c00000007e021200
> NIP [c00000000014a070] .__alloc_pages_nodemask+0xd0/0x910
> LR [c0000000001978cc] .new_slab+0xcc/0x3d0
> Call Trace:
> [c00000007e583930] [c00000007e5839c0] 0xc00000007e5839c0 (unreliable)
> [c00000007e583ac0] [c0000000001978cc] .new_slab+0xcc/0x3d0
> [c00000007e583b70] [c00000000072ae98] .__slab_alloc+0x38c/0x4f8
> [c00000007e583cb0] [c000000000198190] .kmem_cache_alloc_node_trace+0x90/0x260
> [c00000007e583d60] [c000000000a5a404] .numa_init+0x9c/0x188
> [c00000007e583e00] [c00000000000aa30] .do_one_initcall+0x60/0x1e0
> [c00000007e583ec0] [c000000000a40b60] .kernel_init+0x128/0x294
> [c00000007e583f90] [c000000000020788] .kernel_thread+0x54/0x70
> Instruction dump:
> 0b000000 eb1e8000 3b800000 801800a8 2f800000 409e001c 7860efe3 38000000
> 41820008 38000002 787c6fe2 7f9c0378 <e93a0008> 801800a4 3b600000 2fa90000
> ---[ end trace 31fd0ba7d8756002 ]---
>
> Which seems to be this code in __alloc_pages_nodemask
> ---
> /*
> * Check the zones suitable for the gfp_mask contain at least one
> * valid zone. It's possible to have an empty zonelist as a result
> * of GFP_THISNODE and a memoryless node
> */
> if (unlikely(!zonelist->_zonerefs->zone))
> c00000000014a070: e9 3a 00 08 ld r9,8(r26)
> ---
>
> r26 is coming from r5 which is the struct zonelist *zonelist parameter
> to __alloc_pages_nodemask. Having 0000000000001380 in there is clearly
> a bogus pointer.
>
> Bisecting it points to b4cdf91668c27a5a6a5a3ed4234756c042dd8288
> b4cdf91 sched/numa: Implement numa balancer
>
> Trying David's patch just posted doesn't fix it.
>
Hmm, what does CONFIG_DEBUG_VM say?
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Michael Neuling @ 2012-05-22 2:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: LKML, linux-next, ppc-dev, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn, Linus
In-Reply-To: <20120522114051.0c9db9a7c2d660bc9e0e1be2@canb.auug.org.au>
> Hi all,
>
> Last nights boot tests on various PowerPC systems failed like this:
>
> calling .numa_group_init+0x0/0x3c @ 1
> initcall .numa_group_init+0x0/0x3c returned 0 after 0 usecs
> calling .numa_init+0x0/0x1dc @ 1
> Unable to handle kernel paging request for data at address 0x00001688
> Faulting instruction address: 0xc00000000016e154
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 NUMA pSeries
> Modules linked in:
> NIP: c00000000016e154 LR: c0000000001b9140 CTR: 0000000000000000
> REGS: c0000003fc8c76d0 TRAP: 0300 Not tainted (3.4.0-autokern1)
> MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24044022 XER: 00000003
> SOFTE: 1
> CFAR: 000000000000562c
> DAR: 0000000000001688, DSISR: 40000000
> TASK = c0000003fc8c8000[1] 'swapper/0' THREAD: c0000003fc8c4000 CPU: 0
> GPR00: 0000000000000000 c0000003fc8c7950 c000000000d05b30 00000000000012d0
> GPR04: 0000000000000000 0000000000001680 0000000000000000 c0000003fe032f60
> GPR08: 0004005400000001 0000000000000000 ffffffffffffc980 c000000000d24fe0
> GPR12: 0000000024044024 c00000000f33b000 0000000001a3fa78 00000000009bac00
> GPR16: 0000000000e1f338 0000000002d513f0 0000000000001680 0000000000000000
> GPR20: 0000000000000001 c0000003fc8c7c00 0000000000000000 0000000000000001
> GPR24: 0000000000000001 c000000000d1b490 0000000000000000 0000000000001680
> GPR28: 0000000000000000 0000000000000000 c000000000c7ce58 c0000003fe009200
> NIP [c00000000016e154] .__alloc_pages_nodemask+0xc4/0x8f0
> LR [c0000000001b9140] .new_slab+0xd0/0x3c0
> Call Trace:
> [c0000003fc8c7950] [2e6e756d615f696e] 0x2e6e756d615f696e (unreliable)
> [c0000003fc8c7ae0] [c0000000001b9140] .new_slab+0xd0/0x3c0
> [c0000003fc8c7b90] [c0000000001b9844] .__slab_alloc+0x254/0x5b0
> [c0000003fc8c7cd0] [c0000000001bb7a4] .kmem_cache_alloc_node_trace+0x94/0x260
> [c0000003fc8c7d80] [c000000000ba36d0] .numa_init+0x98/0x1dc
> [c0000003fc8c7e10] [c00000000000ace4] .do_one_initcall+0x1a4/0x1e0
> [c0000003fc8c7ed0] [c000000000b7b354] .kernel_init+0x124/0x2e0
> [c0000003fc8c7f90] [c0000000000211c8] .kernel_thread+0x54/0x70
> Instruction dump:
> 5400d97e 7b170020 0b000000 eb3e8000 3b800000 80190088 2f800000 40de0014
> 7860efe2 787c6fe2 78000fa4 7f9c0378 <e81b0008> 83f90000 2fa00000 7fff1838
> ---[ end trace 31fd0ba7d8756001 ]---
>
> swapper/0 (1) used greatest stack depth: 10864 bytes left
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> I may be completely wrong, but I guess the obvious target would be the
> sched/numa branch that came in via the tip tree.
>
> Config file attached. I haven't had a chance to try to bisect this yet.
>
> Anyone have any ideas?
I'm getting similar here:
console [tty0] enabled
console [hvc0] enabled
pid_max: default: 32768 minimum: 301
Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys cpuacct
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
POWER7 performance monitor hardware support registered
Unable to handle kernel paging request for data at address 0x00001388
Faulting instruction address: 0xc00000000014a070
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in:
NIP: c00000000014a070 LR: c0000000001978cc CTR: c0000000000b6870
REGS: c00000007e5836b0 TRAP: 0300 Tainted: G W (3.4.0-rc6-mikey)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 28004022 XER: 02000000
SOFTE: 1
CFAR: 00000000000050fc
DAR: 0000000000001388, DSISR: 40000000
TASK = c00000007e560000[1] 'swapper/0' THREAD: c00000007e580000 CPU: 0
GPR00: 0000000000000000 c00000007e583930 c000000000c034d8 00000000000012d0
GPR04: 0000000000000000 0000000000001380 0000000000000000 0000000000000001
GPR08: c00000007e0dff60 0000000000000000 c000000000ca05a0 0000000000000000
GPR12: 0000000028004024 c00000000ff20000 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000001 0000000000001380
GPR20: 0000000000000001 c000000000e14900 c000000000e148f0 0000000000000001
GPR24: c000000000c6f378 0000000000000000 0000000000001380 00000000000002aa
GPR28: 0000000000000000 0000000000000000 c000000000b576b0 c00000007e021200
NIP [c00000000014a070] .__alloc_pages_nodemask+0xd0/0x910
LR [c0000000001978cc] .new_slab+0xcc/0x3d0
Call Trace:
[c00000007e583930] [c00000007e5839c0] 0xc00000007e5839c0 (unreliable)
[c00000007e583ac0] [c0000000001978cc] .new_slab+0xcc/0x3d0
[c00000007e583b70] [c00000000072ae98] .__slab_alloc+0x38c/0x4f8
[c00000007e583cb0] [c000000000198190] .kmem_cache_alloc_node_trace+0x90/0x260
[c00000007e583d60] [c000000000a5a404] .numa_init+0x9c/0x188
[c00000007e583e00] [c00000000000aa30] .do_one_initcall+0x60/0x1e0
[c00000007e583ec0] [c000000000a40b60] .kernel_init+0x128/0x294
[c00000007e583f90] [c000000000020788] .kernel_thread+0x54/0x70
Instruction dump:
0b000000 eb1e8000 3b800000 801800a8 2f800000 409e001c 7860efe3 38000000
41820008 38000002 787c6fe2 7f9c0378 <e93a0008> 801800a4 3b600000 2fa90000
---[ end trace 31fd0ba7d8756002 ]---
Which seems to be this code in __alloc_pages_nodemask
---
/*
* Check the zones suitable for the gfp_mask contain at least one
* valid zone. It's possible to have an empty zonelist as a result
* of GFP_THISNODE and a memoryless node
*/
if (unlikely(!zonelist->_zonerefs->zone))
c00000000014a070: e9 3a 00 08 ld r9,8(r26)
---
r26 is coming from r5 which is the struct zonelist *zonelist parameter
to __alloc_pages_nodemask. Having 0000000000001380 in there is clearly
a bogus pointer.
Bisecting it points to b4cdf91668c27a5a6a5a3ed4234756c042dd8288
b4cdf91 sched/numa: Implement numa balancer
Trying David's patch just posted doesn't fix it.
Mikey
^ permalink raw reply
* linux-next: manual merge of the nfs tree with Linus' tree
From: Stephen Rothwell @ 2012-05-22 2:10 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-next, linux-kernel, Linus
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
Hi Trond,
Today's linux-next merge of the nfs tree got a conflict in
fs/nfs/nfs4proc.c between commit 26fe57502870 ("vfs: make it possible to
access the dentry hash/len as one 64-bit entry") from Linus' tree and
commit 778d28172f71 ("NFSv4: Simplify the NFSv4 REMOVE, LINK and RENAME
compounds") from the nfs tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc fs/nfs/nfs4proc.c
index ab985f6,78784e5..0000000
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@@ -2782,8 -2799,8 +2799,7 @@@ static int _nfs4_proc_remove(struct ino
struct nfs_server *server = NFS_SERVER(dir);
struct nfs_removeargs args = {
.fh = NFS_FH(dir),
- .name.len = name->len,
- .name.name = name->name,
+ .name = *name,
- .bitmask = server->attr_bitmask,
};
struct nfs_removeres res = {
.server = server,
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: David Rientjes @ 2012-05-22 1:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: LKML, linux-next, ppc-dev, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Lee Schermerhorn, Linus
In-Reply-To: <20120522114051.0c9db9a7c2d660bc9e0e1be2@canb.auug.org.au>
On Tue, 22 May 2012, Stephen Rothwell wrote:
> Unable to handle kernel paging request for data at address 0x00001688
> Faulting instruction address: 0xc00000000016e154
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 NUMA pSeries
> Modules linked in:
> NIP: c00000000016e154 LR: c0000000001b9140 CTR: 0000000000000000
> REGS: c0000003fc8c76d0 TRAP: 0300 Not tainted (3.4.0-autokern1)
> MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24044022 XER: 00000003
> SOFTE: 1
> CFAR: 000000000000562c
> DAR: 0000000000001688, DSISR: 40000000
> TASK = c0000003fc8c8000[1] 'swapper/0' THREAD: c0000003fc8c4000 CPU: 0
> GPR00: 0000000000000000 c0000003fc8c7950 c000000000d05b30 00000000000012d0
> GPR04: 0000000000000000 0000000000001680 0000000000000000 c0000003fe032f60
> GPR08: 0004005400000001 0000000000000000 ffffffffffffc980 c000000000d24fe0
> GPR12: 0000000024044024 c00000000f33b000 0000000001a3fa78 00000000009bac00
> GPR16: 0000000000e1f338 0000000002d513f0 0000000000001680 0000000000000000
> GPR20: 0000000000000001 c0000003fc8c7c00 0000000000000000 0000000000000001
> GPR24: 0000000000000001 c000000000d1b490 0000000000000000 0000000000001680
> GPR28: 0000000000000000 0000000000000000 c000000000c7ce58 c0000003fe009200
> NIP [c00000000016e154] .__alloc_pages_nodemask+0xc4/0x8f0
> LR [c0000000001b9140] .new_slab+0xd0/0x3c0
> Call Trace:
> [c0000003fc8c7950] [2e6e756d615f696e] 0x2e6e756d615f696e (unreliable)
> [c0000003fc8c7ae0] [c0000000001b9140] .new_slab+0xd0/0x3c0
> [c0000003fc8c7b90] [c0000000001b9844] .__slab_alloc+0x254/0x5b0
> [c0000003fc8c7cd0] [c0000000001bb7a4] .kmem_cache_alloc_node_trace+0x94/0x260
> [c0000003fc8c7d80] [c000000000ba36d0] .numa_init+0x98/0x1dc
> [c0000003fc8c7e10] [c00000000000ace4] .do_one_initcall+0x1a4/0x1e0
> [c0000003fc8c7ed0] [c000000000b7b354] .kernel_init+0x124/0x2e0
> [c0000003fc8c7f90] [c0000000000211c8] .kernel_thread+0x54/0x70
> Instruction dump:
> 5400d97e 7b170020 0b000000 eb3e8000 3b800000 80190088 2f800000 40de0014
> 7860efe2 787c6fe2 78000fa4 7f9c0378 <e81b0008> 83f90000 2fa00000 7fff1838
> ---[ end trace 31fd0ba7d8756001 ]---
>
> swapper/0 (1) used greatest stack depth: 10864 bytes left
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> I may be completely wrong, but I guess the obvious target would be the
> sched/numa branch that came in via the tip tree.
>
> Config file attached. I haven't had a chance to try to bisect this yet.
>
> Anyone have any ideas?
Yeah, it's sched/numa since that's what introduced numa_init(). It does
for_each_node() for each node and does a kmalloc_node() even though that
node may not be online. Slub ends up passing this node to the page
allocator through alloc_pages_exact_node(). CONFIG_DEBUG_VM would have
caught this and your config confirms its not enabled.
sched/numa either needs a memory hotplug notifier or it needs to pass
NUMA_NO_NODE for nodes that aren't online. Until we get the former, the
following should fix it.
sched, numa: Allocate node_queue on any node for offline nodes
struct node_queue must be allocated with NUMA_NO_NODE for nodes that are
not (yet) online, otherwise the page allocator has a bad zonelist.
Signed-off-by: David Rientjes <rientjes@google.com>
---
diff --git a/kernel/sched/numa.c b/kernel/sched/numa.c
--- a/kernel/sched/numa.c
+++ b/kernel/sched/numa.c
@@ -885,7 +885,8 @@ static __init int numa_init(void)
for_each_node(node) {
struct node_queue *nq = kmalloc_node(sizeof(*nq),
- GFP_KERNEL | __GFP_ZERO, node);
+ GFP_KERNEL | __GFP_ZERO,
+ node_online(node) ? node : NUMA_NO_NODE);
BUG_ON(!nq);
spin_lock_init(&nq->lock);
^ permalink raw reply
* linux-next: manual merge of the ceph tree with Linus' tree
From: Stephen Rothwell @ 2012-05-22 1:45 UTC (permalink / raw)
To: Sage Weil; +Cc: linux-next, linux-kernel, Eric Dumazet, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]
Hi Sage,
Today's linux-next merge of the ceph tree got a conflict in
net/ceph/messenger.c between commit 95c961747284 ("net: cleanup unsigned
to unsigned int") from Linus' tree and commit 57dac9d16209 ("ceph:
messenger: use read_partial() in read_partial_message()") from the ceph
tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/ceph/messenger.c
index 36fa6bf,1a80907..0000000
--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@@ -695,12 -698,12 +698,12 @@@ static void prepare_write_banner(struc
set_bit(WRITE_PENDING, &con->state);
}
- static int prepare_write_connect(struct ceph_messenger *msgr,
- struct ceph_connection *con,
- int include_banner)
+ static int prepare_write_connect(struct ceph_connection *con)
{
- unsigned global_seq = get_global_seq(con->msgr, 0);
+ unsigned int global_seq = get_global_seq(con->msgr, 0);
int proto;
+ int auth_proto;
+ struct ceph_auth_handshake *auth;
switch (con->peer_name.type) {
case CEPH_ENTITY_TYPE_MON:
@@@ -1627,9 -1663,10 +1663,10 @@@ static int read_partial_message_bio(str
static int read_partial_message(struct ceph_connection *con)
{
struct ceph_msg *m = con->in_msg;
+ int size;
+ int end;
int ret;
- int to, left;
- unsigned front_len, middle_len, data_len;
+ unsigned int front_len, middle_len, data_len;
bool do_datacrc = !con->msgr->nocrc;
int skip;
u64 seq;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: PowerPC boot failures in next-20120521
From: Stephen Rothwell @ 2012-05-22 1:40 UTC (permalink / raw)
To: LKML
Cc: linux-next, ppc-dev, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Lee Schermerhorn, Linus
[-- Attachment #1.1: Type: text/plain, Size: 2690 bytes --]
Hi all,
Last nights boot tests on various PowerPC systems failed like this:
calling .numa_group_init+0x0/0x3c @ 1
initcall .numa_group_init+0x0/0x3c returned 0 after 0 usecs
calling .numa_init+0x0/0x1dc @ 1
Unable to handle kernel paging request for data at address 0x00001688
Faulting instruction address: 0xc00000000016e154
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 NUMA pSeries
Modules linked in:
NIP: c00000000016e154 LR: c0000000001b9140 CTR: 0000000000000000
REGS: c0000003fc8c76d0 TRAP: 0300 Not tainted (3.4.0-autokern1)
MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24044022 XER: 00000003
SOFTE: 1
CFAR: 000000000000562c
DAR: 0000000000001688, DSISR: 40000000
TASK = c0000003fc8c8000[1] 'swapper/0' THREAD: c0000003fc8c4000 CPU: 0
GPR00: 0000000000000000 c0000003fc8c7950 c000000000d05b30 00000000000012d0
GPR04: 0000000000000000 0000000000001680 0000000000000000 c0000003fe032f60
GPR08: 0004005400000001 0000000000000000 ffffffffffffc980 c000000000d24fe0
GPR12: 0000000024044024 c00000000f33b000 0000000001a3fa78 00000000009bac00
GPR16: 0000000000e1f338 0000000002d513f0 0000000000001680 0000000000000000
GPR20: 0000000000000001 c0000003fc8c7c00 0000000000000000 0000000000000001
GPR24: 0000000000000001 c000000000d1b490 0000000000000000 0000000000001680
GPR28: 0000000000000000 0000000000000000 c000000000c7ce58 c0000003fe009200
NIP [c00000000016e154] .__alloc_pages_nodemask+0xc4/0x8f0
LR [c0000000001b9140] .new_slab+0xd0/0x3c0
Call Trace:
[c0000003fc8c7950] [2e6e756d615f696e] 0x2e6e756d615f696e (unreliable)
[c0000003fc8c7ae0] [c0000000001b9140] .new_slab+0xd0/0x3c0
[c0000003fc8c7b90] [c0000000001b9844] .__slab_alloc+0x254/0x5b0
[c0000003fc8c7cd0] [c0000000001bb7a4] .kmem_cache_alloc_node_trace+0x94/0x260
[c0000003fc8c7d80] [c000000000ba36d0] .numa_init+0x98/0x1dc
[c0000003fc8c7e10] [c00000000000ace4] .do_one_initcall+0x1a4/0x1e0
[c0000003fc8c7ed0] [c000000000b7b354] .kernel_init+0x124/0x2e0
[c0000003fc8c7f90] [c0000000000211c8] .kernel_thread+0x54/0x70
Instruction dump:
5400d97e 7b170020 0b000000 eb3e8000 3b800000 80190088 2f800000 40de0014
7860efe2 787c6fe2 78000fa4 7f9c0378 <e81b0008> 83f90000 2fa00000 7fff1838
---[ end trace 31fd0ba7d8756001 ]---
swapper/0 (1) used greatest stack depth: 10864 bytes left
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
I may be completely wrong, but I guess the obvious target would be the
sched/numa branch that came in via the tip tree.
Config file attached. I haven't had a chance to try to bisect this yet.
Anyone have any ideas?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #1.2: dotconfig.bz2 --]
[-- Type: application/octet-stream, Size: 15419 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: at91: Add ADC driver to at91sam9260/at91sam9g20 dtsi files
From: Stephen Rothwell @ 2012-05-21 23:19 UTC (permalink / raw)
To: Nicolas Ferre
Cc: linux-next, Greg KH, Arnd Bergmann, linux-arm-kernel,
linux-kernel, plagnioj, maxime.ripard, olof
In-Reply-To: <4FBA1483.4010008@atmel.com>
[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]
Hi Nicolas,
On Mon, 21 May 2012 12:10:11 +0200 Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>
> After checking the current status of
> arch/arm/boot/dts/at91sam9g20.dtsi in linux-next, it seems the merge
> resolution has not produced a good result:
>
> The "adc0" node, should only look like:
>
> ahb {
> apb {
> adc0: adc@fffe0000 {
> atmel,adc-startup-time = <40>;
> };
> };
> };
>
> without the redundant code carried by the staging git tree. In short,
> the arm-soc version is the proper one.
Rats! That was an automatic merge resolution and I didn't even notice,
sorry. I will fix it up today in linux-next, but someone needs to
remember to tell Linus when the second if these two trees is merged.
I will apply the following as a merge fixup patch after merging the
arm-soc tree (which comes later in my sequence):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 May 2012 09:17:31 +1000
Subject: [PATCH] ARM:at91: merge fixup for dtsi file
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arm/boot/dts/at91sam9g20.dtsi | 35 -----------------------------------
1 file changed, 35 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi b/arch/arm/boot/dts/at91sam9g20.dtsi
index 06ca15b..2a1d1ca 100644
--- a/arch/arm/boot/dts/at91sam9g20.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20.dtsi
@@ -21,41 +21,6 @@
adc0: adc@fffe0000 {
atmel,adc-startup-time = <40>;
};
-
- adc0: adc@fffe0000 {
- compatible = "atmel,at91sam9260-adc";
- reg = <0xfffe0000 0x100>;
- interrupts = <5 4>;
- atmel,adc-use-external-triggers;
- atmel,adc-channels-used = <0xf>;
- atmel,adc-vref = <3300>;
- atmel,adc-num-channels = <4>;
- atmel,adc-startup-time = <10>;
- atmel,adc-channel-base = <0x30>;
- atmel,adc-drdy-mask = <0x10000>;
- atmel,adc-status-register = <0x1c>;
- atmel,adc-trigger-register = <0x04>;
-
- trigger@0 {
- trigger-name = "timer-counter-0";
- trigger-value = <0x1>;
- };
- trigger@1 {
- trigger-name = "timer-counter-1";
- trigger-value = <0x3>;
- };
-
- trigger@2 {
- trigger-name = "timer-counter-2";
- trigger-value = <0x5>;
- };
-
- trigger@3 {
- trigger-name = "external";
- trigger-value = <0x13>;
- trigger-external;
- };
- };
};
};
};
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* linux-next: unable to fetch the watchdog tree
From: Stephen Rothwell @ 2012-05-21 23:16 UTC (permalink / raw)
To: Wim Van Sebroeck; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
Hi Wim,
When I have tried to fetch the watchdog tree (from
git://www.linux-watchdog.org/linux-watchdog-next.git) today and
yesterday, the "git fetch" get a connection, but after some time (maybe
immediately) it hangs and I eventually have to kill the "git fetch".
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the userns tree with the tip tree
From: Eric W. Biederman @ 2012-05-21 23:02 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20120521173006.3c10df123692914ab19497b8@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Eric,
>
> Today's linux-next merge of the userns tree got a conflict in
> include/linux/sched.h between commit 50954a1f450e ("sched/numa: Provide
> sysctl knob to disable numa scheduling and turn it off by default") from
> the tip tree and commit 7b44ab978b77 ("userns: Disassociate user_struct
> from the user_namespace") from the userns tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
It looks reasonable. Thanks.
Eric
^ permalink raw reply
* Re: linux-next: build failure after merge of the userns tree
From: Eric W. Biederman @ 2012-05-21 22:05 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20120521175009.7bd4948c026d8acc61f26753@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Eric,
>
> After merging the userns tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> kernel/sched/numa.c: In function 'ng_allowed':
> kernel/sched/numa.c:1270:16: error: 'struct user_struct' has no member named 'user_ns'
> kernel/sched/numa.c:1270:40: error: 'struct user_struct' has no member named 'user_ns'
> kernel/sched/numa.c:1278:28: error: 'struct user_struct' has no member named 'user_ns'
>
> Caused by commit a2dae61eb839 ("sched/numa: Introduce sys_numa_{t,m}bind
> ()") from the tip tree interacting with commit d0bd6594e286 ("userns:
> Deprecate and rename the user_namespace reference in the user_struct")
> from the userns tree.
>
> I applied this merge fix up patch (more may be required):
The fix is right.
Peter Zijlstra, or Ingo any chance you could add the patch below to your
tree?
It is just a better idiom to access the user namespace pointer as
cred->user_ns, instead of cred->user->user_ns and has been for a few
kernel releases.
Once my usernamespace tree is merged into Linus's tree a little more
will be needed to build this code with user namespaces enabled, but
cred->user->user to cred->user_ns is an improvement whichever way
you look at it.
Otherwise I guess this merge failure will act as a reminder that this
code needs a few more changes.
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 21 May 2012 17:40:55 +1000
> Subject: [PATCH] userns: fix up for user_ns move to struct cred
>
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> kernel/sched/numa.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/numa.c b/kernel/sched/numa.c
> index 8eb92f7..1149993 100644
> --- a/kernel/sched/numa.c
> +++ b/kernel/sched/numa.c
> @@ -1267,7 +1267,7 @@ static int ng_allowed(struct numa_group *ng, struct task_struct *p)
>
> rcu_read_lock();
> tcred = __task_cred(p);
> - if (cred->user->user_ns == tcred->user->user_ns &&
> + if (cred->user_ns == tcred->user_ns &&
> (cred->uid == tcred->euid &&
> cred->uid == tcred->suid &&
> cred->uid == tcred->uid &&
> @@ -1275,7 +1275,7 @@ static int ng_allowed(struct numa_group *ng, struct task_struct *p)
> cred->gid == tcred->sgid &&
> cred->gid == tcred->gid))
> goto ok;
> - if (ns_capable(tcred->user->user_ns, CAP_SYS_PTRACE))
> + if (ns_capable(tcred->user_ns, CAP_SYS_PTRACE))
> goto ok;
> rcu_read_unlock();
> return -EPERM;
> --
> 1.7.10.280.gaa39
^ permalink raw reply
* RE: [PATCH -next v2] usb: add usb.h stubs for CONFIG_USB not enabled
From: H Hartley Sweeten @ 2012-05-21 16:48 UTC (permalink / raw)
To: Randy Dunlap, Greg Kroah-Hartman
Cc: devel@driverdev.osuosl.org, Frank Mori Hess, Sergei Shtylyov,
Stephen Rothwell, linux-usb@vger.kernel.org, LKML, Ian Abbott,
linux-next@vger.kernel.org
In-Reply-To: <4FB7CACF.9030302@xenotime.net>
On Saturday, May 19, 2012 9:31 AM, Randy Dunlap wrote:
>
> Add stubs for some usb core functions when CONFIG_USB
> is not enabled. This fixes these comedi build errors:
>
> ERROR: "usb_deregister" [drivers/staging/comedi/comedi.ko] undefined!
> ERROR: "usb_register_driver" [drivers/staging/comedi/comedi.ko] undefined!
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Sorry about causing the trouble with my changes to the comedi staging driver.
I, wrongly, assumed that the usb register/deregister functions are already
stubbed like the pci functions. I'll make sure the check in the future.
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* Re: linux-next: build failure after merge of the infiniband tree
From: Roland Dreier @ 2012-05-21 16:03 UTC (permalink / raw)
To: Vipul Pandya
Cc: Stephen Rothwell, linux-rdma, linux-next, linux-kernel,
Steve Wise
In-Reply-To: <4FBA4B84.9030302@chelsio.com>
> diff --git a/drivers/infiniband/hw/cxgb4/device.c
> b/drivers/infiniband/hw/cxgb4/device.c
> index c8fd1d8..cb4ecd7 100644
> --- a/drivers/infiniband/hw/cxgb4/device.c
> +++ b/drivers/infiniband/hw/cxgb4/device.c
> @@ -32,6 +32,7 @@
> #include <linux/module.h>
> #include <linux/moduleparam.h>
> #include <linux/debugfs.h>
> +#include <linux/vmalloc.h>
>
> #include <rdma/ib_verbs.h>
Thanks, I folded this into my pull request.
^ permalink raw reply
* Re: linux-next: Tree for May 21
From: Stephen Rothwell @ 2012-05-21 15:44 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-next, LKML
In-Reply-To: <20120522014136.f2b26f8eddab621e8dcf8e22@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
Hi Randy,
On Tue, 22 May 2012 01:41:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 21 May 2012 08:09:49 -0700 Randy Dunlap <rdunlap@xenotime.net> wrote:
> >
> > no linux-next 20120521 patch file :(
>
> It was uploaded (it is scripted) so the mirroring must be broken, I guess.
I can see it there now.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for May 21
From: Stephen Rothwell @ 2012-05-21 15:41 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-next, LKML
In-Reply-To: <4FBA5ABD.2070003@xenotime.net>
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
Hi Randy,
On Mon, 21 May 2012 08:09:49 -0700 Randy Dunlap <rdunlap@xenotime.net> wrote:
>
> no linux-next 20120521 patch file :(
It was uploaded (it is scripted) so the mirroring must be broken, I guess.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for May 21
From: Randy Dunlap @ 2012-05-21 15:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20120521190531.b764b9cd339c883d3434aef8@canb.auug.org.au>
On 05/21/2012 02:05 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 201205018:
> ----------------------------------------------------------------------------
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).
no linux-next 20120521 patch file :(
--
~Randy
^ permalink raw reply
* Re: linux-next: build failure after merge of the infiniband tree
From: Vipul Pandya @ 2012-05-21 14:04 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Roland Dreier, linux-rdma, linux-next, linux-kernel, Steve Wise
In-Reply-To: <20120521120512.15f1e9dfc961b05dfee72f79@canb.auug.org.au>
On 21-05-2012 07:35, Stephen Rothwell wrote:
> Hi all,
>
> After merging the infiniband tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/infiniband/hw/cxgb4/device.c: In function 'qp_release':
> drivers/infiniband/hw/cxgb4/device.c:124:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
> drivers/infiniband/hw/cxgb4/device.c: In function 'qp_open':
> drivers/infiniband/hw/cxgb4/device.c:148:2: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration]
> drivers/infiniband/hw/cxgb4/device.c:148:11: warning: assignment makes pointer from integer without a cast [enabled by default]
>
> Caused by commit d716a2a014ad ("RDMA/cxgb4: Use vmalloc() for debugfs QP
> dump"). See Rule 1 in Documentation/SubmitChecklist.
>
> I have used the infiniband tree from next-20120518 for today.
>
Hi Stephen,
Below patch should resolve this issue.
>From 433d2002d3ba2119146fdec6e0a97b67834df960 Mon Sep 17 00:00:00 2001
From: Vipul Pandya <vipul@chelsio.com>
Date: Mon, 21 May 2012 17:31:13 +0530
Subject: [PATCH] RDMA/cxgb4: Include vmalloc.h for vmalloc and vfree
Signed-off-by: Vipul Pandya <vipul@chelsio.com>
---
drivers/infiniband/hw/cxgb4/device.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/device.c
b/drivers/infiniband/hw/cxgb4/device.c
index c8fd1d8..cb4ecd7 100644
--- a/drivers/infiniband/hw/cxgb4/device.c
+++ b/drivers/infiniband/hw/cxgb4/device.c
@@ -32,6 +32,7 @@
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/debugfs.h>
+#include <linux/vmalloc.h>
#include <rdma/ib_verbs.h>
--
^ permalink raw reply related
* Re: linux-next: manual merge of the usb tree with the net-next tree
From: Greg KH @ 2012-05-21 13:08 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Sarah Sharp, Kalle Valo, David Miller,
netdev, John W. Linville
In-Reply-To: <20120521161008.c0cc00b91642ed7a3875a686@canb.auug.org.au>
On Mon, May 21, 2012 at 04:10:08PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the usb tree got a conflict in
> drivers/net/wireless/ath/ath6kl/usb.c between commit 9cbee358687e
> ("ath6kl: add full USB support") from the net-next tree and commit
> e1f12eb6ba6f ("USB: Disable hub-initiated LPM for comms devices") from
> the usb tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Looks good to me, thanks.
greg k-h
^ 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