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