From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759864AbYDSNX3 (ORCPT ); Sat, 19 Apr 2008 09:23:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754522AbYDSNXV (ORCPT ); Sat, 19 Apr 2008 09:23:21 -0400 Received: from mail.queued.net ([207.210.101.209]:3755 "EHLO mail.queued.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753044AbYDSNXU (ORCPT ); Sat, 19 Apr 2008 09:23:20 -0400 Date: Sat, 19 Apr 2008 09:25:44 -0400 From: Andres Salomon To: Andrew Morton Cc: Joseph Fannin , linux-kernel@vger.kernel.org, Ingo Molnar , jordan.crouse@amd.com Subject: Re: 2.6.25-mm1 Message-ID: <20080419092544.378664a8@ephemeral> In-Reply-To: <20080418202925.b18452c5.akpm@linux-foundation.org> References: <20080418014757.52fb4a4f.akpm@linux-foundation.org> <20080419031024.GC3503@nineveh.local> <20080418202925.b18452c5.akpm@linux-foundation.org> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.12.0; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Apr 2008 20:29:25 -0700 Andrew Morton wrote: > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin 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] [] warn_on_slowpath+0x59/0x80 > > [ 400.783480] [] ? profile_pc+0x3e/0x50 > > [ 400.783682] [] ? irq_exit+0x4e/0xa0 > > [ 400.783879] [] ? smp_apic_timer_interrupt+0x5c/0x90 > > [ 400.784087] [] ? trace_hardirqs_on_thunk+0xc/0x10 > > [ 400.784298] [] ? trace_hardirqs_on_caller+0xcd/0x150 > > [ 400.784506] [] ? trace_hardirqs_on_thunk+0xc/0x10 > > [ 400.784706] [] ? restore_nocheck_notrace+0x0/0xe > > [ 400.784906] [] ? page_is_ram+0xa6/0xd0 > > [ 400.785059] [] __ioremap_caller+0x27d/0x2e0 > > [ 400.785221] [] ? _spin_unlock_irqrestore+0x48/0x80 > > [ 400.785421] [] ? ftrace_record_ip+0x7d/0x250 > > [ 400.785621] [] ? olpc_init+0x31/0x140 > > [ 400.785817] [] ioremap_nocache+0x1f/0x30 > > [ 400.785976] [] ? olpc_init+0x31/0x140 > > [ 400.786165] [] olpc_init+0x31/0x140 > > [ 400.786318] [] kernel_init+0x142/0x2d0 > > [ 400.786479] [] ? trace_hardirqs_on_caller+0xcd/0x150 > > [ 400.786680] [] ? restore_nocheck_notrace+0x0/0xe > > [ 400.786879] [] ? kernel_init+0x0/0x2d0 > > [ 400.787069] [] ? kernel_init+0x0/0x2d0 > > [ 400.787260] [] kernel_thread_helper+0x7/0x10 > > [ 400.787422] ======================= > > [ 400.787727] ---[ end trace 4eaa2a86a8e2da22 ]--- > > > > 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. :) -- Need a kernel or Debian developer? Contact me, I'm looking for contracts.