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