Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

Hi all,

On OMAP3 we are creating a space for DSP components to have shared buffers using the boot arguments.

mem=88M@0x80000000 mem=128M@0x88000000

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

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Woodruff, Richard]

Used to be you needed to build with CONFIG_ARCH_DISCONTIGMEM_ENABLE did you do this?

Regards,
Richard W.

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Syed Mohammed, Khasim
> Sent: Friday, August 07, 2009 3:17 PM
> To: linux-arm-kernel@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=88M@0x80000000 mem=128M@0x88000000
>
> 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 majordomo@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

[Syed Mohammed, Khasim]

> -----Original Message-----
> From: Woodruff, Richard
> Sent: Saturday, August 08, 2009 2:49 AM
> To: Syed Mohammed, Khasim; linux-arm-kernel@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-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Syed Mohammed, Khasim
> > Sent: Friday, August 07, 2009 3:17 PM
> > To: linux-arm-kernel@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=88M@0x80000000 mem=128M@0x88000000
> >
> > 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 majordomo@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 King - ARM Linux]

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=88M@0x80000000 mem=128M@0x88000000

Ensure that you have ARCH_HAS_HOLES_MEMORYMODEL enabled in the
configuration - you need OMAP3 to select this symbol.

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

Hi Russell,

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Saturday, August 08, 2009 3:30 AM
> To: Syed Mohammed, Khasim
> Cc: linux-arm-kernel@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=88M@0x80000000 mem=128M@0x88000000
> 
> 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

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

On Sat, Aug 08, 2009 at 08:45:44PM +0530, Syed Mohammed, Khasim wrote:
> Hi Russell,
> 
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> > Sent: Saturday, August 08, 2009 3:30 AM
> > To: Syed Mohammed, Khasim
> > Cc: linux-arm-kernel@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=88M@0x80000000 mem=128M@0x88000000
> > 
> > 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.

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

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.

80000000 to 857FFFFF - (88M for kernel)
85800000 to 8c3FFFFF - (108M hole)
8c400000 to 8FFFFFFF - (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:linux@arm.linux.org.uk]
> Sent: Saturday, August 08, 2009 10:33 PM
> To: Syed Mohammed, Khasim
> Cc: linux-arm-kernel@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:linux@arm.linux.org.uk]
> > > Sent: Saturday, August 08, 2009 3:30 AM
> > > To: Syed Mohammed, Khasim
> > > Cc: linux-arm-kernel@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=88M@0x80000000 mem=128M@0x88000000
> > >
> > > 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.

root@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]
<d>Modules linked in:Modules linked in: cmemk cmemk

CPU: 0    Tainted: G      D     (2.6.31-rc5-omap1 #7)
CPU: 0    Tainted: 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 : [<c002c348>]    lr : [<c002a950>]    psr: 00000113
sp : ce97be80  ip : c0415de0  fp : 0000081f
pc : [<c002c348>]    lr : [<c002a950>]    psr: 00000113
sp : ce97be80  ip : c0415de0  fp : 0000081f
r10: 00000514  r9 : 00001000  r8 : 40145000
r10: 00000514  r9 : 00001000  r8 : 40145000
r7 : c1daec80  r6 : 85cef383  r5 : cf8b39a0  r4 : c1daec80
r7 : c1daec80  r6 : 85cef383  r5 : cf8b39a0  r4 : c1daec80
r3 : 00000002  r2 : 00000040  r1 : c5cf0000  r0 : c5cef000
r3 : 00000002  r2 : 00000040  r1 : c5cf0000  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: 00000015
Control: 10c5387d  Table: 8f850019  DAC: 00000015 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 00000000 00000000 c007eaa4 c007e
aa4 c0320890 c0320890 c03203f0 c03203f0 b954fd20 b954fd20 000002cc 000002cc

bea0: bea0: 00000001 00000001 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 0000081f 0000081f c002a1b0 c002a1b0 07735940 07735940 00000bd3 00000bd3

bee0: bee0: 07735940 07735940 00000800 00000800 06feeec9 06feeec9 c0317d20
c0317
d20 c0317e10 c0317e10 0000081f 0000081f ce97bfb0 ce97bfb0 40145000 40145000

bf00: bf00: 00000000 00000000 40023000 40023000 be859ce4 be859ce4 c00231ec
c0023
1ec 00000bd3 00000bd3 c03223f8 c03223f8 00000001 00000001 06feeec8 06feeec8

bf20: bf20: 00000060 00000060 c035060c c035060c 00000001 00000001 c018f458 c018f
458 c035060c c035060c 00000008 00000008 c03506b0 c03506b0 c035060c c035060c

bf40: bf40: 00000001 00000001 00000000 00000000 00000000 00000000 0000004a 00000 04a c1d85340 c1d85340 c018f4d0 c018f4d0 ce9e8420 ce9e8420 0000004a 0000004a

bf60: bf60: 00000000 00000000 00000000 00000000 00000000 00000000 ce97a000 ce97a 000 40023000 40023000 c00692b0 c00692b0 c03241d8 c03241d8 0000004a 0000004a

bf80: bf80: 00000000 00000000 00000000 00000000 00000000 00000000 c006aeb8 c006a
eb8 be859ce4 be859ce4 c0049b40 c0049b40 ffffffff ffffffff 00000000 00000000

bfa0: bfa0: 00000000 00000000 00000000 00000000 00000000 00000000 c0023c7c
c0023
c7c 40137000 40137000 00000000 00000000 002f1ff4 002f1ff4 40145000 40145000

bfc0: bfc0: 40022e08 40022e08 00000000 00000000 00000000 00000000 00000000 00000 000 00000000 00000000 00000000 00000000 40023000 40023000 be859ce4 be859ce4

bfe0: bfe0: 4008cac0 4008cac0 be859ce0 be859ce0 000099dc 000099dc 4008caec 4008c aec 20000010 20000010 ffffffff ffffffff 00000000 00000000 00000000 00000000

[<c002c348>] [<c002c348>] (v7_flush_kern_dcache_page+0x14/0x2c)
(v7_flush_kern_d
cache_page+0x14/0x2c) from [<c1daec80>] from [<c1daec80>] (0xc1daec80)
(0xc1daec80)
Code: Code: e2033007 e2033007 e3a02010 e3a02010 e1a02312 e1a02312 e2801a01
e2801
a01 (ee070f3e) (ee070f3e)

00

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

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]
> <d>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.

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Thursday, August 13, 2009 11:03 PM
> To: Syed Mohammed, Khasim
> Cc: linux-arm-kernel@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]
> > <d>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

root@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 c5d00000
pgd = cf858000
[c5d00000] *pgd=00000000
Internal error: Oops: 805 [#1]
Modules linked in: cmemk
CPU: 0    Not 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 : [<c002c268>]    lr : [<c002a8b0>]    psr: 00000113
sp : c1d1de70  ip : c0356000  fp : ce8ce060
r10: cf858000  r9 : 00000200  r8 : 40168000
r7 : ce95b8b8  r6 : ce95b8b8  r5 : c0410000  r4 : 00005d00
r3 : 00000002  r2 : 00000040  r1 : c5d01000  r0 : c5d00000
Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8f858019  DAC: 00000015
Process a.out (pid: 889, stack limit = 0xc1d1c2e8)
Stack: (0xc1d1de70 to 0xc1d1e000)
de60:                                     00005d00 c002a7e4 85d00383 00000000
de80: ce95b8b8 c007e680 c031a3f0 e94f704f 00000011 00165a0c c1d1debc 00000168
dea0: 00000001 000005a0 cf859000 c1d1dee0 00000726 c0311d20 cf8d9360 ce95b8b8
dec0: ce8ce094 ce8ce060 c1d1dfb0 40168000 0000081f c002a118 1405ffdc 00000017
dee0: 13920cdc 00000800 c0312aa0 c0311d20 c0311e10 0000081f c1d1dfb0 40168000
df00: 00000000 40023000 beeafce4 c00231e8 139195a6 00000017 c031c3f8 c005f6f4
df20: 00000000 00000017 c0341820 00000100 00000004 00000081 00000001 c004ce30
df40: c1d1df40 c1d1df40 00000013 c1d1c000 c0324924 c0324958 00000020 c006b67c
df60: c1d1c000 00000100 00000020 c0049478 80000000 c0312b20 0000005f 00000000
df80: 00000000 00000000 00000000 c1d1c000 beeafce4 c0049544 ffffffff 00000000
dfa0: 00000000 00000000 00000000 c0023c9c 40149000 00000000 002e0ff4 40168000
dfc0: 40022e08 00000000 00000000 00000000 00000000 00000000 40023000 beeafce4
dfe0: 4009eac0 beeafce0 000098c4 4009eaec 20000010 ffffffff 47d63e68 9cfcabf3
[<c002c268>] (v7_flush_kern_dcache_page+0x14/0x2c) from [<e94f704f>] (0xe94f704f
)
Code: e2033007 e3a02010 e1a02312 e2801a01 (ee070f3e)
---[ end trace 58a066cdb6c0f78c ]---
Segmentation fault

Regards,
Khasim

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Sudeep K N]

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=88M@0x80000000 mem=128M@0x88000000
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

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

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.

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

> 
> 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,0x85800000);
- memset((void *)userp,0,0x1000000);

Few Observations:
- When my bootargs doesn't is just mem=88M@0x80000000, I don't see any issues it works great
- When my bootargs is mem=88M@0x80000000 mem=60M@0x8C400000 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

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

On Fri, Aug 14, 2009 at 04:43:21PM +0530, Syed Mohammed, Khasim wrote:
> Unable to handle kernel paging request at virtual address c5d00000
> pgd = cf858000
> [c5d00000] *pgd=00000000
> Internal error: Oops: 805 [#1]
> Modules linked in: cmemk
> CPU: 0    Not 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 : [<c002c268>]    lr : [<c002a8b0>]    psr: 00000113
> sp : c1d1de70  ip : c0356000  fp : ce8ce060
> r10: cf858000  r9 : 00000200  r8 : 40168000
> r7 : ce95b8b8  r6 : ce95b8b8  r5 : c0410000  r4 : 00005d00
> r3 : 00000002  r2 : 00000040  r1 : c5d01000  r0 : c5d00000
> Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 10c5387d  Table: 8f858019  DAC: 00000015
> Process a.out (pid: 889, stack limit = 0xc1d1c2e8)
> Stack: (0xc1d1de70 to 0xc1d1e000)
> de60:                                     00005d00 c002a7e4 85d00383 00000000
> de80: ce95b8b8 c007e680 c031a3f0 e94f704f 00000011 00165a0c c1d1debc 00000168
> dea0: 00000001 000005a0 cf859000 c1d1dee0 00000726 c0311d20 cf8d9360 ce95b8b8
> dec0: ce8ce094 ce8ce060 c1d1dfb0 40168000 0000081f c002a118 1405ffdc 00000017
> dee0: 13920cdc 00000800 c0312aa0 c0311d20 c0311e10 0000081f c1d1dfb0 40168000
> df00: 00000000 40023000 beeafce4 c00231e8 139195a6 00000017 c031c3f8 c005f6f4
> df20: 00000000 00000017 c0341820 00000100 00000004 00000081 00000001 c004ce30
> df40: c1d1df40 c1d1df40 00000013 c1d1c000 c0324924 c0324958 00000020 c006b67c
> df60: c1d1c000 00000100 00000020 c0049478 80000000 c0312b20 0000005f 00000000
> df80: 00000000 00000000 00000000 c1d1c000 beeafce4 c0049544 ffffffff 00000000
> dfa0: 00000000 00000000 00000000 c0023c9c 40149000 00000000 002e0ff4 40168000
> dfc0: 40022e08 00000000 00000000 00000000 00000000 00000000 40023000 beeafce4
> dfe0: 4009eac0 beeafce0 000098c4 4009eaec 20000010 ffffffff 47d63e68 9cfcabf3

Okay, this is perfect, up until here:

> [<c002c268>] (v7_flush_kern_dcache_page+0x14/0x2c) from [<e94f704f>] (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?

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

Hi Russell,

Thanks for the review,

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Saturday, August 15, 2009 9:04 PM
> To: Syed Mohammed, Khasim
> Cc: linux-arm-kernel@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 c5d00000
> > pgd = cf858000
<snip>
 
> 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(0x85800000, 16777216)=0xd1000000
mmap: vma->vm_start     = 0x40149000
mmap: vma->vm_pgoff     = 0x85800
mmap: vma->vm_end       = 0x41149000
mmap: size              = 0x1000000

Unable to handle kernel paging request at virtual address c5800000
pgd = cf874000
[c5800000] *pgd=00000000
Internal error: Oops: 805 [#1]
Modules linked in: cmemk
CPU: 0    Not 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 : [<c002e388>]    lr : [<c002c8b4>]    psr: 00000113
sp : c1737e38  ip : c1737e48  fp : c1737e44
r10: cf874000  r9 : 00000200  r8 : 40149000
r7 : ce9b95a0  r6 : ce9b95a0  r5 : c0414000  r4 : 00005800
r3 : 00000002  r2 : 00000040  r1 : c5801000  r0 : c5800000
Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8f874019  DAC: 00000015
Process a.out (pid: 889, stack limit = 0xc17362e8)
Stack: (0xc1737e38 to 0xc1738000)
7e20:                                                       c1737e64 c1737e48
7e40: c002c7c0 c002c890 85800383 00000000 ce9b95a0 ce9b95a0 c1737ebc c1737e68
7e60: c008611c c002c740 c1737e8c c1737e78 c01a00e0 c01a0084 00000149 00000001
7e80: ce90a7e0 00000524 cf875000 c01a00d4 00000000 c031fd38 cf864040 ce9b95a0
7ea0: ce90a814 ce90a7e0 c1737fb0 40149000 c1737efc c1737ec0 c002c098 c0085bf4
7ec0: 00000000 c1737ed0 0000081f 00000800 c1737ef4 c031fd38 c031fe28 0000081f
7ee0: c1737fb0 40149000 00000000 40023000 c1737fac c1737f00 c0025210 c002bfb8
7f00: c018e4c8 00000000 00000000 cf8f1410 00000200 00000002 00000000 cf415538
7f20: cf8f1410 0000000f c1736000 00000000 c1737f6c c1737f40 c009866c c00c0d80
7f40: 00000000 00000000 00000000 00000000 00000000 cf8dd5a0 0000000f 4001c000
7f60: c1737fa4 c1737f70 c0098744 c0098528 00000000 00000000 c002c274 00000000
7f80: ffffffff 0000000f 4001c000 ffffffff 00000000 00000000 00000000 00000000
7fa0: 00000000 c1737fb0 c0025d40 c00251e4 40149000 00000000 00fffff8 40149000
7fc0: 40022e08 00000000 00000000 00000000 00000000 00000000 40023000 bee89ce4
7fe0: 4009eac0 bee89cb8 000086dc 4009eaec 20000010 ffffffff 80566021 80566421
Backtrace:
[<c002c884>] (__flush_dcache_page+0x0/0x3c) from [<c002c7c0>] (update_mmu_cache+
0x8c/0xb0)
[<c002c734>] (update_mmu_cache+0x0/0xb0) from [<c008611c>] (handle_mm_fault+0x53
4/0x5ac)
 r7:ce9b95a0 r6:ce9b95a0 r5:00000000 r4:85800383
[<c0085be8>] (handle_mm_fault+0x0/0x5ac) from [<c002c098>] (do_page_fault+0xec/0
x234)
[<c002bfac>] (do_page_fault+0x0/0x234) from [<c0025210>] (do_DataAbort+0x38/0x98
)
[<c00251d8>] (do_DataAbort+0x0/0x98) from [<c0025d40>] (ret_from_exception+0x0/0
x10)
Exception stack(0xc1737fb0 to 0xc1737ff8)
7fa0:                                     40149000 00000000 00fffff8 40149000
7fc0: 40022e08 00000000 00000000 00000000 00000000 00000000 40023000 bee89ce4
7fe0: 4009eac0 bee89cb8 000086dc 4009eaec 20000010 ffffffff
 r8:00000000 r7:00000000 r6:00000000 r5:00000000 r4:ffffffff
Code: e2033007 e3a02010 e1a02312 e2801a01 (ee070f3e)
---[ end trace b534dcb6339fe900 ]---

Regards,
Khasim

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

On Sat, Aug 15, 2009 at 09:47:18PM +0530, Syed Mohammed, Khasim wrote:
> Backtrace:
> [<c002c884>] (__flush_dcache_page+0x0/0x3c) from [<c002c7c0>] (update_mmu_cache+
> 0x8c/0xb0)
> [<c002c734>] (update_mmu_cache+0x0/0xb0) from [<c008611c>] (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 0xfffff 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_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 <asm/memory.h>
 
 #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 <linux/mman.h>
 #include <linux/nodemask.h>
 #include <linux/initrd.h>
+#include <linux/sort.h>
 #include <linux/highmem.h>
 
 #include <asm/mach-types.h>
@@ -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_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(b) - bank_pfn_start(a);
+	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.
 	 */

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

Hi Russell,

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Saturday, August 15, 2009 11:47 PM
> To: Syed Mohammed, Khasim
> Cc: linux-arm-kernel@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:
> > [<c002c884>] (__flush_dcache_page+0x0/0x3c) from [<c002c7c0>] (update_mmu_cache+
> > 0x8c/0xb0)
> > [<c002c734>] (update_mmu_cache+0x0/0xb0) from [<c008611c>] (handle_mm_fault+0x53
> > 4/0x5ac)
> 
> Bingo!
>
<snip>

> The question is how best to handle determining if a PFN (which could be
> somewhere in the range 0 to 0xfffff 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 <asm/memory.h>
> 
>  #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 <linux/mman.h>
>  #include <linux/nodemask.h>
>  #include <linux/initrd.h>
> +#include <linux/sort.h>
>  #include <linux/highmem.h>
> 
>  #include <asm/mach-types.h>
> @@ -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_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(b) - bank_pfn_start(a);
> +	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.
>  	 */
> 

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

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?

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Monday, August 17, 2009 10:21 PM
> To: Syed Mohammed, Khasim
> Cc: linux-arm-kernel@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

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Rabin Vincent]

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

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

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.

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Rabin Vincent]

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

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

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.)

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Aguirre Rodriguez, Sergio Alberto]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@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-kernel@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 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 majordomo@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

[Rabin Vincent]

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

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

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_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 <asm/memory.h>
 
 #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 <linux/mman.h>
 #include <linux/nodemask.h>
 #include <linux/initrd.h>
+#include <linux/sort.h>
 #include <linux/highmem.h>
 
 #include <asm/mach-types.h>
@@ -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.
 	 */

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

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.

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Aguirre Rodriguez, Sergio Alberto]

From: Russell King - ARM Linux [linux@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

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

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-kernel@lists.arm.linux.org.uk; linux-
> omap@vger.kernel.org
> Subject: RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
> 
> From: Russell King - ARM Linux [linux@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

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

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-kernel@lists.arm.linux.org.uk; linux-
> > omap@vger.kernel.org
> > Subject: RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
> > 
> > From: Russell King - ARM Linux [linux@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?

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

Hi Russell,

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@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-
> kernel@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-kernel@lists.arm.linux.org.uk;
> linux-
> > > omap@vger.kernel.org
> > > Subject: RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8
> > >
> > > From: Russell King - ARM Linux [linux@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

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

On Wed, Sep 09, 2009 at 01:16:48PM +0530, Syed Mohammed, Khasim wrote:
> Hi Russell,
> 
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux@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-
> > kernel@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 <khasim@ti.com>

or is it a just a Reviewed-by: ?

RE: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Syed Mohammed, Khasim]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@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-
> kernel@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:linux@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-
> > > kernel@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 <khasim@ti.com>

I did test this, please add Tested-by.

Thanks,

Regards,
Khasim

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Pavel Machek]

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

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Russell King - ARM Linux]

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.

Re: Exception while handling MEM Hole on OMAP3 / ARM Cortex A8

[Jamie Lokier]

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