From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) by dpdk.org (Postfix) with ESMTP id BBA73B11D for ; Tue, 24 Jun 2014 20:29:18 +0200 (CEST) Received: by mail-we0-f176.google.com with SMTP id u56so774099wes.21 for ; Tue, 24 Jun 2014 11:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0iuN7901PDjjNo/NJK+MOOYCGi9BZnBJqI0eL5MFLpg=; b=HdpxxUTTYnjEQ0WMQHssS0JjPK9sziu6eGT1ITkRI6Hk4NGZ3uhBhwP440gsIZ1gwv P7RfLB01JelpTNrpYxOrXr4wgwAJtbzoLH7LgL7YAaSNM4H2qDpCDjnkkGEo39Ny2TIg JwY1HQfRg8Fxx4AT+POkwsZprewyYS25YiOQQNZpOYdeel8URV3+k+xrLQlzh66lt4h5 EnDy8JcePk1oG254KEd4kEeJXMZ29AMHNT9zp1wApjOX8o1sqLVV89rIo/tr4TPBKSqX CpcNHvCHaDp3iz+SxZLbhIOfvUblZ8bGHAXv+M3fDi1N7C9fynHJb7TyRFQ0Gkv6KBke He2Q== MIME-Version: 1.0 X-Received: by 10.180.83.105 with SMTP id p9mr35810641wiy.8.1403634572541; Tue, 24 Jun 2014 11:29:32 -0700 (PDT) Received: by 10.194.85.76 with HTTP; Tue, 24 Jun 2014 11:29:32 -0700 (PDT) In-Reply-To: <59AF69C657FD0841A61C55336867B5B02CEE3323@IRSMSX103.ger.corp.intel.com> References: <59AF69C657FD0841A61C55336867B5B02CEE3323@IRSMSX103.ger.corp.intel.com> Date: Tue, 24 Jun 2014 21:29:32 +0300 Message-ID: From: Helmut Sim To: "Richardson, Bruce" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] eal_parse_coremask fails on SIGILL X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 18:29:18 -0000 Indeed, I just verified it with building for Westmere, thanks. However the meaning is that the system will be built to the lowest target microarchitecture, or alternatively, multiple builds for different microarchitectures will be delivered. Thanks. On Tue, Jun 24, 2014 at 8:32 PM, Richardson, Bruce < bruce.richardson@intel.com> wrote: > > > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Helmut Sim > > Sent: Tuesday, June 24, 2014 8:08 AM > > To: dev@dpdk.org > > Subject: Re: [dpdk-dev] eal_parse_coremask fails on SIGILL > > > > one more detail, i am using dpdk-1.6.0r1 > > > > > > > > On Tue, Jun 24, 2014 at 6:05 PM, Helmut Sim wrote: > > > > > Hi, > > > > > > I need some help to understand the following issue. > > > > > > I am building the DPDK with make install T=x86_64-default-linuxapp-gcc > and > > > it works well on my machine. > > > However when testing it on my virtual machine (ubuntu 14.04 server > guest n > > > xen hv) it fails for SIGILL: > > > here is the relevant gdb output for the helloworld example: > > > [New LWP 4462] > > > [Thread debugging using libthread_db enabled] > > > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > > > Core was generated by `./build/helloworld -c 3 -n 4'. > > > Program terminated with signal SIGILL, Illegal instruction. > > > (gdb) bt > > > #0 0x00000000004061d9 in eal_parse_coremask (coremask=0x7fff2bf9a9b1 > > "3") > > > at > > > > > > /home/sim/work/prj/common/dpdk/package/lib/librte_eal/linuxapp/eal/eal.c:4 > > 50 > > > #1 eal_parse_args (argv=0x7fff2bf99d68, argc=5) at > > > > > > /home/sim/work/prj/common/dpdk/package/lib/librte_eal/linuxapp/eal/eal.c:6 > > 88 > > > #2 rte_eal_init (argc=5, argv=0x7fff2bf99d68) at > > > > > > /home/sim/work/prj/common/dpdk/package/lib/librte_eal/linuxapp/eal/eal.c:9 > > 56 > > > #3 0x0000000000405436 in main () > > > > > > i am building the dpdk and the examples on one machine and copy the > > > x86_64-default-linuxapp-gcc and the helloworld/build directories to a > > > second machine. > > > > > > the machine i am building the dpdk and the app on is: > > > uname -a > > > Linux sim 3.11.0-23-generic #40-Ubuntu SMP Wed Jun 4 21:05:23 UTC 2014 > > > x86_64 x86_64 x86_64 GNU/Linux > > > > > > model name : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz > > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > > > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall > nx > > > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl > > > xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor > > > ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 > x2apic > > > movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm > ida > > > arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid > fsgsbase > > > tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm > > > > > > > > > the virtual machine i am executing the program on is: > > > uname -a > > > Linux vflow-target 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 > > > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > > > > > from the cpuinfo: > > > model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz > > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > > > cmov pat clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc > > > rep_good nopl pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt > > > tsc_deadline_timer aes hypervisor lahf_lm > > > > > > > > > Any idea why such an exception of SIGILL may occur? > > > > > > > > > Thanks for your help. > > > > > The instruction sets on the compilation machine and the target machine > don't match and you are compiling for the "native" instruction set on the > compilation machine, and this is causing you problems. The i7-4770 machine > is based on the Haswell microarchitecture and has instruction sets such as > AVX and AVX2 available on it, which the compiler will then use when told to > compile for the "native" target. Unfortunately the deployment machine is > from an older microarchitecture (Westmere uarch, perhaps??) and so does not > have all these instructions available to it. When an unsupported > instruction, e.g. an AVX instruction, is hit, you get the error seen above. > > The solution to the problem is either: > a) compile up the code on the deployment machine or another machine with > the same or earlier microarchitecture, or > b) modify the compile-time config (e.g. the .config file in the build > directory) to set the CONFIG_RTE_MACHINE value to whatever the lowest-value > microarchitecture is that you plan on using the deployed binaries on. If > you are not sure, replace "native" with "default" and then optionally work > your way up from that, through "nhm", "wsm" etc. > > Regards, > /Bruce >