All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: david.graham@intel.com
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>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [BUG 2.6.30+] e100 sometimes causes oops during resume
Date: Fri, 18 Sep 2009 00:27:37 +0200	[thread overview]
Message-ID: <200909180027.37387.rjw@sisk.pl> (raw)
In-Reply-To: <4AB29F4A.3030102@intel.com>

On Thursday 17 September 2009, Graham, David wrote:
> 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 ?

I think so.  There have been reports about order 2 allocations failing for
2.6.31, so it looks like newer kernels are more likely to expose such problems.

Adding linux-mm to the CC list.

Thanks,
Rafael

WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: david.graham@intel.com
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>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [BUG 2.6.30+] e100 sometimes causes oops during resume
Date: Fri, 18 Sep 2009 00:27:37 +0200	[thread overview]
Message-ID: <200909180027.37387.rjw@sisk.pl> (raw)
In-Reply-To: <4AB29F4A.3030102@intel.com>

On Thursday 17 September 2009, Graham, David wrote:
> 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 ?

I think so.  There have been reports about order 2 allocations failing for
2.6.31, so it looks like newer kernels are more likely to expose such problems.

Adding linux-mm to the CC list.

Thanks,
Rafael

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-09-17 22:26 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
2009-09-17 22:27     ` Rafael J. Wysocki [this message]
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=200909180027.37387.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=akpm@linux-foundation.org \
    --cc=david.graham@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=karol.k.lewandowski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 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.