On Thu, 2009-04-30 at 18:10 +0400, Anton Vorontsov wrote:
> > @@ -2194,16 +2197,16 @@ static void *kmem_cache_dyn_array_alloc(
> > * never get freed by definition so we can do it rather
> > * simply.
> > */
> > - if (!nextmem) {
> > -
On Thu, 2009-04-30 at 16:10 +0200, Nick Piggin wrote:
> On Fri, May 01, 2009 at 12:00:33AM +1000, Stephen Rothwell wrote:
> > Hi Nick,
> >
> > On Thu, 30 Apr 2009 15:05:42 +0200 Nick Piggin wrote:
> > >
> > > Hmm, this might do it. The following code now passes some stress testing
> > > in a user
On Thu, Apr 30, 2009 at 03:05:42PM +0200, Nick Piggin wrote:
[...]
> ---
> SLQB: fix dumb early allocation cache
>
> The dumb early allocation cache had a bug where it could allow allocation
> to go past the end of a page, which could cause crashes or random memory
> corruption. Fix this and simpl
On Fri, May 01, 2009 at 12:00:33AM +1000, Stephen Rothwell wrote:
> Hi Nick,
>
> On Thu, 30 Apr 2009 15:05:42 +0200 Nick Piggin wrote:
> >
> > Hmm, this might do it. The following code now passes some stress testing
> > in a userspace harness wheras before it did not (and was obviously wrong).
>
Hi Nick,
On Thu, 30 Apr 2009 15:05:42 +0200 Nick Piggin wrote:
>
> Hmm, this might do it. The following code now passes some stress testing
> in a userspace harness wheras before it did not (and was obviously wrong).
Indeed that allows it to boot fine. Thanks.
Tested-by: Stephen Rothwell
--
On Thu, Apr 30, 2009 at 02:20:29PM +0300, Pekka Enberg wrote:
> On Thu, 2009-04-30 at 13:18 +0200, Nick Piggin wrote:
> > OK thanks. So I think we have 2 problems. One with MAX_ORDER <= 9
> > that is fixed by the previous patch, and another which is probably
> > due to having no memory on node 0 wh
On Thu, Apr 30, 2009 at 02:20:29PM +0300, Pekka Enberg wrote:
> On Thu, 2009-04-30 at 13:18 +0200, Nick Piggin wrote:
> > OK thanks. So I think we have 2 problems. One with MAX_ORDER <= 9
> > that is fixed by the previous patch, and another which is probably
> > due to having no memory on node 0 wh
On Thu, 2009-04-30 at 13:18 +0200, Nick Piggin wrote:
> OK thanks. So I think we have 2 problems. One with MAX_ORDER <= 9
> that is fixed by the previous patch, and another which is probably
> due to having no memory on node 0 which I will take another look
> at now.
>
> We can merge the previous
On Thu, Apr 30, 2009 at 09:00:04PM +1000, Stephen Rothwell wrote:
> Hi Pekka, Nick,
>
> On Thu, 30 Apr 2009 13:38:04 +0300 Pekka Enberg
> wrote:
> >
> > Stephen, does this patch fix all the boot problems for you as well?
>
> Unfortunately not, I am still getting this:
>
> Memory: 1967708k/2097
On Thu, Apr 30, 2009 at 2:00 PM, Stephen Rothwell wrote:
> Hi Pekka, Nick,
>
> On Thu, 30 Apr 2009 13:38:04 +0300 Pekka Enberg
> wrote:
>>
>> Stephen, does this patch fix all the boot problems for you as well?
>
> Unfortunately not, I am still getting this:
>
> Memory: 1967708k/2097152k availabl
Hi Pekka, Nick,
On Thu, 30 Apr 2009 13:38:04 +0300 Pekka Enberg wrote:
>
> Stephen, does this patch fix all the boot problems for you as well?
Unfortunately not, I am still getting this:
Memory: 1967708k/2097152k available (9836k kernel code, 129444k reserved, 1440k
data, 8422k bss, 2092k init
On Thu, 2009-04-30 at 12:35 +0200, Nick Piggin wrote:
> On Thu, Apr 30, 2009 at 03:17:12PM +0530, Sachin Sant wrote:
> > Nick Piggin wrote:
> > >Hmm, forget that. Actually my last patch had a silly mistake because I
> > >forgot MAX_ORDER shift is applied to PAGE_SIZE, rather than 1. So
> > >kmalloc
On Thu, Apr 30, 2009 at 03:17:12PM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >Hmm, forget that. Actually my last patch had a silly mistake because I
> >forgot MAX_ORDER shift is applied to PAGE_SIZE, rather than 1. So
> >kmalloc(PAGE_SIZE) was failing as too large.
> >
> >This patch should d
Nick Piggin wrote:
Hmm, forget that. Actually my last patch had a silly mistake because I
forgot MAX_ORDER shift is applied to PAGE_SIZE, rather than 1. So
kmalloc(PAGE_SIZE) was failing as too large.
This patch should do the trick I hope.
Yes this patch fixed the issue for me. Thanks Nick.
Nick Piggin wrote:
On Thu, Apr 30, 2009 at 11:06:36AM +0530, Sachin Sant wrote:
Hmm, OK. Can you post the disassembly of your pidmap_init please?
Here is the information.
Unable to handle kernel paging request for data at address 0x0010
Faulting instruction address: 0xc07d0404
On Thu, Apr 30, 2009 at 11:06:36AM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >Well kmalloc is failing. It should not be though, even if the
> >current node is offline, it should be able to fall back to other
> >nodes. Stephen's trace indicates the same thing.
> >
> >Could you try the followi
On Thu, Apr 30, 2009 at 11:06:36AM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >Well kmalloc is failing. It should not be though, even if the
> >current node is offline, it should be able to fall back to other
> >nodes. Stephen's trace indicates the same thing.
> >
> >Could you try the followi
Nick Piggin wrote:
Well kmalloc is failing. It should not be though, even if the
current node is offline, it should be able to fall back to other
nodes. Stephen's trace indicates the same thing.
Could you try the following patch please, and capture the output
it generates?
With this patch i don'
On Wed, Apr 29, 2009 at 09:56:19PM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >Does this help?
> >---
> With the patch the machine boots past the failure point, but panics
> immediately with the following trace...
OK good, that solves one problem.
> Unable to handle kernel paging request
Hi Nick,
On Wed, 29 Apr 2009 21:56:19 +0530 Sachin Sant wrote:
>
> Nick Piggin wrote:
> > Does this help?
> > ---
> With the patch the machine boots past the failure point, but panics
> immediately with the following trace...
That patch also changes the behaviour of my machine. I now get:
call
Nick Piggin wrote:
Does this help?
---
With the patch the machine boots past the failure point, but panics
immediately with the following trace...
Unable to handle kernel paging request for data at address 0x0010
Faulting instruction address: 0xc07d03ec
Oops: Kernel access of bad ar
On Tue, Apr 28, 2009 at 02:22:06PM +0300, Pekka Enberg wrote:
> Nick,
>
> Here's another one. I think we need to either fix these rather quickly
> or make SLUB the defaut for linux-next again so we don't interfere
> with other testing.
>
> Pekka
>
> On Tue, A
On Tue, Apr 28, 2009 at 02:22:06PM +0300, Pekka Enberg wrote:
> Nick,
>
> Here's another one. I think we need to either fix these rather quickly
> or make SLUB the defaut for linux-next again so we don't interfere
> with other testing.
Yeah, I'm working on it. Let me either give you a fix or a pa
23 matches
Mail list logo
