* Re: Lower wake up time when phy enter lower mode
From: Frank Li @ 2012-11-08 2:09 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Richard Cochran, netdev
In-Reply-To: <1352315183.2725.17.camel@bwh-desktop.uk.solarflarecom.com>
2012/11/8 Ben Hutchings <bhutchings@solarflare.com>:
> On Wed, 2012-11-07 at 10:52 +0800, Frank Li wrote:
>> Richard:
>>
>> Recently, I found out the path delay will increase about
>> 20us suddenly in something when connect two iMX6 board and Ethernet
>> work on 1G mode.
>> The reason is that the PHY enter lower mode automatically
>> when no package send and receive. It takes some time to recover and
>> send out package by PHY but MAC think package have sent and sample
>> time stamper.
>> Do you meet such case? I can workaround it by two method
>> 1. disable phy lower power feature.
>> 2. add some dummy package before SYNC package.
>
> If this low power mode is related to EEE (Energy Efficient Ethernet)
> then there are ethtool operations defined for configuring it, and you
> could implement those.
Yes, it is phy specific, called smart EEE, which compatible with IEEE 802.3az
and can be used in legacy MAC without EEE.
Do you have example about ethtool operations?
>
> 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: [PATCH 1/2] net: fec: default select FEC_PTP at mx6 platform
From: Frank Li @ 2012-11-08 2:15 UTC (permalink / raw)
To: David Miller
Cc: Frank.Li, richardcochran, shawn.guo, linux-arm-kernel, netdev,
bhutchings
In-Reply-To: <20121107.185246.1330887590098677807.davem@davemloft.net>
>
> But please be explicit about which tree your patches are for in the
> subject line in the future.
Okay.
best regards
Frank Li
^ permalink raw reply
* Re: [PATCH] tcp: Avoid infinite loop on recvmsg bug
From: Julius Werner @ 2012-11-08 2:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, Patrick McHardy, Hideaki YOSHIFUJI,
James Morris, Alexey Kuznetsov, David S. Miller, Dave Jones,
Sameer Nanda, Mandeep Singh Baines
In-Reply-To: <1352331754.2748.14.camel@edumazet-glaptop>
> So you probably are fighting a bug we already fixed in upstream kernel.
>
> (commit c8628155ece363 "tcp: reduce out_of_order memory use" did not
> played well with cloned skbs.)
>
> This issue was already discussed on netdev in the past.
Thanks for the hint. Unfortunately, we have not pulled c8628 into our
tree yet, so that's not it. Is there another point where the cloned
skb or the faked truesize might make it break? We have been running
this test with that hardware some 30 times in the last months and only
seen it once, so it cannot be that common.
I have noticed that you have already proposed a patch to repair
smsc95xx (replacing the clone with a copy) on this list a few times...
what's the status on that? Will it be committed eventually or did you
abandon that approach?
Regardless of that, I still think that the bug handling in tcp_recvmsg
should be updated in one way or the other.
^ permalink raw reply
* Re: [PATCH v2 0/2] Fix CDC_EEM with 802.1Q VLAN and 1500 MTU
From: David Miller @ 2012-11-08 2:27 UTC (permalink / raw)
To: iancoolidge-Re5JQEeQqe8AvxtiuMwx3w
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, balbi-l0cyMroinI0,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1352335159-8049-1-git-send-email-iancoolidge-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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.
--
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
* Messenger from Administrator
From: Webmail Admin @ 2012-11-08 5:29 UTC (permalink / raw)
Your E-mail® Account needs to be updated with our 2013 F-Secure R-HTK4S new version anti-spam/anti-virus/anti-spyware. Please click this link below
http://www.contactme.com/509b2c7e59d3f1000202406a
We Are Sorry For Any Inconvenience.
Regards,
WEBMAIL ADMINISTRATOR
Copyright© 2012 All rights reserved®.ABN 31 088 377 860 All Rights Reserved
^ permalink raw reply
* 82571EB: Detected Hardware Unit Hang
From: Joe Jin @ 2012-11-08 6:24 UTC (permalink / raw)
To: e1000-devel@lists.sf.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Mary Mcgrath
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+
Would you please help to it?
Thanks in advance,
Joe
--
Oracle <http://www.oracle.com>
Joe Jin | Software Development Senior Manager | +8610.6106.5624
ORACLE | Linux and Virtualization
No. 24 Zhongguancun Software Park, Haidian District | 100193 Beijing
^ permalink raw reply
* Re: net/smsc911x: problems after commit 3ac3546e [Always wait for the chip to be ready]
From: David Miller @ 2012-11-08 6:57 UTC (permalink / raw)
To: kamlakant.patel; +Cc: steve, linus.walleij, robert.marklund, netdev
In-Reply-To: <20121108064627.GA25027@patelk@broadcom.com>
From: "Kamlakant Patel" <kamlakant.patel@broadcom.com>
Date: Thu, 8 Nov 2012 12:16:28 +0530
> smsc driver is disabled in our bootloader and it is not changing the
> state of the smsc registers at any stage, so it is not a bootloader
> issue.
What puts that chip into a non-default byte swapping mode then?
^ permalink raw reply
* Re: mmap RX_RING socket issue 32b application running on 64b kernel.
From: Ronny Meeus @ 2012-11-08 7:32 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev
In-Reply-To: <CAMJ=MEdjyJ8+Y_ZaHkcizy_Y8gdWFoSbz+PdVbYkRDTKyMzT1Q@mail.gmail.com>
On Wed, Nov 7, 2012 at 7:54 PM, Ronny Meeus <ronny.meeus@gmail.com> wrote:
> On Wed, Nov 7, 2012 at 7:26 PM, Daniel Borkmann
> <danborkmann@iogearbox.net> wrote:
>> On Wed, Nov 7, 2012 at 6:58 PM, Ronny Meeus <ronny.meeus@gmail.com> wrote:
>>> I have an application using raw Ethernet sockets in combination with
>>> the mmaped RX_RING.
>>> The application is running on a Cavium MIPS processor (64bit) and the
>>> application code is compiled with the N32 ABI.
>>>
>>> Since the ring buffer is shared between the Linux kernel and the
>>> application there is a conflict in the way the data is presented.
>>> Each buffer in the ring has a header that has following structure:
>>> (File http://lxr.free-electrons.com/source/include/linux/if_packet.h )
>>> 103 struct tpacket_hdr {
>>> 104 unsigned long tp_status;
>>> 105 unsigned int tp_len;
>>> 106 unsigned int tp_snaplen;
>>> 107 unsigned short tp_mac;
>>> 108 unsigned short tp_net;
>>> 109 unsigned int tp_sec;
>>> 110 unsigned int tp_usec;
>>> 111 };
>>>
>>> The status field indicates that the buffer belongs to the kernel or to
>>> the user. Note that an unsigned long is used to represent the field.
>>> In the kernel the long is 64 bit while in application space the long
>>> is only 32bit, so the bits do not match.
>>>
>>> After adapting the code to take this into account my program works well.
>>> In my test program I have defined a new struct where I change the
>>> “unsigned long” into an “unsigned long long”:
>>>
>>> struct tpacket_hdr_64 {
>>> unsigned long long tp_status;
>>> unsigned int tp_len;
>>> unsigned int tp_snaplen;
>>> unsigned short tp_mac;
>>> unsigned short tp_net;
>>> unsigned int tp_sec;
>>> unsigned int tp_usec;
>>> };
>>>
>>> In my opinion this is not a correct solution. It should be solved
>>> somewhere in the include file I used so that it is transparent for the
>>> application.
>>> Please comment.
>>
>> Have you tried to use packet_mmap with TPACKET version 2 [1]?
>>
>> In my understanding, it was introduced because of such issues that you
>> described.
>>
>> [1] E.g. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=bbd6ef87c544d88c30e4b762b1b61ef267a7d279
>
> I did not try this. I will do it tomorrow.
> Thanks for the quick response.
With the code below it indeed works.
req.tp_block_size = FRAME_SIZE * NR_FRAMES_PER_BLOCK;
req.tp_frame_size = FRAME_SIZE;
req.tp_block_nr = NR_FRAMES / NR_FRAMES_PER_BLOCK;
req.tp_frame_nr = NR_FRAMES;
val = TPACKET_V2;
setsockopt(eth_sock, SOL_PACKET,PACKET_VERSION, &val, sizeof(val));
setsockopt(eth_sock,SOL_PACKET,PACKET_RX_RING,(char *)&req,sizeof(req));
packet_mem = mmap(NULL,req.tp_block_size * req.tp_block_nr,
PROT_READ|PROT_WRITE|PROT_EXEC,MAP_SHARED,eth_sock, 0);
I wonder why there are so many examples available on the Internet that
either do not set the version or set the version to 1.
I would assume that the only correct usage of this interface is to use
version 2 since this is working on all platforms.
Is this correct?
---
Ronny
^ permalink raw reply
* [PATCH 1/2] irda: sh-irda: Remove SH7367 support
From: Nobuhiro Iwamatsu @ 2012-11-08 7:44 UTC (permalink / raw)
To: netdev; +Cc: samuel, Nobuhiro Iwamatsu
The shmobile SH7367 already was removed from source tree.
This remove SH7367 support for sh-irda.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
drivers/net/irda/sh_irda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/irda/sh_irda.c b/drivers/net/irda/sh_irda.c
index 4b746d9..ca49bbf 100644
--- a/drivers/net/irda/sh_irda.c
+++ b/drivers/net/irda/sh_irda.c
@@ -33,7 +33,7 @@
#define DRIVER_NAME "sh_irda"
-#if defined(CONFIG_ARCH_SH7367) || defined(CONFIG_ARCH_SH7377)
+#if defined(CONFIG_ARCH_SH7377)
#define __IRDARAM_LEN 0x13FF
#else
#define __IRDARAM_LEN 0x1039
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] irda: sh-irda: Remove SH7377 support
From: Nobuhiro Iwamatsu @ 2012-11-08 7:44 UTC (permalink / raw)
To: netdev; +Cc: samuel, Nobuhiro Iwamatsu
In-Reply-To: <1352360667-9341-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
The shmobile SH7377 already was removed from source tree.
This remove SH7377 support for sh-irda.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
drivers/net/irda/sh_irda.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/irda/sh_irda.c b/drivers/net/irda/sh_irda.c
index ca49bbf..945360a 100644
--- a/drivers/net/irda/sh_irda.c
+++ b/drivers/net/irda/sh_irda.c
@@ -33,11 +33,7 @@
#define DRIVER_NAME "sh_irda"
-#if defined(CONFIG_ARCH_SH7377)
-#define __IRDARAM_LEN 0x13FF
-#else
#define __IRDARAM_LEN 0x1039
-#endif
#define IRTMR 0x1F00 /* Transfer mode */
#define IRCFR 0x1F02 /* Configuration */
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/4 net-next] net: allow skb->head to be a page fragment
From: Li Yu @ 2012-11-08 7:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <1352286264.3140.3575.camel@edumazet-glaptop>
于 2012年11月07日 19:04, Eric Dumazet 写道:
> On Wed, 2012-11-07 at 16:35 +0800, Li Yu wrote:
>> 于 2012年11月07日 16:20, Li Yu 写道:
>>> 于 2012年04月27日 18:33, Eric Dumazet 写道:
>>>> From: Eric Dumazet <edumazet@google.com>
>>>>
>>>> skb->head is currently allocated from kmalloc(). This is convenient but
>>>> has the drawback the data cannot be converted to a page fragment if
>>>> needed.
>>>>
>>>
>>> Hi, Eric,
>>>
>>> I have a question about this patch, why data are allocated from
>>> kmalloc() can not be converted to page fragment ? We have its kernel
>>> mapped address and length, so we can get its page and offset in the
>>> page. If the skb is not cloned (shared with others), such page and its
>>> offset should be can use safely, in my words.
>>>
>>> I suspected that I may lost important something in slab internals, is
>>> right?
>>>
>>> Thanks
>>>
>>> Yu
>>>
>>
>> Or since slab allocated object may be across multiple pages?
>> I saw __netdev_alloc_skb() only use build_skb() with non-zero
>> fragsz if it is less than PAGE_SIZE.
>>
>
> SLAB allocators have their own way to handle a page, we cant interfere
> with it.
>
> So no, a kmalloced() object cannot be converted to a page fragment.
>
I think that all kmalloced() objects are continuous on both virtual
and physical address space, so such page fragment converting should be
safe until we use slab allocator to free them.
I ask this question since I am working on a patch to try to directly
forward the data from rx queue of a socket to tx queue of another
socket. We noticed that the splice itself still has visible costs when
forwarding small messages, and hope such direct forwarding optimization
can improve this, this idea comes from TCP friends.
Thanks
Yu
>
>
>
^ permalink raw reply
* [PATCH net-next] ipv6: remove rt6i_peer_genid from rt6_info and its handler
From: roy.qing.li @ 2012-11-08 7:56 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
6431cbc25f(Create a mechanism for upward inetpeer propagation into routes)
introduces these codes, but this mechanism is never enabled since
rt6i_peer_genid always is zero whether it is not assigned or assigned by
rt6_peer_genid(). After 5943634fc5 (ipv4: Maintain redirect and PMTU info
in struct rtable again), the ipv4 related codes of this mechanism has been
removed, I think we maybe able to remove them now.
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
include/net/ip6_fib.h | 1 -
net/ipv6/route.c | 18 ++----------------
2 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 20210d7..26210cf 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -117,7 +117,6 @@ struct rt6_info {
struct rt6key rt6i_src;
struct rt6key rt6i_prefsrc;
u32 rt6i_metric;
- u32 rt6i_peer_genid;
struct inet6_dev *rt6i_idev;
unsigned long _rt6i_peer;
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c42650c..0db1828 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -321,13 +321,6 @@ static void ip6_dst_destroy(struct dst_entry *dst)
}
}
-static atomic_t __rt6_peer_genid = ATOMIC_INIT(0);
-
-static u32 rt6_peer_genid(void)
-{
- return atomic_read(&__rt6_peer_genid);
-}
-
void rt6_bind_peer(struct rt6_info *rt, int create)
{
struct inet_peer_base *base;
@@ -341,8 +334,6 @@ void rt6_bind_peer(struct rt6_info *rt, int create)
if (peer) {
if (!rt6_set_peer(rt, peer))
inet_putpeer(peer);
- else
- rt->rt6i_peer_genid = rt6_peer_genid();
}
}
@@ -1099,14 +1090,9 @@ static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie)
if (rt->rt6i_genid != rt_genid(dev_net(rt->dst.dev)))
return NULL;
- if (rt->rt6i_node && (rt->rt6i_node->fn_sernum == cookie)) {
- if (rt->rt6i_peer_genid != rt6_peer_genid()) {
- if (!rt6_has_peer(rt))
- rt6_bind_peer(rt, 0);
- rt->rt6i_peer_genid = rt6_peer_genid();
- }
+ if (rt->rt6i_node && (rt->rt6i_node->fn_sernum == cookie))
return dst;
- }
+
return NULL;
}
--
1.7.4.1
^ permalink raw reply related
* Re: mmap RX_RING socket issue 32b application running on 64b kernel.
From: Daniel Borkmann @ 2012-11-08 8:00 UTC (permalink / raw)
To: Ronny Meeus; +Cc: netdev
In-Reply-To: <CAMJ=MEc1zHTr=X4dT6sD=sQKiLHe2p8F-0atHALBcRkMZidPdA@mail.gmail.com>
On Thu, Nov 8, 2012 at 8:32 AM, Ronny Meeus <ronny.meeus@gmail.com> wrote:
> On Wed, Nov 7, 2012 at 7:54 PM, Ronny Meeus <ronny.meeus@gmail.com> wrote:
>> On Wed, Nov 7, 2012 at 7:26 PM, Daniel Borkmann
>> <danborkmann@iogearbox.net> wrote:
>>> On Wed, Nov 7, 2012 at 6:58 PM, Ronny Meeus <ronny.meeus@gmail.com> wrote:
>>>> I have an application using raw Ethernet sockets in combination with
>>>> the mmaped RX_RING.
>>>> The application is running on a Cavium MIPS processor (64bit) and the
>>>> application code is compiled with the N32 ABI.
>>>>
>>>> Since the ring buffer is shared between the Linux kernel and the
>>>> application there is a conflict in the way the data is presented.
>>>> Each buffer in the ring has a header that has following structure:
>>>> (File http://lxr.free-electrons.com/source/include/linux/if_packet.h )
>>>> 103 struct tpacket_hdr {
>>>> 104 unsigned long tp_status;
>>>> 105 unsigned int tp_len;
>>>> 106 unsigned int tp_snaplen;
>>>> 107 unsigned short tp_mac;
>>>> 108 unsigned short tp_net;
>>>> 109 unsigned int tp_sec;
>>>> 110 unsigned int tp_usec;
>>>> 111 };
>>>>
>>>> The status field indicates that the buffer belongs to the kernel or to
>>>> the user. Note that an unsigned long is used to represent the field.
>>>> In the kernel the long is 64 bit while in application space the long
>>>> is only 32bit, so the bits do not match.
>>>>
>>>> After adapting the code to take this into account my program works well.
>>>> In my test program I have defined a new struct where I change the
>>>> “unsigned long” into an “unsigned long long”:
>>>>
>>>> struct tpacket_hdr_64 {
>>>> unsigned long long tp_status;
>>>> unsigned int tp_len;
>>>> unsigned int tp_snaplen;
>>>> unsigned short tp_mac;
>>>> unsigned short tp_net;
>>>> unsigned int tp_sec;
>>>> unsigned int tp_usec;
>>>> };
>>>>
>>>> In my opinion this is not a correct solution. It should be solved
>>>> somewhere in the include file I used so that it is transparent for the
>>>> application.
>>>> Please comment.
>>>
>>> Have you tried to use packet_mmap with TPACKET version 2 [1]?
>>>
>>> In my understanding, it was introduced because of such issues that you
>>> described.
>>>
>>> [1] E.g. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=bbd6ef87c544d88c30e4b762b1b61ef267a7d279
>>
>> I did not try this. I will do it tomorrow.
>> Thanks for the quick response.
>
> With the code below it indeed works.
>
> req.tp_block_size = FRAME_SIZE * NR_FRAMES_PER_BLOCK;
> req.tp_frame_size = FRAME_SIZE;
> req.tp_block_nr = NR_FRAMES / NR_FRAMES_PER_BLOCK;
> req.tp_frame_nr = NR_FRAMES;
>
> val = TPACKET_V2;
> setsockopt(eth_sock, SOL_PACKET,PACKET_VERSION, &val, sizeof(val));
> setsockopt(eth_sock,SOL_PACKET,PACKET_RX_RING,(char *)&req,sizeof(req));
> packet_mem = mmap(NULL,req.tp_block_size * req.tp_block_nr,
> PROT_READ|PROT_WRITE|PROT_EXEC,MAP_SHARED,eth_sock, 0);
>
> I wonder why there are so many examples available on the Internet that
> either do not set the version or set the version to 1.
Maybe it should be documented somewhere. ;)
> I would assume that the only correct usage of this interface is to use
> version 2 since this is working on all platforms.
> Is this correct?
For using RX_RING/TX_RING ... yep. I think version 1 is only for
backwards compatibility.
^ permalink raw reply
* [PATCH] ipv6: fix two typos in a comment in xfrm6_init()
From: roy.qing.li @ 2012-11-08 8:38 UTC (permalink / raw)
To: netdev
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. It
* would be good to do the same thing for v6, except the table is
* constructed differently here. Here each table for a net namespace
- * can have FIB_TABLE_HASHSZ entries, so lets go with the same
+ * can have FIB6_TABLE_HASHSZ entries, so lets go with the same
* computation that we used for ipv4 here. Also, lets keep the initial
* gc_thresh to a minimum of 1024, since, the ipv6 route cache defaults
* to that as a minimum as well
--
1.7.4.1
^ permalink raw reply related
* [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: Fengguang Wu @ 2012-11-08 9:38 UTC (permalink / raw)
To: Merav Sicron; +Cc: Dmitry Kravkov, Eilon Greenstein, netdev
[-- Attachment #1: Type: text/plain, Size: 12294 bytes --]
Hi Merav,
FYI, there are new sparse warnings show up in
tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: f1e0b5b4f1eae56a3192688177f36e2bdf0e01ac
commit: 55c11941e382cb26010138ab824216f47af37606 [232/235] bnx2x: Support loading cnic resources at run-time
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2465:55: sparse: Using plain integer as NULL pointer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2490:55: sparse: Using plain integer as NULL pointer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2506:39: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2506:39: expected unsigned short [unsigned] [usertype] vif_list_index
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2506:39: got restricted __le16 [usertype] <noident>
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3013:30: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3013:30: expected restricted __le32 [usertype] hi
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3013:30: got unsigned int [unsigned] [usertype] <noident>
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3014:30: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3014:30: expected restricted __le32 [usertype] lo
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3014:30: got unsigned int [unsigned] [usertype] <noident>
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3102:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3102:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3102:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3102:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3105:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3105:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3105:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3105:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3105:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3110:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3110:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3110:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3110:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3110:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3115:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3115:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3115:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3115:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3115:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3120:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3120:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3120:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3120:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3123:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3123:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3123:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3123:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3126:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3126:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3126:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3126:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3129:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3129:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3129:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3129:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3132:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3132:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3132:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3132:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3135:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3135:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3135:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3135:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3135:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3140:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3140:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3140:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3140:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3140:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3145:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3145:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3145:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3145:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3145:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3150:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3150:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3150:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3150:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3153:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3153:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3153:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3153:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3156:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3156:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3156:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3156:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3159:17: sparse: invalid assignment: +=
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3159:17: left side has type unsigned int
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3159:17: right side has type restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:3159:17: sparse: restricted __le32 degrades to integer
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:4815:23: sparse: cast to restricted __le32
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5279:51: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5279:51: expected restricted __le32 [addressable] [assigned] [usertype] hi
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5279:51: got unsigned int [unsigned] [usertype] <noident>
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5280:51: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5280:51: expected restricted __le32 [addressable] [assigned] [usertype] lo
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5280:51: got unsigned int [unsigned] [usertype] <noident>
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5294:52: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5294:52: expected restricted __le32 [addressable] [assigned] [usertype] hi
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5294:52: got unsigned int [unsigned] [usertype] <noident>
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5295:52: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5295:52: expected restricted __le32 [addressable] [assigned] [usertype] lo
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5295:52: got unsigned int [unsigned] [usertype] <noident>
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5398:41: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5398:41: expected restricted __le32 [addressable] [assigned] [usertype] lo
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5398:41: got unsigned int [unsigned] [usertype] <noident>
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5399:41: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5399:41: expected restricted __le32 [addressable] [assigned] [usertype] hi
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:5399:41: got unsigned int [unsigned] [usertype] <noident>
+ drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:7053:6: sparse: symbol 'bnx2x_init_searcher' was not declared. Should it be static?
+ drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:7083:5: sparse: symbol 'bnx2x_reset_nic_mode' was not declared. Should it be static?
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:7970:5: sparse: symbol 'bnx2x_setup_tx_only' was not declared. Should it be static?
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:9013:5: sparse: symbol 'bnx2x_leader_reset' was not declared. Should it be static?
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:10292:16: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:10292:16: expected unsigned short [unsigned] [usertype] mac_hi
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:10292:16: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:10293:16: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:10293:16: expected unsigned int [unsigned] [usertype] mac_lo
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:10293:16: got restricted __be32 [usertype] <noident>
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:11688:21: sparse: cast to restricted __be16
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:11688:21: sparse: cast to restricted __be16
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:11688:21: sparse: cast to restricted __be16
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:11688:21: sparse: cast to restricted __be16
Please consider folding the attached diff :-)
---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu Intel Corporation
[-- Attachment #2: make-it-static-55c1194.diff --]
[-- Type: text/x-diff, Size: 1732 bytes --]
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 0546cf4..49dec05 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -1482,7 +1482,7 @@ static void bnx2x_igu_int_disable(struct bnx2x *bp)
BNX2X_ERR("BUG! proper val not read from IGU!\n");
}
-void bnx2x_int_disable(struct bnx2x *bp)
+static void bnx2x_int_disable(struct bnx2x *bp)
{
if (bp->common.int_block == INT_BLOCK_HC)
bnx2x_hc_int_disable(bp);
@@ -7050,7 +7050,7 @@ static void bnx2x_clear_func_ilt(struct bnx2x *bp, u32 func)
}
-void bnx2x_init_searcher(struct bnx2x *bp)
+static void bnx2x_init_searcher(struct bnx2x *bp)
{
int port = BP_PORT(bp);
bnx2x_src_init_t2(bp, bp->t2, bp->t2_mapping, SRC_CONN_NUM);
@@ -7080,7 +7080,7 @@ static inline int bnx2x_func_switch_update(struct bnx2x *bp, int suspend)
return rc;
}
-int bnx2x_reset_nic_mode(struct bnx2x *bp)
+static int bnx2x_reset_nic_mode(struct bnx2x *bp)
{
int rc, i, port = BP_PORT(bp);
int vlan_en = 0, mac_en[NUM_MACS];
@@ -7967,7 +7967,7 @@ static void bnx2x_pf_q_prep_init(struct bnx2x *bp,
}
}
-int bnx2x_setup_tx_only(struct bnx2x *bp, struct bnx2x_fastpath *fp,
+static int bnx2x_setup_tx_only(struct bnx2x *bp, struct bnx2x_fastpath *fp,
struct bnx2x_queue_state_params *q_params,
struct bnx2x_queue_setup_tx_only_params *tx_only_params,
int tx_index, bool leading)
@@ -9010,7 +9010,7 @@ static int bnx2x_process_kill(struct bnx2x *bp, bool global)
return 0;
}
-int bnx2x_leader_reset(struct bnx2x *bp)
+static int bnx2x_leader_reset(struct bnx2x *bp)
{
int rc = 0;
bool global = bnx2x_reset_is_global(bp);
^ permalink raw reply related
* [PATCH] xfrm: remove redundant replay_esn check
From: Ulrich Weber @ 2012-11-08 10:15 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
x->replay_esn is already checked in if clause,
so remove check and ident properly
Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
---
net/xfrm/xfrm_replay.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/net/xfrm/xfrm_replay.c b/net/xfrm/xfrm_replay.c
index 3efb07d..765f6fe 100644
--- a/net/xfrm/xfrm_replay.c
+++ b/net/xfrm/xfrm_replay.c
@@ -521,13 +521,12 @@ int xfrm_init_replay(struct xfrm_state *x)
replay_esn->bmp_len * sizeof(__u32) * 8)
return -EINVAL;
- if ((x->props.flags & XFRM_STATE_ESN) && replay_esn->replay_window == 0)
- return -EINVAL;
-
- if ((x->props.flags & XFRM_STATE_ESN) && x->replay_esn)
- x->repl = &xfrm_replay_esn;
- else
- x->repl = &xfrm_replay_bmp;
+ if (x->props.flags & XFRM_STATE_ESN) {
+ if (replay_esn->replay_window == 0)
+ return -EINVAL;
+ x->repl = &xfrm_replay_esn;
+ } else
+ x->repl = &xfrm_replay_bmp;
} else
x->repl = &xfrm_replay_legacy;
--
1.7.9.5
^ permalink raw reply related
* SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
From: pkill.2012 @ 2012-11-08 11:15 UTC (permalink / raw)
To: linux-kernel, netdev, kvm
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.
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
--
^ permalink raw reply
* LETTER FROM MRS KATE
From: kate johnson @ 2012-11-08 10:56 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
--
I'm Mrs Kate Johnson from Ireland, suffering from breast cancer wish has got to
stage 4 and my doctor has made understand that i will not be able to live for
more than a month please read the attach file to know why i contacted you.
[-- Attachment #2: Document.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 11720 bytes --]
^ permalink raw reply
* Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
From: Jeff Kirsher @ 2012-11-08 11:23 UTC (permalink / raw)
To: pkill.2012; +Cc: linux-kernel, netdev, kvm, e1000-devel, Greg Rose
In-Reply-To: <201211081915083774239@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 21129 bytes --]
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.
>
> 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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* [PATCH net-next] doc: packet_mmap: update doc to implementation status
From: Daniel Borkmann @ 2012-11-08 12:37 UTC (permalink / raw)
To: davem; +Cc: Ronny Meeus, Ulisses Alonso Camaró, Johann Baudy, netdev
This improves the packet_mmap.txt document in the following ways:
* Add initial information about different TPACKET versions
* Add initial information about packet fanout
* Add pointer to BPF document (since this also could be of interest)
* 'Fix' minor, rather cosmetic things
Information partially taken from related commit messages.
Reported-by: Ronny Meeus <ronny.meeus@gmail.com>
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Cc: Ulisses Alonso Camaró <uaca@alumni.uv.es>
Cc: Johann Baudy <johann.baudy@gnu-log.net>
---
Documentation/networking/packet_mmap.txt | 233 +++++++++++++++++++++++++++---
1 files changed, 209 insertions(+), 24 deletions(-)
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 7cd879e..241364f 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -3,9 +3,9 @@
--------------------------------------------------------------------------------
This file documents the mmap() facility available with the PACKET
-socket interface on 2.4 and 2.6 kernels. This type of sockets is used for
-capture network traffic with utilities like tcpdump or any other that needs
-raw access to network interface.
+socket interface on 2.4/2.6/3.x kernels. This type of sockets is used for
+i) capture network traffic with utilities like tcpdump, ii) transmit network
+traffic, or any other that needs raw access to network interface.
You can find the latest version of this document at:
http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap
@@ -21,19 +21,18 @@ Please send your comments to
+ Why use PACKET_MMAP
--------------------------------------------------------------------------------
-In Linux 2.4/2.6 if PACKET_MMAP is not enabled, the capture process is very
-inefficient. It uses very limited buffers and requires one system call
-to capture each packet, it requires two if you want to get packet's
-timestamp (like libpcap always does).
+In Linux 2.4/2.6/3.x if PACKET_MMAP is not enabled, the capture process is very
+inefficient. It uses very limited buffers and requires one system call to
+capture each packet, it requires two if you want to get packet's timestamp
+(like libpcap always does).
In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size
configurable circular buffer mapped in user space that can be used to either
send or receive packets. This way reading packets just needs to wait for them,
most of the time there is no need to issue a single system call. Concerning
transmission, multiple packets can be sent through one system call to get the
-highest bandwidth.
-By using a shared buffer between the kernel and the user also has the benefit
-of minimizing packet copies.
+highest bandwidth. By using a shared buffer between the kernel and the user
+also has the benefit of minimizing packet copies.
It's fine to use PACKET_MMAP to improve the performance of the capture and
transmission process, but it isn't everything. At least, if you are capturing
@@ -41,7 +40,8 @@ at high speeds (this is relative to the cpu speed), you should check if the
device driver of your network interface card supports some sort of interrupt
load mitigation or (even better) if it supports NAPI, also make sure it is
enabled. For transmission, check the MTU (Maximum Transmission Unit) used and
-supported by devices of your network.
+supported by devices of your network. CPU IRQ pinning of your network interface
+card can also be an advantage.
--------------------------------------------------------------------------------
+ How to use mmap() to improve capture process
@@ -87,9 +87,7 @@ the following process:
socket creation and destruction is straight forward, and is done
the same way with or without PACKET_MMAP:
-int fd;
-
-fd= socket(PF_PACKET, mode, htons(ETH_P_ALL))
+ int fd = socket(PF_PACKET, mode, htons(ETH_P_ALL));
where mode is SOCK_RAW for the raw interface were link level
information can be captured or SOCK_DGRAM for the cooked
@@ -180,7 +178,6 @@ and the PACKET_TX_HAS_OFF option.
+ PACKET_MMAP settings
--------------------------------------------------------------------------------
-
To setup PACKET_MMAP from user level code is done with a call like
- Capture process
@@ -214,7 +211,6 @@ indeed, packet_set_ring checks that the following condition is true
frames_per_block * tp_block_nr == tp_frame_nr
-
Lets see an example, with the following values:
tp_block_size= 4096
@@ -240,7 +236,6 @@ be spawned across two blocks, so there are some details you have to take into
account when choosing the frame_size. See "Mapping and use of the circular
buffer (ring)".
-
--------------------------------------------------------------------------------
+ PACKET_MMAP setting constraints
--------------------------------------------------------------------------------
@@ -277,7 +272,6 @@ User space programs can include /usr/include/sys/user.h and
The pagesize can also be determined dynamically with the getpagesize (2)
system call.
-
Block number limit
--------------------
@@ -297,7 +291,6 @@ called pg_vec, its size limits the number of blocks that can be allocated.
v block #2
block #1
-
kmalloc allocates any number of bytes of physically contiguous memory from
a pool of pre-determined sizes. This pool of memory is maintained by the slab
allocator which is at the end the responsible for doing the allocation and
@@ -312,7 +305,6 @@ pointers to blocks is
131072/4 = 32768 blocks
-
PACKET_MMAP buffer size calculator
------------------------------------
@@ -353,7 +345,6 @@ and a value for <frame size> of 2048 bytes. These parameters will yield
and hence the buffer will have a 262144 MiB size. So it can hold
262144 MiB / 2048 bytes = 134217728 frames
-
Actually, this buffer size is not possible with an i386 architecture.
Remember that the memory is allocated in kernel space, in the case of
an i386 kernel's memory size is limited to 1GiB.
@@ -385,7 +376,6 @@ the following (from include/linux/if_packet.h):
- Start+tp_net: Packet data, aligned to TPACKET_ALIGNMENT=16.
- Pad to align to TPACKET_ALIGNMENT=16
*/
-
The following are conditions that are checked in packet_set_ring
@@ -426,7 +416,6 @@ and the following flags apply:
#define TP_STATUS_LOSING 4
#define TP_STATUS_CSUMNOTREADY 8
-
TP_STATUS_COPY : This flag indicates that the frame (and associated
meta information) has been truncated because it's
larger than tp_frame_size. This packet can be
@@ -475,7 +464,6 @@ packets are in the ring:
It doesn't incur in a race condition to first check the status value and
then poll for frames.
-
++ Transmission process
Those defines are also used for transmission:
@@ -507,6 +495,196 @@ The user can also use poll() to check if a buffer is available:
retval = poll(&pfd, 1, timeout);
-------------------------------------------------------------------------------
++ What TPACKET versions are available and when to use them?
+-------------------------------------------------------------------------------
+
+ int val = tpacket_version;
+ setsockopt(fd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val));
+ getsockopt(fd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val));
+
+where 'tpacket_version' can be TPACKET_V1 (default), TPACKET_V2, TPACKET_V3.
+
+TPACKET_V1:
+ - Default if not otherwise specified by setsockopt(2)
+ - RX_RING, TX_RING available
+ - VLAN metadata information available for packets
+ (TP_STATUS_VLAN_VALID)
+
+TPACKET_V1 --> TPACKET_V2:
+ - Made 64 bit clean due to unsigned long usage in TPACKET_V1
+ structures, thus this also works on 64 bit kernel with 32 bit
+ userspace and the like
+ - Timestamp resolution in nanoseconds instead of microseconds
+ - RX_RING, TX_RING available
+ - How to switch to TPACKET_V2:
+ 1. Replace struct tpacket_hdr by struct tpacket2_hdr
+ 2. Query header len and save
+ 3. Set protocol version to 2, set up ring as usual
+ 4. For getting the sockaddr_ll,
+ use (void *)hdr + TPACKET_ALIGN(hdrlen) instead of
+ (void *)hdr + TPACKET_ALIGN(sizeof(struct tpacket_hdr))
+
+TPACKET_V2 --> TPACKET_V3:
+ - Flexible buffer implementation:
+ 1. Blocks can be configured with non-static frame-size
+ 2. Read/poll is at a block-level (as opposed to packet-level)
+ 3. Added poll timeout to avoid indefinite user-space wait
+ on idle links
+ 4. Added user-configurable knobs:
+ 4.1 block::timeout
+ 4.2 tpkt_hdr::sk_rxhash
+ - RX Hash data available in user space
+ - Currently only RX_RING available
+
+-------------------------------------------------------------------------------
++ AF_PACKET fanout mode
+-------------------------------------------------------------------------------
+
+In the AF_PACKET fanout mode, packet reception can be load balanced among
+processes. This also works in combination with mmap(2) on packet sockets.
+
+Minimal example code by David S. Miller (try things like "./test eth0 hash",
+"./test eth0 lb", etc.):
+
+#include <stddef.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <sys/socket.h>
+#include <sys/ioctl.h>
+
+#include <unistd.h>
+
+#include <linux/if_ether.h>
+#include <linux/if_packet.h>
+
+#include <net/if.h>
+
+static const char *device_name;
+static int fanout_type;
+static int fanout_id;
+
+#ifndef PACKET_FANOUT
+# define PACKET_FANOUT 18
+# define PACKET_FANOUT_HASH 0
+# define PACKET_FANOUT_LB 1
+#endif
+
+static int setup_socket(void)
+{
+ int err, fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_IP));
+ struct sockaddr_ll ll;
+ struct ifreq ifr;
+ int fanout_arg;
+
+ if (fd < 0) {
+ perror("socket");
+ return EXIT_FAILURE;
+ }
+
+ memset(&ifr, 0, sizeof(ifr));
+ strcpy(ifr.ifr_name, device_name);
+ err = ioctl(fd, SIOCGIFINDEX, &ifr);
+ if (err < 0) {
+ perror("SIOCGIFINDEX");
+ return EXIT_FAILURE;
+ }
+
+ memset(&ll, 0, sizeof(ll));
+ ll.sll_family = AF_PACKET;
+ ll.sll_ifindex = ifr.ifr_ifindex;
+ err = bind(fd, (struct sockaddr *) &ll, sizeof(ll));
+ if (err < 0) {
+ perror("bind");
+ return EXIT_FAILURE;
+ }
+
+ fanout_arg = (fanout_id | (fanout_type << 16));
+ err = setsockopt(fd, SOL_PACKET, PACKET_FANOUT,
+ &fanout_arg, sizeof(fanout_arg));
+ if (err) {
+ perror("setsockopt");
+ return EXIT_FAILURE;
+ }
+
+ return fd;
+}
+
+static void fanout_thread(void)
+{
+ int fd = setup_socket();
+ int limit = 10000;
+
+ if (fd < 0)
+ exit(fd);
+
+ while (limit-- > 0) {
+ char buf[1600];
+ int err;
+
+ err = read(fd, buf, sizeof(buf));
+ if (err < 0) {
+ perror("read");
+ exit(EXIT_FAILURE);
+ }
+ if ((limit % 10) == 0)
+ fprintf(stdout, "(%d) \n", getpid());
+ }
+
+ fprintf(stdout, "%d: Received 10000 packets\n", getpid());
+
+ close(fd);
+ exit(0);
+}
+
+int main(int argc, char **argp)
+{
+ int fd, err;
+ int i;
+
+ if (argc != 3) {
+ fprintf(stderr, "Usage: %s INTERFACE {hash|lb}\n", argp[0]);
+ return EXIT_FAILURE;
+ }
+
+ if (!strcmp(argp[2], "hash"))
+ fanout_type = PACKET_FANOUT_HASH;
+ else if (!strcmp(argp[2], "lb"))
+ fanout_type = PACKET_FANOUT_LB;
+ else {
+ fprintf(stderr, "Unknown fanout type [%s]\n", argp[2]);
+ exit(EXIT_FAILURE);
+ }
+
+ device_name = argp[1];
+ fanout_id = getpid() & 0xffff;
+
+ for (i = 0; i < 4; i++) {
+ pid_t pid = fork();
+
+ switch (pid) {
+ case 0:
+ fanout_thread();
+
+ case -1:
+ perror("fork");
+ exit(EXIT_FAILURE);
+ }
+ }
+
+ for (i = 0; i < 4; i++) {
+ int status;
+
+ wait(&status);
+ }
+
+ return 0;
+}
+
+-------------------------------------------------------------------------------
+ PACKET_TIMESTAMP
-------------------------------------------------------------------------------
@@ -532,6 +710,13 @@ the networking stack is used (the behavior before this setting was added).
See include/linux/net_tstamp.h and Documentation/networking/timestamping
for more information on hardware timestamps.
+-------------------------------------------------------------------------------
++ Miscellaneous bits
+-------------------------------------------------------------------------------
+
+- Packet sockets work well together with Linux socket filters, thus you also
+ might want to have a look at Documentation/networking/filter.txt
+
--------------------------------------------------------------------------------
+ THANKS
--------------------------------------------------------------------------------
^ permalink raw reply related
* Re: [net-next:master 209/235] drivers/net/usb/smsc95xx.c:1134:39-50: ERROR: reference preceded by free on line 1136
From: Fengguang Wu @ 2012-11-08 12:40 UTC (permalink / raw)
To: Julia Lawall
Cc: Yuanhan Liu, changlongx.xie, Steve Glendinning,
netdev@vger.kernel.org, linux-usb, LKML
In-Reply-To: <alpine.DEB.2.02.1211080907340.1945@localhost6.localdomain6>
Julia,
On Thu, Nov 08, 2012 at 09:08:04AM +0100, Julia Lawall wrote:
> It's a false positive because check_warn_return does a return.
Right.
> But I wonder if there is a way that we can encourage people not to
> do things like that?
Well I suspect the memory leak bug 06a221be0 tries to fix might be
due to check_warn_return() hiding the otherwise very obvious syntax
highlighted 'return' statement.
Thanks,
Fengguang
> >TO: Ming Lei <ming.lei@canonical.com>
> >CC: netdev@vger.kernel.org
> >
> >
> >Hi Ming,
> >
> >FYI, there are coccinelle warnings in
> >
> >tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
> >head: f1e0b5b4f1eae56a3192688177f36e2bdf0e01ac
> >commit: 06a221be022c2cc98a48e0808a4ef0dc8f0b3a34 [209/235] usbnet: smsc95xx: fix memory leak in smsc95xx_suspend
> >:::::: branch date: 8 hours ago
> >:::::: commit date: 23 hours ago
> >
> >+ drivers/net/usb/smsc95xx.c:1134:39-50: ERROR: reference preceded by free on line 1136
> > drivers/net/usb/smsc95xx.c:1139:8-19: ERROR: reference preceded by free on line 1136
> >
> >git remote update net-next
> >git checkout 06a221be022c2cc98a48e0808a4ef0dc8f0b3a34
> >vim +1134 drivers/net/usb/smsc95xx.c
> >
> >bbd9f9ee Steve Glendinning 2012-10-26 1128 offset[filter/4] |= 0x00 << ((filter % 4) * 8);
> >bbd9f9ee Steve Glendinning 2012-10-26 1129 crc[filter/2] |= smsc_crc(dev->net->dev_addr, ETH_ALEN, filter);
> >bbd9f9ee Steve Glendinning 2012-10-26 1130 filter++;
> >bbd9f9ee Steve Glendinning 2012-10-26 1131 }
> >bbd9f9ee Steve Glendinning 2012-10-26 1132
> >bbd9f9ee Steve Glendinning 2012-10-26 1133 for (i = 0; i < (pdata->wuff_filter_count * 4); i++) {
> >bbd9f9ee Steve Glendinning 2012-10-26 @1134 ret = smsc95xx_write_reg(dev, WUFF, filter_mask[i]);
> >06a221be Ming Lei 2012-11-06 1135 if (ret < 0)
> >06a221be Ming Lei 2012-11-06 @1136 kfree(filter_mask);
> >bbd9f9ee Steve Glendinning 2012-10-26 1137 check_warn_return(ret, "Error writing WUFF");
> >bbd9f9ee Steve Glendinning 2012-10-26 1138 }
> >06a221be Ming Lei 2012-11-06 1139 kfree(filter_mask);
> >
> >:::::: The code at line 1134 was first introduced by commit:
> >:::::: bbd9f9e smsc95xx: add wol support for more frame types
> >
> >:::::: TO: Steve Glendinning <steve.glendinning@shawell.net>
> >:::::: CC: David S. Miller <davem@davemloft.net>
> >
> >---
> >0-DAY kernel build testing backend Open Source Technology Center
> >Fengguang Wu, Yuanhan Liu Intel Corporation
> >
^ 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: Merav Sicron @ 2012-11-08 16:09 UTC (permalink / raw)
To: Fengguang Wu; +Cc: Dmitry Kravkov, Eilon Greenstein, netdev
In-Reply-To: <20121108093805.GA1891@localhost>
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
^ permalink raw reply
* Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: Mugunthan V N @ 2012-11-08 12:59 UTC (permalink / raw)
To: Benoit Cousson
Cc: Vaibhav Hiremath, netdev, paul, linux-arm-kernel, linux-omap,
Richard Cochran
In-Reply-To: <50914107.2090909@ti.com>
On 10/31/2012 8:47 PM, Benoit Cousson wrote:
> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> index c634f87..e233cfa 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -78,3 +78,11 @@
> };
> };
> };
> +
> +&cpsw_emac0 {
> + phy_id = "4a101000.mdio:00";
> Why are you using that kind of interface? You seem to want a reference
> to a device.
>
> Cannot you have something less hard coded like:
> phy_id = <&davinci_mdio>, <0>;
Benoit
I am having a issue in converting the above phy_id conversion from
"<&davinci_mdio>, <0>" to
"4a101000.mdio:00". Since davinci_mdio is a child node to cpsw, the
platform device for mdio is
not created to get the mdio device name "4a101000.mdio".
Can you point me a reference to get the right implementation.
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH 1/4 net-next] net: allow skb->head to be a page fragment
From: Eric Dumazet @ 2012-11-08 13:30 UTC (permalink / raw)
To: Li Yu; +Cc: Linux Netdev List
In-Reply-To: <509B6368.9010206@gmail.com>
On Thu, 2012-11-08 at 15:46 +0800, Li Yu wrote:
> I think that all kmalloced() objects are continuous on both virtual
> and physical address space, so such page fragment converting should be
> safe until we use slab allocator to free them.
>
Its not safe at all. Good luck with coping with SLAB, SLUB, SLOB, and
various debugging facilities on top of them.
> I ask this question since I am working on a patch to try to directly
> forward the data from rx queue of a socket to tx queue of another
> socket. We noticed that the splice itself still has visible costs when
> forwarding small messages, and hope such direct forwarding optimization
> can improve this, this idea comes from TCP friends.
If not using splice, you directly transfert one skb coming from one
side, to the other side, so you dont care skb->head being a frag or not.
If messages are small, there is probably no hope trying to coalesce them
(or else fixing the application would be much easier)
^ permalink raw reply
* [PATCH][net-next] gianfar: Fix alloc_skb_resources on -ENOMEM cleanup path
From: Claudiu Manoil @ 2012-11-08 13:40 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>
---
drivers/net/ethernet/freescale/gianfar.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 1d03dcd..c5c82ad 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -311,7 +311,7 @@ static int gfar_alloc_skb_resources(struct net_device *ndev)
}
if (gfar_init_bds(ndev))
- goto cleanup;
+ return -ENOMEM;
return 0;
@@ -1356,7 +1356,9 @@ static int gfar_restore(struct device *dev)
if (!netif_running(ndev))
return 0;
- gfar_init_bds(ndev);
+ if (gfar_init_bds(ndev))
+ return -ENOMEM;
+
init_registers(ndev);
gfar_set_mac_address(ndev);
gfar_init_mac(ndev);
@@ -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
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