Hey We are facing one strange issue. When we try to run some pre-compiled benchmark(like surgespecweb) on our modified m5-code, we are not getting these aborts. Its only when we run our self-compiled codes, we are getting the aborts. We checked using m5term that the abort comes even before our self-benchmark code starts executing. So, we presume this is in the kernel part. Then in that case, our modules never get activated. We are hence not able to understand why there is no error while running standard benchmark vs the abort in our code in the kernel part.
We compiled our code using Crosscompiler available on the m5sim website and then built it into the linux-image. Are we missing something here?? Thanks Pritha On Mon, May 3, 2010 at 5:23 PM, Gabriel Michael Black <[email protected] > wrote: > That's probably that your read was to an address, 0xFFFFF00188, that wasn't > claimed by any memory, device, etc. That address may fall into a range with > a special purpose in Alpha, but I don't really know. > > > Gabe > > Quoting Pritha Ghoshal <[email protected]>: > > Hi >> >> The assert says : >> m5.opt: build/ALPHA_FS/cpu/simple/atomic.cc:496: Fault >> AtomicSimpleCPU::read(Addr, T&, unsigned int) [with T = uint64_t]: >> Assertion >> `!pkt.isError()' failed. >> >> And we have printf statements in the addlv instruction, so that whenever >> it >> executes, we get to know. Those statements are not being printed, so I >> think >> its not the addlv which is getting executed. >> >> Thanks >> Pritha >> >> >> On Mon, May 3, 2010 at 3:29 PM, Gabriel Michael Black < >> [email protected] >> >>> wrote: >>> >> >> What does the actual assert say? I'm wildly guessing a load crossed a >>> cache >>> line boundary, but it's hard to say from the backtrace. That addlv >>> instruction might actually be executed. You could try implementing a >>> pseudo >>> instruction which is much less likely to be used accidentally. >>> >>> Gabe >>> >>> >>> Quoting Pritha Ghoshal <[email protected]>: >>> >>> Hi, >>> >>>> >>>> We have been getting an abort while running M5 in full system mode. We >>>> have >>>> modified one instruction (addlv) to execute a different function, >>>> because >>>> that instruction is never used in the kernel part of the code. The >>>> debugger >>>> backtrace output is given below. Could anyone help us by suggesting >>>> possible reasons for this abort? >>>> >>>> Thanks >>>> Pritha >>>> >>>> >>>> #0 0x0000003423c30265 in raise () from /lib64/libc.so.6 >>>> #1 0x0000003423c31d10 in abort () from /lib64/libc.so.6 >>>> #2 0x0000003423c296e6 in __assert_fail () from /lib64/libc.so.6 >>>> #3 0x0000000000435a3e in read<uint64_t> (this=0x14e4950, >>>> addr=1099510579592, da...@0x7fffffffd0e8, flags=512) at >>>> build/ALPHA_FS/cpu/simple/atomic.cc:518 >>>> #4 0x0000000000456465 in AlphaISAInst::Hw_ldQ::execute (this=0x2051e70, >>>> xc=0x14e4950, traceData=0x0) at build/ALPHA_FS/base/flags.hh:45 >>>> #5 0x0000000000425be6 in AtomicSimpleCPU::tick (this=0x14e4950) at >>>> build/ALPHA_FS/base/refcnt.hh:83 >>>> #6 0x00000000006703d5 in EventQueue::serviceOne (this=<value optimized >>>> out>) at build/ALPHA_FS/sim/eventq.cc:202 >>>> #7 0x00000000009f2f12 in simulate (num_cycles=9223372036854775807) at >>>> build/ALPHA_FS/sim/simulate.cc:73 >>>> #8 0x0000000000a62fd7 in _wrap_simulate (self=<value optimized out>, >>>> args=<value optimized out>) at >>>> build/ALPHA_FS/python/swig/event_wrap.cc:4079 >>>> #9 0x000000343b2360f0 in PyObject_Call () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #10 0x000000343b29352c in PyEval_EvalFrame () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #11 0x000000343b295fe5 in PyEval_EvalCodeEx () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #12 0x000000343b29473f in PyEval_EvalFrame () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #13 0x000000343b294b66 in PyEval_EvalFrame () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #14 0x000000343b295fe5 in PyEval_EvalCodeEx () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #15 0x000000343b296032 in PyEval_EvalCode () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #16 0x000000343b295237 in PyEval_EvalFrame () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #17 0x000000343b295fe5 in PyEval_EvalCodeEx () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #18 0x000000343b29473f in PyEval_EvalFrame () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #19 0x000000343b295fe5 in PyEval_EvalCodeEx () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #20 0x000000343b296032 in PyEval_EvalCode () from >>>> /usr/lib64/libpython2.4.so.1.0 >>>> #21 0x000000343b2b2729 in ?? () from /usr/lib64/libpython2.4.so.1.0 >>>> #22 0x0000000000791365 in m5Main (argc=<value optimized out>, >>>> argv=<value >>>> optimized out>) at build/ALPHA_FS/sim/init.cc:194 >>>> #23 0x000000000040854c in main (argc=7, argv=0x7fffffffe848) at >>>> build/ALPHA_FS/sim/main.cc:57 >>>> >>>> >>>> -- >>>> Pritha Ghoshal >>>> Texas A&M University >>>> >>>> >>>> >>> _______________________________________________ >>> m5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>> >>> >> >> >> -- >> Pritha Ghoshal >> >> > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > -- Pritha Ghoshal
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
