sry forgot to cc the mailing list. ---------- Forwarded message ---------- From: Samuel Hitz <[email protected]> Date: Sun, Mar 11, 2012 at 5:58 PM Subject: Re: [gem5-users] panic: invalid access size and debugging from the start To: Ali Saidi <[email protected]>
Yes you're right, I specified --bare-metal to test some stuff. I changed my linker script to get the same entry point as the sample arm linux kernel. Without --bare-metal it now complains that 'udelay' is missing, but it seems to get past the error. I don't know about udelay yet. Is that something linux kernel specific (I'm not booting a linux kernel)? Do I have to provide this or can I just 'ignore' it? Best, Samuel On Sun, Mar 11, 2012 at 5:21 PM, Ali Saidi <[email protected]> wrote: > What is happening is that the elf loader is trying to load the kernel in > memory at address 0xc0008000 which doesn't exist in the system. It should > be loading it at address 0x8000. Perhaps you've specified bare-metal on the > command line or somehow created a ArmSystem object as opposed to > LinuxArmSystem? The latter takes care of mundging the address for Linux. > > Thanks, > Ali > > > On Mar 11, 2012, at 11:58 AM, Samuel Hitz wrote: > > Ok I investigated further, but I can't exactly figure out what's going > wrong. Here is a backtrace of the error > > Breakpoint 1, IsaFake::write (this=0x34441d0, pkt=0x7fffffffc7d0) at > build/ARM/dev/isa_fake.cc:116 > 116 panic("invalid access size!\n"); > (gdb) bt > #0 IsaFake::write (this=0x34441d0, pkt=0x7fffffffc7d0) at > build/ARM/dev/isa_fake.cc:116 > #1 0x000000000163ebbc in PioPort::recvAtomic (this=0x3444200, > pkt=0x7fffffffc7d0) at build/ARM/dev/io_device.cc:47 > #2 0x00000000017238f2 in SimpleTimingPort::recvFunctional > (this=0x3444200, pkt=0x7fffffffc7d0) at build/ARM/mem/tport.cc:87 > #3 0x0000000000526846 in Port::sendFunctional (this=0x3259ec0, > pkt=0x7fffffffc7d0) at build/ARM/mem/port.hh:210 > #4 0x00000000017167d1 in Bus::recvFunctional (this=0x3438330, > pkt=0x7fffffffc7d0) at build/ARM/mem/bus.cc:473 > #5 0x000000000171acbd in Bus::BusPort::recvFunctional (this=0x32bed60, > pkt=0x7fffffffc7d0) at build/ARM/mem/bus.hh:113 > #6 0x0000000000526846 in Port::sendFunctional (this=0x3436dd8, > pkt=0x7fffffffc7d0) at build/ARM/mem/port.hh:210 > #7 0x0000000001724fbd in PortProxy::blobHelper (this=0x3436e58, > addr=3221258240, > p=0x7fffeb6be0a0 "\004\340N\342\016@\240", <incomplete sequence > \341>, size=112012, cmd=...) at build/ARM/mem/port_proxy.cc:53 > #8 0x00000000004ff735 in PortProxy::writeBlob (this=0x3436e58, > addr=3221258240, > p=0x7fffeb6be0a0 "\004\340N\342\016@\240", <incomplete sequence > \341>, size=112012) at build/ARM/mem/port_proxy.hh:107 > #9 0x0000000001364e5f in ObjectFile::loadSection (this=0x323ba30, > sec=0x323ba70, memProxy=..., addrMask=4294967295) > at build/ARM/base/loader/object_file.cc:73 > #10 0x0000000001364ec6 in ObjectFile::loadSections (this=0x323ba30, > memProxy=..., addrMask=4294967295) > at build/ARM/base/loader/object_file.cc:87 > #11 0x0000000001361a85 in ElfObject::loadSections (this=0x323ba30, > memProxy=..., addrMask=4294967295) > at build/ARM/base/loader/elf_object.cc:419 > #12 0x00000000013f0dae in System::initState (this=0x3436db0) at > build/ARM/sim/system.cc:275 > #13 0x000000000051681a in ArmSystem::initState (this=0x3436db0) at > build/ARM/arch/arm/system.cc:80 > #14 0x0000000001c4442f in _wrap_SimObject_initState (args=0x3320ed0) at > build/ARM/python/m5/internal/param_SimObject_wrap.cc:3057 > #15 0x00007ffff74da215 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 0x00007ffff74d9a9e in PyEval_EvalFrameEx () from > /usr/lib/libpython2.7.so.1.0 > #18 0x00007ffff74db86f in PyEval_EvalCodeEx () from > /usr/lib/libpython2.7.so.1.0 > #19 0x00007ffff74d9a9e in PyEval_EvalFrameEx () from > /usr/lib/libpython2.7.so.1.0 > #20 0x00007ffff74da4a8 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 0x00007ffff74d9d20 in PyEval_EvalFrameEx () from > /usr/lib/libpython2.7.so.1.0 > #24 0x00007ffff74db86f in PyEval_EvalCodeEx () from > /usr/lib/libpython2.7.so.1.0 > #25 0x00007ffff74d9a9e in PyEval_EvalFrameEx () from > /usr/lib/libpython2.7.so.1.0 > #26 0x00007ffff74db86f in PyEval_EvalCodeEx () from > /usr/lib/libpython2.7.so.1.0 > #27 0x00007ffff74db9a2 in PyEval_EvalCode () from > /usr/lib/libpython2.7.so.1.0 > #28 0x00007ffff74f5cac in run_mod () from /usr/lib/libpython2.7.so.1.0 > #29 0x00007ffff74f689d in PyRun_StringFlags () from > /usr/lib/libpython2.7.so.1.0 > #30 0x000000000138d577 in m5Main (argc=4, argv=0x7fffffffe0c8) at > build/ARM/sim/init.cc:256 > #31 0x000000000040b00b in main (argc=4, argv=0x7fffffffe0c8) at > build/ARM/sim/main.cc:57 > > It seems to me, that when loading the ELF sections, the system tries to > load chunks of 64 bytes, but the port on which this chunk is sent doesn't > support this chunk size. You have more insight in the system, can you get > something concrete out of this? > > Best, > > Samuel > > On Thu, Mar 8, 2012 at 7:06 PM, Samuel Hitz <[email protected]> wrote: > >> It's because packet size in >> >> Tick IsaFake::write(PacketPtr pkt) >> >> is 64 bytes. I don't know what's causing it yet, but I'll investigate >> further. >> >> >> >> On Thu, Mar 8, 2012 at 6:01 PM, Ali Saidi <[email protected]> wrote: >> >>> ** >>> >>> >>> I imagine that your jumping to a i/o device or a bad-address responder >>> in the memory system and trying to access it with a cache block sized >>> request. You should be able to figure out what's gone wrong with some trace >>> flags, but if you want to get gdb attached at cycle 0 just set rgdb_wait in >>> sim/system.cc to a positive integer. >>> >>> >>> Ali >>> >>> >>> On 07.03.2012 05:55, Samuel Hitz wrote: >>> >>> Hi there, >>> When I run gem5 with my kernel I get >>> panic: invalid access size! >>> @ cycle 0 >>> [write:build/ARM/dev/isa_fake.cc, line 116] >>> What could be causing such an error? I assume it hasn't even started >>> executing, since it's at cycle 0. >>> And how can I remote debug with gdb from the beginning? Basically I want >>> to connect with gdb and then start executing code. >>> Help is much appreciated. >>> Best, >>> Samuel >>> >>> >>> >>> >>> _______________________________________________ >>> 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
