Messages in this thread | | | Date | Sat, 19 Apr 2008 10:38:33 -0700 | From | Andrew Morton <> | Subject | Re: 2.6.25-mm1 |
| |
> 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.
| |