public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: "Graham, David" <david.graham@intel.com>
Cc: Karol Lewandowski <karol.k.lewandowski@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"e1000-devel@lists.sourceforge.net" 
	<e1000-devel@lists.sourceforge.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [E1000-devel] [BUG 2.6.30+] e100 sometimes causes oops during resume
Date: Thu, 17 Sep 2009 01:11:52 +0200	[thread overview]
Message-ID: <200909170111.52204.rjw@sisk.pl> (raw)
In-Reply-To: <13830B75AD5A2F42848F92269B11996F5BF592C3@orsmsx509.amr.corp.intel.com>

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

  parent reply	other threads:[~2009-09-16 23:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-15 12:05 [BUG 2.6.30+] e100 sometimes causes oops during resume Karol Lewandowski
2009-09-15 15:32 ` Karol Lewandowski
2009-09-15 22:54 ` [E1000-devel] " Graham, David
2009-09-16  1:44   ` Karol Lewandowski
2009-09-16  9:19     ` Karol Lewandowski
2009-09-16 21:06     ` Graham, David
2009-09-16 21:17       ` Karol Lewandowski
2009-09-16 23:11   ` Rafael J. Wysocki [this message]
2009-09-16 23:18 ` Rafael J. Wysocki
2009-09-17 20:42   ` Graham, David
2009-09-17 22:27     ` Rafael J. Wysocki
2009-09-22 23:35       ` Karol Lewandowski
2009-09-22 23:51         ` Rafael J. Wysocki
2009-09-23 14:22           ` Karol Lewandowski
2009-09-23 21:45             ` Rafael J. Wysocki
2009-09-29 13:58         ` Mel Gorman
2009-09-30 15:37           ` Karol Lewandowski
2009-09-30 15:55             ` Mel Gorman
2009-09-30 18:48               ` Karol Lewandowski
2009-09-17 23:05     ` Karol Lewandowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200909170111.52204.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=david.graham@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=karol.k.lewandowski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox