Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
Pavel Machek wrote:
> On Mon 2009-09-07 15:22:10, Russell King - ARM Linux wrote:
> > On Tue, Aug 18, 2009 at 08:31:49AM +0530, Rabin Vincent wrote:
> > > Here's a fixed version:
> >
> > And here's my revised version with these fixes in. I changed the
> > while loop to a do..while loop instead (since we will always have
> > at least one memory bank, it's pointless doing that test for the
> > first iteration.)
> >
> > Acks and tested-bys would be useful please.
> >
>
> > +static int __init meminfo_cmp(const void *_a, const void *_b)
> > +{
> > + const struct membank *a = _a, *b = _b;
> > + long cmp = bank_pfn_start(a) - bank_pfn_start(b);
> > + return cmp < 0 ? -1 : cmp > 0 ? 1 : 0;
> > +}
>
> I believe you can just return cmp here.
If this were generic code, the long value might overflow int.
But this is ARM code, limited to 32 bits, so it could.
It'd be asking for trouble if someone copied the code elsewhere, though.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Tue, Sep 15, 2009 at 01:32:56PM +0200, Pavel Machek wrote: > I believe you can just return cmp here. Maybe... unfortunately this comment is after Linus has merged the patch. Might as well leave it as is since we know it works. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon 2009-09-07 15:22:10, Russell King - ARM Linux wrote:
> On Tue, Aug 18, 2009 at 08:31:49AM +0530, Rabin Vincent wrote:
> > Here's a fixed version:
>
> And here's my revised version with these fixes in. I changed the
> while loop to a do..while loop instead (since we will always have
> at least one memory bank, it's pointless doing that test for the
> first iteration.)
>
> Acks and tested-bys would be useful please.
>
> +static int __init meminfo_cmp(const void *_a, const void *_b)
> +{
> + const struct membank *a = _a, *b = _b;
> + long cmp = bank_pfn_start(a) - bank_pfn_start(b);
> + return cmp < 0 ? -1 : cmp > 0 ? 1 : 0;
> +}
I believe you can just return cmp here.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Thursday, September 10, 2009 12:04 AM > To: Syed Mohammed, Khasim > Cc: Aguirre Rodriguez, Sergio Alberto; Rabin Vincent; linux-arm- > ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > On Wed, Sep 09, 2009 at 01:16:48PM +0530, Syed Mohammed, Khasim wrote: > > Hi Russell, > > > > > -Original Message- > > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > > > Sent: Wednesday, September 09, 2009 12:47 PM > > > To: Syed Mohammed, Khasim > > > Cc: Aguirre Rodriguez, Sergio Alberto; Rabin Vincent; linux-arm- > > > ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > > > Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > > > > > And how about my revised version, which is the version which is going > > > to be merged? > > > > Sorry for missing this out. This works, no issues reported. > > And so can I add a: > > Tested-by: Khasim Syed Mohammed I did test this, please add Tested-by. Thanks, Regards, Khasim -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Wed, Sep 09, 2009 at 01:16:48PM +0530, Syed Mohammed, Khasim wrote: > Hi Russell, > > > -Original Message- > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > > Sent: Wednesday, September 09, 2009 12:47 PM > > To: Syed Mohammed, Khasim > > Cc: Aguirre Rodriguez, Sergio Alberto; Rabin Vincent; linux-arm- > > ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > > Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > > > And how about my revised version, which is the version which is going > > to be merged? > > Sorry for missing this out. This works, no issues reported. And so can I add a: Tested-by: Khasim Syed Mohammed or is it a just a Reviewed-by: ? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
Hi Russell,
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Wednesday, September 09, 2009 12:47 PM
> To: Syed Mohammed, Khasim
> Cc: Aguirre Rodriguez, Sergio Alberto; Rabin Vincent; linux-arm-
> ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org
> Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
>
> On Wed, Sep 09, 2009 at 10:12:48AM +0530, Syed Mohammed, Khasim wrote:
> > Hello all,
> >
> > > -Original Message-
> > > From: Aguirre Rodriguez, Sergio Alberto
> > > Sent: Wednesday, September 09, 2009 7:35 AM
> > > To: Russell King - ARM Linux; Rabin Vincent
> > > Cc: Syed Mohammed, Khasim; linux-arm-ker...@lists.arm.linux.org.uk;
> linux-
> > > o...@vger.kernel.org
> > > Subject: RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
> > >
> > > From: Russell King - ARM Linux [li...@arm.linux.org.uk]
> > > Sent: Tuesday, September 08, 2009 11:23 PM
> > > > >
> > > > > Acks and tested-bys would be useful please.
> > > >
> > > > Haven't heard anything, so I've committed it as is. It is my intention
> > > > to push it to Linus as is in the next couple of days.
> > >
> > > Russell,
> > >
> > > I don't have ways of testing this, but I think Khasim's testing will make
> > > more sense,
> > > since he reported the bug... anyways, it's probably too late.
> > >
> > I am really sorry, wanted to try this out when RMK returns from vacation
> meanwhile forgot :(
> >
> > The below logic from Rabin works great !!! no issues with this as well.
>
> And how about my revised version, which is the version which is going
> to be merged?
Sorry for missing this out. This works, no issues reported.
+int pfn_valid(unsigned long pfn)
+{
+struct meminfo *mi = &meminfo;
+unsigned int left = 0, right = mi->nr_banks;
+
+do {
+unsigned int mid = (right + left) / 2;
+struct membank *bank = &mi->bank[mid];
+
+if (pfn < bank_pfn_start(bank))
+right = mid;
+else if (pfn >= bank_pfn_end(bank))
+left = mid + 1;
+else
+return 1;
+} while (left < right);
+return 0;
+}
Thanks.
Regards,
Khasim
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Wed, Sep 09, 2009 at 10:12:48AM +0530, Syed Mohammed, Khasim wrote: > Hello all, > > > -Original Message- > > From: Aguirre Rodriguez, Sergio Alberto > > Sent: Wednesday, September 09, 2009 7:35 AM > > To: Russell King - ARM Linux; Rabin Vincent > > Cc: Syed Mohammed, Khasim; linux-arm-ker...@lists.arm.linux.org.uk; linux- > > o...@vger.kernel.org > > Subject: RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > > > From: Russell King - ARM Linux [li...@arm.linux.org.uk] > > Sent: Tuesday, September 08, 2009 11:23 PM > > > > > > > > Acks and tested-bys would be useful please. > > > > > > Haven't heard anything, so I've committed it as is. It is my intention > > > to push it to Linus as is in the next couple of days. > > > > Russell, > > > > I don't have ways of testing this, but I think Khasim's testing will make > > more sense, > > since he reported the bug... anyways, it's probably too late. > > > I am really sorry, wanted to try this out when RMK returns from vacation > meanwhile forgot :( > > The below logic from Rabin works great !!! no issues with this as well. And how about my revised version, which is the version which is going to be merged? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
Hello all,
> -Original Message-
> From: Aguirre Rodriguez, Sergio Alberto
> Sent: Wednesday, September 09, 2009 7:35 AM
> To: Russell King - ARM Linux; Rabin Vincent
> Cc: Syed Mohammed, Khasim; linux-arm-ker...@lists.arm.linux.org.uk; linux-
> o...@vger.kernel.org
> Subject: RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
>
> From: Russell King - ARM Linux [li...@arm.linux.org.uk]
> Sent: Tuesday, September 08, 2009 11:23 PM
> > >
> > > Acks and tested-bys would be useful please.
> >
> > Haven't heard anything, so I've committed it as is. It is my intention
> > to push it to Linus as is in the next couple of days.
>
> Russell,
>
> I don't have ways of testing this, but I think Khasim's testing will make
> more sense,
> since he reported the bug... anyways, it's probably too late.
>
I am really sorry, wanted to try this out when RMK returns from vacation
meanwhile forgot :(
The below logic from Rabin works great !!! no issues with this as well.
File arch/arm/mm/init.c
int pfn_valid(unsigned long pfn)
{
struct meminfo *mi = &meminfo;
unsigned int left = 0, right = mi->nr_banks;
while (left < right) {
unsigned int mid = (left + right) / 2;
struct membank *bank = &mi->bank[mid];
if (pfn < bank_pfn_start(bank))
right = mid;
else if (pfn >= bank_pfn_end(bank))
left = mid + 1;
else
return 1;
}
return 0;
}
Thanks for all the help.
Regards,
Khasim
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
From: Russell King - ARM Linux [li...@arm.linux.org.uk] Sent: Tuesday, September 08, 2009 11:23 PM > On Mon, Sep 07, 2009 at 03:22:10PM +0100, Russell King - ARM Linux wrote: > > On Tue, Aug 18, 2009 at 08:31:49AM +0530, Rabin Vincent wrote: > > > Here's a fixed version: > > > > And here's my revised version with these fixes in. I changed the > > while loop to a do..while loop instead (since we will always have > > at least one memory bank, it's pointless doing that test for the > > first iteration.) > > > > Acks and tested-bys would be useful please. > > Haven't heard anything, so I've committed it as is. It is my intention > to push it to Linus as is in the next couple of days. Russell, I don't have ways of testing this, but I think Khasim's testing will make more sense, since he reported the bug... anyways, it's probably too late. Regards, Sergio-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Sep 07, 2009 at 03:22:10PM +0100, Russell King - ARM Linux wrote: > On Tue, Aug 18, 2009 at 08:31:49AM +0530, Rabin Vincent wrote: > > Here's a fixed version: > > And here's my revised version with these fixes in. I changed the > while loop to a do..while loop instead (since we will always have > at least one memory bank, it's pointless doing that test for the > first iteration.) > > Acks and tested-bys would be useful please. Haven't heard anything, so I've committed it as is. It is my intention to push it to Linus as is in the next couple of days. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Tue, Aug 18, 2009 at 08:31:49AM +0530, Rabin Vincent wrote:
> Here's a fixed version:
And here's my revised version with these fixes in. I changed the
while loop to a do..while loop instead (since we will always have
at least one memory bank, it's pointless doing that test for the
first iteration.)
Acks and tested-bys would be useful please.
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 376be1a..cefedf0 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -218,7 +218,6 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
*
* page_to_pfn(page) convert a struct page * to a PFN number
* pfn_to_page(pfn) convert a _valid_ PFN number to struct page *
- * pfn_valid(pfn) indicates whether a PFN number is valid
*
* virt_to_page(k)convert a _valid_ virtual address to struct page *
* virt_addr_valid(k) indicates whether a virtual address is valid
@@ -227,10 +226,6 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
#define ARCH_PFN_OFFSETPHYS_PFN_OFFSET
-#ifndef CONFIG_SPARSEMEM
-#define pfn_valid(pfn) ((pfn) >= PHYS_PFN_OFFSET && (pfn) <
(PHYS_PFN_OFFSET + max_mapnr))
-#endif
-
#define virt_to_page(kaddr)pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
#define virt_addr_valid(kaddr) ((unsigned long)(kaddr) >= PAGE_OFFSET &&
(unsigned long)(kaddr) < (unsigned long)high_memory)
@@ -247,18 +242,6 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
#define arch_pfn_to_nid(pfn) PFN_TO_NID(pfn)
#define arch_local_page_offset(pfn, nid) LOCAL_MAP_NR((pfn) << PAGE_SHIFT)
-#define pfn_valid(pfn) \
- ({ \
- unsigned int nid = PFN_TO_NID(pfn); \
- int valid = nid < MAX_NUMNODES; \
- if (valid) {\
- pg_data_t *node = NODE_DATA(nid); \
- valid = (pfn - node->node_start_pfn) < \
- node->node_spanned_pages; \
- } \
- valid; \
- })
-
#define virt_to_page(kaddr)\
(ADDR_TO_MAPBASE(kaddr) + LOCAL_MAP_NR(kaddr))
diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index 9c746af..3a32af4 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -194,6 +194,10 @@ typedef unsigned long pgprot_t;
typedef struct page *pgtable_t;
+#ifndef CONFIG_SPARSEMEM
+extern int pfn_valid(unsigned long);
+#endif
+
#include
#endif /* !__ASSEMBLY__ */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8277802..2542583 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -334,12 +335,43 @@ static void __init bootmem_free_node(int node, struct
meminfo *mi)
free_area_init_node(node, zone_size, start_pfn, zhole_size);
}
+#ifndef CONFIG_SPARSEMEM
+int pfn_valid(unsigned long pfn)
+{
+ struct meminfo *mi = &meminfo;
+ unsigned int left = 0, right = mi->nr_banks;
+
+ do {
+ unsigned int mid = (right + left) / 2;
+ struct membank *bank = &mi->bank[mid];
+
+ if (pfn < bank_pfn_start(bank))
+ right = mid;
+ else if (pfn >= bank_pfn_end(bank))
+ left = mid + 1;
+ else
+ return 1;
+ } while (left < right);
+ return 0;
+}
+EXPORT_SYMBOL(pfn_valid);
+#endif
+
+static int __init meminfo_cmp(const void *_a, const void *_b)
+{
+ const struct membank *a = _a, *b = _b;
+ long cmp = bank_pfn_start(a) - bank_pfn_start(b);
+ return cmp < 0 ? -1 : cmp > 0 ? 1 : 0;
+}
+
void __init bootmem_init(void)
{
struct meminfo *mi = &meminfo;
unsigned long memend_pfn = 0;
int node, initrd_node;
+ sort(&mi->bank, mi->nr_banks, sizeof(mi->bank[0]), meminfo_cmp, NULL);
+
/*
* Locate which node contains the ramdisk image, if any.
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 03:23:18PM -0500, Aguirre Rodriguez, Sergio Alberto
wrote:
> #ifndef CONFIG_SPARSEMEM
> int pfn_valid(unsigned long pfn)
> {
> struct meminfo *mi = &meminfo;
> unsigned int left = 0, right = mi->nr_banks;
>
> while (left <= right) {
This condition will cause the while to loop forever when left == right
and pfn < bank_pfn_start(bank).
> unsigned int mid = (right - left) / 2;
This calculation is incorrect when left != 0 (also in the original
patch).
> struct membank *bank = &mi->bank[mid];
>
> if (pfn < bank_pfn_start(bank))
> right = mid;
> else if (pfn >= bank_pfn_end(bank))
> left = mid + 1;
> else
> return 1;
> }
> return 0;
> }
> EXPORT_SYMBOL(pfn_valid);
> #endif
Here's a fixed version:
int pfn_valid(unsigned long pfn)
{
struct meminfo *mi = &meminfo;
unsigned int left = 0, right = mi->nr_banks;
while (left < right) {
unsigned int mid = (left + right) / 2;
struct membank *bank = &mi->bank[mid];
if (pfn < bank_pfn_start(bank))
right = mid;
else if (pfn >= bank_pfn_end(bank))
left = mid + 1;
else
return 1;
}
return 0;
}
Rabin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Monday, August 17, 2009 1:05 PM
> To: Rabin Vincent
> Cc: Syed Mohammed, Khasim; linux-arm-ker...@lists.arm.linux.org.uk; linux-
> o...@vger.kernel.org
> Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
>
> On Mon, Aug 17, 2009 at 11:31:45PM +0530, Rabin Vincent wrote:
> > When mid == 0, the loop exits because the condition you have is :
> >
> > while ((mid = (right - left) / 2) > 0) {
> > ^^
> >
> > Thus bank[0] will never be checked.
>
> Ah yes, right. Damn it.
>
> Oh well, this will probably have to wait a couple of weeks now (by
> which time I expect I will have forgotten about the problem.)
How about this?:
#ifndef CONFIG_SPARSEMEM
int pfn_valid(unsigned long pfn)
{
struct meminfo *mi = &meminfo;
unsigned int left = 0, right = mi->nr_banks;
while (left <= right) {
unsigned int mid = (right - left) / 2;
struct membank *bank = &mi->bank[mid];
if (pfn < bank_pfn_start(bank))
right = mid;
else if (pfn >= bank_pfn_end(bank))
left = mid + 1;
else
return 1;
}
return 0;
}
EXPORT_SYMBOL(pfn_valid);
#endif
Regards,
Sergio
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 11:31:45PM +0530, Rabin Vincent wrote:
> When mid == 0, the loop exits because the condition you have is :
>
> while ((mid = (right - left) / 2) > 0) {
> ^^
>
> Thus bank[0] will never be checked.
Ah yes, right. Damn it.
Oh well, this will probably have to wait a couple of weeks now (by
which time I expect I will have forgotten about the problem.)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 06:47:18PM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 17, 2009 at 11:03:44PM +0530, Rabin Vincent wrote:
> > On Sat, Aug 15, 2009 at 07:17:11PM +0100, Russell King - ARM Linux wrote:
> > > +#ifndef CONFIG_SPARSEMEM
> > > +int pfn_valid(unsigned long pfn)
> > > +{
> > > + struct meminfo *mi = &meminfo;
> > > + unsigned int mid, left = 0, right = mi->nr_banks;
> > > +
> > > + while ((mid = (right - left) / 2) > 0) {
> > > + struct membank *bank = &mi->bank[mid];
> > > +
> > > + if (pfn < bank_pfn_start(bank))
> > > + right = mid;
> > > + else if (pfn >= bank_pfn_end(bank))
> > > + left = mid + 1;
> > > + else
> > > + return 1;
> > > + }
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(pfn_valid);
> > > +#endif
> >
> > The above function will ignore the first bank. I don't think that was
> > intended.
>
> Why do you say that?
>
> Let's start with 4 membank entries - 0 1 2 3.
>
> 0 covers 0-10, 1 covers 20-30, 2 covers 40-50 and 3 covers 60-70.
>
> Let's run through the steps looking for 5:
>
> Initally, left = 0, right = 4, so mid=2. 5 < 40? Yes, so right becomes 2.
>
> left = 0, right = 2, so mid=1. 5 < 20? Yes, so right becomes 1.
>
> left = 0, right = 1, so mid=0. 5 < 0? No. 5 >= 10? No. so return 1.
>
> This doesn't look to me like it ignores the first bank. I think you're
> wrong. Please provide me with your proof ASAP because right now it's
> pending for Linus.
When mid == 0, the loop exits because the condition you have is :
while ((mid = (right - left) / 2) > 0) {
^^
Thus bank[0] will never be checked.
Rabin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 11:03:44PM +0530, Rabin Vincent wrote:
> On Sat, Aug 15, 2009 at 07:17:11PM +0100, Russell King - ARM Linux wrote:
> > +#ifndef CONFIG_SPARSEMEM
> > +int pfn_valid(unsigned long pfn)
> > +{
> > + struct meminfo *mi = &meminfo;
> > + unsigned int mid, left = 0, right = mi->nr_banks;
> > +
> > + while ((mid = (right - left) / 2) > 0) {
> > + struct membank *bank = &mi->bank[mid];
> > +
> > + if (pfn < bank_pfn_start(bank))
> > + right = mid;
> > + else if (pfn >= bank_pfn_end(bank))
> > + left = mid + 1;
> > + else
> > + return 1;
> > + }
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(pfn_valid);
> > +#endif
>
> The above function will ignore the first bank. I don't think that was
> intended.
Why do you say that?
Let's start with 4 membank entries - 0 1 2 3.
0 covers 0-10, 1 covers 20-30, 2 covers 40-50 and 3 covers 60-70.
Let's run through the steps looking for 5:
Initally, left = 0, right = 4, so mid=2. 5 < 40? Yes, so right becomes 2.
left = 0, right = 2, so mid=1. 5 < 20? Yes, so right becomes 1.
left = 0, right = 1, so mid=0. 5 < 0? No. 5 >= 10? No. so return 1.
This doesn't look to me like it ignores the first bank. I think you're
wrong. Please provide me with your proof ASAP because right now it's
pending for Linus.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Sat, Aug 15, 2009 at 07:17:11PM +0100, Russell King - ARM Linux wrote:
> +#ifndef CONFIG_SPARSEMEM
> +int pfn_valid(unsigned long pfn)
> +{
> + struct meminfo *mi = &meminfo;
> + unsigned int mid, left = 0, right = mi->nr_banks;
> +
> + while ((mid = (right - left) / 2) > 0) {
> + struct membank *bank = &mi->bank[mid];
> +
> + if (pfn < bank_pfn_start(bank))
> + right = mid;
> + else if (pfn >= bank_pfn_end(bank))
> + left = mid + 1;
> + else
> + return 1;
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL(pfn_valid);
> +#endif
The above function will ignore the first bank. I don't think that was
intended.
Rabin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Monday, August 17, 2009 10:21 PM
> To: Syed Mohammed, Khasim
> Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org
> Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
>
> On Mon, Aug 17, 2009 at 04:40:27PM +0530, Syed Mohammed, Khasim wrote:
> > This patch seem to be working, I don't see any dump like before.
>
> Great.
>
> > Can you please advice on how to get this patch into kernel? I mean,
> > will you be handling it or we need to re-submit them with your signed off?
>
> Yes, I'll be sending it. However, I believe the patch I sent contains
> one error:
Thanks.
> > > +static int __init meminfo_cmp(const void *_a, const void *_b)
> > > +{
> > > + const struct membank *a = _a, *b = _b;
> > > + long cmp = bank_pfn_start(b) - bank_pfn_start(a);
>
> I think this should be bank_pfn_start(a) - bank_pfn_start(b). When you
> tested this unmodified patch, did the "Memory:" line list the memory
> bank sizes in reverse order?
Unmodified results in
MEM: unordered memory banks. Not freeing memmap.
Memory: 60MB 88MB = 148MB total
Making it a - b results in
Memory: 88MB 60MB = 148MB total
a-b is correct one, fortunately both worked for me.
Regards,
Khasim
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Mon, Aug 17, 2009 at 04:40:27PM +0530, Syed Mohammed, Khasim wrote:
> This patch seem to be working, I don't see any dump like before.
Great.
> Can you please advice on how to get this patch into kernel? I mean,
> will you be handling it or we need to re-submit them with your signed off?
Yes, I'll be sending it. However, I believe the patch I sent contains
one error:
> > +static int __init meminfo_cmp(const void *_a, const void *_b)
> > +{
> > + const struct membank *a = _a, *b = _b;
> > + long cmp = bank_pfn_start(b) - bank_pfn_start(a);
I think this should be bank_pfn_start(a) - bank_pfn_start(b). When you
tested this unmodified patch, did the "Memory:" line list the memory
bank sizes in reverse order?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
Hi Russell,
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Saturday, August 15, 2009 11:47 PM
> To: Syed Mohammed, Khasim
> Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org
> Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
>
> On Sat, Aug 15, 2009 at 09:47:18PM +0530, Syed Mohammed, Khasim wrote:
> > Backtrace:
> > [] (__flush_dcache_page+0x0/0x3c) from []
> > (update_mmu_cache+
> > 0x8c/0xb0)
> > [] (update_mmu_cache+0x0/0xb0) from []
> > (handle_mm_fault+0x53
> > 4/0x5ac)
>
> Bingo!
>
> The question is how best to handle determining if a PFN (which could be
> somewhere in the range 0 to 0xf for 32-bit address space) is valid
> without eating up too much memory. One simple way would be to allocate
> a bitmap. That'll eat up 128K of memory though, and we know that we
> normally have a small amount of that range used... I think a binary
> search of the meminfo struct might be the best all-round solution.
>
> Could you try this patch please?
>
This patch seem to be working, I don't see any dump like before.
Can you please advice on how to get this patch into kernel? I mean, will you be
handling it or we need to re-submit them with your signed off?
Please let me know if there are any corrections that you want me to test, I
will be more happy to do the same.
Thanks for all your help.
Regards,
Khasim
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 376be1a..cefedf0 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -218,7 +218,6 @@ static inline __deprecated void *bus_to_virt(unsigned
> long x)
> *
> * page_to_pfn(page)convert a struct page * to a PFN number
> * pfn_to_page(pfn) convert a _valid_ PFN number to struct page *
> - * pfn_valid(pfn) indicates whether a PFN number is valid
> *
> * virt_to_page(k) convert a _valid_ virtual address to struct page *
> * virt_addr_valid(k) indicates whether a virtual address is valid
> @@ -227,10 +226,6 @@ static inline __deprecated void *bus_to_virt(unsigned
> long x)
>
> #define ARCH_PFN_OFFSET PHYS_PFN_OFFSET
>
> -#ifndef CONFIG_SPARSEMEM
> -#define pfn_valid(pfn) ((pfn) >= PHYS_PFN_OFFSET && (pfn) <
> (PHYS_PFN_OFFSET + max_mapnr))
> -#endif
> -
> #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
> #define virt_addr_valid(kaddr) ((unsigned long)(kaddr) >= PAGE_OFFSET
> && (unsigned long)(kaddr)
> < (unsigned long)high_memory)
>
> @@ -247,18 +242,6 @@ static inline __deprecated void *bus_to_virt(unsigned
> long x)
> #define arch_pfn_to_nid(pfn) PFN_TO_NID(pfn)
> #define arch_local_page_offset(pfn, nid) LOCAL_MAP_NR((pfn) << PAGE_SHIFT)
>
> -#define pfn_valid(pfn) \
> - ({ \
> - unsigned int nid = PFN_TO_NID(pfn); \
> - int valid = nid < MAX_NUMNODES; \
> - if (valid) {\
> - pg_data_t *node = NODE_DATA(nid); \
> - valid = (pfn - node->node_start_pfn) < \
> - node->node_spanned_pages; \
> - } \
> - valid; \
> - })
> -
> #define virt_to_page(kaddr) \
> (ADDR_TO_MAPBASE(kaddr) + LOCAL_MAP_NR(kaddr))
>
> diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
> index 9c746af..3a32af4 100644
> --- a/arch/arm/include/asm/page.h
> +++ b/arch/arm/include/asm/page.h
> @@ -194,6 +194,10 @@ typedef unsigned long pgprot_t;
>
> typedef struct page *pgtable_t;
>
> +#ifndef CONFIG_SPARSEMEM
> +extern int pfn_valid(unsigned long);
> +#endif
> +
> #include
>
> #endif /* !__ASSEMBLY__ */
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 8277802..2542583 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -334,12 +335,42 @@ static void __init bootmem_free_node(int node, struct
> meminfo *mi)
> free_area_init_node(node, zone_size, start_pfn, zhole_size);
> }
>
> +#ifndef CONFIG_SPARSEMEM
> +int pfn_valid(unsigned long pfn)
> +{
> + struct meminfo *mi = &meminfo;
> +
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Sat, Aug 15, 2009 at 09:47:18PM +0530, Syed Mohammed, Khasim wrote:
> Backtrace:
> [] (__flush_dcache_page+0x0/0x3c) from []
> (update_mmu_cache+
> 0x8c/0xb0)
> [] (update_mmu_cache+0x0/0xb0) from []
> (handle_mm_fault+0x53
> 4/0x5ac)
Bingo!
void update_mmu_cache(struct vm_area_struct *vma, unsigned long addr, pte_t pte)
{
unsigned long pfn = pte_pfn(pte);
struct address_space *mapping;
struct page *page;
#define pfn_valid(pfn) ((pfn) >= PHYS_PFN_OFFSET && (pfn) < (PHYS_PFN_OFFSET +
max_mapnr))
if (!pfn_valid(pfn))
return;
page = pfn_to_page(pfn);
mapping = page_mapping(page);
The problem with the above is that in your case is that pfn_valid returns
true for pages in the "hole", which causes update_mmu_cache() to try to
dereference a pointer to them.
Normally, when we have such holes, no one ever maps them (because they
tend to be just an alias of existing memory.)
The real answer to all this is to get pfn_valid() working properly in
_every_ case - that'll also solve the problem which Mel Gorman has been
having to fix several times as well.
The question is how best to handle determining if a PFN (which could be
somewhere in the range 0 to 0xf for 32-bit address space) is valid
without eating up too much memory. One simple way would be to allocate
a bitmap. That'll eat up 128K of memory though, and we know that we
normally have a small amount of that range used... I think a binary
search of the meminfo struct might be the best all-round solution.
Could you try this patch please?
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 376be1a..cefedf0 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -218,7 +218,6 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
*
* page_to_pfn(page) convert a struct page * to a PFN number
* pfn_to_page(pfn) convert a _valid_ PFN number to struct page *
- * pfn_valid(pfn) indicates whether a PFN number is valid
*
* virt_to_page(k)convert a _valid_ virtual address to struct page *
* virt_addr_valid(k) indicates whether a virtual address is valid
@@ -227,10 +226,6 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
#define ARCH_PFN_OFFSETPHYS_PFN_OFFSET
-#ifndef CONFIG_SPARSEMEM
-#define pfn_valid(pfn) ((pfn) >= PHYS_PFN_OFFSET && (pfn) <
(PHYS_PFN_OFFSET + max_mapnr))
-#endif
-
#define virt_to_page(kaddr)pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
#define virt_addr_valid(kaddr) ((unsigned long)(kaddr) >= PAGE_OFFSET &&
(unsigned long)(kaddr) < (unsigned long)high_memory)
@@ -247,18 +242,6 @@ static inline __deprecated void *bus_to_virt(unsigned long
x)
#define arch_pfn_to_nid(pfn) PFN_TO_NID(pfn)
#define arch_local_page_offset(pfn, nid) LOCAL_MAP_NR((pfn) << PAGE_SHIFT)
-#define pfn_valid(pfn) \
- ({ \
- unsigned int nid = PFN_TO_NID(pfn); \
- int valid = nid < MAX_NUMNODES; \
- if (valid) {\
- pg_data_t *node = NODE_DATA(nid); \
- valid = (pfn - node->node_start_pfn) < \
- node->node_spanned_pages; \
- } \
- valid; \
- })
-
#define virt_to_page(kaddr)\
(ADDR_TO_MAPBASE(kaddr) + LOCAL_MAP_NR(kaddr))
diff --git a/arch/arm/include/asm/page.h b/arch/arm/include/asm/page.h
index 9c746af..3a32af4 100644
--- a/arch/arm/include/asm/page.h
+++ b/arch/arm/include/asm/page.h
@@ -194,6 +194,10 @@ typedef unsigned long pgprot_t;
typedef struct page *pgtable_t;
+#ifndef CONFIG_SPARSEMEM
+extern int pfn_valid(unsigned long);
+#endif
+
#include
#endif /* !__ASSEMBLY__ */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8277802..2542583 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -334,12 +335,42 @@ static void __init bootmem_free_node(int node, struct
meminfo *mi)
free_area_init_node(node, zone_size, start_pfn, zhole_size);
}
+#ifndef CONFIG_SPARSEMEM
+int pfn_valid(unsigned long pfn)
+{
+ struct meminfo *mi = &meminfo;
+ unsigned int mid, left = 0, right = mi->nr_banks;
+
+ while ((mid = (right - left) / 2) > 0) {
+ struct membank *bank = &mi->bank[mid];
+
+ if (pfn < bank_pfn_start(bank))
+ right = mid;
+ else if (pfn >= bank_pfn_end(bank))
+ left = mid + 1;
+ else
+ return 1;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(pfn_vali
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
Hi Russell, Thanks for the review, > -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Saturday, August 15, 2009 9:04 PM > To: Syed Mohammed, Khasim > Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > On Fri, Aug 14, 2009 at 04:43:21PM +0530, Syed Mohammed, Khasim wrote: > > Unable to handle kernel paging request at virtual address c5d0 > > pgd = cf858000 > Can you rebuild your kernel yet again, this time with the unwinder > disabled (and therefore frame pointers enabled) please, and reproduce > yet again? Attached below, hope this is correct. ioremap_nocache(0x8580, 16777216)=0xd100 mmap: vma->vm_start = 0x40149000 mmap: vma->vm_pgoff = 0x85800 mmap: vma->vm_end = 0x41149000 mmap: size = 0x100 Unable to handle kernel paging request at virtual address c580 pgd = cf874000 [c580] *pgd= Internal error: Oops: 805 [#1] Modules linked in: cmemk CPU: 0Not tainted (2.6.31-rc5-omap1 #1) PC is at v7_flush_kern_dcache_page+0x14/0x2c LR is at __flush_dcache_page+0x30/0x3c pc : []lr : []psr: 0113 sp : c1737e38 ip : c1737e48 fp : c1737e44 r10: cf874000 r9 : 0200 r8 : 40149000 r7 : ce9b95a0 r6 : ce9b95a0 r5 : c0414000 r4 : 5800 r3 : 0002 r2 : 0040 r1 : c5801000 r0 : c580 Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 8f874019 DAC: 0015 Process a.out (pid: 889, stack limit = 0xc17362e8) Stack: (0xc1737e38 to 0xc1738000) 7e20: c1737e64 c1737e48 7e40: c002c7c0 c002c890 85800383 ce9b95a0 ce9b95a0 c1737ebc c1737e68 7e60: c008611c c002c740 c1737e8c c1737e78 c01a00e0 c01a0084 0149 0001 7e80: ce90a7e0 0524 cf875000 c01a00d4 c031fd38 cf864040 ce9b95a0 7ea0: ce90a814 ce90a7e0 c1737fb0 40149000 c1737efc c1737ec0 c002c098 c0085bf4 7ec0: c1737ed0 081f 0800 c1737ef4 c031fd38 c031fe28 081f 7ee0: c1737fb0 40149000 40023000 c1737fac c1737f00 c0025210 c002bfb8 7f00: c018e4c8 cf8f1410 0200 0002 cf415538 7f20: cf8f1410 000f c1736000 c1737f6c c1737f40 c009866c c00c0d80 7f40: cf8dd5a0 000f 4001c000 7f60: c1737fa4 c1737f70 c0098744 c0098528 c002c274 7f80: 000f 4001c000 7fa0: c1737fb0 c0025d40 c00251e4 40149000 00f8 40149000 7fc0: 40022e08 40023000 bee89ce4 7fe0: 4009eac0 bee89cb8 86dc 4009eaec 2010 80566021 80566421 Backtrace: [] (__flush_dcache_page+0x0/0x3c) from [] (update_mmu_cache+ 0x8c/0xb0) [] (update_mmu_cache+0x0/0xb0) from [] (handle_mm_fault+0x53 4/0x5ac) r7:ce9b95a0 r6:ce9b95a0 r5: r4:85800383 [] (handle_mm_fault+0x0/0x5ac) from [] (do_page_fault+0xec/0 x234) [] (do_page_fault+0x0/0x234) from [] (do_DataAbort+0x38/0x98 ) [] (do_DataAbort+0x0/0x98) from [] (ret_from_exception+0x0/0 x10) Exception stack(0xc1737fb0 to 0xc1737ff8) 7fa0: 40149000 00f8 40149000 7fc0: 40022e08 40023000 bee89ce4 7fe0: 4009eac0 bee89cb8 86dc 4009eaec 2010 r8: r7: r6: r5: r4: Code: e2033007 e3a02010 e1a02312 e2801a01 (ee070f3e) ---[ end trace b534dcb6339fe900 ]--- Regards, Khasim -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Fri, Aug 14, 2009 at 04:43:21PM +0530, Syed Mohammed, Khasim wrote: > Unable to handle kernel paging request at virtual address c5d0 > pgd = cf858000 > [c5d0] *pgd= > Internal error: Oops: 805 [#1] > Modules linked in: cmemk > CPU: 0Not tainted (2.6.31-rc5-omap1 #2) > PC is at v7_flush_kern_dcache_page+0x14/0x2c > LR is at __flush_dcache_page+0x28/0x34 > pc : []lr : []psr: 0113 > sp : c1d1de70 ip : c0356000 fp : ce8ce060 > r10: cf858000 r9 : 0200 r8 : 40168000 > r7 : ce95b8b8 r6 : ce95b8b8 r5 : c041 r4 : 5d00 > r3 : 0002 r2 : 0040 r1 : c5d01000 r0 : c5d0 > Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 10c5387d Table: 8f858019 DAC: 0015 > Process a.out (pid: 889, stack limit = 0xc1d1c2e8) > Stack: (0xc1d1de70 to 0xc1d1e000) > de60: 5d00 c002a7e4 85d00383 > de80: ce95b8b8 c007e680 c031a3f0 e94f704f 0011 00165a0c c1d1debc 0168 > dea0: 0001 05a0 cf859000 c1d1dee0 0726 c0311d20 cf8d9360 ce95b8b8 > dec0: ce8ce094 ce8ce060 c1d1dfb0 40168000 081f c002a118 1405ffdc 0017 > dee0: 13920cdc 0800 c0312aa0 c0311d20 c0311e10 081f c1d1dfb0 40168000 > df00: 40023000 beeafce4 c00231e8 139195a6 0017 c031c3f8 c005f6f4 > df20: 0017 c0341820 0100 0004 0081 0001 c004ce30 > df40: c1d1df40 c1d1df40 0013 c1d1c000 c0324924 c0324958 0020 c006b67c > df60: c1d1c000 0100 0020 c0049478 8000 c0312b20 005f > df80: c1d1c000 beeafce4 c0049544 > dfa0: c0023c9c 40149000 002e0ff4 40168000 > dfc0: 40022e08 40023000 beeafce4 > dfe0: 4009eac0 beeafce0 98c4 4009eaec 2010 47d63e68 9cfcabf3 Okay, this is perfect, up until here: > [] (v7_flush_kern_dcache_page+0x14/0x2c) from [] > (0xe94f704f > ) where we don't have the full backtrace, and therefore don't know how we got to this function. Gah, this is intensely frustrating. As Catalin has recently pointed out, this could be because of a toolchain which doesn't know how to emit the unwind information. I'm sure there's other reasons. But, at the end of the day, if this is the kind of oops dump we can now expect, bug hunting is going to become a very frustrating business. Can you rebuild your kernel yet again, this time with the unwinder disabled (and therefore frame pointers enabled) please, and reproduce yet again? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
> > On Sat, Aug 15, 2009 at 06:33:20PM +0530, Sudeep K N wrote: > > I had intially tried memmap=xxM$yyM to reserve xxM at yyM > > This has some issue with 2.6.27 and fixed in later versions(not sure > > of exact version) and I have not tried it. > > memmap= is not supported on ARM - there is no code to parse or use the > option except on x86 and blackfin, so it gets passed to the init program > when userspace starts. I am just wondering if there is something extra that needs to be done in my kernel or app, below are the lines that I feel will matter, In driver module: - request_mem_region(start_addr, length, "name"); - ioremap_nocache (start_addr,length); (in mmap function) - vma->vm_flags |= VM_RESERVED | VM_IO; - remap_pfn_range(vma,vma->vm_start,vma->vm_pgoff,vma->vm_end-vma->vm_start, vma->vm_page_prot); In my app: - userp = mmap((void *)0x0, size, PROT_WRITE|PROT_READ,MAP_SHARED,fd,0x8580); - memset((void *)userp,0,0x100); Few Observations: - When my bootargs doesn't is just mem=...@0x8000, I don't see any issues it works great - When my bootargs is mem=...@0x8000 mem=...@0x8c40 it crashes at user space. Where as when I do same memset in driver (kernel space) it passes, the issue is only with user space (over mmap) - With hole, when I use mmap with MAP_PRIVATE it passes fine. I can give both driver and app that I have, but it has nothing but the above lines. Thanks for the comments. Regards, Khasim -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Sat, Aug 15, 2009 at 06:33:20PM +0530, Sudeep K N wrote: > I had intially tried memmap=xxM$yyM to reserve xxM at yyM > This has some issue with 2.6.27 and fixed in later versions(not sure > of exact version) and I have not tried it. memmap= is not supported on ARM - there is no code to parse or use the option except on x86 and blackfin, so it gets passed to the init program when userspace starts. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
Khasim, As far as I understand there are two options: 1. memmap I had intially tried memmap=xxM$yyM to reserve xxM at yyM This has some issue with 2.6.27 and fixed in later versions(not sure of exact version) and I have not tried it. As Russell has mentioned the new option ARCH_HAS_HOLES_MEMORYMODEL is the part of that fix I believe. The bug was particular to few architecture including ARM(details at http://lkml.org/lkml/2009/5/5/64) With this option its only resevered and you can still mmap that memory. 2. mem As an alternate, I tried spliting the memory to the kernel similar to what you have tried. mem=...@0x8000 mem=1...@0x8800 But if you see how this is parsed by the kernel, you will see that the kernel doesnot create any virtual address space for the hole you have created. In otherwords the kernel is totally unware of that memory. So you cannot mmap that hole. This is my understanding and please correct if I am wrong. -- Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Thursday, August 13, 2009 11:03 PM > To: Syed Mohammed, Khasim > Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > On Thu, Aug 13, 2009 at 10:51:43PM +0530, Syed Mohammed, Khasim wrote: > > <1>Unable to handle kernel paging request at virtual address c5cef000 > > Unable to handle kernel > paging request at virtual address c5cef000 > > > > Internal error: Oops: 805 [#4] > > Internal error: Oops: 805 [#4] > > Modules linked in:Modules linked in: cmemk cmemk > > Please. If you've got the kernel booting. Turn off printascii support. > This oops dump is almost unreadable as a result of keeping printascii > support enabled. Sorry, here is the one with out DEBUG_LL r...@beagleboard:/media/mmcblk0p1# ./a.out mmap: vma->vm_start = 0x40149000 mmap: vma->vm_pgoff = 0x85ce1 mmap: vma->vm_end = 0x404b8000 mmap: size = 0x36f000 mmap: calling set_noncached(ce95b8b8) ... mmap: vma->vm_start = 0x404b8000 mmap: vma->vm_pgoff = 0x85972 mmap: vma->vm_end = 0x40827000 mmap: size = 0x36f000 mmap: calling set_noncached(ce95bc28) ... Unable to handle kernel paging request at virtual address c5d0 pgd = cf858000 [c5d0] *pgd= Internal error: Oops: 805 [#1] Modules linked in: cmemk CPU: 0Not tainted (2.6.31-rc5-omap1 #2) PC is at v7_flush_kern_dcache_page+0x14/0x2c LR is at __flush_dcache_page+0x28/0x34 pc : []lr : []psr: 0113 sp : c1d1de70 ip : c0356000 fp : ce8ce060 r10: cf858000 r9 : 0200 r8 : 40168000 r7 : ce95b8b8 r6 : ce95b8b8 r5 : c041 r4 : 5d00 r3 : 0002 r2 : 0040 r1 : c5d01000 r0 : c5d0 Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 8f858019 DAC: 0015 Process a.out (pid: 889, stack limit = 0xc1d1c2e8) Stack: (0xc1d1de70 to 0xc1d1e000) de60: 5d00 c002a7e4 85d00383 de80: ce95b8b8 c007e680 c031a3f0 e94f704f 0011 00165a0c c1d1debc 0168 dea0: 0001 05a0 cf859000 c1d1dee0 0726 c0311d20 cf8d9360 ce95b8b8 dec0: ce8ce094 ce8ce060 c1d1dfb0 40168000 081f c002a118 1405ffdc 0017 dee0: 13920cdc 0800 c0312aa0 c0311d20 c0311e10 081f c1d1dfb0 40168000 df00: 40023000 beeafce4 c00231e8 139195a6 0017 c031c3f8 c005f6f4 df20: 0017 c0341820 0100 0004 0081 0001 c004ce30 df40: c1d1df40 c1d1df40 0013 c1d1c000 c0324924 c0324958 0020 c006b67c df60: c1d1c000 0100 0020 c0049478 8000 c0312b20 005f df80: c1d1c000 beeafce4 c0049544 dfa0: c0023c9c 40149000 002e0ff4 40168000 dfc0: 40022e08 40023000 beeafce4 dfe0: 4009eac0 beeafce0 98c4 4009eaec 2010 47d63e68 9cfcabf3 [] (v7_flush_kern_dcache_page+0x14/0x2c) from [] (0xe94f704f ) Code: e2033007 e3a02010 e1a02312 e2801a01 (ee070f3e) ---[ end trace 58a066cdb6c0f78c ]--- Segmentation fault Regards, Khasim -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Thu, Aug 13, 2009 at 10:51:43PM +0530, Syed Mohammed, Khasim wrote: > <1>Unable to handle kernel paging request at virtual address c5cef000 Unable > to handle kernel paging request at virtual address c5cef000 > > Internal error: Oops: 805 [#4] > Internal error: Oops: 805 [#4] > Modules linked in:Modules linked in: cmemk cmemk Please. If you've got the kernel booting. Turn off printascii support. This oops dump is almost unreadable as a result of keeping printascii support enabled. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
Russell, I have attached the dump below, Summary, we have latest kernel 2.6.31-rc5-omap1 running on beagle with ARCH_HAS_HOLES_MEMORYMODEL enabled for OMAP architecture. 8000 to 857F - (88M for kernel) 8580 to 8c3F - (108M hole) 8c40 to 8FFF - (60M for kernel) After booting the kernel and a kernel module uses request_mem_region and ioremap to create some pool of memory in the hole region. A user application mmap s this space and uses memset to fill 0s in one of the pool. This results in a crash. When we don't create the hole (kernel has only 88M) and run same kernel module and app then it passes. I am doing some clean up to my test driver and app, I can pass these later this week. Thanks Regards, Khasim > -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Saturday, August 08, 2009 10:33 PM > To: Syed Mohammed, Khasim > Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > On Sat, Aug 08, 2009 at 08:45:44PM +0530, Syed Mohammed, Khasim wrote: > > Hi Russell, > > > > > -Original Message- > > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > > > Sent: Saturday, August 08, 2009 3:30 AM > > > To: Syed Mohammed, Khasim > > > Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > > > Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > > > > > On Sat, Aug 08, 2009 at 01:46:35AM +0530, Syed Mohammed, Khasim wrote: > > > > On OMAP3 we are creating a space for DSP components to have shared > > > > buffers using the boot arguments. > > > > > > > > mem=...@0x8000 mem=1...@0x8800 > > > > > > Ensure that you have ARCH_HAS_HOLES_MEMORYMODEL enabled in the > > > configuration - you need OMAP3 to select this symbol. > > > > We are on 2.6.29 on beagleboard, this kernel doesn't support > > ARCH_HAS_HOLES_MEMORYMODEL so I > applied the patch from > > > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- > 2.6.git;a=commitdiff;h=eb33575cf67d3f35fa2510210ef92631266e2465 > > > > Didn't help, still fails, do you suggest us to move to latest kernel and > > try the same instead of > patch alone? > > In which case, please supply a full bug report with a _full_ oops dump. r...@beagleboard:/media/mmcblk0p1# ./a.out mmap: vma->vm_start = 0x40137000 mmap: vma->vm_pgoff = 0x85ce1 mmap: vma->vm_end = 0x404a6000 mmap: size = 0x36f000 <1>Unable to handle kernel paging request at virtual address c5cef000 Unable to handle kernel paging request at virtual address c5cef000 Internal error: Oops: 805 [#4] Internal error: Oops: 805 [#4] Modules linked in:Modules linked in: cmemk cmemk CPU: 0Tainted: G D (2.6.31-rc5-omap1 #7) CPU: 0Tainted: G D (2.6.31-rc5-omap1 #7) PC is at v7_flush_kern_dcache_page+0x14/0x2c PC is at v7_flush_kern_dcache_page+0x14/0x2c LR is at __flush_dcache_page+0x28/0x34 LR is at __flush_dcache_page+0x28/0x34 pc : []lr : []psr: 0113 sp : ce97be80 ip : c0415de0 fp : 081f pc : []lr : []psr: 0113 sp : ce97be80 ip : c0415de0 fp : 081f r10: 0514 r9 : 1000 r8 : 40145000 r10: 0514 r9 : 1000 r8 : 40145000 r7 : c1daec80 r6 : 85cef383 r5 : cf8b39a0 r4 : c1daec80 r7 : c1daec80 r6 : 85cef383 r5 : cf8b39a0 r4 : c1daec80 r3 : 0002 r2 : 0040 r1 : c5cf r0 : c5cef000 r3 : 0002 r2 : 0040 r1 : c5cf r0 : c5cef000 Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 8f850019 DAC: 0015 Control: 10c5387d Table: 8f850019 DAC: 0015 Process a.out (pid: 893, stack limit = 0xce97a2e8) Process a.out (pid: 893, stack limit = 0xce97a2e8) Stack: (0xce97be80 to 0xce97c000) Stack: (0xce97be80 to 0xce97c000) be80: be80: c1daec80 c1daec80 c002a88c c002a88c c007eaa4 c007e aa4 c0320890 c0320890 c03203f0 c03203f0 b954fd20 b954fd20 02cc 02cc bea0: bea0: 0001 0001 ce8ed7e0 ce8ed7e0 07735940 07735940 cf851000 cf851 000 ce97bee0 ce97bee0 c0317d20 c0317d20 cf8b39a0 cf8b39a0 c1daec80 c1daec80 bec0: bec0: ce8ed814 ce8ed814 ce8ed7e0 ce8ed7e0 ce97bfb0 ce97bfb0 40145000 40145 000 081f 081f c002a1b0 c002a1b0 07735940 07735940 0bd3 0bd3 bee0: bee0: 07735940 07735940 0800 0800 06feeec9 06feeec9 c0317d20 c0317 d20 c0317e10 c0317e10 081f 081f ce97bfb0 ce97bfb0 40145000 40145000 bf00: bf00: 40023000 40023000 be859ce4 be859ce4 c00231ec c0023 1ec 0bd3 0bd3 c03223f8 c03223f8
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Sat, Aug 08, 2009 at 08:45:44PM +0530, Syed Mohammed, Khasim wrote: > Hi Russell, > > > -Original Message- > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > > Sent: Saturday, August 08, 2009 3:30 AM > > To: Syed Mohammed, Khasim > > Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > > Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > > > On Sat, Aug 08, 2009 at 01:46:35AM +0530, Syed Mohammed, Khasim wrote: > > > On OMAP3 we are creating a space for DSP components to have shared > > > buffers using the boot arguments. > > > > > > mem=...@0x8000 mem=1...@0x8800 > > > > Ensure that you have ARCH_HAS_HOLES_MEMORYMODEL enabled in the > > configuration - you need OMAP3 to select this symbol. > > We are on 2.6.29 on beagleboard, this kernel doesn't support > ARCH_HAS_HOLES_MEMORYMODEL so I applied the patch from > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=eb33575cf67d3f35fa2510210ef92631266e2465 > > Didn't help, still fails, do you suggest us to move to latest kernel and try > the same instead of patch alone? In which case, please supply a full bug report with a _full_ oops dump. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
Hi Russell, > -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Saturday, August 08, 2009 3:30 AM > To: Syed Mohammed, Khasim > Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > Subject: Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > On Sat, Aug 08, 2009 at 01:46:35AM +0530, Syed Mohammed, Khasim wrote: > > On OMAP3 we are creating a space for DSP components to have shared > > buffers using the boot arguments. > > > > mem=...@0x8000 mem=1...@0x8800 > > Ensure that you have ARCH_HAS_HOLES_MEMORYMODEL enabled in the > configuration - you need OMAP3 to select this symbol. We are on 2.6.29 on beagleboard, this kernel doesn't support ARCH_HAS_HOLES_MEMORYMODEL so I applied the patch from http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=eb33575cf67d3f35fa2510210ef92631266e2465 Didn't help, still fails, do you suggest us to move to latest kernel and try the same instead of patch alone? Regards, Khasim -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
> -Original Message- > From: Woodruff, Richard > Sent: Saturday, August 08, 2009 2:49 AM > To: Syed Mohammed, Khasim; linux-arm-ker...@lists.arm.linux.org.uk; > linux-omap@vger.kernel.org > Subject: RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > Used to be you needed to build with CONFIG_ARCH_DISCONTIGMEM_ENABLE did you > do this? > Hi Richard, This shows as deprecated, # Discontigmem is deprecated config ARCH_DISCONTIGMEM_ENABLE I tried this today, enabling this for ARCH_OMAP results in compilation error In file included from arch/arm/kernel/asm-offsets.c:14: include/linux/mm.h: In function 'virt_to_head_page': include/linux/mm.h:310: error: implicit declaration of function 'KVADDR_TO_NID' include/linux/mm.h:310: error: implicit declaration of function 'LOCAL_MAP_NR' This is because NODE_MEM_SIZE_BITS is not enabled, I didn't get a proper value just tried copying others with 24 and 26, - THIS Just didn't boot to prompt. Should we fix this up? -or leave it out as it is getting deprecated ? Thanks for the input. Regards, Khasim > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Syed Mohammed, Khasim > > Sent: Friday, August 07, 2009 3:17 PM > > To: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > > Subject: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > > > Hi all, > > > > On OMAP3 we are creating a space for DSP components to have shared buffers > > using the boot arguments. > > > > mem=...@0x8000 mem=1...@0x8800 > > > > This creates a 40M hole for DSP components, the drivers dynamically do a > > request mem region and ioremap of pre-defined address space with in the 40M > > region. > > > > With the above setup, we see the system running for a while but then ends up > > with exception. > > > > "Unable to handle kernel paging request at virtual address c7381000" > > > > The address reported here is not in kernel space, and this doesn't result > > in a > > kernel panic. > > > > Other observation: > > - The same setup works fine with no hole or space created. The 40M space for > > DSP components will be allocated at the end (216M). > > - If we increase the mem hole region we can make the system fail with in > > less > > time. > > - Free returns expected memory map > > > > While I am still debugging the issue, I thought of posting this message to > > know if there are any known issues with ARM architecture in handling such > > non > > contiguous space / mem hole. > > > > I see some special boot parameters for other architectures like exactmap, we > > don't see similar stuff on ARM. Do we need to port any such support for ARM > > ? > > > > Kindly advice, > > > > Thanks. > > > > Regards, > > Khasim > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
On Sat, Aug 08, 2009 at 01:46:35AM +0530, Syed Mohammed, Khasim wrote: > On OMAP3 we are creating a space for DSP components to have shared > buffers using the boot arguments. > > mem=...@0x8000 mem=1...@0x8800 Ensure that you have ARCH_HAS_HOLES_MEMORYMODEL enabled in the configuration - you need OMAP3 to select this symbol. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
Used to be you needed to build with CONFIG_ARCH_DISCONTIGMEM_ENABLE did you do this? Regards, Richard W. > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Syed Mohammed, Khasim > Sent: Friday, August 07, 2009 3:17 PM > To: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org > Subject: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8 > > Hi all, > > On OMAP3 we are creating a space for DSP components to have shared buffers > using the boot arguments. > > mem=...@0x8000 mem=1...@0x8800 > > This creates a 40M hole for DSP components, the drivers dynamically do a > request mem region and ioremap of pre-defined address space with in the 40M > region. > > With the above setup, we see the system running for a while but then ends up > with exception. > > "Unable to handle kernel paging request at virtual address c7381000" > > The address reported here is not in kernel space, and this doesn't result in a > kernel panic. > > Other observation: > - The same setup works fine with no hole or space created. The 40M space for > DSP components will be allocated at the end (216M). > - If we increase the mem hole region we can make the system fail with in less > time. > - Free returns expected memory map > > While I am still debugging the issue, I thought of posting this message to > know if there are any known issues with ARM architecture in handling such non > contiguous space / mem hole. > > I see some special boot parameters for other architectures like exactmap, we > don't see similar stuff on ARM. Do we need to port any such support for ARM ? > > Kindly advice, > > Thanks. > > Regards, > Khasim > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
