[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Jun 2008 09:17:07 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: Tree for June 5
* Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Thu, 5 Jun 2008 17:52:17 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> > I have created today's linux-next tree at
> > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
>
> Instantly oopses on two x86_64 boxes with this config:
> http://userweb.kernel.org/~akpm/config-akpm2.txt
>
> oops: http://userweb.kernel.org/~akpm/p6056454.jpg
>
> At a guess I'd say the sched_domains code is calling into slab before
> slab is initalised. Something like that.
did SLUB change in linux-next? There no such problem in -tip.
> I had to do this:
>
> --- a/arch/x86/kernel/traps_64.c~a
> +++ a/arch/x86/kernel/traps_64.c
> @@ -504,6 +504,7 @@ void show_registers(struct pt_regs *regs
> }
> }
> printk("\n");
> + for ( ;; );
> }
>
> int is_valid_bugaddr(unsigned long ip)
> _
>
> to collect that oops. Otherwise it scrolled away due to "trying to
> kill init" doing a dump_stack. pause_on_oops seems to not be working
> properly any more. It used to.
hm, perhaps mdelay(1) does not loop for 1 msec anymore? You'll probably
be able to work it around via pause_on_oops=5000000 or so.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists