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
