Re: 2.6.25-mm1

[Andrew Morton <akpm@linux-foundation.org>]

> On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon <dilinger@queued.net> wrote:
> On Fri, 18 Apr 2008 20:29:25 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin <jfannin@gmail.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.