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
