From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761967AbYDSRit (ORCPT ); Sat, 19 Apr 2008 13:38:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755232AbYDSRim (ORCPT ); Sat, 19 Apr 2008 13:38:42 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:47208 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755214AbYDSRil (ORCPT ); Sat, 19 Apr 2008 13:38:41 -0400 Date: Sat, 19 Apr 2008 10:38:33 -0700 From: Andrew Morton To: Andres Salomon Cc: jfannin@gmail.com, linux-kernel@vger.kernel.org, mingo@elte.hu, jordan.crouse@amd.com Subject: Re: 2.6.25-mm1 Message-Id: <20080419103833.8b609319.akpm@linux-foundation.org> In-Reply-To: <20080419092544.378664a8@ephemeral> References: <20080418014757.52fb4a4f.akpm@linux-foundation.org> <20080419031024.GC3503@nineveh.local> <20080418202925.b18452c5.akpm@linux-foundation.org> <20080419092544.378664a8@ephemeral> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.19; i686-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 Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon wrote: > 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. :) > Do both ;) The quick-n-easy version sounds suitable for now.