请教怎样让1G memory在kernel里注册只使用物理的512m-1G部分

fei1700

我碰到的问题是如果uboot传入的参数是mem=512m系统就正常，mem>512m系统会出现随机死机问题，死机是开机系统报库出错，概率大于10%，每次死的不同。但单纯做 视频播放+memory R/W compare test又正常
我想专门注册后半段memory地址来排除ddr的问题，我目前ddr地址是0x80000000-0xc0000000，我想实际使用0xa0000000-0xc0000000的地址让kernel使用，要怎样做呢？
或者大家觉得可能是哪里的问题？
lk 2.6.34，ARM Cortex A9，谢谢大家

fei1700

回复 4# oscarvei


    我试过mem=176m@16m 这类的uboot参数，系统就起不来了

关于这个，我这板子有人改过arch/arm/kernel/setup.c里的early_mem这个函数，所以不是完全线性map，有额外64m video，额外100多m 特定driver的，额外1m suspend等

fei1700

目前的状况是只要High Total为0，系统就正常
1. 修改mem=XXXm，此时lowmem+vmalloc <768M, 让High Total为0， 系统正常
2. 直接去掉CONFIG_HIGHMEM，系统正常

fei1700

hanshu830 发表于 2012-12-28 13:58
你需要修改你的 bootloader  加载 kernel的位置 0xa0000000 + 0x8000

bootloader 传给kernel参数的地址  ...

谢谢你，目前我没有修改uboot，关于启动参数，我修改内核cmdline，让它使用config里的值。lk修改memory.h这样不行，
或许是要改uboot的加载地址，不过lk不是会rellocate吗，读到哪里会有影响吗

fei1700

回复 8# hanshu830


    hi，目前我不认为是ddr的问题了，所以不打算修改memory注册后512M，谢谢你的帮助

该问题目前的规避办法是去掉CONFIG_HIGHMEM, 修改VMALLOC_END和减小VMALLOC_OFFSET，尽可能扩大系统内存，并修改IO MAP BASE，也就是要浪费一部分内存了，从c0000000-fd0000000(VMALLOC_END)是976M，比原本768M多了一点。

那么其实问题还是HIGHMEM相关的，2.6.34不知问题在哪，我另一个3.0.8版本的平台就没这个问题，但差别就不是一点了.

那么HIGHMEM问题，要怎么入手来查呢，我只打开了highmem debug这一个

fei1700

我这还在看2.6.34 ARM 配置CONFIG_HIGHMEM传vmalloc=256m后系统起不来的问题，起不来跟我们注册memory bank有关吧(我们从512M开始又注册了一个bank，然后碰到了__va(bank->start)和vmalloc_min相等的情况)，但这里确实也有问题，
http://git.kernel.org/?p=linux/k ... 3b2b9dc1feec3c47ed9

改动是其中这一个
#ifdef CONFIG_HIGHMEM
-               if (__va(bank->start) > vmalloc_min ||
+               if (__va(bank->start) >= vmalloc_min ||
                    __va(bank->start) < (void *)PAGE_OFFSET)
                        highmem = 1;

我在想系统库崩溃的现象在去掉HIGHMEM就正常的问题，或许跟2.6.34-3.0.8之间的改动有关？谁能给些可能的2.6.34到3.0.8之间的patch让我来试试呢？

fei1700

回复 13# frank529


    走运了，让我试了一个patch，发现能解决问题，但我还没想明白我这边driver调用bio_flush_dcache_page为什么会在highmem有问题
我这是单核，EMMC EXT4，出现android库崩溃就是走的__do_user_fault

http://article.gmane.org/gmane.linux.ports.arm.kernel/51556
Re: MPCore SMP Linux : should all dcaches be invalidated after handling prefetch abort ?

diff --git a/fs/mpage.c b/fs/mpage.c
index 552b80b..979a4a9 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -51,6 +51,7 @@ static void mpage_end_io_read(struct bio *bio, int err)
                        prefetchw(&bvec->bv_page->flags);

                if (uptodate) {
+                        flush_dcache_page(page);
                        SetPageUptodate(page);
                } else {
                        ClearPageUptodate(page);


谢谢大家帮忙，我再想想原因，那么或许真的是2.6.34配我的driver有问题，3.0.8配我的driver没问题了

fei1700

回复 11# hanshu830


    结一下该贴吧，怎么改贴名呢？后面讨论的都不是注册memory的问题了

这个提交可以解决该问题
http://git.kernel.org/?p=linux/k ... 6bd6084d39e5f70a382

commit ac8456d6f9a3011c824176bd6084d39e5f70a382
Author: Gary King <gking@nvidia.com>
Date:   Thu Sep 9 16:38:05 2010 -0700

    bounce: call flush_dcache_page() after bounce_copy_vec()
   
    I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM
    enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform cache
    maintenance lazily), and the root cause appears to be that the mm bouncing
    code is calling flush_dcache_page before it copies the bounce buffer into
    the bio.
   
    The bounced page needs to be flushed after data is copied into it, to
    ensure that architecture implementations can synchronize instruction and
    data caches if necessary.
   
    Signed-off-by: Gary King <gking@nvidia.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Acked-by: Jens Axboe <axboe@kernel.dk>
    Cc: <stable@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/mm/bounce.c b/mm/bounce.c
index 13b6dad..1481de6 100644
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from)
                 */
                vfrom = page_address(fromvec->bv_page) + tovec->bv_offset;

-               flush_dcache_page(tovec->bv_page);
                bounce_copy_vec(tovec, vfrom);
+               flush_dcache_page(tovec->bv_page);
        }
}