From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0053.outbound.protection.outlook.com [104.47.0.53]) by dpdk.org (Postfix) with ESMTP id E09282BC5 for ; Mon, 22 Aug 2016 15:58:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mJRv8/wzq3/RvndOIeEEpW0nzJnSHdfJBqNLYqvo9B0=; b=hXwaxP8dy4jaPNYXYZAJrJHoRR18Znakow0PtATKcjKERedw2ql8cZ8ORfjs5OZ/DoM0qIKW91APwWlqx+IgtwI1luDsYTB4w+WPLASvyZ9vi9K3d9RLtH/pGY/P/Wj3cnH723M4R8VdNK+WtV1QQAX2XUf7qqosHITn9U0n7dQ= Received: from DB5PR0401MB2054.eurprd04.prod.outlook.com (10.166.11.137) by DB5PR0401MB2056.eurprd04.prod.outlook.com (10.166.11.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.2; Mon, 22 Aug 2016 13:58:44 +0000 Received: from DB5PR0401MB2054.eurprd04.prod.outlook.com ([10.166.11.137]) by DB5PR0401MB2054.eurprd04.prod.outlook.com ([10.166.11.137]) with mapi id 15.01.0599.001; Mon, 22 Aug 2016 13:58:44 +0000 From: Shreyansh Jain To: "martin_curran-gray@keysight.com" , "users@dpdk.org" Thread-Topic: segfault with dpdk 16.07 in rte_mempool_populate_phys Thread-Index: AdH4kORR/4kmue64QRuvda8Df4kUXwBTgvEAAASWNaAAoiZ4wA== Date: Mon, 22 Aug 2016 13:58:44 +0000 Message-ID: References: <22C95CA62CBADB498D32A348F0F073BC20AE2583@wcosexch02k.cos.is.keysight.com> <22C95CA62CBADB498D32A348F0F073BC20AE28CB@wcosexch02k.cos.is.keysight.com> In-Reply-To: <22C95CA62CBADB498D32A348F0F073BC20AE28CB@wcosexch02k.cos.is.keysight.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shreyansh.jain@nxp.com; x-originating-ip: [192.88.169.1] x-ms-office365-filtering-correlation-id: 18597a01-79b9-45cc-50d8-08d3ca946e64 x-microsoft-exchange-diagnostics: 1; DB5PR0401MB2056; 6:3qukCbyp2H1eZAmzqhVKfKNOQiCiZwvGPiVeJSKI0qE2CQR2QlvK95o+sKUgBANqr3O6KfSMJ2UyjidvAxJYiJwD2/F0D1GLy1uxb0MfgyVsBomQFECpSMpr9CSFKN3whdGb/fpDeMZ1KxzhNtJBerpdpqTOJZuyJu114OhcPvrDr6Xwp5l2vMTU8NsqpHGo2XX4o0si6SZtSor6eQ0OL2mILp6FHJAY2yqoGP675cx00WbiOVYLX0NYXOmg1mAdY5fbUwK79BSn0B8WMmXduvb98EATYd4OO5U6f7lkjSY3oGDCrV/9SSuzRf1nL2bu0iGJrkHEcW1xSa8DbMTRWA==; 5:Jn/66OqNKwwnY/ckBzBNeRwa71phevBQponXtszCGMy0ksAc4K60aRscFtJaG6GI1gHzHpUgZ5GPcXCCRtZHxX9NwA4baYxacAPnzUUeyqzhaNxRvAWktNkNJWSDBd9gpWchzcIcY+PrAJQO1aEaFg==; 24:iaeoMhUppJfv9G74r6QKXYieY1sycy9VZDgnpk5hSLoVJcU4TlJ/oIWfsopuawbTav8AQrdVvnGue83IpjgX0BtBI82tItVjzUNO6vkGSrw=; 7:owwh5eOs8G3MkUn3XynioNk7pMS/FxbUju8O5eOvVmadVQ30cPFhmrLIuy1OAXg2d0ekYfohOwp5cNbl95syudlT43IW0iM1hFF/OO7S6Gs9HZK25jWXP0MriVNp3/5V5Owgmi9GeV9QQVXmlk/8c98CsoN4tJ3k3/58eWVL2DYX0uC4K09RN7X8xoa5YGfYnodJ8UNuHwTRVZF64w1GEV7v2Z380r/jyDvUGp4sJqVMxwpbUo1++pGWDeKWOdwJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR0401MB2056; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(185117386973197); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DB5PR0401MB2056; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0401MB2056; x-forefront-prvs: 00429279BA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(13464003)(189002)(199003)(51884002)(8676002)(50986999)(5002640100001)(76576001)(76176999)(5001770100001)(77096005)(122556002)(97736004)(81166006)(305945005)(5660300001)(19580395003)(2950100001)(3280700002)(106356001)(54356999)(102836003)(6116002)(3846002)(11100500001)(81156014)(74316002)(2900100001)(3660700001)(10400500002)(107886002)(8936002)(2501003)(66066001)(101416001)(586003)(189998001)(2906002)(33656002)(87936001)(86362001)(68736007)(19580405001)(9686002)(92566002)(7846002)(105586002)(7696003)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR0401MB2056; H:DB5PR0401MB2054.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2016 13:58:44.4009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0401MB2056 Subject: Re: [dpdk-users] segfault with dpdk 16.07 in rte_mempool_populate_phys X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 13:58:47 -0000 Hi Martin, See inline. (Also, please don't remove mail thread text in replied as it loses context)= . > -----Original Message----- > From: martin_curran-gray@keysight.com [mailto:martin_curran- > gray@keysight.com] > Sent: Friday, August 19, 2016 1:58 PM > To: Shreyansh Jain ; users@dpdk.org > Subject: RE: segfault with dpdk 16.07 in rte_mempool_populate_phys >=20 > Hi Shreyansh, >=20 > Thanks for your reply, >=20 > Hmmm, I had wondered if the debug output from 16.7 was reduced compared t= o > 2.2.0, but perhaps this is what I should have been concentrating on, rath= er > than the core later >=20 >=20 > On a vm running our app using 2.2.0 at startup, I see: >=20 > dpdk: In dpdk_init_eal core_mask is 79, master_core_id is 0 > EAL: Detected lcore 0 as core 0 on socket 0 > EAL: Detected lcore 1 as core 0 on socket 0 > EAL: Detected lcore 2 as core 0 on socket 0 > EAL: Detected lcore 3 as core 0 on socket 0 > EAL: Detected lcore 4 as core 0 on socket 0 > EAL: Detected lcore 5 as core 0 on socket 0 > EAL: Detected lcore 6 as core 0 on socket 0 > EAL: Support maximum 32 logical core(s) by configuration. > EAL: Detected 7 lcore(s) > EAL: Setting up physically contiguous memory... > EAL: Ask a virtual area of 0x40000000 bytes > EAL: Virtual area found at 0x7f2735600000 (size =3D 0x40000000) > EAL: Requesting 512 pages of size 2MB from socket 0 > EAL: TSC frequency is ~2094950 KHz > EAL: WARNING: cpu flags constant_tsc=3Dyes nonstop_tsc=3Dno -> using unre= liable > clock cycles ! > EAL: Master lcore 0 is ready (tid=3D9a11c720;cpuset=3D[0]) > EAL: Failed to set thread name for interrupt handling > EAL: Cannot set name for lcore thread > EAL: Cannot set name for lcore thread > EAL: Cannot set name for lcore thread > EAL: Cannot set name for lcore thread > EAL: lcore 4 is ready (tid=3D33ff7700;cpuset=3D[4]) > EAL: lcore 3 is ready (tid=3D349f8700;cpuset=3D[3]) > EAL: lcore 6 is ready (tid=3D32bf5700;cpuset=3D[6]) > EAL: lcore 5 is ready (tid=3D335f6700;cpuset=3D[5]) > EAL: PCI device 0000:00:07.0 on NUMA socket -1 > EAL: probe driver: 8086:1521 rte_igb_pmd > EAL: Not managed by a supported kernel driver, skipped > EAL: PCI device 0000:00:08.0 on NUMA socket -1 > EAL: probe driver: 8086:1572 rte_i40e_pmd > EAL: PCI memory mapped at 0x7f27319f5000 > EAL: PCI memory mapped at 0x7f279a33c000 > PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.02 eetrack 8000224e >=20 > However on my vm running our app but with 16.7 I see much less EAL output= , > the other stuff is printf output I put in the dpdk code to try and figure= out > where it was going wrong >=20 > dpdk: In dpdk_init_eal core_mask is 79, master_core_id is 0 > EAL: Detected 7 lcore(s) > EAL: WARNING: cpu flags constant_tsc=3Dyes nonstop_tsc=3Dno -> using unre= liable > clock cycles ! >=20 > dpdk_init_memory_pools position 1 > dpdk_init_memory_pools position 2 > dpdk_init_memory_pools position 3 >=20 > about to call ret_mempool_create >=20 > name Error Ind Mempool > number 8 > element size 256 > cache size 4 > private data size 4 > mp_init 1158173360 > mp_init_arg 0 > obj_init 1158173120 > obj_init_arg 0 > socket_id 4294967295 > flags 0 >=20 >=20 > at start of rte_mempool_create > at start of rte_mempool_populate_default > at start of rte_mempool_populate_phys >=20 >=20 > Is this just down to a change of the debug output from within the EAL , o= r is > something going fundamentally wrong. The number of messages (specially the lcore detection, etc) have definitely= been reduced across 16.07. >>From what I remember, Lcore detection, VFIO support and eventually applicat= ion specific log was what was getting printed. As soon as I have access to = a vanilla 16.07 app, I will post the output (on Host only). But, it seems f= ine to me as of now. >=20 > There is output about the individual detected lcores, there is no output > about the setting up physically contiguous memory.. etc Which is OK I think. Most of the INFO have been moved to DEBUG which is why= you won't see the 2.2.0 messages.=20 >=20 > However if my call to rte_eal_init hadn't worked, I shouldn't have to as= far > as trying to call rte_mempool_create >=20 > We check for a return of rte_eal_init of < 0 and if so, we rte_exit. >=20 > I'll have a look over the newer documentation for the debug output For the stack trace that you dumped in previous email, would it be possible= to recompile without the optimization flags and dump it again? It is possible that the core is hitting some path because of which clean ex= it is not happening. >=20 > Thanks >=20 > Martin >=20 - Shreyansh