From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Brandeburg Subject: Re: [E1000-devel] recent e100 fixes cause kernel panic? Date: Fri, 19 Mar 2010 12:42:20 -0700 Message-ID: <1269027740.3029.33.camel@jbrandeb-mobl3.amr.corp.intel.com> References: <12968172.251031268372359953.JavaMail.root@tahiti.vyatta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "e1000-devel@lists.sourceforge.net" , Stephen Hemminger , "netdev@vger.kernel.org" To: Ed Ravin , roger.oksanen@cs.helsinki.fi Return-path: Received: from mga14.intel.com ([143.182.124.37]:25543 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751253Ab0CSTlu (ORCPT ); Fri, 19 Mar 2010 15:41:50 -0400 In-Reply-To: <12968172.251031268372359953.JavaMail.root@tahiti.vyatta.com> Sender: netdev-owner@vger.kernel.org List-ID: Added netdev, the place to talk about in-kernel driver problems. On Thu, 2010-03-11 at 22:39 -0700, Stephen Hemminger wrote: > ----- "Ed Ravin" wrote: > > > I'm using the Vyatta "kenwood" Linux distribution, which is currently > > at 2.6.31-1. I upgraded to their latest version, and began seeing > > kernel > > panics shortly after starting to use ssh/scp on the network connected > > to > > an e100 NIC. I was able to reproduce the problem immediately after > > booting up - sometimes it even crashed during the boot. > > > > One of the crash logs is attached. Ed, thanks for the report, looks like these patches introduced a new problem. e100 hardware has a tricky data structure that seems to cause some problems for (particularly arm) some cpu architectures. > > > > Since the problem seemed to be related to e100.c, I reverted the two > > commits to e100.c that had taken place since I last built the kernel > > for this box: > > > > Author: Roger Oksanen > > Date: Fri Dec 18 20:18:21 2009 -0800 > > e100: Fix broken cbs accounting due to missing memset. > > > > Author: Roger Oksanen > > Date: Sun Nov 29 17:17:29 2009 -0800 > > e100: Use pci pool to work around GFP_ATOMIC order 5 memory > > allocation failu > > > > I rebuilt the kernel and it's not panicking anymore. so you just reverted both, and its good news things are working again, but can you try one or the other and let us know if things still break for you? > The Vyatta kernel for 2.6.31 is based on the 2.6.31.10 + unionfs. > These two patches came from the 2.6.31.10 -stable update. This is the only report of this issue I have heard so far, so something must be a little unique to your system or workload such that the driver works mostly. I'm looking more closely into the panic trace now, maybe I can figure it out from there. -- Jesse Brandeburg This email sent via Evolution, powered by Linux