On Mon, 22 Jun 2009 08:25:04 +1000
Benjamin Herrenschmidt wrote:
> Kumar already submitted a couple, Frans, feel free to beat me
> at converting UIC (just use kmalloc directly in there instead
> of alloc_bootmem).
I replace the bootmem_alloc with a kzalloc and the badness went away.
So it looks
Hi Sean,
On Mon, Jun 22, 2009 at 1:36 AM, Sean MacLennan wrote:
> On Mon, 22 Jun 2009 08:25:04 +1000
> Benjamin Herrenschmidt wrote:
>
>> Right, our interrupt controllers need those fixes, they are low
>> on my priority list since it's a reasonably harmless warning and I'm
>> still chasing some a
On Sun, 2009-06-21 at 18:36 -0400, Sean MacLennan wrote:
> On Mon, 22 Jun 2009 08:25:04 +1000
> Benjamin Herrenschmidt wrote:
>
> > Right, our interrupt controllers need those fixes, they are low
> > on my priority list since it's a reasonably harmless warning and I'm
> > still chasing some actua
On Mon, 22 Jun 2009 08:25:04 +1000
Benjamin Herrenschmidt wrote:
> Right, our interrupt controllers need those fixes, they are low
> on my priority list since it's a reasonably harmless warning and I'm
> still chasing some actual breakage (though maybe not directly related
> to your patches).
>
On Sun, 2009-06-21 at 13:20 +0300, Pekka Enberg wrote:
> The WARN_ON() is there to let us know that someone is doing a bootmem
> allocation but the slab allocator is already up. So the proper fix
> here is to use kmalloc() directly in the call-site that triggers this
> WARN_ON. I'm cc'ing Ben as he
On Sun, Jun 21, 2009 at 7:28 AM, Frans Pop wrote:
> On Sunday 21 June 2009, Sean MacLennan wrote:
>> I found the source of the badness. The backtrace is correct:
>>
>> uic_init_one
>
> So that's in arch/powerpc/sysdev/uic.c.
>
>> ___alloc_bootmem
>> ___alloc_bootmem_nopanic
>> alloc_arch_preferred_
Frans Pop wrote:
>
> The fact that your bisect ended at a merge essentially means that it is
> invalid. As a merge does not introduce any actual change (unless it
> includes changes to resolve conflicts), it normally cannot be the cause
> of a regression.
>
Sort of. You can have a "bum merge
On Sun, 21 Jun 2009, Frans Pop wrote:
> On Sunday 21 June 2009, Sean MacLennan wrote:
> > On Sat, 20 Jun 2009 22:56:45 +0200 Frans Pop wrote:
> > > The fact that your bisect ended at a merge essentially means that it
> > > is invalid. As a merge does not introduce any actual change (unless
> > >
On Sunday 21 June 2009, Sean MacLennan wrote:
> I found the source of the badness. The backtrace is correct:
>
> uic_init_one
So that's in arch/powerpc/sysdev/uic.c.
> ___alloc_bootmem
> ___alloc_bootmem_nopanic
> alloc_arch_preferred_bootmem
>
> In alloc_arch_preferred_bootmem we have:
>
>
On Sunday 21 June 2009, Sean MacLennan wrote:
> On Sat, 20 Jun 2009 22:56:45 +0200 Frans Pop wrote:
> > The fact that your bisect ended at a merge essentially means that it
> > is invalid. As a merge does not introduce any actual change (unless
> > it includes changes to resolve conflicts), it nor
> The git bisect returned:
>
> 871fa90791a6f83dd8e2e489feb9534a8c02088d is first bad commit
>
> That is it, no more info strange. git show 8714...088d gives:
>
> Merge: 7702667... 79f52b7...
> Author: Linus Torvalds
> Date: Thu Jun 11 11:27:09 2009 -0700
>
> The Warp has jfs disabled, so I
I found the source of the badness. The backtrace is correct:
uic_init_one
___alloc_bootmem
___alloc_bootmem_nopanic
alloc_arch_preferred_bootmem
In alloc_arch_preferred_bootmem we have:
if (WARN_ON_ONCE(slab_is_available()))
return kzalloc(size, GFP_NOWAIT);
Since the sl
On Sat, 20 Jun 2009 22:56:45 +0200
Frans Pop wrote:
> The fact that your bisect ended at a merge essentially means that it
> is invalid. As a merge does not introduce any actual change (unless
> it includes changes to resolve conflicts), it normally cannot be the
> cause of a regression.
Makes s
[0.00] [ cut here ]
[0.00] Badness at c033ebc4 [verbose debug info unavailable]
[0.00] NIP: c033ebc4 LR: c033eb94 CTR:
[0.00] REGS: c037fe70 TRAP: 0700 Not tainted (2.6.30-pika)
[0.00] MSR: 00021000 CR: 22022024 XER: 000
14 matches
Mail list logo
