When I try to boot with multiple cores, I get the following error :

....
warn: Address 0xffffffc0 is outside of physical memory, stopping fetch
warn: Address 0xffffffc0 is outside of physical memory, stopping fetch
warn: Address 0xffffffc0 is outside of physical memory, stopping fetch
warn: Address 0xffffffc0 is outside of physical memory, stopping fetch
warn: Address 0xffffffc0 is outside of physical memory, stopping fetch
warn: Address 0xffffffc0 is outside of physical memory, stopping fetch
warn: Address 0xffffffc0 is outside of physical memory, stopping fetch
warn: instruction 'wbinvd' unimplemented
panic: Legacy mode interrupts with error codes aren't implementde.
 @ cycle 157113832500
[invoke:build/X86_FS/arch/x86/faults.cc, line 85]
Memory Usage: 297884 KBytes
Program aborted at cycle 157113832500
Aborted

The boot status as indicated on the terminal was:

Memory: 121384k/131072k available (3699k kernel code, 8500k reserved, 1767k
data, 248k init)
Calibrating delay loop (skipped)... 3999.96 BogoMIPS preset
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
Freeing SMP alternatives: 34k freed
Using local APIC timer interrupts.
result 7812511
Detected 7.812 MHz APIC timer.
Booting processor 1/2 APIC 0x1

The commandline used was:

$ build/X86_FS/gem5.opt configs/example/fs.py --cpu-type=detailed
--kernel=x86_64-vmlinux-2.6.22.9.smp --caches -n 2

Any ideas on why this might be happening ?

Regards,
Ankita

On Mon, Feb 20, 2012 at 6:47 PM, Ankita (Garg) Goel <[email protected]>wrote:

> Thanks Gabe for the quick patch. I was able to boot-up detailed CPU in FS
> mode (though with only 1cpus so far).
>
> On Sun, Feb 19, 2012 at 6:12 AM, Gabe Black <[email protected]> wrote:
>
>>  Give this patch a try: http://reviews.gem5.org/r/1052/
>>
>> As far as the python error, it looks like new_cpu doesn't have anything
>> set for _ccObject. I'd guess whatever's setting that up is wrong.
>>
>> Gabe
>>
>>
>> On 02/18/12 13:26, Ankita (Garg) Goel wrote:
>>
>> Thanks Gabe for looking into this. Awaiting your patch. Also, in the
>> meantime, I played around with switch_cpu to try and switch over to
>> detailed once the kernel is booted with atomic cpu. I tried the examples
>> indicated in the tutorial as below:
>>
>>  $ build/X86/gem5.opt configs/example/fs.py --cpu-type=detailed
>> --kernel=vmlinux  --caches --l2cache -F 1000000000
>>  .... <system boots up fine>.....
>> hack: be nice to actually delete the event here
>> Switched CPUS @ tick 237558550517000
>> Changing memory mode to timing
>> switching cpus
>> Traceback (most recent call last):
>>   File "<string>", line 1, in <module>
>>   File "src/python/m5/main.py", line 357, in main
>>     exec filecode in scope
>>   File "configs/example/fs.py", line 215, in <module>
>>     Simulation.run(options, root, test_sys, FutureClass)
>>   File "configs/common/Simulation.py", line 268, in run
>>     m5.switchCpus(switch_cpu_list)
>>   File "src/python/m5/simulate.py", line 226, in switchCpus
>>     new_cpu.takeOverFrom(old_cpu)
>>   File "src/python/m5/SimObject.py", line 1040, in takeOverFrom
>>     self._ccObject.takeOverFrom(old_cpu._ccObject)
>> AttributeError: 'NoneType' object has no attribute 'takeOverFrom'
>>
>>  I looked at the code in Simulate.py and do find that old_cpu is indeed
>> being passed as an object. Not sure what I might be doing wrng.
>>
>>  Thanks for your help!
>>
>>  Regards,
>> Ankita
>>
>> On Sat, Feb 18, 2012 at 2:22 PM, Gabe Black <[email protected]>wrote:
>>
>>>  I'm pretty sure I know what's happening. When certain microops in x86
>>> are executed, they may run into some condition they don't like and call
>>> panic. That's actually wrong. What they *should* do is return a fault
>>> object which, when "invoked", aka committed, will call panic on behalf of
>>> the microop. That way if a microop is executed speculatively with bad
>>> arguments, the CPU has a chance to squash the instruction before commit and
>>> save itself from the panic. Everything works ok in the atomic CPU because
>>> it never executes anything speculatively. I initially implemented x86
>>> targeting the simple CPU, and at the time I didn't realize using panic was
>>> wrong. I've cleaned up some of the places it's used, but there are still
>>> some left. I'll get the rest at some point soon (maybe a couple days) and
>>> send you a patch.
>>>
>>> Gabe
>>>
>>>
>>> On 02/18/12 08:03, Ankita (Garg) Goel wrote:
>>>
>>> Hi,
>>>
>>>  When running the detailed mode, this is the error I get:
>>>
>>>  $ build/X86/gem5.opt  configs/example/fs.py --cpu-type=detailed
>>> --kernel=x86_64-vmlinux-2.6.28.4-smp --num-cpus=2 --caches
>>>
>>>  **** REAL SIMULATION ****
>>> info: Entering event queue @ 0.  Starting simulation...
>>> 264721000: system.pc.com_1.terminal: attach terminal 0
>>> warn: Don't know what interrupt to clear for console.
>>> warn: instruction 'wbinvd' unimplemented
>>> ....
>>> warn: instruction 'fxsave' unimplemented
>>> warn: Address 0xffffffc0 is outside of physical memory, stopping fetch
>>> warn: Address 0xffffffc0 is outside of physical memory, stopping fetch
>>> warn: Address 0xffffffc0 is outside of physical memory, stopping fetch
>>> warn: instruction 'wbinvd' unimplemented
>>> panic: Wrdh used with wrong descriptor type!
>>>  @ cycle 309622856000
>>> [execute:build/X86/arch/x86/o3_cpu_exec.cc, line 12585]
>>> Memory Usage: 318880 KBytes
>>> Program aborted at cycle 309622856000
>>> Aborted
>>>
>>>  On the terminal, these were the last boot up messages:
>>>
>>>  Memory: 119608k/131072k available (4219k kernel code, 1024k absent,
>>> 10284k reserved, 2101k data, 332k init)
>>> Calibrating delay loop (skipped) preset value.. 3999.96 BogoMIPS
>>> (lpj=7999923)
>>> Mount-cache hash table entries: 256
>>> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
>>> CPU: L2 Cache: 1024K (64 bytes/line)
>>> Setting APIC routing to flat
>>> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
>>> CPU0: M5 Simulator Fake M5 x86_64 CPU stepping 01
>>> Booting processor 1 APIC 0x1 ip 0x6000
>>>
>>>  Any idea what might be going on ?
>>>
>>>  Thanks for your help!
>>>
>>>  Regards,
>>> Ankita
>>>
>>>  On Fri, Feb 17, 2012 at 10:03 PM, Gabriel Michael Black <
>>> [email protected]> wrote:
>>>
>>>> I'm not aware of anybody else having this problem. Does it hang, return
>>>> an error from gem5, return an error from the kernel on the terminal, or?
>>>> Did you try building from scratch by deleting the entire build directory?
>>>> Sometimes stray files can survive longer than they're supposed to and mess
>>>> up incremental builds. A lot will have changed in your update, so there's a
>>>> non-zero chance of that happening.
>>>>
>>>> Gabe
>>>>
>>>>
>>>> Quoting "Ankita (Garg) Goel" <[email protected]>:
>>>>
>>>>  Hi,
>>>>>
>>>>> I have been using X86_FS for a while now. Just upgraded to the new
>>>>> version
>>>>> that has combined FS and SE mode. However, now I am unable to boot into
>>>>> Linux. The command I used is:
>>>>>
>>>>> # build/X86/gem5.opt  configs/example/fs.py
>>>>>  --cpu-type=[detailed|timing]
>>>>> --kernel=x86_64-vmlinux-2.6.28.4-smp --caches
>>>>>
>>>>> The kernel does boot up if the cpu-type is the default, ie, atomic. Is
>>>>> this
>>>>> a known issue ?
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Ankita
>>>>>
>>>>>
>>>>
>>>>
>>>>  _______________________________________________
>>>> gem5-users mailing list
>>>> [email protected]
>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>
>>>
>>>
>>>
>>>  --
>>> Regards,
>>> Ankita
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>>  --
>> Regards,
>> Ankita
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Regards,
> Ankita
>
>
>


-- 
Regards,
Ankita
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to