Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760242AbZIPXKs (ORCPT ); Wed, 16 Sep 2009 19:10:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755185AbZIPXKm (ORCPT ); Wed, 16 Sep 2009 19:10:42 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:38768 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752866AbZIPXKl (ORCPT ); Wed, 16 Sep 2009 19:10:41 -0400 From: "Rafael J. Wysocki" To: "Graham, David" Subject: Re: [E1000-devel] [BUG 2.6.30+] e100 sometimes causes oops during resume Date: Thu, 17 Sep 2009 01:11:52 +0200 User-Agent: KMail/1.12.1 (Linux/2.6.31-rjw; KDE/4.3.1; x86_64; ; ) Cc: Karol Lewandowski , "linux-kernel@vger.kernel.org" , "e1000-devel@lists.sourceforge.net" , "netdev@vger.kernel.org" References: <20090915120538.GA26806@bizet.domek.prywatny> <13830B75AD5A2F42848F92269B11996F5BF592C3@orsmsx509.amr.corp.intel.com> In-Reply-To: <13830B75AD5A2F42848F92269B11996F5BF592C3@orsmsx509.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909170111.52204.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1311 Lines: 26 On Wednesday 16 September 2009, Graham, David wrote: > A v2.6.30..v2.6.31 diff shows that this is probably exposed by Rafael Wysocki's > commit 6905b1f1, which now allows systems with e100 to sleep. If I understand > correctly, it looks like these systems simply couldn't sleep before. Is that right Rafael? The systems where e100 is not power manageable by any means couldn't suspend before that commit. For the other systems, where e100 is power manageable either with ACPI or natively, the commit doesn't change anything. > I don't think its likely that the commit is a direct cause of the problem, but that the > suspend/resume cycle now allows us to see another issue. Maybe e100 is > leaking memory on suspend/resume cycles, or something else is leaking memory, > or memory is becoming fragmented and the e100 driver is improperly > requesting and being failed on an 'atomic' memory allocation from a heavily > fragmented memory map. Or something else. I have a couple of test systems with e100 that don't have any resume problems, FWIW. Thanks, Rafael -- 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/