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

hanshu830

回复 9# fei1700

我在论坛里找到关于 VMALLOC 这部分相关介绍的帖子， 也许对你分析问题有帮助。

http://bbs.chinaunix.net/thread-2193269-1-1.html


   

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让我来试试呢？

frank529

写一个程序不停malloc看是不是内存分配到一定大小后就崩溃。这种问题多半是由于CPU的内存控制器初始化得不对，看看芯片的datasheet，然后去一级boot或者u-boot的low_level_init里面找。

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);
        }
}