Hi Gabe, Thank you for the reply, I will try to see more with GDB. Interestingly, same workload works in older version of gem5. We had Ubuntu 16 machines with gem5 2016 version. If I use same work load with it's "se.py" and run, the workload executes with any number of CPUs with out resulting in this error. This is observed in only newer version of gem5. We upgraded our machines with newer version of ubuntu ( Ubuntu 20) and installed newer gem5 package. We see this behaviour in these machines. With this info, are there any additional suggestions you have for me.
Thanks, Sachin On Mon, Nov 22, 2021 at 3:17 AM Gabe Black <gabe.bl...@gmail.com> wrote: > Hi Sachin. Without looking at the output, this sounds like a null pointer > to a structure or object within your workload, where the thing within being > accessed is at offset 0x14 from the start of the struct/object. You can use > GDB to debug code within gem5 using the remote GDB stub: > > > https://www.gem5.org/documentation/general_docs/debugging_and_testing/debugging/debugging_simulated_code > > On Sun, Nov 21, 2021 at 6:43 PM Sachin Vijay Kumar <vijay...@ualberta.ca> > wrote: > >> Hi Gabe, >> Thanks for the suggestion, it worked. I used "se.py" file and submitted >> workload. It seems that for multithreaded work load, if number of threads >> is equal to number of cores, things work. I used --debug flag to verify >> whether both cores are running. But unfortunately, I have ran into another >> problem. This seem to work for number of cores and threads equal to 2. When >> I use more than 2, I get an panic error "panic: panic condition !handled >> occurred: Page table fault when accessing virtual address 0x14". >> >> I have attached the console output for working ( n=2) and non working >> (n=3) case, do you have any suggestion on where I should look into in >> solving this problem? I spent lot of time on this with out making any >> progress. >> >> Thanks, >> Sachin >> >> >> On Mon, Nov 15, 2021 at 5:51 PM Gabe Black via gem5-users < >> gem5-users@gem5.org> wrote: >> >>> I'm not 100% sure this is right, but I think what you do is assign the >>> same process object to each core you want a thread to run on. >>> >>> Gabe >>> >>> On Mon, Nov 15, 2021 at 10:25 AM Sachin Vijay Kumar via gem5-users < >>> gem5-users@gem5.org> wrote: >>> >>>> Hi all, >>>> >>>> I have some basic question about assigning a multithreaded program >>>> into different cores of ARM in gem5 simulation. >>>> Basically, I have hashmark benchmark file which is built for arm core >>>> with "m5 threads". >>>> The executable takes number of threads to create and a input file as >>>> argument. Now when I run simulations, I have to assign each thread of this >>>> benchmark program to each core of the processor. How can I do that? >>>> I have gone through "se.py" and I understand, how different program >>>> could be loaded into different cores. I also understand, how different >>>> programs can be loaded into multi-threaded single core (by looking at same >>>> script file). >>>> But I do not get, How can I assign a thread of a benchmark application >>>> to a core of the processor, Can some one please provide some pointers? >>>> >>>> Thanks, >>>> Sachin >>>> _______________________________________________ >>>> gem5-users mailing list -- gem5-users@gem5.org >>>> To unsubscribe send an email to gem5-users-le...@gem5.org >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>> >>> _______________________________________________ >>> gem5-users mailing list -- gem5-users@gem5.org >>> To unsubscribe send an email to gem5-users-le...@gem5.org >>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> >>
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
