From: jbe@pengutronix.de (Juergen Beisert)
To: linux-arm-kernel@lists.infradead.org
Subject: Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system
Date: Fri, 16 Oct 2009 10:10:15 +0200 [thread overview]
Message-ID: <200910161010.15864.jbe@pengutronix.de> (raw)
In-Reply-To: <200908131122.40423.jbe@pengutronix.de>
On Donnerstag, 13. August 2009, Juergen Beisert wrote:
> On Donnerstag, 13. August 2009, Mel Gorman wrote:
> > On Wed, Aug 12, 2009 at 02:40:30PM -0400, Arnaud Faucher wrote:
> > > I have a rather similar problem on a driver that I try to keep
> > > up-to-date with recent kernel versions
> > > (http://code.ximeta.com/trac-ndas/ticket/1110#comment:30). The NDAS
> > > hardware is an ethernet-enabled disk controller on one chip, kind of a
> > > cheap iSCSI.
> > >
> > > In my case there is no oops: the symptoms are that the read blocks seem
> > > to be swapped or full of garbage.
> > >
> > > After investigation in the NDAS code, the bug triggers when the driver
> > > tries to merge adjacent requests before sending them to the controller.
> > > I had to disable this merge in order to restore normal behavior, at the
> > > expense of a reduced efficiency.
> >
> > That is a very interesting point and one I hadn't considered. The point
> > of the patch was to help drivers that merge adjacent requests if they
> > happen to be physically contiguous. The reported bug that led to the
> > patch was a regression of memory not being physically contiguous and
> > requests not being merged.
> >
> > > > After this oops, system startup continues. Then the next oops occurs:
> > > >
> > > > This one is new, since I try to mount the connected SD card.
> > >
> > > Mel's buffer overrun theory seems to apply in the NDAS driver case,
> > > where the original requests adjacency test seems faulty.
> > >
> > > May it also be the cause of the SD mounting crash ?
> >
> > It's a possibility. If it's not an overrun, it's possible that the
> > automatic merging code is buggy as well.
> >
> > Juergen, is the disk controller on your machine capable of merging
> > requests? If so, can you disable it and see if the bug still occurs
> > please?
>
> Hmmm, hard to say. Maybe the author of this driver can say more.
>
> @Ben: MMC/SD/SDHC driver for the s3c2440-CPU. Can you answer Mel's
> question?
For the records: A wrong __initdata at the MMC/SD/SDHC platform structure
causes this failure to happen. I copied it from a broken implementation in
mach-mini2440.c.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | Phone: +49-8766-939 228 |
Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
WARNING: multiple messages have this Message-ID (diff)
From: Juergen Beisert <jbe@pengutronix.de>
To: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Cc: Mel Gorman <mel@csn.ul.ie>, linux-kernel@vger.kernel.org
Subject: Re: Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system
Date: Fri, 16 Oct 2009 10:10:15 +0200 [thread overview]
Message-ID: <200910161010.15864.jbe@pengutronix.de> (raw)
In-Reply-To: <200908131122.40423.jbe@pengutronix.de>
On Donnerstag, 13. August 2009, Juergen Beisert wrote:
> On Donnerstag, 13. August 2009, Mel Gorman wrote:
> > On Wed, Aug 12, 2009 at 02:40:30PM -0400, Arnaud Faucher wrote:
> > > I have a rather similar problem on a driver that I try to keep
> > > up-to-date with recent kernel versions
> > > (http://code.ximeta.com/trac-ndas/ticket/1110#comment:30). The NDAS
> > > hardware is an ethernet-enabled disk controller on one chip, kind of a
> > > cheap iSCSI.
> > >
> > > In my case there is no oops: the symptoms are that the read blocks seem
> > > to be swapped or full of garbage.
> > >
> > > After investigation in the NDAS code, the bug triggers when the driver
> > > tries to merge adjacent requests before sending them to the controller.
> > > I had to disable this merge in order to restore normal behavior, at the
> > > expense of a reduced efficiency.
> >
> > That is a very interesting point and one I hadn't considered. The point
> > of the patch was to help drivers that merge adjacent requests if they
> > happen to be physically contiguous. The reported bug that led to the
> > patch was a regression of memory not being physically contiguous and
> > requests not being merged.
> >
> > > > After this oops, system startup continues. Then the next oops occurs:
> > > >
> > > > This one is new, since I try to mount the connected SD card.
> > >
> > > Mel's buffer overrun theory seems to apply in the NDAS driver case,
> > > where the original requests adjacency test seems faulty.
> > >
> > > May it also be the cause of the SD mounting crash ?
> >
> > It's a possibility. If it's not an overrun, it's possible that the
> > automatic merging code is buggy as well.
> >
> > Juergen, is the disk controller on your machine capable of merging
> > requests? If so, can you disable it and see if the bug still occurs
> > please?
>
> Hmmm, hard to say. Maybe the author of this driver can say more.
>
> @Ben: MMC/SD/SDHC driver for the s3c2440-CPU. Can you answer Mel's
> question?
For the records: A wrong __initdata at the MMC/SD/SDHC platform structure
causes this failure to happen. I copied it from a broken implementation in
mach-mini2440.c.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | Phone: +49-8766-939 228 |
Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2009-10-16 8:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-11 16:30 Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system Juergen Beisert
2009-08-11 16:30 ` Juergen Beisert
2009-08-12 7:47 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD Robert Schwebel
2009-08-12 7:47 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system Robert Schwebel
2009-08-12 9:20 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD Mel Gorman
2009-08-12 9:20 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system Mel Gorman
2009-08-12 11:11 ` Juergen Beisert
2009-08-12 11:11 ` Juergen Beisert
2009-08-12 13:50 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD Mel Gorman
2009-08-12 13:50 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system Mel Gorman
2009-08-12 15:35 ` Juergen Beisert
2009-08-12 15:35 ` Juergen Beisert
2009-08-12 18:40 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD Arnaud Faucher
2009-08-12 18:40 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system Arnaud Faucher
2009-08-13 8:39 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD Mel Gorman
2009-08-13 8:39 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system Mel Gorman
2009-08-13 9:22 ` Juergen Beisert
2009-08-13 9:22 ` Juergen Beisert
2009-10-16 8:10 ` Juergen Beisert [this message]
2009-10-16 8:10 ` Juergen Beisert
-- strict thread matches above, loose matches on Subject: below --
2009-08-12 18:29 Arnaud Faucher
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=200910161010.15864.jbe@pengutronix.de \
--to=jbe@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.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.