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

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

Reply via email to