Hi Samuel,
The idea is that if you experience this you'd want to know about it, so we issue a SIG_TRAP which causes a debugger to stop execution so you can examine what is wrong. I highly recommend that you create a new barrelfish system (e.g. src/arm/arm/barrelfish/system.*) and do the right thing for barrelfish, which will involve not creating the kernelPanicEvent if you don't need it. Ali On 26.03.2012 08:51, Samuel Hitz wrote: > I'm not running a linux kernel, I'm porting Barrelfish-OS to ARMv7. I ran gem5 in debug mode and dropped into the break_event. A backtrace gave me this > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00007ffff6460c57 in kill () from /lib/libc.so.6 > (gdb) bt > #0 0x00007ffff6460c57 in kill () from /lib/libc.so.6 > #1 0x000000000131d8ed in Debug::breakpoint () at build/ARM/base/debug.cc:56 > #2 0x0000000001410ab2 in BreakPCEvent::process (this=0x348c780, tc=0x34dc490) at build/ARM/cpu/pc_event.cc:137 > #3 0x000000000140ff68 in PCEventQueue::doService (this=0x348c1e0, tc=0x34dc490) at build/ARM/cpu/pc_event.cc:102 > #4 0x000000000142ca32 in PCEventQueue::service (this=0x348c1e0, tc=0x34dc490) at build/ARM/cpu/pc_event.hh:107 > #5 0x000000000142ca84 in BaseSimpleCPU::checkPcEventQueue (this=0x34da230) at build/ARM/cpu/simple/base.hh:98 > #6 0x000000000142b485 in AtomicSimpleCPU::tick (this=0x34da230) at build/ARM/cpu/simple/atomic.cc:446 > #7 0x0000000001427b90 in AtomicSimpleCPU::TickEvent::process (this=0x34da4c0) at build/ARM/cpu/simple/atomic.cc:59 > #8 0x0000000001382ebc in EventQueue::serviceOne (this=0x2704940) at build/ARM/sim/eventq.cc:204 > #9 0x00000000013ceb21 in simulate (num_cycles=9223372036854775807) at build/ARM/sim/simulate.cc:73 > #10 0x0000000000445a99 in _wrap_simulate__SWIG_0 (args=0x3320e10) at build/ARM/python/swig/event_wrap.cc:4475 > #11 0x0000000000445c56 in _wrap_simulate (self=0x0, args=0x3320e10) at build/ARM/python/swig/event_wrap.cc:4525 > #12 0x00007ffff74da1b9 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 > #13 0x00007ffff74db86f in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 > #14 0x00007ffff74d9a9e in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 > #15 0x00007ffff74da4a8 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 > #16 0x00007ffff74db86f in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 > #17 0x00007ffff74db9a2 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0 > #18 0x00007ffff74d9d20 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 > #19 0x00007ffff74db86f in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 > #20 0x00007ffff74d9a9e in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 > #21 0x00007ffff74db86f in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 > #22 0x00007ffff74db9a2 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0 > #23 0x00007ffff74f5cac in run_mod () from /usr/lib/libpython2.7.so.1.0 > #24 0x00007ffff74f689d in PyRun_StringFlags () from /usr/lib/libpython2.7.so.1.0 > #25 0x000000000138ca67 in m5Main (argc=3, argv=0x7fffffffe0e8) at build/ARM/sim/init.cc:256 > #26 0x000000000040b00b in main (argc=3, argv=0x7fffffffe0e8) at build/ARM/sim/main.cc:57 > I went through the corresponding gem5 code and I'm not sure why you call 'Debug::breakpoint()' in 'process', because I don't set a breakpoint at the point, where this break_event triggers. The thing is, this sends a SIG_TRAP to the kernel, but since I've not yet setup the exception handlers, this fails obviously. It seems to have something to do with the breakpoint I set, because when I set a breakpoint after the critical code section or break before and remove the breakpoint afterwards, everything goes well. > Maybe you can shed some light on the behavior of gem5? > Best, > Samuel > > On Mon, Mar 26, 2012 at 4:20 AM, Steve Reinhardt <[email protected] [13]> wrote: > >> Strange... have you modified the kernel? Perhaps the hook that's trying to intercept the panic call is latching on to the wrong PC for some reason. If you run from gdb the break_event should drop you into it and perhaps you can poke around and figure out why you're there. >> Steve >> >> ---------- Forwarded message ---------- >> From: SAMUEL HITZ <[email protected] [6]> >> Date: Sun, Mar 25, 2012 at 4:25 AM >> Subject: Re: [gem5-users] break event panic triggered >> To: gem5 users mailing list <[email protected] [7]> >> >> Yes I'm running in FS mode. The thing is, it happens pretty early in the boot process, where I install exception handlers, so there is no 'panic' call or handler at that time. >> >> On Sun, Mar 25, 2012 at 7:44 AM, Steve Reinhardt <[email protected] [8]> wrote: >> >>> Are you running in full-system mode? This could indicate a kernel panic on your simulated system. We trap the panic call and generate a break event, since generally it's more useful to look around at the point of the panic than to simulate the kernel running through its panic handling code. >>> Steve >>> >>> On Fri, Mar 23, 2012 at 7:10 AM, Samuel Hitz <[email protected] [3]> wrote: >>> >>>> Hi there, >>>> I encounter a >>>> >>>> 9035000: system.cpu.break_event: break event panic triggered >>>> Now my question is, what could possibly cause such a panic? >>>> I can trace the execution of the program up to the point, where this happens. Strangely enough, if I just jump past this small part of the program causing this, the execution can go on. The jumped part does some writes to memory but it doesn't overwrite code or something. >>>> There is no other relevant output of gem5 before this happens. >>>> Any help is much appreciated. >>>> Best, >>>> Samuel _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] [1] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2] >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] [4] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [5] >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] [9] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [10] >> _______________________________________________ >> gem5-users mailing list >> [email protected] [11] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [12] Links: ------ [1] mailto:[email protected] [2] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [3] mailto:[email protected] [4] mailto:[email protected] [5] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [6] mailto:[email protected] [7] mailto:[email protected] [8] mailto:[email protected] [9] mailto:[email protected] [10] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [11] mailto:[email protected] [12] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [13] mailto:[email protected]
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
