Ankita, did you ever solve or work-around this panic?
On Thu, Feb 23, 2012 at 12:00 AM, Ankita (Garg) Goel <gargank...@gmail.com> wrote: > 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 <gargank...@gmail.com> > 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 <gbl...@eecs.umich.edu> 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 <gbl...@eecs.umich.edu> >>> 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 >>>> <gbl...@eecs.umich.edu> 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" <gargank...@gmail.com>: >>>>> >>>>>> 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 >>>>> gem5-users@gem5.org >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Ankita >>>> >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> gem5-users@gem5.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> gem5-users@gem5.org >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >>> >>> >>> -- >>> Regards, >>> Ankita >>> >>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> >> >> -- >> Regards, >> Ankita >> >> > > > > -- > Regards, > Ankita > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
