It turns out that the benchmark was using msync which was not implemented
in gem5. As a result, the benchmark was corrupting the gem5 memory.
Implemented msync and things seem to work now.

Thanks.


On 31 October 2014 17:52, Steve Reinhardt <ste...@gmail.com> wrote:

> It should always fault in the same place; the simulator is deterministic.
>
> Faulting in advancePC() indicates that it's an instruction fetch that's
> faulting, which is particularly unusual.
>
> You should look at an execution trace to see why execution is heading off
> into the weeds, if that's what's happening.  You can use --debug-start to
> turn on the trace just a little bit before the fault, so you don't have to
> waste time tracing from the beginning.
>
> Steve
>
> On Fri, Oct 31, 2014 at 12:38 PM, Ahmad Hassan <ahmad.has...@gmail.com>
> wrote:
>
>> More interestingly, it always page faults in advancePC method:
>>
>> #0  0x00007ffff6416425 in __GI_raise (sig=<optimised out>) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> #1  0x00007ffff6419b8b in __GI_abort () at abort.c:91
>> #2  0x0000000000a37bde in __exit_epilogue(int, char const*, char const*,
>> int, char const*) ()
>> #3  0x00000000008c09a6 in X86ISA::PageFault::invoke(ThreadContext*,
>> RefCountingPtr<StaticInst> const&) ()
>> #4  0x000000000097c8b8 in
>> BaseSimpleCPU::advancePC(RefCountingPtr<FaultBase> const&) ()
>> #5  0x0000000000974ed7 in AtomicSimpleCPU::tick() ()
>> #6  0x0000000000903c91 in EventQueue::serviceOne() ()
>> #7  0x00000000009211ca in doSimLoop(EventQueue*) ()
>> #8  0x0000000000921775 in simulate(unsigned long) ()
>>
>> Regards,
>>
>>
>> On 31 October 2014 17:17, Ahmad Hassan <ahmad.has...@gmail.com> wrote:
>>
>>> Hi Steve,
>>>
>>> If I just do allocateMem and don't do 'writeBlob', then simulation runs
>>> fine without errors but I get '0' values in the result. This is
>>> understandable. But If I do writeBlob then I always get page fault
>>> exception exactly at the same clock tick (just before the benchmark
>>> finishing the execution)
>>>
>>> Regards,
>>>
>>>
>>> On 31 October 2014 17:11, Steve Reinhardt <ste...@gmail.com> wrote:
>>>
>>>> I don't know... that's basically a page fault.  Do you know the address
>>>> range that your file is mapped to?  It may or may not be directly related
>>>> to mmap.
>>>>
>>>> Steve
>>>>
>>>> On Fri, Oct 31, 2014 at 6:33 AM, Ahmad Hassan <ahmad.has...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Steve,
>>>>>
>>>>> I am running x96 SE mode. The writeBlob() works fine for very small
>>>>> test application. For real benchmark with 1GB working set, the simulation
>>>>> ends with exception:
>>>>>
>>>>> panic: Tried to read unmapped address
>>>>> 0x2800000002d773b0.
>>>>> 0x2aaaaaaab000ULL
>>>>>  @ tick 771687885000
>>>>> [invoke:build/X86/arch/x86/faults.cc, line 160]
>>>>> Memory Usage: 11788528 KBytes
>>>>> Program aborted at tick 771687885000
>>>>>
>>>>> Any ideas why 0x2800 range is getting problems by writeBlob?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>> On 7 October 2014 15:20, Steve Reinhardt <ste...@gmail.com> wrote:
>>>>>
>>>>>> We have a patch internally that implements more of mmap(), but
>>>>>> unfortunately it's not quite ready to post.
>>>>>>
>>>>>> If you just want to do a read mapping (you don't care if writes to
>>>>>> the mmap'd region get written back to disk), and you don't mind just
>>>>>> reading the whole mmap region in up front (which you need to do, since SE
>>>>>> mode doesn't support page faulting), it's not too hard; just call
>>>>>> p->allocateMem() to allocate the memory in the simulated process, and 
>>>>>> then
>>>>>> read the data out of the file and use writeBlob() to copy it into the
>>>>>> memory you just allocated.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On Tue, Oct 7, 2014 at 6:14 AM, Ahmad Hassan via gem5-users <
>>>>>> gem5-users@gem5.org> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The existing implementation in GEM5 SE mode only supports MMAP to
>>>>>>> /dev/zero. Has anyone implemented MMAP in gem5 that can map a file from 
>>>>>>> the
>>>>>>> disk? If not, how can I extend this?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> gem5-users mailing list
>>>>>>> gem5-users@gem5.org
>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to