Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758389Ab0DHHMA (ORCPT ); Thu, 8 Apr 2010 03:12:00 -0400 Received: from ey-out-2122.google.com ([74.125.78.25]:19400 "EHLO ey-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753424Ab0DHHLz (ORCPT ); Thu, 8 Apr 2010 03:11:55 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DHOFL82INKDFEFZU2GgXmKNKunDZlh8kCUMxhBPUoVih5NnYvoMv3OZAS8Oe9iLG2l ItSDwuwZe7ZyihwJIvn88PgrG+WT7DKnw/6XXNXmWslWbPBxzL+rwL324MbE0kP+BAa/ oCfkN7ncagHe8Yp2PWjLEGyMhSS+wemYfFjT8= Message-ID: <4BBD81B3.3030500@iki.fi> Date: Thu, 08 Apr 2010 10:11:47 +0300 From: =?ISO-8859-1?Q?Timo_Ter=E4s?= User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Stephen Rothwell CC: David Miller , netdev@vger.kernel.org, linux-next@vger.kernel.org, LKML Subject: Re: linux-next: powerpc boot failure References: <20100408165848.38f75f40.sfr@canb.auug.org.au> In-Reply-To: <20100408165848.38f75f40.sfr@canb.auug.org.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2119 Lines: 50 Stephen Rothwell wrote: > Today's linux-next (20100408) failed a powerpc boot test like this: > > [While bringing up the network interfaces ...] > > Unable to handle kernel paging request for data at address 0x200000025 > Faulting instruction address: 0xc00000000053d32c > cpu 0x5: Vector: 300 (Data Access) at [c0000000bb277680] > pc: c00000000053d32c: .__xfrm_lookup+0x32c/0x4c0 > lr: c0000000004e6e10: .ip_route_output_flow+0xb0/0x300 > sp: c0000000bb277900 > msr: 8000000000009032 > dar: 200000025 > dsisr: 40000000 > current = 0xc0000000bce55640 > paca = 0xc000000007691a00 > pid = 4106, comm = ntpdate > [c0000000bb277a20] c0000000004e6e10 .ip_route_output_flow+0xb0/0x300 > [c0000000bb277ad0] c0000000005158c8 .ip4_datagram_connect+0x1a8/0x2f0 > [c0000000bb277bd0] c000000000523dc0 .inet_dgram_connect+0x80/0x110 > [c0000000bb277c60] c0000000004a6904 .SyS_connect+0xa4/0xf0 > [c0000000bb277d90] c0000000004d5f48 .compat_sys_socketcall+0x128/0x2f0 > [c0000000bb277e30] c00000000000852c syscall_exit+0x0/0x40 > > The most obvious suspect is commit > 80c802f3073e84c956846e921e8a0b02dfa3755f ("xfrm: cache bundles instead of > policies for outgoing flows") and the couple of commits around that > (these are new to linux-next today). > > The above pc is in this piece of code (I think - I don't have the actual > kernel) from __xfrm_lookup (in net/xfrm/xfrm_policy.c): > > if ((flags & XFRM_LOOKUP_ICMP) && > !(pols[0]->flags & XFRM_POLICY_ICMP)) { > err = -ENOENT; > goto error; > } > > for (i = 0; i < num_pols; i++) > pols[i]->curlft.use_time = get_seconds(); <-------- (line 1845) > > And the 0x200000025 is probably &(pols[i]) (which actually seems unlikely > since pols is an array on the stack). What kind of xfrm policies the system has? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/