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