[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080419103833.8b609319.akpm@linux-foundation.org>
Date: Sat, 19 Apr 2008 10:38:33 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Andres Salomon <dilinger@...ued.net>
Cc: jfannin@...il.com, linux-kernel@...r.kernel.org, mingo@...e.hu,
jordan.crouse@....com
Subject: Re: 2.6.25-mm1
> On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon <dilinger@...ued.net> wrote:
> On Fri, 18 Apr 2008 20:29:25 -0700
> Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin <jfannin@...il.com> wrote:
> >
> > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
> > >
> > > New, in 2.6.25-mm1 is a hang I'm seeing, just after the kernel prints:
> > >
> > > "[ 0.160375] NET: Registered protocol family 16"
> > >
> > > The hang lasts about five minutes, and then boot continues.
> >
> > Please add initcall_debug to the kernel boot command line - that should
> > narrow it down.
> >
> > > Just
> > > after that, a backtrace is printed; I don't know if it's related. The
> > > backtrace will follow.
> > >
> > > This does not occur in mainline. It seems it might be related to OLPC
> > > support -- I enabled all those options -- but that's not good
> > > behavior, and I see no warning of thus in the help.
> > >
> > > I'm sending a number or reports against 2.6.25-mm1, so I've put my
> > > dmesg and .config on a server:
> > >
> > > http://home.columbus.rr.com/jfannin3/dmesg.txt
> > > http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
> > >
> > > [ 0.160375] NET: Registered protocol family 16
> > > [ 400.782683] ------------[ cut here ]------------
> > > [ 400.782832] WARNING: at arch/x86/mm/ioremap.c:158 __ioremap_caller+0x27d/0x2e0()
> > > [ 400.783022] Modules linked in:
> > > [ 400.783169] Pid: 1, comm: swapper Not tainted 2.6.25-mm1 #7
> > > [ 400.783300] [<c0130fa9>] warn_on_slowpath+0x59/0x80
> > > [ 400.783480] [<c0106c2e>] ? profile_pc+0x3e/0x50
> > > [ 400.783682] [<c01374ee>] ? irq_exit+0x4e/0xa0
> > > [ 400.783879] [<c0115aec>] ? smp_apic_timer_interrupt+0x5c/0x90
> > > [ 400.784087] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> > > [ 400.784298] [<c01552cd>] ? trace_hardirqs_on_caller+0xcd/0x150
> > > [ 400.784506] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> > > [ 400.784706] [<c010416c>] ? restore_nocheck_notrace+0x0/0xe
> > > [ 400.784906] [<c011d0e6>] ? page_is_ram+0xa6/0xd0
> > > [ 400.785059] [<c011d4ed>] __ioremap_caller+0x27d/0x2e0
> > > [ 400.785221] [<c03569d8>] ? _spin_unlock_irqrestore+0x48/0x80
> > > [ 400.785421] [<c017f4cd>] ? ftrace_record_ip+0x7d/0x250
> > > [ 400.785621] [<c0474801>] ? olpc_init+0x31/0x140
> > > [ 400.785817] [<c011d59f>] ioremap_nocache+0x1f/0x30
> > > [ 400.785976] [<c0474801>] ? olpc_init+0x31/0x140
> > > [ 400.786165] [<c0474801>] olpc_init+0x31/0x140
> > > [ 400.786318] [<c0464992>] kernel_init+0x142/0x2d0
> > > [ 400.786479] [<c01552cd>] ? trace_hardirqs_on_caller+0xcd/0x150
> > > [ 400.786680] [<c010416c>] ? restore_nocheck_notrace+0x0/0xe
> > > [ 400.786879] [<c0464850>] ? kernel_init+0x0/0x2d0
> > > [ 400.787069] [<c0464850>] ? kernel_init+0x0/0x2d0
> > > [ 400.787260] [<c0104d9b>] kernel_thread_helper+0x7/0x10
> > > [ 400.787422] =======================
> > > [ 400.787727] ---[ end trace 4eaa2a86a8e2da22 ]---
> >
> > <looks at this again>
> >
> > That's
> >
> > WARN_ON_ONCE(is_ram);
> >
> > the changelog for the patch which added that warning is information-free
> > and there's no code comment explaining what went wrong, which makes things
> > rather harder than they ought to be.
> >
> > Yes it's due to the new OLPC code. olpc_init() has
> >
> > romsig = ioremap(0xffffffc0, 16);
> >
> > which we probably just shouldn't do this at all unless we're running on the
> > OLPC hardware. But we need to do this to find out if we're running on the OLPC
> > hardware! Perhaps the warning should just be removed.
>
> Hm. We could either protect that code with an:
>
> if (!is_geode())
> return;
>
> Or I could add the OpenFirmware patches which would allow us to get
> rid of this code, and instead check for the existence of OFW using
> that.
>
> The former is quick and easy; the latter is (imo) nicer, so long as
> people don't have problems w/ the OFW code. :)
>
Do both ;)
The quick-n-easy version sounds suitable for now.
--
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