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