From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>,
"Mcnamara, John" <john.mcnamara@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [dpdk-dev] Issue with igb_uio in Fedora 24
Date: Sat, 2 Jul 2016 00:12:50 +0000 [thread overview]
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D8973C984D77@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <57764BA3.5030903@intel.com>
> -----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
>
> 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
> >
>
>
> Thanks for Pablo figuring out the details, and related config option,
> otherwise I was digging same issue without success.
>
> Disabling following code in igb_uio makes it work again:
> "pci_request_regions(dev, "igb_uio");"
>
> This call adds device bars as active resources, and with above config
> option mmap fails for those addresses.
>
> uio_pci_generic already doesn't have this call, and I can send a patch
> to remove this from igb_uio.
>
> 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?
>
> Thanks,
> ferruh
>
>
Another workaround to make this work is setting "iomem=relaxed" in the kernel parameters,
to avoid recompiling the kernel with IO_STRICT_DEVMEM disabled.
Thanks,
Pablo
prev parent reply other threads:[~2016-07-02 0:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-01 10:21 Mcnamara, John
2016-07-01 10:53 ` Ferruh Yigit
2016-07-01 11:35 ` [dpdk-dev] [PATCH] igb_uio: fix mmap failure Ferruh Yigit
2016-07-01 12:47 ` Thomas Monjalon
2016-07-01 14:39 ` Ferruh Yigit
2016-07-01 14:54 ` Thomas Monjalon
2016-07-01 15:07 ` [dpdk-dev] [PATCH v2] igb_uio: fix possible mmap failure for Linux > v4.3 Ferruh Yigit
2016-07-01 15:52 ` De Lara Guarch, Pablo
2016-07-01 15:54 ` Ferruh Yigit
2016-07-01 15:59 ` [dpdk-dev] [PATCH v3] igb_uio: fix possible mmap failure for Linux >= v4.5 Ferruh Yigit
2016-07-05 15:00 ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
2016-07-10 13:58 ` Thomas Monjalon
2016-07-02 0:12 ` De Lara Guarch, Pablo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E115CCD9D858EF4F90C690B0DCB4D8973C984D77@IRSMSX108.ger.corp.intel.com \
--to=pablo.de.lara.guarch@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=john.mcnamara@intel.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).