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] <mailto:[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] <mailto:[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] >>>> <mailto:[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] <mailto:[email protected]> >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] <mailto:[email protected]> >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] <mailto:[email protected]> >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] <mailto:[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
