Re: [gem5-users] gem5 X86 Full System fails with DerivO3CPU

[Abhishek Singh]

Hello Everyone,

Yaz: I do not change anything, I am using commit
2a98a994df296f818b05da90ba073d879562da04
of gem5.

Is there anyone who was able to *boot* the full system for x86 ISA using
O3CPU?

My command line :

*build/X86/gem5.opt configs/example/fs.py  --kernel=x86_64-vmlinux-2.6.22.9
--disk-image=linux-x86.img --cpu-type=DerivO3CPU --caches*

Best regards,

Abhishek


On Fri, Mar 8, 2019 at 2:09 PM Ayaz Akram  wrote:

> Hi Abhishek,
>
> I wonder if you are using the default CPU configuration for full-system or
> do you have any changes?
>
> Regards
> -Ayaz
>
> On Wed, Mar 6, 2019 at 2:20 PM Abhishek Singh <
> abhishek.singh199...@gmail.com> wrote:
>
>> Hello Everyone,
>>
>> I am trying to run the gem5 full system with X86 ISA and DerivO3CPU
>>
>> I have built image and kernel following Jason's Website (ref:
>> http://www.lowepower.com/jason/setting-up-gem5-full-system.html)
>> My image is* Ubuntu 16.04.5 LTS*
>> My kernel is  *Linux-4.8.13*
>> Gem5 version: Latest as of 6th March 2019
>>
>> The image and kernel work fine with Atomic and Timing CPU for x86.
>> But for O3CPU, it gives an error as shown below:
>> "
>>
>> command line: *./build/X86/gem5.opt configs/example/fs.py
>> --script=./script.rcS
>> --disk-image=/home/abs218/image_kernel/ubuntu-test.img
>> --kernel=/home/abs218/new_fs/gem5/linux-4.8.13/vmlinux --caches --l2cache
>> --cpu-type=DerivO3CPU*
>>
>>
>> Global frequency set at 1 ticks per second
>>
>> warn: DRAM device capacity (8192 Mbytes) does not match the address range
>> assigned (512 Mbytes)
>>
>> info: kernel located at: /home/abs218/new_fs/gem5/linux-4.8.13/vmlinux
>>
>> system.pc.com_1.device: Listening for connections on port 3456
>>
>>   0: rtc: Real-time clock set to Sun Jan  1 00:00:00 2012
>>
>> 0: system.remote_gdb: listening for remote gdb on port 7000
>>
>> warn: Reading current count from inactive timer.
>>
>>  REAL SIMULATION 
>>
>> info: Entering event queue @ 0.  Starting simulation...
>>
>> *gem5.opt: build/X86/mem/packet.hh:1047: T* Packet::getPtr() [with T =
>> unsigned char]: Assertion `flags.isSet(STATIC_DATA|DYNAMIC_DATA)' failed*
>> .
>>
>> Program aborted at tick 11637500
>>
>> --- BEGIN LIBC BACKTRACE ---
>>
>> ./build/X86/gem5.opt(_Z15print_backtracev+0x2c)[0x561f4b44d8bc]
>>
>> ./build/X86/gem5.opt(_Z12abortHandleri+0x4a)[0x561f4b45fc8a]
>>
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f25466db890]
>>
>> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f2544e02e97]
>>
>> /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f2544e04801]
>>
>> /lib/x86_64-linux-gnu/libc.so.6(+0x3039a)[0x7f2544df439a]
>>
>> /lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7f2544df4412]
>>
>>
>> ./build/X86/gem5.opt(_ZN6X86ISA13handleIprReadEP13ThreadContextP6Packet+0x17c)[0x561f4ace817c]
>>
>>
>> ./build/X86/gem5.opt(_ZN7LSQUnitI9O3CPUImplE4readEPN3LSQIS0_E10LSQRequestEi+0x431)[0x561f4aca8781]
>>
>>
>> ./build/X86/gem5.opt(_ZN3LSQI9O3CPUImplE4readEPNS1_10LSQRequestEi+0xad)[0x561f4acee75d]
>>
>>
>> ./build/X86/gem5.opt(_ZN3LSQI9O3CPUImplE11pushRequestERK14RefCountingPtrI13BaseO3DynInstIS0_EEbPhjm5FlagsImEPmP15AtomicOpFunctor+0x523)[0x561f4aceecf3]
>>
>>
>> ./build/X86/gem5.opt(_ZN11BaseDynInstI9O3CPUImplE15initiateMemReadEmj5FlagsImE+0x7b)[0x561f4ac8cb3b]
>>
>>
>> ./build/X86/gem5.opt(_ZNK10X86ISAInst5LdBig11initiateAccEP11ExecContextPN5Trace10InstRecordE+0xd1)[0x561f4b99e521]
>>
>>
>> ./build/X86/gem5.opt(_ZN13BaseO3DynInstI9O3CPUImplE11initiateAccEv+0x45)[0x561f4acbfc15]
>>
>>
>> ./build/X86/gem5.opt(_ZN7LSQUnitI9O3CPUImplE11executeLoadERK14RefCountingPtrI13BaseO3DynInstIS0_EE+0x57)[0x561f4acf87e7]
>>
>>
>> ./build/X86/gem5.opt(_ZN3LSQI9O3CPUImplE11executeLoadERK14RefCountingPtrI13BaseO3DynInstIS0_EE+0x3b)[0x561f4ace8a0b]
>>
>>
>> ./build/X86/gem5.opt(_ZN10DefaultIEWI9O3CPUImplE12executeInstsEv+0xf06)[0x561f4acd6e96]
>>
>>
>> ./build/X86/gem5.opt(_ZN10DefaultIEWI9O3CPUImplE4tickEv+0x8c0)[0x561f4acda9a0]
>>
>>
>> ./build/X86/gem5.opt(_ZN9FullO3CPUI9O3CPUImplE4tickEv+0x144)[0x561f4acac574]
>>
>> ./build/X86/gem5.opt(_ZN10EventQueue10serviceOneEv+0xd9)[0x561f4b455699]
>>
>> ./build/X86/gem5.opt(_Z9doSimLoopP10EventQueue+0x87)[0x561f4b470e77]
>>
>> ./build/X86/gem5.opt(_Z8simulatem+0xcaa)[0x561f4b471eba]
>>
>> ./build/X86/gem5.opt(+0x5b4d4e)[0x561f4aaedd4e]
>>
>> ./build/X86/gem5.opt(+0x591bf4)[0x561f4aacabf4]
>>
>>
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x64d7)[0x7f2546995697]
>>
>>
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f2546ac7278]
>>
>>
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7f2546994db6]
>>
>>
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f2546ac7278]
>>
>>
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7f2546994db6]
>>
>>
>> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f2546ac7278]
>>
>>
>> 

Re: [gem5-users] SPECCPU 2006 application crashes on x86 gem5

[Shyam Murthy]

Thanks a lot for the inputs, Gururaj and Gabe.

Thanks,
Shyam

On Mon, Jul 1, 2019 at 1:21 AM Saileshwar, Gururaj 
wrote:

> Hi Shyam,
>
> I also faced this issue with “movntdq_Mo_Vo” in the recent past when I
> was trying to compile and run SPEC2006 with Gem5.
>
> I managed to debug it to some extent – the source of these unimplemented
> instructions is likely one of the linked libraries (mostly glibc) that the
> binary uses.
>
> While I didn’t manage to find a fix, I got a work-around: I compiled my
> binaries with static linking (-static flag to linker) on a older system
> that apparently did not use this instruction. Subsequently, those binaries
> also worked with Gem5 on my newer system where I was originally facing this
> issue. Sorry, I am unable to give you precise versions of the SW I used – I
> no longer have access.
>
> Hope this helps!
> Gururaj
>
> From: gem5-users  on behalf of Gabe Black <
> gabebl...@google.com>
> Reply-To: gem5 users mailing list 
> Date: Sunday, June 30, 2019 at 10:42 PM
> To: Shyam Murthy 
> Cc: gem5 users mailing list 
> Subject: Re: [gem5-users] SPECCPU 2006 application crashes on x86 gem5
>
> Hi Shyam. Part of the issue is an unfortunate aspect of how gcc works
> where there are some components that are built when gcc itself is
> built/installed which use certain settings, and if you link against them
> later (which gcc will do implicitly/automatically in at least a couple
> cases) those settings won't change and you can get, for instance,
> instructions that you'd turned off. There can be even bigger issues if you
> change flags that break ABI compatibility since those libraries won't work
> at all instead of just disregarding your settings.
>
> There are apparently also header files which get pulled in which use
> features you can technically disable, but disabling them breaks those
> headers.
>
> I think the linked thread is probably where someone was using instructions
> which were too new to be supported, but in your case I think (without
> having the time to check for sure) that that instruction isn't supported
> because it's the non-temporal version, and there isn't (or at least wasn't)
> a good way to implement that behavior. I vaguely remember adding a flag
> which disabled caching which you might find if you look at the repository
> history or archived emails, so it may be possible to implement that
> instruction properly now.
>
> Gabe
>
> On Sun, Jun 30, 2019 at 4:38 PM Shyam Murthy 
> wrote:
>
>> Hi,
>>
>> Additionally, I also tried using the -mno-sse2 flag, with which it
>> compiles, but the error persists. However, when I tried to compile using
>> the -mno-sse flag, then compilation fails saying:
>>
>> */usr/include/x86_64-linux-gnu/bits/stdlib-float.h: In function 'atof':
>> /usr/include/x86_64-linux-gnu/bits/stdlib-float.h:26:1: error: SSE register
>> return with SSE disabled*
>>
>> Thanks,
>> Shyam
>>
>> On Sun, Jun 30, 2019 at 3:24 PM Shyam Murthy 
>> wrote:
>>
>>> Hi,
>>>
>>> This is slightly different, there is no panic message here. However,
>>> this instruction is unimplemented, but is required by the application for
>>> its execution, causing it to abort. As in your link, Gabe mentions that we
>>> need to tell the compiler not to use this instruction. I was unsure how to
>>> achieve the same, I tried passing the -msse flag to gcc during compilation,
>>> but the movntdq instruction still seems to be getting generated.
>>>
>>> Thanks,
>>> Shyam
>>>
>>> On Sun, Jun 30, 2019 at 1:06 PM Kleovoulos Kalaitzidis <
>>> kleovoulos.kalaitzi...@inria.fr> wrote:
>>>
 Hello,
 it is normal to get these warnings for unimplemented instructions.
 However, in my experience, these warnings are not the case for aborting.
 Normally some panic message follows, but maybe not related to this "warn".
 For instance, there is the case of avx instructions that are not
 implemented and will abort the execution :
 https://gem5-users.gem5.narkive.com/jO22f7kV/spec2017-on-gem5-se-mode

 Regards,

 --
 Kleovoulos Kalaitzidis
 Doctorant - Équipe PACAP

 Centre de recherche INRIA Rennes - Bretagne Atlantique
 Bâtiment 12E, Bureau E321, Campus de Beaulieu,
 35042 Rennes Cedex, France

 --

 *From: *"Shyam Murthy" 
 *To: *"gem5 users mailing list" 
 *Sent: *Sunday, June 30, 2019 7:02:37 PM
 *Subject: *[gem5-users] SPECCPU 2006 application crashes on x86 gem5

 Hi All,
 I am trying to run some of the FP applications from SPECCPU 2006.
 However, for some of these applications (like povray, tonto), I get an
 error that says:

 warn: instruction 'movntdq_Mo_Vo' unimplemented.

 I am compiling these applications on my machine, and then running them
 on x86 gem5. My machine uses gcc version 7.4.0. I tried using gcc version
 5.5 (already installed on my machine), but the problem persists.


 Any suggestions as 

Re: [gem5-users] SPECCPU 2006 application crashes on x86 gem5

[Saileshwar, Gururaj]

Hi Shyam,

I also faced this issue with “movntdq_Mo_Vo” in the recent past when I was 
trying to compile and run SPEC2006 with Gem5.

I managed to debug it to some extent – the source of these unimplemented 
instructions is likely one of the linked libraries (mostly glibc) that the 
binary uses.

While I didn’t manage to find a fix, I got a work-around: I compiled my 
binaries with static linking (-static flag to linker) on a older system that 
apparently did not use this instruction. Subsequently, those binaries also 
worked with Gem5 on my newer system where I was originally facing this issue. 
Sorry, I am unable to give you precise versions of the SW I used – I no longer 
have access.

Hope this helps!
Gururaj

From: gem5-users 
mailto:gem5-users-boun...@gem5.org>> on behalf of 
Gabe Black mailto:gabebl...@google.com>>
Reply-To: gem5 users mailing list 
mailto:gem5-users@gem5.org>>
Date: Sunday, June 30, 2019 at 10:42 PM
To: Shyam Murthy mailto:shyammurth...@gmail.com>>
Cc: gem5 users mailing list mailto:gem5-users@gem5.org>>
Subject: Re: [gem5-users] SPECCPU 2006 application crashes on x86 gem5

Hi Shyam. Part of the issue is an unfortunate aspect of how gcc works where 
there are some components that are built when gcc itself is built/installed 
which use certain settings, and if you link against them later (which gcc will 
do implicitly/automatically in at least a couple cases) those settings won't 
change and you can get, for instance, instructions that you'd turned off. There 
can be even bigger issues if you change flags that break ABI compatibility 
since those libraries won't work at all instead of just disregarding your 
settings.

There are apparently also header files which get pulled in which use features 
you can technically disable, but disabling them breaks those headers.

I think the linked thread is probably where someone was using instructions 
which were too new to be supported, but in your case I think (without having 
the time to check for sure) that that instruction isn't supported because it's 
the non-temporal version, and there isn't (or at least wasn't) a good way to 
implement that behavior. I vaguely remember adding a flag which disabled 
caching which you might find if you look at the repository history or archived 
emails, so it may be possible to implement that instruction properly now.

Gabe

On Sun, Jun 30, 2019 at 4:38 PM Shyam Murthy 
mailto:shyammurth...@gmail.com>> wrote:
Hi,

Additionally, I also tried using the -mno-sse2 flag, with which it compiles, 
but the error persists. However, when I tried to compile using the -mno-sse 
flag, then compilation fails saying:
/usr/include/x86_64-linux-gnu/bits/stdlib-float.h: In function 'atof':
/usr/include/x86_64-linux-gnu/bits/stdlib-float.h:26:1: error: SSE register 
return with SSE disabled

Thanks,
Shyam

On Sun, Jun 30, 2019 at 3:24 PM Shyam Murthy 
mailto:shyammurth...@gmail.com>> wrote:
Hi,

This is slightly different, there is no panic message here. However, this 
instruction is unimplemented, but is required by the application for its 
execution, causing it to abort. As in your link, Gabe mentions that we need to 
tell the compiler not to use this instruction. I was unsure how to achieve the 
same, I tried passing the -msse flag to gcc during compilation, but the movntdq 
instruction still seems to be getting generated.

Thanks,
Shyam

On Sun, Jun 30, 2019 at 1:06 PM Kleovoulos Kalaitzidis 
mailto:kleovoulos.kalaitzi...@inria.fr>> wrote:
Hello,
it is normal to get these warnings for unimplemented instructions. However, in 
my experience, these warnings are not the case for aborting. Normally some 
panic message follows, but maybe not related to this "warn". For instance, 
there is the case of avx instructions that are not implemented and will abort 
the execution : 
https://gem5-users.gem5.narkive.com/jO22f7kV/spec2017-on-gem5-se-mode

Regards,

--
Kleovoulos Kalaitzidis
Doctorant - Équipe PACAP

Centre de recherche INRIA Rennes - Bretagne Atlantique
Bâtiment 12E, Bureau E321, Campus de Beaulieu,
35042 Rennes Cedex, France


From: "Shyam Murthy" mailto:shyammurth...@gmail.com>>
To: "gem5 users mailing list" mailto:gem5-users@gem5.org>>
Sent: Sunday, June 30, 2019 7:02:37 PM
Subject: [gem5-users] SPECCPU 2006 application crashes on x86 gem5
Hi All,
I am trying to run some of the FP applications from SPECCPU 2006. However, for 
some of these applications (like povray, tonto), I get an error that says:

warn: instruction 'movntdq_Mo_Vo' unimplemented.

I am compiling these applications on my machine, and then running them on x86 
gem5. My machine uses gcc version 7.4.0. I tried using gcc version 5.5 (already 
installed on my machine), but the problem persists.


Any suggestions as to what I can do to fix this?


Thanks,

Shyam

___
gem5-users mailing list
gem5-users@gem5.org

Re: [gem5-users] Changing buffer depth in virtual channels - Garnet

[Krishna, Tushar]

Those values are used when initializing the credits in OutVCstate for the data 
and control VCs.
The flitBuffer object has infinite size but the actual number of flits that can 
sit in it are controlled by the credits.

- Tushar
On Jun 27, 2019, 2:44 PM -0700, CARLOS ANDRES PIEDRAHITA VELASQUEZ 
, wrote:
Greetings Everyone,

I want to modify the buffer depth of virtual channels in Garnet from the 
default values (buffers_per_ctrl_vc = 1 and buffers_per_data_vc = 4). Analyzing 
GarnetNetwork.cc, I can see that these attributes are instantiated in 
GarnetNetwork's constructor (lines 65 and 66), but never used anywhere in the 
code. Additionally, In VirtualChannel.cc  the attribute m_input_buffer is 
instantiated as a flitBuffer object with infinite size (line 40).

So, does this mean that the buffers in the virtual channels are of infinite 
size?, is there something that I don't understand yet?

Thank you for your kind attention.

--
Carlos A. Piedrahita-Velásquez
Universidad de Antioquia

[https://0c595a64-a-57bd039f-s-sites.googlegroups.com/a/udea.edu.co/repositorio-logos/home/firma/FIRMA_CAMPUS50.jpg]
"La información aquí contenida es para uso exclusivo de la persona o entidad de 
destino. Está estrictamente prohibida su utilización, copia, descarga, 
distribución, modificación y/o reproducción total o parcial, sin el permiso 
expreso de Universidad de Antioquia, pues su contenido puede ser de carácter 
confidencial y/o contener material privilegiado. Si usted recibió esta 
información por error, por favor contacte en forma inmediata a quien la envió y 
borre este material de su computador. Universidad de Antioquia no es 
responsable por la información contenida en esta comunicación, el directo 
responsable es quien la firma o el autor de la misma."

___
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users