在 2008-09-01一的 15:42 +1000，Benjamin Herrenschmidt写道： > On Sun, 2008-08-31 at 13:50 +0200, Zhou Rui wrote: > > Hi, all: > > My problem seems basically solved. > > We we used to call vmalloc() in the memory management part of our > > source, but it seems to be the key unreliable point resulting in the > > problem. vmalloc() always assigns some virtual addresses whose > > corresponding physical addresses are out of memory size (there is only > > 32MB DRAM in our 405 board). Once instructions try to access these > > illegal physical address, machine check happens > > That should -never- happen. > > Have you verified, as I asked you a while ago, that you are actually > passing the right amount of memory to your kernel from the device-tree > or the bootloader ? > > Ben.
I added "mem=32M" to linux command line of the bootloader, and got the same machine check. Best Wishes Zhou Rui 2008-09-01 > > > Afterwards, we call kmalloc() instead and it works basically as what > > we want. But problems of the memory management still exist because > > therea are program check exception sometimes and page always: > > .... > > -bash-3.2# PROGRAM: reason: 0x8000000, nip: 0xc028bf20 > > Oops: Exception in kernel mode, sig: 4 [#1] > > NIP: C028BF20 LR: C028BF20 CTR: C31C6078 > > REGS: c028be80 TRAP: 0700 Not tainted (2.6.19.2-eldk-xm.1.0) > > MSR: 00029030 <EE,ME,IR,DR> CR: 00000000 XER: 00000000 > > TASK = c0228a30[0] 'swapper' THREAD: c028a000 > > GPR00: 00000000 C028BF30 C0228A30 C034B7B0 C028BF20 00000000 00000001 > > 00000000 > > GPR08: 00000003 C31D0000 22000082 00029030 2BDD9FE1 C03B3164 0000066F > > 2B1F1DC8 > > GPR16: C03B3050 0FFEA478 10010000 C31D0000 C028BEF0 C31CA2E4 00021030 > > C028A000 > > GPR24: C028BEF0 C0228B44 C0228468 C03B3050 C028BF10 C31C60C4 00029030 > > C03B3050 > > NIP [C028BF20] init_thread_union+0x1f20/0x2000 > > LR [C028BF20] init_thread_union+0x1f20/0x2000 > > Call Trace: > > [C028BF30] [0FFEA478] 0xffea478 (unreliable) > > Instruction dump: > > XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX > > XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX > > Kernel panic - not syncing: Attempted to kill the idle task! > > <0>Rebooting in 180 seconds.. > > > > And there is bad page: > > Message from syslogd@ at Thu Jan 1 01:32:00 1970 ... > > 405 kernel: Backtrace: > > Message from syslogd@ at Thu Jan 1 01:32:00 1970 ... > > 405 kernel: Bad page state in process 'loader.xm' > > Message from syslogd@ at Thu Jan 1 01:32:00 1970 ... > > 405 kernel: Trying to fix it up, but a reboot is needed > > Message from syslogd@ at Thu Jan 1 01:32:00 1970 ... > > 405 kernel: Bad page state in process 'loader.xm' > > Message from syslogd@ at Thu Jan 1 01:32:00 1970 ... > > 405 kernel: Trying to fix it up, but a reboot is needed > > Message from syslogd@ at Thu Jan 1 01:32:00 1970 ... > > 405 kernel: page:c02f0e60 flags:0x00000400 mapping:00000000 mapcount:0 > > count:1 > > > > I will do some traces for fixing those problems. > > > > And could anyone like to give some explanation between vmalloc() and > > kmalloc()? Based on our work, there seems to be great difference. > > > > Thank you very much! > > > > Best Wishes > > > > Zhou Rui > > 2008-08-31 > > > > 在 2008-08-25一的 21:16 +0200，Zhou Rui写道： > > > Hi, > > > I think maybe you have known this project named XtratuM > > > (http://www.xtratum.org). I'm porting it from x86 to PPC405. The > > > implementation on PPC440 has been basically finished > > > (ftp://dslab.lzu.edu.cn/pub/xtratum/xtratum-ppc/snapshots/xtratum-ppc-20071205.tar.bz2) > > > and I know there was discussion about it in this mail list before. > > > XtratuM is an ADEOS based nano kernel. It aims for realtime and is > > > designed to provide virtual timer, virtual interrupt and memory space > > > sperations for domains. Each domain is loaded by a userspace program > > > (instead of the root domain as a kernel module) and the loader will load > > > the domain's (ELF staticly excutable) PT_LOAD section into memory, and > > > then raise a properly system call (passing the structurized loaded data > > > as arguments) to load the domain via load_domain_sys() of XtratuM, and at > > > the last step of loading the domain, xtratum will jump to the entry code > > > of the new domain(asm wrappered start() routine) and then everything > > > should be fine. 0x100000a0 is the entry point of the test domain, and > > > that is why I need to start execution from it. > > > > > > I think I can say something of my analysis so far for the cause of my > > > problem. Thanks for the mention of memory size. Once the kernel module > > > of XtratuM is loaded, the symbols of it are placed to virtual addresses > > > like 0xc3xxxxxx. Because in normal state, address translation is enabled > > > (MSR[IR, DR] = [1, 1]), these addresses are okay. However, when loading > > > the domain, because the entry point 0x100000a0 is not in TLB and it > > > should be reloaded, Data TLB Miss Exception arises and DTLBMiss is > > > called. The exception clears MSR[IR, DR], so address translation is > > > disabled and physical address should be used at this moment. If we want > > > something at the virtual address of 0xc3xxxxxx, we must access the > > > physical addresses like 0x03xxxxxx. Nevertheless, the limitation of 32MB > > > memory makes the valid physical address range from 0x0 to 0x1ffffff. > > > Therefore, during the exception handling, the addresses out of range > > > should not be accessed, but the instructions cannot know the memory > > > limitation in advance and tries to do something in addresses such as > > > 0x03072da0 based on the address translation mechanism, which leads to > > > machine check. > > > I haved tried to append "mem=32M" to kernel command line but no help. I > > > think it is because when loading the kernel in normal state, address > > > translation is enabled and the virtual addresses are okay. Kernel cannot > > > foresee that there is going to be a TLB miss exception and the illegal > > > physical addresses like 0x03xxxxxx may be accessed. > > > > > > So any ideas for this problem are welcome. > > > > > > Thank you very much for taking care. > > > > > > Best Wishes > > > > > > Zhou Rui > > > 2008-08-25 > > > > > > 在 2008-08-24日的 20:55 +0200，Wolfgang Denk写道： > > > > Dear Zhou Rui, > > > > > > > > In message <[EMAIL PROTECTED]> you wrote: > > > > > > > > > > > > I am running a kernel module which will execute a user space > > > > > > >application. The entry point of the application is 0x100000a0. At > > > > > > >the > > > > > > > > > > > > That should be the first clue that you are doing it wrong. Don't do > > > > > > stuff like that in modules... > > > > > > > > > > Oh, but our project needs a function like that ... > > > > > > > > You should really think about this. Why do you think you need this? > > > > What exactly are you trying to do? [Probably there are better > > > > approaches to solve your problem...] > > > > > > > > It is physical address at this moment. Address translation is disabled > > > > > automatically (MSR[IR, DR] = [0, 0]) because of TLB Miss Exception and > > > > > Instrunction Storage Exception. > > > > > > > > Hm.. are you absolutely sure that the 0x100000a0 mentioned above is a > > > > physical address? > > > > > > > > > > Do you have enough DRAM to cover that? Some of those boards only > > > > > > come > > > > > > with 32MiB of DRAM. > > > > > > > > > > My board only has 32MB DRAM. Do you mean 32MB is not enough for that? > > > > > > > > Well, 0x1000'00A0 is above 256 MB, while you have only 32 MB RAM > > > > which is most probably mapped from 0x0000'0000...0x01FF'FFFF... So > > > > what you claim to be a physical address (and I think your claim is > > > > wrong) is far outside available physical memory. > > > > > > > > > The same codes can run well in a PPC440EP (Yosemite Board) which owns > > > > > 256MB DRAM. At the beginning of my work, I thought memory size may be > > > > > the cause of failure. But I did not know how to demonstrate it. So if > > > > > the limitation of 32MB DRAM leads to the failure, are there any > > > > > methods > > > > > for the codes to solve it? > > > > > > > > I think you got lost on the wrong track. Please describe which task > > > > you want to implement, and there might be another, better approach > > > > for it. > > > > > > > > Best regards, > > > > > > > > Wolfgang Denk > > > > > > __________________________________________________ > > > ϿעŻ? > > > http://cn.mail.yahoo.com > > > > > > _______________________________________________ > > > Linuxppc-dev mailing list > > > Linuxppc-dev@ozlabs.org > > > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > > > __________________________________________________ > > ϿעŻ? > > http://cn.mail.yahoo.com > > > > _______________________________________________ > > Linuxppc-dev mailing list > > Linuxppc-dev@ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev __________________________________________________ �Ͽ�ע���Ż�����������������? http://cn.mail.yahoo.com
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
