In original bootmem wrapper for memblock, we have limit checking.
Add it to memblock_virt_alloc, to address arm and x86 booting crash.
Signed-off-by: Yinghai Lu <[email protected]>
---
mm/memblock.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6/mm/memblock.c
===================================================================
--- linux-2.6.orig/mm/memblock.c
+++ linux-2.6/mm/memblock.c
@@ -1077,6 +1077,9 @@ static void * __init memblock_virt_alloc
if (!align)
align = SMP_CACHE_BYTES;
+ if (max_addr > memblock.current_limit)
+ max_addr = memblock.current_limit;
+
again:
alloc = memblock_find_in_range_node(size, align, min_addr, max_addr,
nid);
On 01/28/2014 02:04 PM, Yinghai Lu wrote:
> In original bootmem wrapper for memblock, we have limit checking.
>
> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>
> Signed-off-by: Yinghai Lu <[email protected]>
Do you have a git tree or cumulative set of patches that you'd like us
to all test? I'm happy to boot it on my system, I just want to make
sure I've got the same set that you're testing.
On Tue, 28 Jan 2014 14:04:25 -0800 Yinghai Lu <[email protected]> wrote:
> In original bootmem wrapper for memblock, we have limit checking.
>
> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>
> ...
>
> --- linux-2.6.orig/mm/memblock.c
> +++ linux-2.6/mm/memblock.c
> @@ -1077,6 +1077,9 @@ static void * __init memblock_virt_alloc
> if (!align)
> align = SMP_CACHE_BYTES;
>
> + if (max_addr > memblock.current_limit)
> + max_addr = memblock.current_limit;
> +
> again:
> alloc = memblock_find_in_range_node(size, align, min_addr, max_addr,
> nid);
Thanks.
Kevin, Olof and Konrad (at least) have been hitting this. It would be
great to get some tested-by's, please?
On Tue, Jan 28, 2014 at 2:04 PM, Yinghai Lu <[email protected]> wrote:
> In original bootmem wrapper for memblock, we have limit checking.
>
> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>
> Signed-off-by: Yinghai Lu <[email protected]>
Tested-by: Olof Johansson <[email protected]>
Verified to resolve the crashes on boot on ARM.
-Olof
On Tue, Jan 28, 2014 at 2:08 PM, Dave Hansen <[email protected]> wrote:
> On 01/28/2014 02:04 PM, Yinghai Lu wrote:
>> In original bootmem wrapper for memblock, we have limit checking.
>>
>> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>>
>> Signed-off-by: Yinghai Lu <[email protected]>
>
> Do you have a git tree or cumulative set of patches that you'd like us
> to all test? I'm happy to boot it on my system, I just want to make
> sure I've got the same set that you're testing.
This one should only affect on arm and x86 the 32 bit kernel with more
then 4G RAM.
thanks
Yinghai
On 01/28/2014 02:47 PM, Yinghai Lu wrote:
> On Tue, Jan 28, 2014 at 2:08 PM, Dave Hansen <[email protected]> wrote:
>> On 01/28/2014 02:04 PM, Yinghai Lu wrote:
>>> In original bootmem wrapper for memblock, we have limit checking.
>>>
>>> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>>>
>> Do you have a git tree or cumulative set of patches that you'd like us
>> to all test? I'm happy to boot it on my system, I just want to make
>> sure I've got the same set that you're testing.
>
> This one should only affect on arm and x86 the 32 bit kernel with more
> then 4G RAM.
OK, let me rephrase.
Does anyone want me to test this on a 1TB 64-bit x86 system? If yes,
please tell me which patches you want me to test, and on top of which
kernel. I have three patches in this area, I think, but I don't want to
waste my time testing and reporting the wrong thing.
On Tue, Jan 28, 2014 at 2:04 PM, Yinghai Lu <[email protected]> wrote:
> In original bootmem wrapper for memblock, we have limit checking.
>
> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>
> Signed-off-by: Yinghai Lu <[email protected]>
>
> ---
> mm/memblock.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> Index: linux-2.6/mm/memblock.c
> ===================================================================
> --- linux-2.6.orig/mm/memblock.c
> +++ linux-2.6/mm/memblock.c
> @@ -1077,6 +1077,9 @@ static void * __init memblock_virt_alloc
> if (!align)
> align = SMP_CACHE_BYTES;
>
> + if (max_addr > memblock.current_limit)
> + max_addr = memblock.current_limit;
> +
> again:
> alloc = memblock_find_in_range_node(size, align, min_addr, max_addr,
> nid);
Tested-by: Kevin Hilman <[email protected]>
Verified various ARM boots to be passing again.
Kevin
On Tue, Jan 28, 2014 at 02:47:57PM -0800, Yinghai Lu wrote:
> On Tue, Jan 28, 2014 at 2:08 PM, Dave Hansen <[email protected]> wrote:
> > On 01/28/2014 02:04 PM, Yinghai Lu wrote:
> >> In original bootmem wrapper for memblock, we have limit checking.
> >>
> >> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
> >>
> >> Signed-off-by: Yinghai Lu <[email protected]>
> >
> > Do you have a git tree or cumulative set of patches that you'd like us
> > to all test? I'm happy to boot it on my system, I just want to make
> > sure I've got the same set that you're testing.
>
> This one should only affect on arm and x86 the 32 bit kernel with more
> then 4G RAM.
Tested-by: Konrad Rzeszutek Wilk <[email protected]>
It fixes the issue I saw with Xen and 32-bit dom0 blowing up.
>
> thanks
>
> Yinghai
Hmmph. ia64 is broken too. git bisect says:
commit ad6492b80f60a2139fa9bf8fd79b182fe5e3647c
Author: Yinghai Lu <[email protected]>
Date: Mon Jan 27 17:06:49 2014 -0800
memblock, nobootmem: add memblock_virt_alloc_low()
is to blame. But this patch doesn't fix it. Still dies with:
PID hash table entries: 4096 (order: -1, 32768 bytes)
Sorting __ex_table...
kernel BUG at mm/bootmem.c:504!
swapper[0]: bugcheck! 0 [1]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.13.0-bisect-09219-g5e345db #10
task: a000000101040000 ti: a000000101040f10 task.ti: a000000101040f10
psr : 00001010084a2018 ifs : 8000000000000797 ip :
[<a000000100eea530>] Not tainted (3.13.0-bisect-09219-g5e345db)
ip is at alloc_bootmem_bdata+0x230/0x790
unat: 0000000000000000 pfs : 0000000000000797 rsc : 0000000000000003
rnat: a000000100dff0ee bsps: 0000000000000000 pr : 96669601598a95a9
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
csd : 0930ffff00063000 ssd : 0930ffff00063000
b0 : a000000100eea530 b6 : a0000001005f4040 b7 : a0000001005f3e00
f6 : 000000000000000000000 f7 : 1003e0000000000000000
f8 : 1003e0044b82fa09b5a53 f9 : 1003e0000000000001680
f10 : 1003e0000000000000008 f11 : 1003e00000000000002d0
r1 : a0000001017ce170 r2 : a00000010158e0a0 r3 : a0000001015ced80
r8 : 000000000000001f r9 : 0000000000000664 r10 : 0000000000000000
r11 : 0000000000000000 r12 : a00000010104fe20 r13 : a000000101040000
r14 : a00000010158e0a8 r15 : a00000010158e0a8 r16 : 0000000006640332
r17 : 0000000000000000 r18 : 0000000000007fff r19 : 0000000000000000
r20 : a000000101727e98 r21 : 0000000000000058 r22 : a000000101616c98
r23 : a000000101616c00 r24 : a000000101616c00 r25 : 00000000000003f8
r26 : a000000100e901a8 r27 : a000000100f59480 r28 : 0000000000000058
r29 : 0000000000000057 r30 : 00000000000016d0 r31 : 0000000000000030
Unable to handle kernel NULL pointer dereference (address 0000000000000000)
swapper[0]: Oops 11012296146944 [2]
-Tony
On Tue, Jan 28, 2014 at 5:50 PM, Konrad Rzeszutek Wilk
<[email protected]> wrote:
> On Tue, Jan 28, 2014 at 02:47:57PM -0800, Yinghai Lu wrote:
>> On Tue, Jan 28, 2014 at 2:08 PM, Dave Hansen <[email protected]> wrote:
>> > On 01/28/2014 02:04 PM, Yinghai Lu wrote:
>> >> In original bootmem wrapper for memblock, we have limit checking.
>> >>
>> >> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>> >>
>> >> Signed-off-by: Yinghai Lu <[email protected]>
>> >
>> > Do you have a git tree or cumulative set of patches that you'd like us
>> > to all test? I'm happy to boot it on my system, I just want to make
>> > sure I've got the same set that you're testing.
>>
>> This one should only affect on arm and x86 the 32 bit kernel with more
>> then 4G RAM.
>
> Tested-by: Konrad Rzeszutek Wilk <[email protected]>
>
> It fixes the issue I saw with Xen and 32-bit dom0 blowing up.
>
>>
>> thanks
>>
>> Yinghai
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Wed, Jan 29, 2014 at 3:07 PM, Tony Luck <[email protected]> wrote:
> Hmmph. ia64 is broken too. git bisect says:
>
> commit ad6492b80f60a2139fa9bf8fd79b182fe5e3647c
> Author: Yinghai Lu <[email protected]>
> Date: Mon Jan 27 17:06:49 2014 -0800
>
> memblock, nobootmem: add memblock_virt_alloc_low()
>
> is to blame. But this patch doesn't fix it. Still dies with:
>
> PID hash table entries: 4096 (order: -1, 32768 bytes)
> Sorting __ex_table...
> kernel BUG at mm/bootmem.c:504!
that's another path with memblock_virt wrapper for bootmem.
Let's me check that.
On Wed, Jan 29, 2014 at 3:39 PM, Yinghai Lu <[email protected]> wrote:
> On Wed, Jan 29, 2014 at 3:07 PM, Tony Luck <[email protected]> wrote:
>> Hmmph. ia64 is broken too. git bisect says:
>>
>> commit ad6492b80f60a2139fa9bf8fd79b182fe5e3647c
>> Author: Yinghai Lu <[email protected]>
>> Date: Mon Jan 27 17:06:49 2014 -0800
>>
>> memblock, nobootmem: add memblock_virt_alloc_low()
>>
>> is to blame. But this patch doesn't fix it. Still dies with:
>>
>> PID hash table entries: 4096 (order: -1, 32768 bytes)
>> Sorting __ex_table...
>> kernel BUG at mm/bootmem.c:504!
>
> that's another path with memblock_virt wrapper for bootmem.
Please check attached patch.
Thanks
Yinghai
Applying on top of Linus' tree (commit =
dda68a8c1707b4011dc3c656fa1b2c6de6f7f304) I just get:
patching file include/linux/bootmem.h
Hunk #1 FAILED at 264.
Hunk #2 FAILED at 272.
2 out of 2 hunks FAILED -- saving rejects to file include/linux/bootmem.h.rej
- not a promising start :-(
-Tony
On Wed, 29 Jan 2014 16:12:13 -0800 Tony Luck <[email protected]> wrote:
> Applying on top of Linus' tree (commit =
> dda68a8c1707b4011dc3c656fa1b2c6de6f7f304) I just get:
>
> patching file include/linux/bootmem.h
> Hunk #1 FAILED at 264.
> Hunk #2 FAILED at 272.
> 2 out of 2 hunks FAILED -- saving rejects to file include/linux/bootmem.h.rej
>
> - not a promising start :-(
>
It applies for me. MIME getting you down?
From: Yinghai Lu <[email protected]>
Subject: memblock, bootmem: restore goal for alloc_low
Now we have memblock_virt_alloc_low to replace original bootmem api
in swiotlb.
But we should not use BOOTMEM_LOW_LIMIT for arch that does not support
CONFIG_NOBOOTMEM, as old api take 0.
| #define alloc_bootmem_low(x) \
| __alloc_bootmem_low(x, SMP_CACHE_BYTES, 0)
|#define alloc_bootmem_low_pages_nopanic(x) \
| __alloc_bootmem_low_nopanic(x, PAGE_SIZE, 0)
and we have
#define BOOTMEM_LOW_LIMIT __pa(MAX_DMA_ADDRESS)
for CONFIG_NOBOOTMEM.
Restore goal to 0 to fix ia64 crash, that Tony found.
Signed-off-by: Yinghai Lu <[email protected]>
Reported-by: Tony Luck <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
include/linux/bootmem.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN include/linux/bootmem.h~memblock-bootmem-restore-goal-for-alloc_low include/linux/bootmem.h
--- a/include/linux/bootmem.h~memblock-bootmem-restore-goal-for-alloc_low
+++ a/include/linux/bootmem.h
@@ -264,7 +264,7 @@ static inline void * __init memblock_vir
{
if (!align)
align = SMP_CACHE_BYTES;
- return __alloc_bootmem_low(size, align, BOOTMEM_LOW_LIMIT);
+ return __alloc_bootmem_low(size, align, 0);
}
static inline void * __init memblock_virt_alloc_low_nopanic(
@@ -272,7 +272,7 @@ static inline void * __init memblock_vir
{
if (!align)
align = SMP_CACHE_BYTES;
- return __alloc_bootmem_low_nopanic(size, align, BOOTMEM_LOW_LIMIT);
+ return __alloc_bootmem_low_nopanic(size, align, 0);
}
static inline void * __init memblock_virt_alloc_from_nopanic(
_
On Wed, Jan 29, 2014 at 4:34 PM, Andrew Morton
<[email protected]> wrote:
> It applies for me. MIME getting you down?
Perhaps - Gmail's web client showed me a downward pointing arrow when I
moused over the attachment icon in Yinghai's e-mail. So I clicked it ... and
it looked like it downloaded a patch-like looking file. So I ran
"patch -p1 < file"
and whoops - that wasn't so great after all :-(
Your plain text e-mail version applied just fine.
GUI: 0 CLI: 1
Patch works - my ia64 boots again. Thanks.
Tested-by: Tony Luck <[email protected]>
-Tony
On 29 January 2014 03:34, Yinghai Lu <[email protected]> wrote:
> In original bootmem wrapper for memblock, we have limit checking.
>
> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>
> Signed-off-by: Yinghai Lu <[email protected]>
>
> ---
Confirmed that this patch fixes the boot crash issue on Exynos (ARM
based) boards.
Tested-by: Sachin Kamat <[email protected]>
--
With warm regards,
Sachin