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
