Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

On Apr 3, 2018, at 11:27 AM, Michael S. Tsirkin wrote: I'm not sure why you would need a feature bit. The capability is controlled via PCI configuration space. If it is present the device has the capability. If it is not then it does not. Basically if the PCI configuration

Re: [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

On Mar 15, 2018, at 11:42 AM, Alexander Duyck wrote: > From: Alexander Duyck > > Hardware-realized virtio_pci devices can implement SR-IOV, so this > patch enables its use. The device in question is an upcoming Intel > NIC that implements

Re: [virtio-dev] [pci PATCH v7 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources

On Mar 15, 2018, at 11:41 AM, Alexander Duyck wrote: > From: Alexander Duyck > > This patch adds a common configuration function called > pci_sriov_configure_simple that will allow for managing VFs on devices > where the PF is not capable

Re: [RFC PATCH V3] virtio_pci: Add SR-IOV support

> On Feb 27, 2018, at 7:35 AM, David Miller wrote: > > I don't like these helpers on many different levels. > So kill off pci_sriov_enable() helper completely, it is unnecessary, > and rename the disable helper so that it says something meaningful to > the reader. Yes.

Re: [RFC PATCH V4] pci: virtio_pci: Add SR-IOV support for virtio_pci devices

Alex, > On Feb 26, 2018, at 7:26 AM, Alexander Duyck > wrote: > > Mark, > > In the future please don't put my "Reviewed-by" on a patch that I > haven't reviewed. I believe I reviewed one of the earlier patches, but > I hadn't reviewed this version. I'm very sorry.

Re: [RFC PATCH V2] virtio_pci: Add SR-IOV support

> On Feb 22, 2018, at 10:26 AM, Christoph Hellwig wrote: > > Can we move this into common code as a a generic_sriov_configure > helper? Nothing is really virtio specific, and it seems like > some other drivers could also use it, e.g. ena or nvme. That seems like a good idea

Re: [Intel-wired-lan] [next-queue 02/10] ixgbe: add ipsec register access routines

> On Dec 4, 2017, at 9:35 PM, Shannon Nelson wrote: > > Add a few routines to make access to the ipsec registers just a little > easier, and throw in the beginnings of an initialization. > > Signed-off-by: Shannon Nelson > --- >

Re: [PATCH net-next] tools: bpf: handle long path in jit disasm

> On Nov 2, 2017, at 1:09 AM, Prashant Bhole > wrote: > > Use PATH_MAX instead of hardcoded array size 256 > > Signed-off-by: Prashant Bhole > --- > tools/bpf/bpf_jit_disasm.c | 3 ++- > tools/bpf/bpftool/jit_disasm.c | 3

Re: [PATCH] tests: Remove bashisms (s/source/.)

> On Oct 8, 2017, at 7:39 AM, Petr Vorel wrote: > > diff --git a/testsuite/tests/ip/route/add_default_route.t > b/testsuite/tests/ip/route/add_default_route.t > index e5ea6473..0b566f1f 100755 > --- a/testsuite/tests/ip/route/add_default_route.t > +++

Re: netlink backwards compatibility in userspace tools

> On Sep 29, 2017, at 3:22 AM, Jason A. Donenfeld wrote: > > Hi guys, > > One handy aspect of Netlink is that it's backwards compatible. This > means that you can run old userspace utilities on new kernels, even if > the new kernel supports new features and netlink attributes.

Re: [PATCH V2] r8152: add Linksys USB3GIGV1 id

> On Sep 27, 2017, at 9:39 AM, Grant Grundler wrote: > > On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum wrote: >> Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson: >>> >>> I know that for at least some of the adapters in the CDC Ethernet

Re: [PATCH V4 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

> On Jul 23, 2017, at 10:05 AM, Florian Fainelli wrote: >> + >> +strncpy(drvinfo->version, HNAE_DRIVER_VERSION, >> +sizeof(drvinfo->version)); >> +drvinfo->version[sizeof(drvinfo->version) - 1] = '\0'; > > strlcpy() would probably do that for you. You

Re: [PATCH] x86-32: fix tlb flushing when lguest clears PGE

On Mar 12, 2017, at 7:02 PM, Kees Cook wrote: > Are there nominations for most comprehensive changelog of the year? :) > This is awesome. Especially for a one-liner! Truly comprehensive and completely relevant. -- Mark Rustad, Networking Division, Intel Corporation

Re: [Intel-wired-lan] [PATCH 1/1] ixgbe: fcoe: return value of skb_linearize should be handled

Zhouyi Zhou wrote: diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index fee1f29..4926d48 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -2173,8

Re: [Intel-wired-lan] [net-next PATCH v3 2/3] e1000: add initial XDP support

Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: On Tue, Sep 13, 2016 at 10:41:12PM +, Rustad, Mark D wrote: That said, I can see that you have tried to keep the original code path pretty much intact. I would note that you introduced rcu calls into the !bpf path that would

Re: [Intel-wired-lan] [net-next PATCH v3 2/3] e1000: add initial XDP support

Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: On Tue, Sep 13, 2016 at 07:14:27PM +, Rustad, Mark D wrote: Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: On Tue, Sep 13, 2016 at 06:28:03PM +0000, Rustad, Mark D wrote: Alexei Starovoitov <alexei.starov

Re: [PATCH v3] net: ip, diag -- Add diag interface for raw sockets

Greg wrote: Someday Linux will be a modern OS that just includes IPV6 and forces a config option to NOT have it. That'll be great. All the IS_ENABLED_(CONFIG_IPV6) scattered everywhere is nuts. Better wait until everyone at least *has* IPv6! I have yet to have IPv6

Re: [Intel-wired-lan] [net-next PATCH v3 2/3] e1000: add initial XDP support

Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: On Tue, Sep 13, 2016 at 06:28:03PM +, Rustad, Mark D wrote: Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: I've looked through qemu and it appears only emulate e1k and tg3. The latter is still used in t

Re: [Intel-wired-lan] [net-next PATCH v3 2/3] e1000: add initial XDP support

Alexei Starovoitov wrote: I've looked through qemu and it appears only emulate e1k and tg3. The latter is still used in the field, so the risk of touching it is higher. I have no idea what makes you think that e1k is *not* "used in the field". I grant you it

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

Benjamin Herrenschmidt wrote: Filtering things to work around bugs in existing guests to avoid crashes is a different kettle of fish and could be justified but keep in mind that in most cases a malicious guest will be able to exploit those HW flaws. Bugs in existing

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

Benjamin Herrenschmidt wrote: We may want some kind of "strict" vs. "relaxed" model here to differenciate the desktop user wanting to give a function to his/her windows partition and doesn't care about strict isolation vs. the cloud data center. I don't think

Re: [Intel-wired-lan] [PATCH net] e1000e: fix PTP on e1000_pch_lpt variants

Jarod Wilson wrote: I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used as a PTP slave experiences random ~10 hour clock jumps, which are resolved if the same workaround for the 82574 and 82583 is employed. Switching from an if to a select, because the

Re: [PATCH] (resend) ixgbe: always initialize setup_fc

Patrick McLean wrote: Gmail mangled my first message, sorry about that. Second attempt. In ixgbe_init_mac_link_ops_X550em, the code has a special case for backplane media type, but does not fall through to the default case, so the setup_fc never gets initialized. This

Re: [Intel-wired-lan] [PATCH] e1000e: prevent division by zero if TIMINCA is zero

Denys Vlasenko wrote: Users report that under VMWare, er32(TIMINCA) returns zero. This causes division by zero at init time as follows: ==>incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK; for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS;

Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

KY Srinivasan <k...@microsoft.com> wrote: -Original Message- From: Rustad, Mark D [mailto:mark.d.rus...@intel.com] Sent: Thursday, April 14, 2016 5:07 PM To: KY Srinivasan <k...@microsoft.com> Cc: David Miller <da...@davemloft.net>; netdev <netdev@vger.k

Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

KY Srinivasan <k...@microsoft.com> wrote: -Original Message- From: Rustad, Mark D [mailto:mark.d.rus...@intel.com] Sent: Thursday, April 14, 2016 4:01 PM To: KY Srinivasan <k...@microsoft.com> Cc: David Miller <da...@davemloft.net>; netdev <netdev@vger.k

Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

Some comments below: K. Y. Srinivasan wrote: On Hyper-V, the VF/PF communication is a via software mediated path as opposed to the hardware mailbox. Make the necessary adjustments to support Hyper-V. Signed-off-by: K. Y. Srinivasan ---

Re: [PATCH] mwifiex: fix possible NULL dereference

Andy Shevchenko wrote: On Mon, Apr 11, 2016 at 6:27 PM, Sudip Mukherjee wrote: From: Sudip Mukherjee We have a check for card just after dereferencing it. So if it is NULL we have already dereferenced

Re: [net-next PATCH v3 6/8] net: ixgbe: add minimal parser details for ixgbe

John Fastabend wrote: diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_model.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_model.h new file mode 100644 index 000..43ebec4 --- /dev/null +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_model.h @@ -0,0 +1,112 @@

Re: [Intel-wired-lan] [PATCH net-next V2 4/6] igb: call ndo_stop() instead of dev_close() when running offline selftest

Aaron F wrote: From: Intel-wired-lan [intel-wired-lan-boun...@lists.osuosl.org] on behalf of Stefan Assmann [sassm...@kpanic.de] Sent: Wednesday, February 03, 2016 12:20 AM To: intel-wired-...@lists.osuosl.org Cc: netdev@vger.kernel.org; da...@davemloft.net;

Re: [Intel-wired-lan] [PATCH net-next V2 5/6] e1000: call ndo_stop() instead of dev_close() when running offline selftest

Aaron F wrote: From: Intel-wired-lan [intel-wired-lan-boun...@lists.osuosl.org] on behalf of Stefan Assmann [sassm...@kpanic.de] Sent: Wednesday, February 03, 2016 12:20 AM To: intel-wired-...@lists.osuosl.org Cc: netdev@vger.kernel.org; da...@davemloft.net;

Re: [PATCH V2 5/5] net: can: ifi: Add IFI CANFD IP support

Marek Vasut wrote: I see, so adding u32 also here works. I'm starting to wonder if the BIT macro is really that nice and if I shouldn't just use (1 << n) as usual. Actually, (1 << n) is not so good either when n is 31 - it can trigger overflow warnings since it will be

Re: [PATCH net-next 6/8] net: gre: Implement LCO for GRE over IPv4

Alexander Duyck wrote: Actually you may want to go the other way on that. If they weren't flipping the checksum value for GRE before why should we start doing that now? I'm pretty sure the checksum mangling is a very UDP centric thing. There is no need to

Re: [PATCH net-next 6/8] net: gre: Implement LCO for GRE over IPv4

Alexander Duyck wrote: There isn't any need to add such an indication, nor do we need to start bitflipping the return value from csum_fold in all cases. I think there was just some confusion about UDP checksums vs GRE or TCP checksums. Yeah. I think I finally got

Re: [PATCH 3/3] ixgbe: synchronize the link_speed and link_up of a slave interface

zyjzyj2...@gmail.com wrote: > From: Zhu Yanjun <yanjun@windriver.com> > > According to the suggestion from Rustad, Mark D, this behavior perhaps > is more related to the copper phy. But to make fiber phy more robust, > to all the interfaces as a slave interface, the l

Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed

Emil S wrote: >> */ >> -if (hw->mac.type == ixgbe_mac_X540) >> +if ((hw->mac.type == ixgbe_mac_X540) && >> +(netdev->flags & IFF_SLAVE)) >> if (link_speed == IXGBE_LINK_SPEED_UNKNOWN) >> return; > > If you were to

Re: [PATCH v5 4/4] net: diag: Support destroying TCP socketsr

Maciej Żenczykowski wrote: > I'd tend to agree that reset or abort would be preferable to destroy. > After all... the socket doesn't actually go away. Or maybe terminate? Reset kind of implies to me that it may resume operation. Abort could be ok. I think terminate is

Re: Checksum offload queries

Edward Cree wrote: > I have just realised something startling. Assuming the inner protocol uses > the ones complement checksum in the way IP, UDP and TCP do, the outer > checksum can be computed *without looking at the payload*. Why? Because the > ones complement sum

Re: [BUG] net: performance regression on ixgbe (Intel 82599EB 10-Gigabit NIC)

Otto Sabart wrote: > I probably found a performance regression on ixgbe (Intel 82599EB > 10-Gigabit NIC) on v4.4-rc3. I am able to see this problem since > v4.4-rc1. > > The bug report you can find here [0]. > > Can somebody take a look at it? > > [0]

Re: [net-next 13/15] ixgbe: Handle extended IPv6 headers in tx path

Alexander Duyck wrote: > This doesn't look right. How come this doesn't match the implementation you > did for the ixgbevf driver? If I am not mistaken this approach had issues > where it could spin forever didn't it? Yes, this is the original version of the patch

Re: [net-next 06/16] i40e: Properly cast type for arithmetic

Joe Perches wrote: > On Wed, 2015-11-25 at 02:46 -0800, Jeff Kirsher wrote: >> On Tue, 2015-11-24 at 16:43 -0800, Joe Perches wrote: >>> On Tue, 2015-11-24 at 16:04 -0800, Jeff Kirsher wrote: From: Helin Zhang Pointer of type void *

Re: [PATCH 13/15] ixgbe: Convert to advertise NETIF_F_HW_CSUM

Tom Herbert wrote: > The skb_csum_offload_chk is used to resolve checksums that are unable > to be offloaded to the device. > > Signed-off-by: Tom Herbert > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 41 +++ > 1 file

Re: [Intel-wired-lan] regression in ixgbe SFP detection patch

William, Emil S wrote: >> It also fixes my issue: even if eth{2,3} are still up with no carrier, I >> don't have any kworker in D state. > > It appears that you have 2 ports with empty cages. If that is the case there > is no reason to keep the interfaces up. If you

Re: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_setup_tc

Nicholas Krause wrote: > This fixes error handling in the function fm10k_setup_tc to properly > check if the call to the function fm10k_open has failed by returning > a error and if so return immediately to the caller of the function > fm10k_setup_tc to properly signal this

Re: [patch net-next v2 06/13] rocker: introduce worlds infrastructure

Jiri Pirko wrote: >>> + int (*port_init)(struct rocker_port *rocker_port, void *priv, >>> +void *port_priv); >> >> Yuck, void *. Can we do better? > > I see nothing wrong with this priv usage. It's done like this on many > places. I think it is

Re: [RFC PATCH] Fix false positives in can_checksum_protocol()

> On Oct 5, 2015, at 9:23 AM, Tom Herbert wrote: > > 4) To help drivers for devices with limited offload capabilities we'll > define a helper function to check for typical restrictions (.e.g. IPv4 > only, TCP/UDP only. no encapsulation, no IPv6 extension headers, > etc.). I

Re: [PATCH net 3/7] openvswitch: Fix skb leak in ovs_fragment()

> On Sep 29, 2015, at 3:39 PM, Joe Stringer wrote: > > @@ -728,8 +727,14 @@ static void ovs_fragment(struct vport *vport, struct > sk_buff *skb, u16 mru, > WARN_ONCE(1, "Failed fragment ->%s: eth=%04x, MRU=%d, MTU=%d.", >

Re: [PATCH V4 1/2] pci: Add dev_flags bit to access VPD through function 0

> On Sep 15, 2015, at 2:17 PM, Alex Williamson > wrote: > > Also, rather than clearing the flag, can we move the tests done by > pci_vpd_f0_dev_check() into the > quirk setup function? It seems like function 0 should be sufficiently > configured by the time we're

Re: [PATCH V4 1/2] pci: Add dev_flags bit to access VPD through function 0

> On Sep 15, 2015, at 11:19 AM, Alex Williamson > wrote: > > In addition to the (PCI_SLOT() != devfn) issue, I'm concerned about > topologies like we see on Skylake. IIRC, the integrated NIC appears at > something like 00:1f.6. I don't know if that specific NIC has

Re: [PATCH V4 1/2] pci: Add dev_flags bit to access VPD through function 0

> On Sep 15, 2015, at 12:04 PM, Alex Williamson > wrote: > > > FRU-type information is only one of the use cases of VPD, the spec also > defines (PCI rev 3.0, 6.4): > >... a mechanism for storing information such as performance and >failure data on

Re: [PATCH] igb: don't unmap hw_addr if its NULL

> On Sep 9, 2015, at 9:07 PM, Jarod Wilson wrote: > > diff --git a/drivers/net/ethernet/intel/igb/igb_main.c > b/drivers/net/ethernet/intel/igb/igb_main.c > index e174fbb..a5e0022 100644 > --- a/drivers/net/ethernet/intel/igb/igb_main.c > +++

Re: [GIT] Networking

> On Sep 7, 2015, at 4:02 AM, David Laight wrote: > > Feed: > int bar(int (*f)[10]) { return sizeof *f; } > into cc -O2 -S and look at the generated code - returns 40 not 4. Yes, indeed it does. And with clang too. I guess I was too easily discouraged when looking for

Re: [GIT] Networking

> On Sep 4, 2015, at 2:07 AM, David Laight wrote: > >> I find them useful as syntactic sugar. We have not used them a lot, but >> there are cases in our crypto >> handling code where we have fixed size array inputs/outputs and there we >> opted to use them. They make

Re: [net-next 05/19] ixgbe: Add support for UDP-encapsulated tx checksum offload

> On Sep 1, 2015, at 8:17 PM, Tom Herbert wrote: > > I suspect this is not UDP-encapsulation specific, will it work with > TCP/IP/IP, TCP/IP/GRE etc.? It could do more, but this is what has been tested up to this point. > Isn't there anyway the ixgbe could just be made to

Re: [net-next 05/19] ixgbe: Add support for UDP-encapsulated tx checksum offload

> On Sep 2, 2015, at 4:21 PM, Tom Herbert wrote: > > Mark, another question in this area of code. Looking at ixgbe_tx_csum, > I'm wondering what happens with those default cases for the switch > statements. If those are hit for whatever reason does that mean the > checksum

Re: [PATCH net-next 09/13] vxlan: provide access function for vxlan socket address family

On Aug 18, 2015, at 1:33 PM, Jiri Benc jb...@redhat.com wrote: Signed-off-by: Jiri Benc jb...@redhat.com --- drivers/net/vxlan.c | 8 include/net/vxlan.h | 5 + 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index

Re: [patch net-next 0/4] Introduce Mellanox Technologies Switch ASICs switchdev drivers

On Jul 23, 2015, at 5:03 PM, Scott Feldman sfel...@gmail.com wrote: On the CHECKs on space after cast, should we modify checkpatch.pl to not flag those for drivers/net? Please don't. My internal parser really wants to see the cast right up against whatever it is casting. Has this practice

Re: ss -p segfaults

On Jul 15, 2015, at 8:12 AM, Vadim Kochan vadi...@gmail.com wrote: Would you please check this fix ? diff --git a/misc/ss.c b/misc/ss.c index 03f92fa..3a826e4 100644 --- a/misc/ss.c +++ b/misc/ss.c @@ -683,8 +683,8 @@ static inline void sock_addr_set_str(inet_prefix *prefix, char **ptr)

Re: ss -p segfaults

On Jul 15, 2015, at 9:49 AM, Rustad, Mark D mark.d.rus...@intel.com wrote: On Jul 15, 2015, at 8:12 AM, Vadim Kochan vadi...@gmail.com wrote: Would you please check this fix ? diff --git a/misc/ss.c b/misc/ss.c index 03f92fa..3a826e4 100644 --- a/misc/ss.c +++ b/misc/ss.c @@ -683,8

Re: [Intel-wired-lan] [PATCH V3 0/2] pci: Provide a flag to access VPD through function 0

On Jun 26, 2015, at 11:04 AM, Rustad, Mark D mark.d.rus...@intel.com wrote: Sorry, Mark, I've just been busy with other issues and haven't had a chance to look at this yet. Is there any chance of this getting into this merge window? Well, it has missed the merge window, but this really

Re: [PATCH V3 0/2] pci: Provide a flag to access VPD through function 0

On Jun 17, 2015, at 9:44 AM, Bjorn Helgaas bhelg...@google.com wrote: On Wed, Jun 17, 2015 at 11:29 AM, Rustad, Mark D mark.d.rus...@intel.com wrote: + Alex On Jun 5, 2015, at 2:59 PM, Rustad, Mark D mark.d.rus...@intel.com wrote: On Jun 3, 2015, at 11:46 AM, Mark D Rustad mark.d.rus

Re: [PATCH V3 0/2] pci: Provide a flag to access VPD through function 0

+ Alex On Jun 5, 2015, at 2:59 PM, Rustad, Mark D mark.d.rus...@intel.com wrote: On Jun 3, 2015, at 11:46 AM, Mark D Rustad mark.d.rus...@intel.com wrote: Many multi-function devices provide shared registers in extended config space for accessing VPD. The behavior of these registers

Re: [PATCH V3 0/2] pci: Provide a flag to access VPD through function 0

On Jun 3, 2015, at 11:46 AM, Mark D Rustad mark.d.rus...@intel.com wrote: Many multi-function devices provide shared registers in extended config space for accessing VPD. The behavior of these registers means that the state must be tracked and access locked correctly for accesses not to

Re: [Intel-wired-lan] [PATCH V2 1/2] pci: Add dev_flags bit to access VPD through function 0

On Jun 2, 2015, at 7:28 PM, Alexander Duyck alexander.du...@gmail.com wrote: You can probably combine the dev-multifunction check with the dev_flags check. After all you don't need this workaround if the device is not multifunction. It might even make more sense to move the multifunction

Re: [Intel-wired-lan] [PATCH 1/2] pci: Add dev_flags bit to access VPD through function 0

On Jun 2, 2015, at 10:48 AM, Alexander Duyck alexander.h.du...@redhat.com wrote: I'm pretty sure these could cause some serious errors if you direct assign the device into a VM since you then end up with multiple devices sharing a bus. Also it would likely have side-effects on a LOM

Re: [PATCH] pci: Use a bus-global mutex to protect VPD operations

On May 27, 2015, at 10:27 AM, Bjorn Helgaas bhelg...@google.com wrote: It sounds like there are real problems here that would be fixed by changing the mutex strategy and limiting VPD read lengths, but that we don't quite have consensus on how to solve them yet. I have a new pair of patches

Re: [Intel-wired-lan] [PATCH] pci: Use a bus-global mutex to protect VPD operations

On May 19, 2015, at 6:02 PM, Alexander Duyck alexander.h.du...@redhat.com wrote: My suspicion is that we have a number of bugs floating around out there like the Broadcom issue. Specifically, one of the ones I found was that the r8169 seems to have a similar issue as called out in the

Re: [Intel-wired-lan] [PATCH] pci: Limit VPD reads for all Intel Ethernet devices

On May 19, 2015, at 10:50 AM, Alexander Duyck alexander.h.du...@redhat.com wrote: These two patches are very much related. They are only related because I saw an opportunity to do this while working on the other issue. That is the only relationship. snip material on the other patch

Re: [Intel-wired-lan] [PATCH] pci: Limit VPD reads for all Intel Ethernet devices

On May 19, 2015, at 2:17 PM, Alexander Duyck alexander.du...@gmail.com wrote: Any chance you could point me toward the software in question? Just wondering because it seems like what you are fixing with this is an implementation issue in the application since you really shouldn't be