From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id B50A32BA0 for ; Sat, 2 Jul 2016 02:12:53 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 01 Jul 2016 17:12:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,559,1459839600"; d="scan'208";a="838962132" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga003.jf.intel.com with ESMTP; 01 Jul 2016 17:12:51 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.125]) by irsmsx105.ger.corp.intel.com ([169.254.7.51]) with mapi id 14.03.0248.002; Sat, 2 Jul 2016 01:12:50 +0100 From: "De Lara Guarch, Pablo" To: "Yigit, Ferruh" , "Mcnamara, John" , "dev@dpdk.org" CC: Stephen Hemminger Thread-Topic: [dpdk-dev] Issue with igb_uio in Fedora 24 Thread-Index: AdHTgeu4MrDIw6CuTEWVm8rIPsmOS///+PiA//8Qh0A= Date: Sat, 2 Jul 2016 00:12:50 +0000 Message-ID: References: <57764BA3.5030903@intel.com> In-Reply-To: <57764BA3.5030903@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTUwMTY2YWYtNWM3Ni00ZjY5LTljYTYtODUxYWI0YzZmYmQ2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IklRTHJqMWFqZ1UzMkJERlJvc1l5M2NSb1AyMjRJUGtCYldyQko5ZDZzd1U9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Issue with igb_uio in Fedora 24 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: Sat, 02 Jul 2016 00:12:54 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit > Sent: Friday, July 01, 2016 11:53 AM > To: Mcnamara, John; dev@dpdk.org > Cc: De Lara Guarch, Pablo; Stephen Hemminger > Subject: Re: [dpdk-dev] Issue with igb_uio in Fedora 24 >=20 > On 7/1/2016 11:21 AM, Mcnamara, John wrote: > > Hi, > > > > We have seen an issue when using the igb_uio module in Fedora > > 24. However, it relates to kernel 4.5+ so it could occur in other > > distros/oses. > > > > The issue occurs after binding a nic to igb_uio: > > > > # ./tools/dpdk_nic_bind.py -b igb_uio 0000:03:00.0 > > # ./x86_64-native-linuxapp-gcc/app/test > > > > EAL: Detected 8 lcore(s) > > EAL: Probing VFIO support... > > PMD: bnxt_rte_pmd_init() called for (null) > > EAL: PCI device 0000:03:00.0 on NUMA socket -1 > > EAL: probe driver: 8086:1533 rte_igb_pmd > > EAL: pci_map_resource(): > > cannot mmap(39, 0x7f1c51800000, 0x100000, 0x0): > > Invalid argument (0xffffffffffffffff) > > EAL: Error - exiting with code: 1 > > Cause: Requested device 0000:03:00.0 cannot be used > > > > The issue is exposed when the kernel is compiled with option > > CONFIG_IO_STRICT_DEVMEM turned on. > > > > This option is new from kernel 4.5 and is on by default in Fedora 24: > > > > config IO_STRICT_DEVMEM > > bool "Filter I/O access to /dev/mem" > > depends on STRICT_DEVMEM > > ---help--- > > > > If this option is disabled, you allow userspace (root) access > > to all io-memory regardless of whether a driver is actively > > using that range. Accidental access to this is obviously > > disastrous, but specific access can be used by people > > debugging kernel drivers. > > > > If this option is switched on, the /dev/mem file only allows > > userspace access to *idle* io-memory ranges (see /proc/iomem) > > This may break traditional users of /dev/mem (dosemu, legacy > > X, etc...) if the driver using a given range cannot be > > disabled. > > > > If in doubt, say Y. > > > > This issue doesn't occur with uio_pci_generic. > > > > John > > >=20 >=20 > Thanks for Pablo figuring out the details, and related config option, > otherwise I was digging same issue without success. >=20 > Disabling following code in igb_uio makes it work again: > "pci_request_regions(dev, "igb_uio");" >=20 > This call adds device bars as active resources, and with above config > option mmap fails for those addresses. >=20 > uio_pci_generic already doesn't have this call, and I can send a patch > to remove this from igb_uio. >=20 > BUT, I don't know why that call added at first place and concerned about > any corner case that requires this call. > Anybody out has/knows a reason to keep this call? >=20 > Thanks, > ferruh >=20 >=20 Another workaround to make this work is setting "iomem=3Drelaxed" in the ke= rnel parameters, to avoid recompiling the kernel with IO_STRICT_DEVMEM disabled. Thanks, Pablo