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
