All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karol Lewandowski <karol.k.lewandowski@gmail.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: david.graham@intel.com,
	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: Wed, 23 Sep 2009 01:35:31 +0200	[thread overview]
Message-ID: <20090922233531.GA3198@bizet.domek.prywatny> (raw)
In-Reply-To: <200909180027.37387.rjw@sisk.pl>

On Fri, Sep 18, 2009 at 12:27:37AM +0200, Rafael J. Wysocki wrote:
> On Thursday 17 September 2009, Graham, David wrote:
> > Rafael J. Wysocki wrote:
> > > 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.

I've hit this bug 2 times since my last email.  Is there anything I
could do?

Maybe I should revert following commits (chosen somewhat randomly)?

1. 49255c619fbd482d704289b5eb2795f8e3b7ff2e

2. dd5d241ea955006122d76af88af87de73fec25b4 - alters changes made by
commit above

Any ideas?

Thanks.

WARNING: multiple messages have this Message-ID (diff)
From: Karol Lewandowski <karol.k.lewandowski@gmail.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: david.graham@intel.com,
	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: Wed, 23 Sep 2009 01:35:31 +0200	[thread overview]
Message-ID: <20090922233531.GA3198@bizet.domek.prywatny> (raw)
In-Reply-To: <200909180027.37387.rjw@sisk.pl>

On Fri, Sep 18, 2009 at 12:27:37AM +0200, Rafael J. Wysocki wrote:
> On Thursday 17 September 2009, Graham, David wrote:
> > Rafael J. Wysocki wrote:
> > > 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.

I've hit this bug 2 times since my last email.  Is there anything I
could do?

Maybe I should revert following commits (chosen somewhat randomly)?

1. 49255c619fbd482d704289b5eb2795f8e3b7ff2e

2. dd5d241ea955006122d76af88af87de73fec25b4 - alters changes made by
commit above

Any ideas?

Thanks.

--
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-22 23:35 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
2009-09-17 22:27       ` Rafael J. Wysocki
2009-09-22 23:35       ` Karol Lewandowski [this message]
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=20090922233531.GA3198@bizet.domek.prywatny \
    --to=karol.k.lewandowski@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david.graham@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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.