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
