Following thread seem to have fallen silent. Was anybody able to boot Linux 3.X on gem5 finally?
Thanks Arka On 12/16/2011 08:08 AM, Anders Handler wrote: > Hi, > > My current finding suggests that the problem exists in the e820 stuff. > Maybe some changes to the handling of realModeData. > > Any help is appreciated. > > Best regards > Anders > > 2011/12/16 Anders Handler<[email protected]> > >> Hi again, >> >> I enabled memory debugging and got the following output. >> >> [ 0.000000] memblock_x86_reserve_range: [0x000f0050-0x000f005f] * >> MP-table mpf >> [ 0.000000] memblock_x86_reserve_range: [0x000f0060-0x000f019f] * >> MP-table mpc >> [ 0.000000] memblock_x86_reserve_range: [0x01de3000-0x01de3012] >> BRK >> [ 0.000000] MEMBLOCK configuration: >> [ 0.000000] memory size = 0x7f00000 >> [ 0.000000] memory.cnt = 0x1 >> [ 0.000000] memory[0x0] [0x00000000100000-0x00000007ffffff], >> 0x7f00000 bytes >> [ 0.000000] reserved.cnt = 0x2 >> [ 0.000000] reserved[0x0] [0x0000000009f000-0x000000000fffff], >> 0x61000 bytes >> [ 0.000000] reserved[0x1] [0x00000001000000-0x00000001de3012], >> 0xde3013 bytes >> >> This looks rather normal to me. So still no idea about why it does not >> work. >> >> / Anders >> >> 2011/12/16 Anders Handler<[email protected]> >> >>> Hi, >>> >>> I did indeed create a trace file, and it's huge. The check is correct, >>> but the values are false. The memblockbase is fetched from >>> memblock.memory.regions[i].base, which has been initialized with a wrong >>> value (0x10000), which is the same as top. >>> >>> I have not yet tracked down where memblock.memory.regions[i].base is >>> initialized. >>> >>> Best regards >>> Anders >>> >>> >>> 2011/12/15 Gabe Black<[email protected]> >>> >>>> ** >>>> Also, if you haven't seen it, this page documents some of the methods >>>> you can use to debug what's going on. >>>> >>>> http://www.gem5.org/Debugging >>>> >>>> The section called "Trace-based debugging" will probably be the most >>>> useful. Be sure to only trace a portion of execution at a time. Tracing too >>>> much creates some enormous files that are hard to work with. >>>> >>>> Gabe >>>> >>>> >>>> On 12/15/11 15:25, Gabe Black wrote: >>>> >>>> Where bottom>= top, is bottom really greater than or equal to top? Or >>>> in other words, is the comparison returning the wrong result, or are the >>>> values wrong in the first place? If it's the comparison that's wrong, that >>>> would be a bit surprising but easier to debug because it's pretty >>>> contained. If it's the values you'll need to figure out where those get >>>> corrupted, or if they were passed to Linux incorrectly from the start. >>>> Thank you for digging into the problem on your own. >>>> >>>> Gabe >>>> >>>> On 12/15/11 06:21, Anders Handler wrote: >>>> >>>> Hi, >>>> >>>> X86 kernels version>2.6.32 (here 3.1.0) still gets the error "Cannot >>>> allocate trampoline". Seems like the memory regions does not get >>>> initialized correctly. >>>> >>>> The stack trace is: >>>> [ 0.000000] Kernel panic - not syncing: Cannot allocate trampoline >>>> [ 0.000000] >>>> [ 0.000000] Pid: 0, comm: swapper Not tainted 3.1.0-gentoo #13 >>>> [ 0.000000] Call Trace: >>>> [ 0.000000] [<ffffffff816772ab>] panic+0x8c/0x192 >>>> [ 0.000000] [<ffffffff81c9f733>] setup_trampolines+0x52/0xb1 >>>> [ 0.000000] [<ffffffff81c9ce1b>] setup_arch+0x5ca/0xabb >>>> [ 0.000000] [<ffffffff816773ed>] ? printk+0x3c/0x3e >>>> [ 0.000000] [<ffffffff81cad37e>] ? cgroup_init_early+0x25b/0x276 >>>> [ 0.000000] [<ffffffff81c998a1>] start_kernel+0x82/0x312 >>>> [ 0.000000] [<ffffffff81c99322>] >>>> x86_64_start_reservations+0x132/0x136 >>>> [ 0.000000] [<ffffffff81c99417>] x86_64_start_kernel+0xf1/0xf8 >>>> [ 0.000000] [<ffffffff81c99326>] >>>> x86_64_start_reservations+0x136/0x136 >>>> >>>> A further investigation shows that in /arch/x86/kernel/trampoline.c >>>> function setup_trampolines we call /mm/memblock.c, memblock_find_in_range >>>> which again calls memblock_find_base. >>>> Here we loop through the memory regions, where there is only 1, but that >>>> is expected. Unfortunatly the line: >>>> if (bottom>= top) >>>> Evaluates to true, thus we never have a chance to call >>>> memblock_find_region. >>>> http://lxr.linux.no/linux+v3.1/mm/memblock.c#L111 >>>> >>>> Gem5 does not cast any faults. >>>> >>>> Any help/suggestions is really appreciated. >>>> >>>> >>>> Best regards >>>> Anders >>>> >>>> >>>> On Tue, Nov 29, 2011 at 10:15 AM, huangyongbing< >>>> [email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> The Linue kernel 3.1 can pass gem5's checkes using the patch. However, >>>>> there exists a kernel panic "Kernel panic - not syncing: Cannot allocate >>>>> trampoline". Additional >>>>> work are needed. >>>>> >>>>> >>>>> Yongbing Huang >>>>> >>>>> >>>>> ------------------------------ >>>>> *发件人：* Gabe Black >>>>> *发送时间：* 2011-11-29 16:05:31 >>>>> *收件人：* gem5-users >>>>> *抄送：* >>>>> *主题：* Re: [gem5-users] Problem with Linux kernel 3.1 >>>>> I haven't tested this at all (even to make sure it compiles) but >>>>> give this a shot. This is a quick attempt to actually fix the check. >>>>> >>>>> Gabe >>>>> >>>>> On 11/28/11 20:35, huangyongbing wrote: >>>>> >>>>> Hi, >>>>> >>>>> I just tested your patch on my PC (Intel Nehalem), but unfortunately it >>>>> didn't work. >>>>> >>>>> >>>>> Yongbing Huang >>>>> >>>>> ** >>>>> ------------------------------ >>>>> *发件人：* Anders Handler >>>>> *发送时间：* 2011-11-29 06:47:33 >>>>> *收件人：* gem5 users mailing list >>>>> *抄送：* >>>>> *主题：* Re: [gem5-users] Problem with Linux kernel 3.1 >>>>> Hi, >>>>> >>>>> The attached patch will make it work (just disables some checks). I >>>>> will make the right checks and send it here on Wednesday. >>>>> >>>>> The problem was some faulty checks in >>>>> src/arch/x86/isa/microops/regop.isa, where the descriptor-table register >>>>> might fail. I'll find the appropriate checks in the AMD manual. >>>>> >>>>> Anders >>>>> >>>>> >>>>> On Mon, Nov 28, 2011 at 10:38 PM, Gabe Black<[email protected]>wrote: >>>>> >>>>>> What CPU are you using? How did you determine this is where it gets >>>>>> stuck? Have you traced execution near there? Does it get stuck in the >>>>>> microcode looping forever, executing the same instruction over and over, >>>>>> etc., or does it stop executing instructions all together, perpetually >>>>>> trying to vector to an exception handler for instance? >>>>>> >>>>>> My off hand guess to what's going on is that the check that makes sure >>>>>> the selector is ok isn't handling a NULL selector properly. The AMD >>>>>> architecture manal says this: >>>>>> >>>>>> "Null selectors can only be loaded into the DS, ES, FS and GS >>>>>> data-segment registers, and into the LDTR descriptor-table register. A >>>>>> #GP >>>>>> occurs if software attempts to load the CS register with a null selector >>>>>> or >>>>>> if software attempts to load the SS register with a null selector in non >>>>>> 64-bit mode or at CPL 3." >>>>>> >>>>>> It sounds like you've determined that %eax should really be 0 when >>>>>> that instruction executes. >>>>>> >>>>>> With some more information I'll try to look at this sometime in the >>>>>> next week or two. >>>>>> >>>>>> Gabe >>>>>> >>>>>> >>>>>> On 11/28/11 05:16, Anders Handler wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have the same problem. The last instruction decoded in a kernel >>>>>>> 2.6.32 is >>>>>> >>>>>> 8e d0 mov %eax,%ss >>>>>> where %eax contains 0 (xor %eax,%eax). >>>>>> >>>>>> In 2.6.32 and earlier the segment registers was set to "movl >>>>>> $__KERNEL_DS,%eax", which in my 2.6.32 kernel was 0x18. >>>>>> >>>>>> The code is found in head_64.S in entry point "secondary_startup_64". >>>>>> >>>>>> Any clue why the simulator gets stuck here? >>>>>> >>>>>> >>>>>> Best regards >>>>>> Anders >>>>>> >>>>>> 2011/11/28 huangyongbing<[email protected]> >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I try to run Gem5 using X86_FS and Linux kernel 3.1. The >>>>>>> configuration file I use is downloaded from Gem5 website which >>>>>>> contained in >>>>>>> file 'config-x86.tar.gz'. No errors are printed out by gem5. However, >>>>>>> there is also nothing printed out in m5term console. Using the same >>>>>>> configuration file, Linux kernel 2.6.32 is runnable on Gem5. Thus, >>>>>>> what's >>>>>>> the problem? >>>>>>> >>>>>>> >>>>>>> 2011-11-28 >>>>>>> ------------------------------ >>>>>>> -- Yongbing Huang >>>>>>> >>>>>>> _______________________________________________ >>>>>>> gem5-users mailing list >>>>>>> [email protected] >>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> gem5-users mailing >>>>>> [email protected]http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> gem5-users mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> gem5-users mailing >>>>> [email protected]http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> [email protected] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing >>>> [email protected]http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing >>>> [email protected]http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >> > > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
