* RE: 82571EB: Detected Hardware Unit Hang
From: Dave, Tushar N @ 2012-11-08 20:35 UTC (permalink / raw)
To: Joe Jin, e1000-devel@lists.sf.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Mary Mcgrath
In-Reply-To: <509B5038.8090304@oracle.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of Joe Jin
>Sent: Wednesday, November 07, 2012 10:25 PM
>To: e1000-devel@lists.sf.net
>Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Mary Mcgrath
>Subject: 82571EB: Detected Hardware Unit Hang
>
>Hi list,
>
>IHAC reported "82571EB Detected Hardware Unit Hang" on HP ProLiant DL360
>G6, and have to reboot the server to recover:
>
>e1000e 0000:06:00.1: eth3: Detected Hardware Unit Hang:
> TDH <1a>
> TDT <1a>
> next_to_use <1a>
> next_to_clean <18>
>buffer_info[next_to_clean]:
> time_stamp <10047a74e>
> next_to_watch <18>
> jiffies <10047a88c>
> next_to_watch.status <1>
>MAC Status <80383>
>PHY Status <792d>
>PHY 1000BASE-T Status <3800>
>PHY Extended Status <3000>
>PCI Status <10>
>
>With newer kernel 2.0.0.1 the issue still reproducible.
>
>Device info:
>06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>Controller (Copper) (rev 06)
>06:00.1 0200: 8086:10bc (rev 06)
>
>I compared lspci output before and after the issue, different as below:
> 06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>Controller (Copper) (rev 06)
> Subsystem: Hewlett-Packard Company NC364T PCI Express Quad Port
>Gigabit Server Adapter
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
>Stepping- SERR- FastB2B- DisINTx-
>- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
><TAbort- <MAbort- >SERR- <PERR- INTx-
>+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>+<TAbort- <MAbort- >SERR- <PERR- INTx+
Are you sure this is not similar issue as before that you reported.
i.e.
On Mon, 2012-07-09 at 16:51 +0800, Joe Jin wrote:
> I'm seeing a Unit Hang even with the latest e1000e driver 2.0.0 when
> doing scp test. this issue is easy do reproduced on SUN FIRE X2270 M2,
> just copy a big file (>500M) from another server will hit it at once.
All devices in path from root complex to 82571, should have *same* max payload size otherwise it can cause hang.
Can you double check this?
-Tushar
^ permalink raw reply
* [PATCH] vmxnet3: convert BUG_ON(true) into a simple BUG()
From: Sasha Levin @ 2012-11-08 20:23 UTC (permalink / raw)
To: linux-kernel; +Cc: Sasha Levin, Shreyas Bhatewara, VMware, Inc., netdev
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 0ae1bcc..7e9622f 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -1922,7 +1922,7 @@ vmxnet3_free_irqs(struct vmxnet3_adapter *adapter)
free_irq(adapter->pdev->irq, adapter->netdev);
break;
default:
- BUG_ON(true);
+ BUG();
}
}
--
1.7.10.4
^ permalink raw reply related
* essentially offline...
From: David Miller @ 2012-11-08 20:09 UTC (permalink / raw)
To: netdev; +Cc: netfilter-devel, linux-wireless
Once again I am without any real internet access both at home (Time
Warner major Manhattan outage since this morning) and at the office
(Verizon still largely out in Lower Manhattan).
So I'm not going to be resonsive until one of these two outages are
resolved. I cannot even call Time Warner customer support, I get "all
circuits are busy" so they're obviously getting bombed with calls.
Want to help? There are two ways:
1) Don't do anything that makes more overhead for me.
Don't ask about patch status, that's what the heck patchwork
is for. If you're patch isn't there and active and you think
it needs to bee considered seriously, REPOST it, DON'T ASK ME
about a patch I already moved out of my TODO list. That's more
work for me.
And, this should go without saying %100 of the time, DO NOT
send me private email. It is never appropriate, I don't care
what excuse you come up with. Just simply don't do it.
2) Don't be a jackass and avoid reviewing patches that you can
actually provide feedback on.
That is what makes my backlog something that is actually
manageable, when everyone else dutifully reviews patches that get
posted so that I have something to immediately work against when I
get to reviewing that patch myself.
One great example is the gianfar patch posted the other day.
Nobody is going to review that and I know absolutely nothing
about gianfar hardware, whether that is the correct fix, etc.
So it'll either just rot there, or I'll have to guess if it's
correct.
But this is exactly what breaks down my productivity, when
people who are knowledgable don't review patches like that one.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name
From: David Miller @ 2012-11-08 20:02 UTC (permalink / raw)
To: brian.haley; +Cc: bhutchings, xemul, eric.dumazet, netdev
In-Reply-To: <509BD162.1000205@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Thu, 08 Nov 2012 08:36:02 -0700
> I noticed this isn't in patchwork anymore.
I want all the races resolved, and in any event the thing to do
when something isn't in patchwork IS TO RESUBMIT IT!
Every time you ask me stuff like this you take up more of my already
low amount of time.
Today I'm again without internet access other than my cell phone, so
everything you can do TO REDUCE my overhead would be greatly
appreciated.
^ permalink raw reply
* Re: [PATCH] qmi_wwan/cdc_ether: add Dell Wireless 5800 (Novatel E362) USB IDs
From: Bjørn Mork @ 2012-11-08 20:00 UTC (permalink / raw)
To: Dan Williams; +Cc: Aleksander Morgado, netdev, linux-usb
In-Reply-To: <1352398471.22225.18.camel@dcbw.foobar.com>
Dan Williams <dcbw@redhat.com> writes:
> The Dell Wireless 5800 appears to be a Novatel E362 rebrand.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
> Cc: stable@vger.kernel.org
Acked-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* [PATCH net-next] ipip: add GSO support
From: Eric Dumazet @ 2012-11-08 19:59 UTC (permalink / raw)
To: David Miller
Cc: netdev, Maciej Żenczykowski, Tom Herbert, Willem de Bruijn
From: Eric Dumazet <edumazet@google.com>
In commit 6b78f16e4b (gre: add GSO support) we added GSO support to GRE
tunnels.
This patch does the same for IPIP tunnels.
Performance of single TCP flow over an IPIP tunnel is increased by 40%
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Willem de Bruijn <willemb@google.com>
---
net/ipv4/ipip.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index e15b452..cc49cc1 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -479,6 +479,10 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
if (skb->protocol != htons(ETH_P_IP))
goto tx_error;
+ if (skb->ip_summed == CHECKSUM_PARTIAL &&
+ skb_checksum_help(skb))
+ goto tx_error;
+
if (tos & 1)
tos = old_iph->tos;
@@ -773,6 +777,11 @@ static void ipip_dev_free(struct net_device *dev)
free_netdev(dev);
}
+#define IPIP_FEATURES (NETIF_F_SG | \
+ NETIF_F_FRAGLIST | \
+ NETIF_F_HIGHDMA | \
+ NETIF_F_HW_CSUM)
+
static void ipip_tunnel_setup(struct net_device *dev)
{
dev->netdev_ops = &ipip_netdev_ops;
@@ -787,6 +796,9 @@ static void ipip_tunnel_setup(struct net_device *dev)
dev->features |= NETIF_F_NETNS_LOCAL;
dev->features |= NETIF_F_LLTX;
dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
+
+ dev->features |= IPIP_FEATURES;
+ dev->hw_features |= IPIP_FEATURES;
}
static int ipip_tunnel_init(struct net_device *dev)
^ permalink raw reply related
* Re: [PATCH] ipv6: fix two typos in a comment in xfrm6_init()
From: David Miller @ 2012-11-08 19:59 UTC (permalink / raw)
To: steffen.klassert; +Cc: roy.qing.li, netdev
In-Reply-To: <20121108141936.GC22290@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 8 Nov 2012 15:19:36 +0100
> On Thu, Nov 08, 2012 at 04:38:08PM +0800, roy.qing.li@gmail.com wrote:
>> From: Li RongQing <roy.qing.li@gmail.com>
>>
>> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
>> ---
>> net/ipv6/xfrm6_policy.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
>> index f3ed8ca..93832e8 100644
>> --- a/net/ipv6/xfrm6_policy.c
>> +++ b/net/ipv6/xfrm6_policy.c
>> @@ -332,10 +332,10 @@ int __init xfrm6_init(void)
>> /*
>> * We need a good default value for the xfrm6 gc threshold.
>> * In ipv4 we set it to the route hash table size * 8, which
>> - * is half the size of the maximaum route cache for ipv4. It
>> + * is half the size of the maximum route cache for ipv4.
>
> The routing cache is removed, so this comment is obsolete. But it reminds
> me that we set the gc threshold to ip_rt_max_size/2 in ipv4. With the
> routing cache removal patch, ip_rt_max_size was set to INT_MAX. So the gc
> starts to remove entries when a threshold of INT_MAX/2 is reached.
>
> cat /proc/sys/net/ipv4/xfrm4_gc_thresh
> 1073741823
>
> I guess this was not intentional.
Do you mean for IPSEC routes? For non-IPSEC routes on ipv4 there
is nothing to garbage collect.
^ permalink raw reply
* Re: [PATCH v2 0/2] Fix CDC_EEM with 802.1Q VLAN and 1500 MTU
From: David Miller @ 2012-11-08 19:58 UTC (permalink / raw)
To: balbi-l0cyMroinI0
Cc: iancoolidge-Re5JQEeQqe8AvxtiuMwx3w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20121108133736.GA19533-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
From: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
Date: Thu, 8 Nov 2012 15:37:36 +0200
> Hi,
>
> On Wed, Nov 07, 2012 at 09:27:52PM -0500, David Miller wrote:
>> From: Ian Coolidge <iancoolidge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date: Wed, 7 Nov 2012 16:39:17 -0800
>>
>> > cdc_eem USB host driver and gadget driver both are broken in 1500 MTU
>> > case while using 802.1Q VLANs. In both cases, this is due to the
>> > assumption of standard Ethernet frame length.
>> >
>> > v2: rebase against Dave Miller's 'net/master' tree
>> >
>> > Ian Coolidge (2):
>> > usb: gadget: g_ether: fix frame size check for 802.1Q
>> > net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
>>
>> Applied, thanks.
>
> did you take both ?
Yes.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* question on netdev_completed_queue()
From: Oliver Neukum @ 2012-11-08 19:38 UTC (permalink / raw)
To: netdev
Hi,
is this function to be called whenever a driver is done with transmitting
data, whether the transmission be successful or not?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH] ethtool: Support et131x registers in -d
From: Ben Hutchings @ 2012-11-08 19:25 UTC (permalink / raw)
To: Mark Einon; +Cc: netdev
In-Reply-To: <1351634243-10265-1-git-send-email-mark.einon@gmail.com>
On Tue, 2012-10-30 at 21:57 +0000, Mark Einon wrote:
> The et131x register set contains useful details of RX/TX queues for
> the device. This dumps them with the -d option.
>
> Signed-off-by: Mark Einon <mark.einon@gmail.com>
Applied, thanks. However:
[...]
> --- /dev/null
> +++ b/et131x.c
> @@ -0,0 +1,120 @@
> +#include <stdio.h>
> +#include <string.h>
> +#include "internal.h"
> +
> +int et131x_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
> +{
> + u32 *reg = (u32 *)regs->data;
> +
> + fprintf(stdout, "PHY Registers\n");
[...]
In case you need to change the dump format later, it might be worth
adding a version check here. But if you're confident that you'll only
ever append to the dump format, this should be fine for now.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* HELLO !!!
From: William Lee Cheng @ 2012-11-08 15:53 UTC (permalink / raw)
Dear Friend,
Greetings to you, I have a business proposal for you that will be
beneficial to the both of us.This proposal has to do with funds transfer.
In confirmation of your acceptance,I would need you to provide me with
your full names, current house and mailing address,date of birth telephone
and fax numbers so as to be very confident that I am dealing with the
right person.(This is very important).
Once I have received confirmation from you with the required information,
I shall then send you further details about this transaction and how it
will be executed. I look forward to hearing from you soonest and hope that
this marks the beginning of a successful and long lasting business
relationship with you. My profound greetings to you and your family.
Best regards,
William Lee Cheng.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [PATCH net-next] netconsole: add oops_only module option
From: Randy Dunlap @ 2012-11-08 19:49 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David Miller
In-Reply-To: <1352382158-3928-1-git-send-email-amwang@redhat.com>
On 11/08/2012 05:42 AM, Cong Wang wrote:
> Some people wants to log only oops messages via netconsole,
> (this is also why netoops was invented)
> so add a module option for netconsole. This can be tuned
> via /sys/module/netconsole/parameters/oops_only at run time
> as well.
>
Hi,
What does this do with panics?
Do they set oops_in_progress?
thanks.
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
>
> ---
> diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> index b332112..6989ebe 100644
> --- a/drivers/net/netconsole.c
> +++ b/drivers/net/netconsole.c
> @@ -56,6 +56,10 @@ static char config[MAX_PARAM_LENGTH];
> module_param_string(netconsole, config, MAX_PARAM_LENGTH, 0);
> MODULE_PARM_DESC(netconsole, " netconsole=[src-port]@[src-ip]/[dev],[tgt-port]@<tgt-ip>/[tgt-macaddr]");
>
> +static bool oops_only = false;
> +module_param(oops_only, bool, 0600);
> +MODULE_PARM_DESC(oops_only, "Only log oops messages");
> +
> #ifndef MODULE
> static int __init option_setup(char *opt)
> {
> @@ -683,6 +687,8 @@ static void write_msg(struct console *con, const char *msg, unsigned int len)
> struct netconsole_target *nt;
> const char *tmp;
>
> + if (oops_only && !oops_in_progress)
> + return;
> /* Avoid taking lock and disabling interrupts unnecessarily */
> if (list_empty(&target_list))
> return;
> --
--
~Randy
^ permalink raw reply
* [PATCH] qmi_wwan/cdc_ether: add Dell Wireless 5800 (Novatel E362) USB IDs
From: Dan Williams @ 2012-11-08 18:14 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Aleksander Morgado, netdev, linux-usb
The Dell Wireless 5800 appears to be a Novatel E362 rebrand.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable@vger.kernel.org
---
Greg: CC-ed to linux-usb@ for visibility but should go through davem
drivers/net/usb/cdc_ether.c | 15 +++++++++++++++
drivers/net/usb/qmi_wwan.c | 14 ++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index d095b39..a74f35f 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -487,6 +487,7 @@ static const struct driver_info wwan_info = {
#define HUAWEI_VENDOR_ID 0x12D1
#define NOVATEL_VENDOR_ID 0x1410
#define ZTE_VENDOR_ID 0x19D2
+#define DELL_VENDOR_ID 0x413C
static const struct usb_device_id products [] = {
/*
@@ -606,6 +607,20 @@ static const struct usb_device_id products [] = {
.driver_info = 0,
},
+/* Dell Wireless 5800 (Novatel E362) - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x8195, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
+/* Dell Wireless 5800 V2 (Novatel E362) - handled by qmi_wwan */
+{
+ USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x8196, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+ .driver_info = 0,
+},
+
/*
* WHITELIST!!!
*
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3b566fa..28a76b2 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -383,6 +383,20 @@ static const struct usb_device_id products[] = {
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)&qmi_wwan_info,
},
+ { /* Dell Wireless 5800 (Novatel E362) */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x8195,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
+ { /* Dell Wireless 5800 V2 (Novatel E362) */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x8196,
+ USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
/* 3. Combined interface devices matching on interface number */
{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
--
1.7.11.7
^ permalink raw reply related
* [PATCH] cdc_ether: use USB_DEVICE_AND_INTERFACE_INFO for Novatel 551L/E362
From: Dan Williams @ 2012-11-08 18:09 UTC (permalink / raw)
To: Bjørn Mork; +Cc: Aleksander Morgado, netdev
Small cleanup.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/net/usb/cdc_ether.c | 20 ++++----------------
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index d012982..d095b39 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -594,27 +594,15 @@ static const struct usb_device_id products [] = {
/* Novatel USB551L and MC551 - handled by qmi_wwan */
{
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = NOVATEL_VENDOR_ID,
- .idProduct = 0xB001,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0xB001, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
.driver_info = 0,
},
/* Novatel E362 - handled by qmi_wwan */
{
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR
- | USB_DEVICE_ID_MATCH_PRODUCT
- | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = NOVATEL_VENDOR_ID,
- .idProduct = 0x9010,
- .bInterfaceClass = USB_CLASS_COMM,
- .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
- .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0x9010, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
.driver_info = 0,
},
^ permalink raw reply related
* explaining the math behind the buffering done in USB network drivers
From: Oliver Neukum @ 2012-11-08 17:35 UTC (permalink / raw)
To: Robert Bradley, Dave Taht, Jim Gettys, netdev
Hi,
it is probably necessary to state the limitations of USB to understand
why we buffer as much data as we buffer. Basically the schedule on
the USB bus is set in stone for a period of 1ms(full speed). This means that a driver
has to have submitted to USB core enough data to fill _2_ such periods
at all times. Thus the schedule for the current period is filled up and the
host controller can seamlessly switch to the next period.
In addition the driver has to be ready to provide the data for the next period
as soon as one period is done.
Thus conceptually for USB we do tripple-buffering.
Few drivers actually express this logic internally. One usually calculates
a rough approximation, but this is the logic behind the thing.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-08 17:18 UTC (permalink / raw)
To: Shan Wei
Cc: dev-yBygre7rU0TnMu66kgdUjQ, NetDev, Kernel-Maillist, David Miller
In-Reply-To: <509BC026.4040209-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 8 Nov 2012, Shan Wei wrote:
> Christoph Lameter said, at 2012/11/3 1:46:
> >> u64_stats_update_begin(&stats->sync);
> >> stats->tx_packets++;
> >
> > Use this_cpu_inc(vport->percpu_stats->packets) here?
>
> Lots of network drivers use u64_stats_sync infrastructure for statistics
So they would all have an advantage from the patch.
^ permalink raw reply
* Re: [net-next:master 232/235] drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:7053:6: sparse: symbol 'bnx2x_init_searcher' was not declared. Should it be static?
From: Ben Hutchings @ 2012-11-08 17:15 UTC (permalink / raw)
To: Merav Sicron; +Cc: Fengguang Wu, Dmitry Kravkov, Eilon Greenstein, netdev
In-Reply-To: <1352390951.5555.5.camel@lb-tlvb-meravs.il.broadcom.com>
On Thu, 2012-11-08 at 18:09 +0200, Merav Sicron wrote:
> On Thu, 2012-11-08 at 17:38 +0800, Fengguang Wu wrote:
> > Hi Merav,
> >
> > FYI, there are new sparse warnings show up in
>
> Thanks. Before submitting I run sparse and it didn't catch these issues,
> but apparently it didn't function well. I will submit a patch soon.
> Merav
The kernel doesn't enable byte-order type checks by default; you have to
add CHECKFLAGS=-D__CHECK_ENDIAN__ to the make command line.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
From: Rose, Gregory V @ 2012-11-08 16:53 UTC (permalink / raw)
To: Kirsher, Jeffrey T, pkill.2012
Cc: e1000-devel@lists.sourceforge.net, netdev, linux-kernel, kvm
In-Reply-To: <509B962C.6070002@gmail.com>
> -----Original Message-----
> From: Jeff Kirsher [mailto:tarbal@gmail.com]
> Sent: Thursday, November 08, 2012 3:23 AM
> To: pkill.2012
> Cc: linux-kernel; netdev; kvm; e1000-devel@lists.sourceforge.net; Rose,
> Gregory V
> Subject: Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources
> for SR-IOV)
>
> On 11/08/2012 03:15 AM, pkill.2012 wrote:
> > Hello,
> >
> > I installed kvm and tried to use SR-IOV virtualizaton for
> > 82599EB(Intel XT-520 T2) dual port card with latest ixgbe
> > driver(version:3.11.33) ,
> > kernel2.6.32-279.14.1(OS:Centos6.3) ,after configuration and reboot It
> > seems that only first port of the card's VFs works,second port of the
> > card's VFs didn't work I found some errors in /var/log messages:
> >
> > Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: not enough MMIO
> > resources for SR-IOV Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1:
> > (unregistered net_device): Failed to enable PCI sriov: -12
> >
> > How to fix it,any help would be greatly appreciated.
The BIOS in your machine doesn't support SR-IOV. You'll need to ask the manufacturer for a BIOS upgrade, if in fact one is available. Sometimes they're not.
- Greg
> >
> > below is the related information:
> > Server: R710
> > OS: centos6.3
> > NIC: X520-T2(dual port)
> > kernel: 2.6.32-279.14.1.el6.x86_64
> > BIOSVersion: 6.3.0(latest)
> > BIOS:Inter VT/VT-d or SR-IOV(enabled)
> > ixgbe:3.11.33(latest)
> > ixgbevf:2.7.12(latest)
> > grub config:intel_iommu=on appended
> >
> > /var/log/messages:
> > Nov 8 14:56:54 12 kernel: Intel(R) 10 Gigabit PCI Express Network
> > Driver - version 3.11.33 Nov 8 14:56:54 12 kernel: Copyright (c) 1999-
> 2012 Intel Corporation.
> > Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.0: PCI INT B -> GSI 50
> > (level, low) -> IRQ 50 Nov 8 14:56:54 12 kernel: ixgbe: I/O
> > Virtualization (IOV) set to 2 Nov 8 14:56:54 12 kernel: ixgbe:
> > 0000:07:00.0: ixgbe_check_options: FCoE Offload feature enabled Nov 8
> > 14:56:54 12 kernel: ixgbe 0000:07:00.0: (unregistered net_device):
> > SR-IOV enabled with 2 VFs Nov 8 14:56:54 12 kernel: ixgbe
> > 0000:07:00.0: FCoE offload feature is not available. Disabling FCoE
> > offload feature Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.0: (PCI
> > Express:5.0GT/s:Width x8) 68:05:ca:0c:7a:e2 Nov 8 14:56:54 12 kernel:
> > ixgbe 0000:07:00.0: eth4: MAC: 2, PHY: 2, PBA No: G21371-003 Nov 8
> > 14:56:54 12 kernel: ixgbe 0000:07:00.0: eth4: Enabled Features: RxQ: 1
> > TxQ: 1 LRO Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.0: eth4: IOV:
> > VF 0 is enabled mac 0E:15:B9:26:B3:7D Nov 8 14:56:54 12 kernel: ixgbe
> > 0000:07:00.0: eth4: IOV: VF 1 is enabled mac 32:69:2D:16:B9:40 Nov 8
> > 14:56:54 12 kernel: ixgbe 0000:07:00.0: eth4: Intel(R) 10 Gigabit
> > Network Connection Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: PCI
> > INT A -> GSI 40 (level, low) -> IRQ 40 Nov 8 14:56:54 12 kernel:
> > ixgbe: I/O Virtualization (IOV) set to 2 Nov 8 14:56:54 12 kernel:
> > ixgbe: 0000:07:00.1: ixgbe_check_options: FCoE Offload feature enabled
> > Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: not enough MMIO resources
> for SR-IOV Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: (unregistered
> net_device): Failed to enable PCI sriov: -12 Nov 8 14:56:54 12 kernel:
> ixgbe 0000:07:00.1: FCoE offload feature is not available. Disabling FCoE
> offload feature Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: (PCI
> Express:5.0GT/s:Width x8) 68:05:ca:0c:7a:e3 Nov 8 14:56:54 12 kernel:
> ixgbe 0000:07:00.1: eth5: MAC: 2, PHY: 2, PBA No: G21371-003 Nov 8
> 14:56:54 12 kernel: ixgbe 0000:07:00.1: eth5: Enabled Features:
> > RxQ: 16 TxQ: 16 FdirHash RSC
> > Nov 8 14:56:54 12 kernel: ixgbe 0000:07:00.1: eth5: Intel(R) 10
> > Gigabit Network Connection
> >
> > # dmesg |grep -E 'DMA|IOMMU'
> > ACPI: DMAR 00000000bf3b3668 001C0 (v01 DELL PE_SC3 00000001 DELL
> 00000001)
> > DMA 0x00000001 -> 0x00001000
> > DMA32 0x00001000 -> 0x00100000
> > DMA zone: 56 pages used for memmap
> > DMA zone: 102 pages reserved
> > DMA zone: 3839 pages, LIFO batch:0
> > DMA32 zone: 14280 pages used for memmap
> > DMA32 zone: 764849 pages, LIFO batch:31
> > Intel-IOMMU: enabled
> > DMAR: Host address width 40
> > DMAR: DRHD base: 0x000000fed90000 flags: 0x1 IOMMU fed90000: ver 1:0
> > cap c90780106f0462 ecap f020fe
> > DMAR: RMRR base: 0x000000bf4c8000 end: 0x000000bf4dffff
> > DMAR: RMRR base: 0x000000bf4b1000 end: 0x000000bf4bffff
> > DMAR: RMRR base: 0x000000bf4a1000 end: 0x000000bf4a1fff
> > DMAR: RMRR base: 0x000000bf4a3000 end: 0x000000bf4a3fff
> > DMAR: RMRR base: 0x000000bf4a5000 end: 0x000000bf4a5fff
> > DMAR: RMRR base: 0x000000bf4a7000 end: 0x000000bf4a7fff
> > DMAR: RMRR base: 0x000000bf4c0000 end: 0x000000bf4c0fff
> > DMAR: RMRR base: 0x000000bf4c2000 end: 0x000000bf4c2fff
> > DMAR: ATSR flags: 0x0
> > DMAR: Device scope device [0000:00:1a.02] not found
> > DMAR: Device scope device [0000:00:1a.02] not found
> > DMAR: Device scope device [0000:00:1d.02] not found
> > DMAR: Device scope device [0000:00:1d.02] not found IOMMU 0xfed90000:
> > using Queued invalidation
> > IOMMU: Setting RMRR:
> > IOMMU: Setting identity map for device 0000:00:1d.7 [0xbf4c2000 -
> > 0xbf4c3000]
> > IOMMU: Setting identity map for device 0000:00:1a.7 [0xbf4c0000 -
> > 0xbf4c1000]
> > IOMMU: Setting identity map for device 0000:00:1d.1 [0xbf4a7000 -
> > 0xbf4a8000]
> > IOMMU: Setting identity map for device 0000:00:1d.0 [0xbf4a5000 -
> > 0xbf4a6000]
> > IOMMU: Setting identity map for device 0000:00:1a.1 [0xbf4a3000 -
> > 0xbf4a4000]
> > IOMMU: Setting identity map for device 0000:00:1a.0 [0xbf4a1000 -
> > 0xbf4a2000]
> > IOMMU: Setting identity map for device 0000:00:1a.0 [0xbf4b1000 -
> > 0xbf4c0000]
> > IOMMU: Setting identity map for device 0000:00:1a.1 [0xbf4b1000 -
> > 0xbf4c0000]
> > IOMMU: Setting identity map for device 0000:00:1d.0 [0xbf4b1000 -
> > 0xbf4c0000]
> > IOMMU: Setting identity map for device 0000:00:1d.1 [0xbf4b1000 -
> > 0xbf4c0000]
> > IOMMU: Setting identity map for device 0000:00:1a.7 [0xbf4c8000 -
> > 0xbf4e0000]
> > IOMMU: Setting identity map for device 0000:00:1d.7 [0xbf4c8000 -
> > 0xbf4e0000]
> > IOMMU: Prepare 0-16MiB unity mapping for LPC
> > IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]
> > PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
> > ata1: SATA max UDMA/133 cmd 0xdc10 ctl 0xdc08 bmdma 0xdc20 irq 23
> > ata2: SATA max UDMA/133 cmd 0xdc18 ctl 0xdc0c bmdma 0xdc28 irq 23
> > ata1.00: ATAPI: TSSTcorp DVD-ROM SN-108BB, D150, max UDMA/100
> > ata1.00: configured for UDMA/100
> >
> > # lspci|grep Virtual
> > 07:10.0 Ethernet controller: Intel Corporation 82599 Virtual Function
> > (rev 01)
> > 07:10.2 Ethernet controller: Intel Corporation 82599 Virtual Function
> > (rev 01)
> >
> > #lspci|grep '82599EB'
> > 07:00.0 Ethernet controller: Intel Corporation 82599EB 10 Gigabit TN
> > Network Connection (rev 01)
> > 07:00.1 Ethernet controller: Intel Corporation 82599EB 10 Gigabit TN
> > Network Connection (rev 01)
> >
> > # lspci -n|grep 07:00
> > 07:00.0 0200: 8086:151c (rev 01)
> > 07:00.1 0200: 8086:151c (rev 01)
> >
> > # lspci -n -d 8086:151c -vvv|grep -i width
> > LnkCap: Port #2, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <1us, L1
> > <8us
> > LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive-
> > BWMgmt- ABWMgmt-
> > LnkCap: Port #2, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <1us, L1
> > <8us
> > LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive-
> > BWMgmt- ABWMgmt-
> >
> > #lspci -vvv -s 07:00
> > 07:00.0 Ethernet controller: Intel Corporation 82599EB 10 Gigabit TN
> > Network Connection (rev 01)
> > Subsystem: Intel Corporation Ethernet Server Adapter X520-T2
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR- FastB2B- DisINTx+
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0, Cache Line Size: 64 bytes
> > Interrupt: pin B routed to IRQ 50
> > Region 0: Memory at de400000 (64-bit, non-prefetchable) [size=2M]
> > Region 2: I/O ports at ecc0 [size=32] Region 4: Memory at de3f8000
> > (64-bit, non-prefetchable) [size=16K] Expansion ROM at de200000
> > [disabled] [size=1M]
> > Capabilities: [40] Power Management version 3
> > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> > PME(D0+,D1-,D2-,D3hot+,D3cold+)
> > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> > Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> > Address: 0000000000000000 Data: 0000
> > Masking: 00000000 Pending: 00000000
> > Capabilities: [70] MSI-X: Enable+ Count=64 Masked- Vector table: BAR=4
> > offset=00000000
> > PBA: BAR=4 offset=00002000
> > Capabilities: [a0] Express (v2) Endpoint, MSI 00
> > DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1
> > <64us
> > ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
> > DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
> > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
> > MaxPayload 256 bytes, MaxReadReq 512 bytes
> > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
> > LnkCap: Port #2, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <1us, L1
> > <8us
> > ClockPM- Surprise- LLActRep- BwNot-
> > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive-
> > BWMgmt- ABWMgmt-
> > DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
> > DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis-
> > LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-,
> > Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range,
> > EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB
> > LnkSta2: Current De-emphasis Level: -6dB
> > Capabilities: [e0] Vital Product Data
> > Unknown small resource type 06, will not decode more.
> > Capabilities: [100] Advanced Error Reporting
> > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> > MalfTLP- ECRC- UnsupReq- ACSViol-
> > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt+ UnxCmplt+ RxOF-
> > MalfTLP- ECRC- UnsupReq- ACSViol-
> > UESvrt: DLP+ SDES- TLP+ FCP+ CmpltTO+ CmpltAbrt- UnxCmplt- RxOF+
> > MalfTLP+ ECRC+ UnsupReq- ACSViol-
> > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> > CEMsk: RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+
> > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> > Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-0c-7a-e2
> > Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
> > ARICap: MFVC- ACS-, Next Function: 1
> > ARICtl: MFVC- ACS-, Function Group: 0
> > Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
> > IOVCap: Migration-, Interrupt Message Number: 000
> > IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy+
> > IOVSta: Migration-
> > Initial VFs: 64, Total VFs: 64, Number of VFs: 2, Function Dependency
> > Link: 00 VF offset: 128, stride: 2, Device ID: 10ed Supported Page
> > Size: 00000553, System Page Size: 00000001 Region 0: Memory at
> > 00000000d5900000 (64-bit, prefetchable) Region 3: Memory at
> > 00000000d5a00000 (64-bit, prefetchable) VF Migration: offset:
> > 00000000, BIR: 0 Kernel driver in use: ixgbe Kernel modules: ixgbe
> > 07:00.1 Ethernet controller: Intel Corporation 82599EB 10 Gigabit TN
> > Network Connection (rev 01)
> > Subsystem: Intel Corporation Ethernet Server Adapter X520-T2
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> > Stepping- SERR- FastB2B- DisINTx+
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0, Cache Line Size: 64 bytes
> > Interrupt: pin A routed to IRQ 40
> > Region 0: Memory at de600000 (64-bit, non-prefetchable) [size=2M]
> > Region 2: I/O ports at ece0 [size=32] Region 4: Memory at de3fc000
> > (64-bit, non-prefetchable) [size=16K] Expansion ROM at d5800000
> > [disabled] [size=1M]
> > Capabilities: [40] Power Management version 3
> > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> > PME(D0+,D1-,D2-,D3hot+,D3cold+)
> > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
> > Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> > Address: 0000000000000000 Data: 0000
> > Masking: 00000000 Pending: 00000000
> > Capabilities: [70] MSI-X: Enable+ Count=64 Masked- Vector table: BAR=4
> > offset=00000000
> > PBA: BAR=4 offset=00002000
> > Capabilities: [a0] Express (v2) Endpoint, MSI 00
> > DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1
> > <64us
> > ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
> > DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported+
> > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
> > MaxPayload 256 bytes, MaxReadReq 512 bytes
> > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
> > LnkCap: Port #2, Speed 5GT/s, Width x8, ASPM L0s, Latency L0 <1us, L1
> > <8us
> > ClockPM- Surprise- LLActRep- BwNot-
> > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > LnkSta: Speed 5GT/s, Width x8, TrErr- Train- SlotClk+ DLActive-
> > BWMgmt- ABWMgmt-
> > DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
> > DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis-
> > LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
> > Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range,
> > EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB
> > LnkSta2: Current De-emphasis Level: -6dB
> > Capabilities: [e0] Vital Product Data
> > Unknown small resource type 06, will not decode more.
> > Capabilities: [100] Advanced Error Reporting
> > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
> > MalfTLP- ECRC- UnsupReq- ACSViol-
> > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt+ UnxCmplt+ RxOF-
> > MalfTLP- ECRC- UnsupReq- ACSViol-
> > UESvrt: DLP+ SDES- TLP+ FCP+ CmpltTO+ CmpltAbrt- UnxCmplt- RxOF+
> > MalfTLP+ ECRC+ UnsupReq- ACSViol-
> > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> > CEMsk: RxErr+ BadTLP+ BadDLLP+ Rollover+ Timeout+ NonFatalErr+
> > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> > Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-0c-7a-e2
> > Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
> > ARICap: MFVC- ACS-, Next Function: 0
> > ARICtl: MFVC- ACS-, Function Group: 0
> > Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
> > IOVCap: Migration-, Interrupt Message Number: 000
> > IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
> > IOVSta: Migration-
> > Initial VFs: 64, Total VFs: 64, Number of VFs: 2, Function Dependency
> > Link: 01 VF offset: 128, stride: 2, Device ID: 10ed Supported Page
> > Size: 00000553, System Page Size: 00000001 Region 0: Memory at
> > 00000000d5b00000 (64-bit, prefetchable) Region 3: Memory at
> > 00000000d5b00000 (64-bit, prefetchable) VF Migration: offset:
> > 00000000, BIR: 0 Kernel driver in use: ixgbe Kernel modules: ixgbe
> >
> > #modinfo ixgbe
> > filename: /lib/modules/2.6.32-
> 279.14.1.el6.x86_64/kernel/drivers/net/ixgbe/ixgbe.ko
> > version: 3.11.33
> > license: GPL
> > description: Intel(R) 10 Gigabit PCI Express Network Driver
> > author: Intel Corporation, <linux.nics@intel.com>
> > srcversion: ADDCBFA6FAFE8A0299074F8
> > alias: pci:v00008086d0000154Asv*sd*bc*sc*i*
> > alias: pci:v00008086d00001557sv*sd*bc*sc*i*
> > alias: pci:v00008086d0000154Fsv*sd*bc*sc*i*
> > alias: pci:v00008086d0000154Dsv*sd*bc*sc*i*
> > alias: pci:v00008086d00001528sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010F8sv*sd*bc*sc*i*
> > alias: pci:v00008086d0000151Csv*sd*bc*sc*i*
> > alias: pci:v00008086d00001529sv*sd*bc*sc*i*
> > alias: pci:v00008086d0000152Asv*sd*bc*sc*i*
> > alias: pci:v00008086d000010F9sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001514sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001507sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010FBsv*sd*bc*sc*i*
> > alias: pci:v00008086d00001517sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010FCsv*sd*bc*sc*i*
> > alias: pci:v00008086d000010F7sv*sd*bc*sc*i*
> > alias: pci:v00008086d00001508sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010DBsv*sd*bc*sc*i*
> > alias: pci:v00008086d000010F4sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010E1sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010F1sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010ECsv*sd*bc*sc*i*
> > alias: pci:v00008086d000010DDsv*sd*bc*sc*i*
> > alias: pci:v00008086d0000150Bsv*sd*bc*sc*i*
> > alias: pci:v00008086d000010C8sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010C7sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010C6sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010B6sv*sd*bc*sc*i*
> > depends: dca
> > vermagic: 2.6.32-279.14.1.el6.x86_64 SMP mod_unload modversions
> > parm: InterruptType:Change Interrupt Mode (0=Legacy, 1=MSI,
> 2=MSI-X), default IntMode (deprecated) (array of int)
> > parm: IntMode:Change Interrupt Mode (0=Legacy, 1=MSI, 2=MSI-
> X), default 2 (array of int)
> > parm: MQ:Disable or enable Multiple Queues, default 1 (array
> of int)
> > parm: DCA:Disable or enable Direct Cache Access, 0=disabled,
> 1=descriptor only, 2=descriptor and data (array of int)
> > parm: RSS:Number of Receive-Side Scaling Descriptor Queues,
> default 0=number of cpus (array of int)
> > parm: VMDQ:Number of Virtual Machine Device Queues: 0/1 =
> disable, 2-16 enable (default=8) (array of int)
> > parm: max_vfs:Number of Virtual Functions: 0 = disable
> (default), 1-63 = enable this many VFs (array of int)
> > parm: L2LBen:L2 Loopback Enable: 0 = disable, 1 = enable
> (default) (array of int)
> > parm: InterruptThrottleRate:Maximum interrupts per second, per
> vector, (0,1,956-488281), default 1 (array of int)
> > parm: LLIPort:Low Latency Interrupt TCP Port (0-65535) (array
> of int)
> > parm: LLIPush:Low Latency Interrupt on TCP Push flag (0,1)
> (array of int)
> > parm: LLISize:Low Latency Interrupt on Packet Size (0-1500)
> (array of int)
> > parm: LLIEType:Low Latency Interrupt Ethernet Protocol Type
> (array of int)
> > parm: LLIVLANP:Low Latency Interrupt on VLAN priority
> threshold (array of int)
> > parm: FdirPballoc:Flow Director packet buffer allocation
> level:
> > 1 = 8k hash filters or 2k perfect filters
> > 2 = 16k hash filters or 4k perfect filters
> > 3 = 32k hash filters or 8k perfect filters (array of int)
> > parm: AtrSampleRate:Software ATR Tx packet sample rate (array
> of int)
> > parm: FCoE:Disable or enable FCoE Offload, default 1 (array of
> int)
> > parm: LRO:Large Receive Offload (0,1), default 1 = on (array
> of int)
> > parm: allow_unsupported_sfp:Allow unsupported and untested
> SFP+ modules on 82599 based adapters, default 0 = Disable (array of int)
> >
> > # modinfo ixgbevf
> > filename: /lib/modules/2.6.32-
> 279.14.1.el6.x86_64/kernel/drivers/net/ixgbevf/ixgbevf.ko
> > version: 2.7.12
> > license: GPL
> > description: Intel(R) 10 Gigabit PCI Express Virtual Function Network
> Driver
> > author: Intel Corporation, <linux.nics@intel.com>
> > srcversion: 4D00B4A5B811D6D07D8BD15
> > alias: pci:v00008086d00001515sv*sd*bc*sc*i*
> > alias: pci:v00008086d000010EDsv*sd*bc*sc*i*
> > depends:
> > vermagic: 2.6.32-279.14.1.el6.x86_64 SMP mod_unload modversions
> > parm: InterruptThrottleRate:Maximum interrupts per second, per
> vector, (956-488281), default 8000, use 1 for dynamic (array of int)
> >
> >
> > # dmidecode -t bios
> > # dmidecode 2.11
> > SMBIOS 2.6 present.
> > Handle 0x0000, DMI type 0, 24 bytes
> > BIOS Information
> > Vendor: Dell Inc.
> > Version: 6.3.0
> > Release Date: 07/24/2012
> > Address: 0xF0000
> > Runtime Size: 64 kB
> > ROM Size: 4096 kB
> > Characteristics:
> > ISA is supported
> > PCI is supported
> > PNP is supported
> > BIOS is upgradeable
> > BIOS shadowing is allowed
> > Boot from CD is supported
> > Selectable boot is supported
> > EDD is supported
> > Japanese floppy for Toshiba 1.2 MB is supported (int
> 13h)
> > 5.25"/360 kB floppy services are supported (int 13h)
> > 5.25"/1.2 MB floppy services are supported (int 13h)
> > 3.5"/720 kB floppy services are supported (int 13h)
> > 8042 keyboard services are supported (int 9h)
> > Serial services are supported (int 14h)
> > CGA/mono video services are supported (int 10h)
> > ACPI is supported
> > USB legacy is supported
> > BIOS boot specification is supported
> > Function key-initiated network boot is supported
> > Targeted content distribution is supported
> > BIOS Revision: 6.3
> > Handle 0x0D00, DMI type 13, 22 bytes
> > BIOS Language Information
> > Language Description Format: Long
> > Installable Languages: 1
> > en|US|iso8859-1
> > Currently Installed Language: en|US|iso8859-1
> >
> > Jason Gao
> > --
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> Adding e100-devel mailing list
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH] allow pkg-config to be customized
From: Mike Frysinger @ 2012-11-08 16:41 UTC (permalink / raw)
To: stephen.hemminger, netdev
Rather than hard coding `pkg-config`, use ${PKG_CONFIG} so people can
override it to their specific version (like when cross-compiling).
This is the same way the upstream pkg-config code works.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
configure | 6 ++++--
tc/Makefile | 4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 2c2d1c4..0bfedf9 100755
--- a/configure
+++ b/configure
@@ -2,6 +2,8 @@
# This is not an autconf generated configure
#
INCLUDE=${1:-"$PWD/include"}
+: ${PKG_CONFIG:=pkg-config}
+echo "PKG_CONFIG:=${PKG_CONFIG}" >>Config
# Make a temp directory in build tree.
TMPDIR=$(mktemp -d config.XXXXXX)
@@ -51,7 +53,7 @@ int main(int argc, char **argv)
EOF
-if gcc -I$INCLUDE $IPTC -o $TMPDIR/ipttest $TMPDIR/ipttest.c $IPTL $(pkg-config xtables --cflags --libs) -ldl >/dev/null 2>&1
+if gcc -I$INCLUDE $IPTC -o $TMPDIR/ipttest $TMPDIR/ipttest.c $IPTL $(${PKG_CONFIG} xtables --cflags --libs) -ldl >/dev/null 2>&1
then
echo "TC_CONFIG_XT:=y" >>Config
echo "using xtables"
@@ -148,7 +150,7 @@ check_ipt()
check_ipt_lib_dir()
{
- IPT_LIB_DIR=$(pkg-config --variable=xtlibdir xtables)
+ IPT_LIB_DIR=$(${PKG_CONFIG} --variable=xtlibdir xtables)
if [ -n "$IPT_LIB_DIR" ]; then
echo $IPT_LIB_DIR
echo "IPT_LIB_DIR:=$IPT_LIB_DIR" >> Config
diff --git a/tc/Makefile b/tc/Makefile
index 389029d..696f891 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -135,10 +135,10 @@ q_atm.so: q_atm.c
$(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o q_atm.so q_atm.c -latm
m_xt.so: m_xt.c
- $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt.so m_xt.c $$(pkg-config xtables --cflags --libs)
+ $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt.so m_xt.c $$($(PKG_CONFIG) xtables --cflags --libs)
m_xt_old.so: m_xt_old.c
- $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt_old.so m_xt_old.c $$(pkg-config xtables --cflags --libs)
+ $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt_old.so m_xt_old.c $$($(PKG_CONFIG) xtables --cflags --libs)
%.yacc.c: %.y
$(YACC) $(YACCFLAGS) -o $@ $<
--
1.7.12.4
^ permalink raw reply related
* [PATCH] usbnet: ratelimit kevent may have been dropped warnings
From: Steve Glendinning @ 2012-11-08 16:26 UTC (permalink / raw)
To: oneukum; +Cc: netdev, Steve Glendinning
when something goes wrong, a flood of these messages can be
generated by usbnet (thousands per second). This doesn't
generally *help* the condition so this patch ratelimits the
rate of their generation.
There's an underlying problem in usbnet's kevent deferral
mechanism which needs fixing, specifically that events *can*
get dropped and not handled. This patch doesn't address this,
but just mitigates fallout caused by the current implemention.
Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
---
drivers/net/usb/usbnet.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 5bf7717..3565e6d 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -359,10 +359,12 @@ static enum skb_state defer_bh(struct usbnet *dev, struct sk_buff *skb,
void usbnet_defer_kevent (struct usbnet *dev, int work)
{
set_bit (work, &dev->flags);
- if (!schedule_work (&dev->kevent))
- netdev_err(dev->net, "kevent %d may have been dropped\n", work);
- else
+ if (!schedule_work (&dev->kevent)) {
+ if (net_ratelimit())
+ netdev_err(dev->net, "kevent %d may have been dropped\n", work);
+ } else {
netdev_dbg(dev->net, "kevent %d scheduled\n", work);
+ }
}
EXPORT_SYMBOL_GPL(usbnet_defer_kevent);
--
1.7.10.4
^ permalink raw reply related
* [PATCH][net-next v1] gianfar: Fix alloc_skb_resources on -ENOMEM cleanup path
From: Claudiu Manoil @ 2012-11-08 15:59 UTC (permalink / raw)
To: netdev; +Cc: Paul Gortmaker, David S. Miller, Claudiu Manoil
Should gfar_init_bds() return with -ENOMEM inside gfar_alloc_skb_resources(),
free_skb_resources() will be called twice in a row on the "cleanup" path,
leading to duplicate kfree() calls for rx_|tx_queue->rx_|tx_skbuff resulting
in segmentation fault.
This patch prevents the segmentation fault to happen in the future
(rx_|tx_sbkbuff set to NULL), and corrects the error path handling
for gfar_init_bds().
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
---
v1: do free_skb_resources() on the cleanup path of gfar_init_bds()'s parent
drivers/net/ethernet/freescale/gianfar.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 1d03dcd..ce2007f 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -210,7 +210,7 @@ static int gfar_init_bds(struct net_device *ndev)
skb = gfar_new_skb(ndev);
if (!skb) {
netdev_err(ndev, "Can't allocate RX buffers\n");
- goto err_rxalloc_fail;
+ return -ENOMEM;
}
rx_queue->rx_skbuff[j] = skb;
@@ -223,10 +223,6 @@ static int gfar_init_bds(struct net_device *ndev)
}
return 0;
-
-err_rxalloc_fail:
- free_skb_resources(priv);
- return -ENOMEM;
}
static int gfar_alloc_skb_resources(struct net_device *ndev)
@@ -1356,7 +1352,9 @@ static int gfar_restore(struct device *dev)
if (!netif_running(ndev))
return 0;
- gfar_init_bds(ndev);
+ if (gfar_init_bds(ndev))
+ goto cleanup;
+
init_registers(ndev);
gfar_set_mac_address(ndev);
gfar_init_mac(ndev);
@@ -1373,6 +1371,10 @@ static int gfar_restore(struct device *dev)
enable_napi(priv);
return 0;
+
+cleanup:
+ free_skb_resources(priv);
+ return -ENOMEM;
}
static struct dev_pm_ops gfar_pm_ops = {
@@ -1709,6 +1711,7 @@ static void free_skb_tx_queue(struct gfar_priv_tx_q *tx_queue)
tx_queue->tx_skbuff[i] = NULL;
}
kfree(tx_queue->tx_skbuff);
+ tx_queue->tx_skbuff = NULL;
}
static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
@@ -1732,6 +1735,7 @@ static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
rxbdp++;
}
kfree(rx_queue->rx_skbuff);
+ rx_queue->rx_skbuff = NULL;
}
/* If there are any tx skbs or rx skbs still around, free them.
--
1.6.6
^ permalink raw reply related
* Re: [PATCH][net-next v1] gianfar: Fix alloc_skb_resources on -ENOMEM cleanup path
From: Paul Gortmaker @ 2012-11-08 16:08 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, David S. Miller
In-Reply-To: <1352390396-10053-1-git-send-email-claudiu.manoil@freescale.com>
On 12-11-08 10:59 AM, Claudiu Manoil wrote:
> Should gfar_init_bds() return with -ENOMEM inside gfar_alloc_skb_resources(),
> free_skb_resources() will be called twice in a row on the "cleanup" path,
> leading to duplicate kfree() calls for rx_|tx_queue->rx_|tx_skbuff resulting
> in segmentation fault.
> This patch prevents the segmentation fault to happen in the future
> (rx_|tx_sbkbuff set to NULL), and corrects the error path handling
> for gfar_init_bds().
>
> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
> Cc: "David S. Miller" <davem@davemloft.net>
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
> ---
> v1: do free_skb_resources() on the cleanup path of gfar_init_bds()'s parent
>
> drivers/net/ethernet/freescale/gianfar.c | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> index 1d03dcd..ce2007f 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -210,7 +210,7 @@ static int gfar_init_bds(struct net_device *ndev)
> skb = gfar_new_skb(ndev);
> if (!skb) {
> netdev_err(ndev, "Can't allocate RX buffers\n");
> - goto err_rxalloc_fail;
> + return -ENOMEM;
> }
> rx_queue->rx_skbuff[j] = skb;
>
> @@ -223,10 +223,6 @@ static int gfar_init_bds(struct net_device *ndev)
> }
>
> return 0;
> -
> -err_rxalloc_fail:
> - free_skb_resources(priv);
> - return -ENOMEM;
> }
>
> static int gfar_alloc_skb_resources(struct net_device *ndev)
> @@ -1356,7 +1352,9 @@ static int gfar_restore(struct device *dev)
> if (!netif_running(ndev))
> return 0;
>
> - gfar_init_bds(ndev);
> + if (gfar_init_bds(ndev))
> + goto cleanup;
> +
Since this is the only exit point, just put the free and
return right here, and avoid the goto and the separate
unwind block entirely?
P.
--
> init_registers(ndev);
> gfar_set_mac_address(ndev);
> gfar_init_mac(ndev);
> @@ -1373,6 +1371,10 @@ static int gfar_restore(struct device *dev)
> enable_napi(priv);
>
> return 0;
> +
> +cleanup:
> + free_skb_resources(priv);
> + return -ENOMEM;
> }
>
> static struct dev_pm_ops gfar_pm_ops = {
> @@ -1709,6 +1711,7 @@ static void free_skb_tx_queue(struct gfar_priv_tx_q *tx_queue)
> tx_queue->tx_skbuff[i] = NULL;
> }
> kfree(tx_queue->tx_skbuff);
> + tx_queue->tx_skbuff = NULL;
> }
>
> static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
> @@ -1732,6 +1735,7 @@ static void free_skb_rx_queue(struct gfar_priv_rx_q *rx_queue)
> rxbdp++;
> }
> kfree(rx_queue->rx_skbuff);
> + rx_queue->rx_skbuff = NULL;
> }
>
> /* If there are any tx skbs or rx skbs still around, free them.
>
^ permalink raw reply
* [PATCH] socket.7: Correctly describe SO_SNDTIMEO for connect
From: Andi Kleen @ 2012-11-08 15:55 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Andi Kleen
From: Andi Kleen <ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
When SO_SNDTIMEO is set before connect() connect may return EWOULDBLOCK
when the timeout fires. Describe this correctly.
Signed-off-by: Andi Kleen <ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
man7/socket.7 | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/man7/socket.7 b/man7/socket.7
index cd75746..9e05f48 100644
--- a/man7/socket.7
+++ b/man7/socket.7
@@ -434,6 +434,9 @@ set to
.B EAGAIN
or
.B EWOULDBLOCK
+or
+.B EINPROGRESS
+(for connect)
.\" in fact to EAGAIN
just as if the socket was specified to be nonblocking.
If the timeout is set to zero (the default)
@@ -442,6 +445,7 @@ Timeouts only have effect for system calls that perform socket I/O (e.g.,
.BR read (2),
.BR recvmsg (2),
.BR send (2),
+.BR connect (2),
.BR sendmsg (2));
timeouts have no effect for
.BR select (2),
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ipv4: Handle very small SO_SNDTIMEOs
From: Andi Kleen @ 2012-11-08 15:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Andi Kleen
From: Andi Kleen <ak@linux.intel.com>
When the SO_SNDTIMEO timeout is short enough it may round down to zero
jiffies. This causes unexpected behaviour because the socket
essentially becomes always non blocking.
Round up the timeout to at least two jiffies, so that
we guarantee waiting for at least some time. With one jiffie
we could potentially still wait zero time because we might
be just at the edge of the jiffie, and if it flips over
in the middle of the check it could be still zero.
This has been observed in a real application.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
net/core/sock.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index a6000fb..93c0060 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -362,8 +362,15 @@ static int sock_set_timeout(long *timeo_p, char __user *optval, int optlen)
*timeo_p = MAX_SCHEDULE_TIMEOUT;
if (tv.tv_sec == 0 && tv.tv_usec == 0)
return 0;
- if (tv.tv_sec < (MAX_SCHEDULE_TIMEOUT/HZ - 1))
+ if (tv.tv_sec < (MAX_SCHEDULE_TIMEOUT/HZ - 1)) {
*timeo_p = tv.tv_sec*HZ + (tv.tv_usec+(1000000/HZ-1))/(1000000/HZ);
+ /* Do at least two jiffies to ensure we wait at all.
+ * Otherwise we may be on the edge of the next jiffie already,
+ * and then essentially non block.
+ */
+ if ((unsigned long)*timeo_p < 2)
+ *timeo_p = 2;
+ }
return 0;
}
--
1.7.7.6
^ permalink raw reply related
* Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
From: Andy King @ 2012-11-08 15:47 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: pv-drivers, netdev, linux-kernel, virtualization, gregkh,
David Miller, georgezhang
In-Reply-To: <509A06AB.2020700@redhat.com>
Hi Gerd,
>> Also, there was some interest from RedHat into using vSockets as
>> a unified interface, routed over a hypervisor-specific transport
>> (virtio or otherwise, although for now VMCI is the only one
>> implemented).
>
> Can you outline how this can be done? From a quick look over the
> code it seems like vsock has a hard dependency on vmci, is that
> correct?
That's correct, VMCI is wired into vSockets and we don't currently
provide any way to insert another transport.
> When making vsock a generic, reusable kernel service it should be
> the other way around: vsock should provide the core implementation
> and an interface where hypervisor-specific transports (vmci,
> virtio, xenbus, ...) can register themself.
Sorry, that was a bad explanation on my part. You're absolutely
correct as to how it _should_ work. But it's up to Red Hat or others
to get the ball rolling and motivate the necessary work on vSockets
to make this happen. As Greg says, "everyone is lazy and just wants
their code accepted" ;)
Thanks!
- Andy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox