All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Graham, David" <david.graham@intel.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Karol Lewandowski <karol.k.lewandowski@gmail.com>,
	"e1000-devel@lists.sourceforge.net" 
	<e1000-devel@lists.sourceforge.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [BUG 2.6.30+] e100 sometimes causes oops during resume
Date: Thu, 17 Sep 2009 13:42:50 -0700	[thread overview]
Message-ID: <4AB29F4A.3030102@intel.com> (raw)
In-Reply-To: <200909170118.53965.rjw@sisk.pl>

Rafael J. Wysocki wrote:
> On Tuesday 15 September 2009, Karol Lewandowski wrote:
>> Hello,
>>
>> I'm getting following oops sometimes during resume on my Thinkpad T21
>> (where "sometimes" means about 10/1 good/bad ratio):
>>
>> ifconfig: page allocation failure. order:5, mode:0x8020
> 
> Well, this only tells you that an attempt to make order 5 allocation failed,
> which is not unusual at all.
> 
> Allocations of this order are quite likely to fail if memory is fragmented,
> the probability of which rises with the number of suspend-resume cycles already
> carried out.
> 
> I guess the driver releases its DMA buffer during suspend and attempts to
> allocate it back on resume, which is not really smart (if that really is the
> case).
> 
Yes, we free a 70KB block (0x80 by 0x230 bytes) on suspend and 
reallocate on resume, and so that's an Order 5 request. It looks 
symmetric, and hasn't changed for years. I don't think we are leaking 
memory, which points back to that the memory is too fragmented to 
satisfy the request.

I also concur that Rafael's commit 6905b1f1 shouldn't change the logic 
in the driver for systems with e100 (like yours Karol) that could 
already sleep, and I don't see anything else in the driver that looks to 
be relevant. I'm expecting that your test result without commit 6905b1f1 
will still show the problem.

So I wonder if this new issue may be triggered by some other change in 
the memory subsystem ?

Karol, how much physical RAM do you have in this system ? I'd expect 
that the fragmentation would be less of an issue if there's simply more 
memory in total.

Unfortunately I still have no actual repro in house.

I can try to rework the codepaths around suspend & resume so that we 
don't free & reallocate this order 5 memory, but I think its risky. I'm 
looking into that now.

Thanks


> Thanks,
> Rafael


  reply	other threads:[~2009-09-17 20:42 UTC|newest]

Thread overview: 35+ 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-15 22:54   ` Graham, David
2009-09-16  1:44   ` [E1000-devel] " Karol Lewandowski
2009-09-16  1:44     ` Karol Lewandowski
2009-09-16  9:19     ` Karol Lewandowski
2009-09-16  9:19       ` Karol Lewandowski
2009-09-16 21:06     ` Graham, David
2009-09-16 21:06       ` Graham, David
2009-09-16 21:17       ` [E1000-devel] " Karol Lewandowski
2009-09-16 21:17         ` Karol Lewandowski
2009-09-16 23:11   ` Rafael J. Wysocki
2009-09-16 23:11     ` Rafael J. Wysocki
2009-09-16 23:18 ` Rafael J. Wysocki
2009-09-17 20:42   ` Graham, David [this message]
2009-09-17 22:27     ` Rafael J. Wysocki
2009-09-17 22:27       ` Rafael J. Wysocki
2009-09-22 23:35       ` Karol Lewandowski
2009-09-22 23:35         ` Karol Lewandowski
2009-09-22 23:51         ` Rafael J. Wysocki
2009-09-22 23:51           ` Rafael J. Wysocki
2009-09-23 14:22           ` Karol Lewandowski
2009-09-23 14:22             ` Karol Lewandowski
2009-09-23 21:45             ` Rafael J. Wysocki
2009-09-23 21:45               ` Rafael J. Wysocki
2009-09-29 13:58         ` Mel Gorman
2009-09-29 13:58           ` Mel Gorman
2009-09-30 15:37           ` Karol Lewandowski
2009-09-30 15:37             ` Karol Lewandowski
2009-09-30 15:55             ` Mel Gorman
2009-09-30 15:55               ` Mel Gorman
2009-09-30 18:48               ` Karol Lewandowski
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=4AB29F4A.3030102@intel.com \
    --to=david.graham@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=karol.k.lewandowski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.