Re: Multicast issues with RTL8110SC in r8169.c
Francois Romieu wrote: Glen Gray <[EMAIL PROTECTED]> : Hey Francois, I've CC'd the netdev list as requested Your PR is not lost (nor are the pending ones btw...). I'm simply trying to find a real explanation for https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242572 Ah, apologies. When I couldn't see my follow up posts hitting the list, I figured I'd sign up and post it again. The linked bug entry indicates issues with the driver initializing certain cards etc. As previously stated, my issue was mainly in multicast. I was able to get the machine up and on the network without issue in the 2.6.21 kernel from F7. Though there's obviously issues with the newer Realtek cards and the post 2.6.20 kernels. FYI, The Realtek driver release 1.06 (r1000.ko), although not officially supporting the 2.6 kernel (the Makefile just needed modification) works extremely well for us here. If I can help test experimental patchs or anything, please don't hesitate to let me know. -- Glen Gray <[EMAIL PROTECTED]> Digital Depot, Thomas Street Senior Software EngineerDublin 8, Ireland Lincor Solutions Ltd. Ph: +353 (0) 1 4893682 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT 4/4] fib_trie: whitespace cleanup
Try and be consistent with whitespace and line wrapping.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/ipv4/fib_trie.c 2007-07-27 08:57:53.0 +0100
+++ b/net/ipv4/fib_trie.c 2007-07-27 08:57:54.0 +0100
@@ -154,7 +154,8 @@ struct trie {
};
static void put_child(struct trie *t, struct tnode *tn, int i, struct node *n);
-static void tnode_put_child_reorg(struct tnode *tn, int i, struct node *n, int
wasfull);
+static void tnode_put_child_reorg(struct tnode *tn, int i, struct node *n,
+ int wasfull);
static struct node *resize(struct trie *t, struct tnode *tn);
static struct tnode *inflate(struct trie *t, struct tnode *tn);
static struct tnode *halve(struct trie *t, struct tnode *tn);
@@ -222,7 +223,7 @@ static inline int tkey_mismatch(t_key a,
if (!diff)
return 0;
- while ((diff << i) >> (KEYLENGTH-1) == 0)
+ while ((diff << i) >> (KEYLENGTH - 1) == 0)
i++;
return i;
}
@@ -284,7 +285,6 @@ static inline int tkey_mismatch(t_key a,
The bits from (n->pos) to (n->pos + n->bits - 1) - "C" - are the index into
n's child array, and will of course be different for each child.
-
The rest of the bits, from (n->pos + n->bits) onward, are completely unknown
at this point.
@@ -292,7 +292,7 @@ static inline int tkey_mismatch(t_key a,
static inline void check_tnode(const struct tnode *tn)
{
- WARN_ON(tn && tn->pos+tn->bits > 32);
+ WARN_ON(tn && tn->pos + tn->bits > 32);
}
static int halve_threshold = 25;
@@ -300,7 +300,6 @@ static int inflate_threshold = 50;
static int halve_threshold_root = 8;
static int inflate_threshold_root = 15;
-
static void __alias_free_mem(struct rcu_head *head)
{
struct fib_alias *fa = container_of(head, struct fib_alias, rcu);
@@ -334,7 +333,7 @@ static struct tnode *tnode_alloc(unsigne
if (size <= PAGE_SIZE)
return kcalloc(size, 1, GFP_KERNEL);
- pages = alloc_pages(GFP_KERNEL|__GFP_ZERO, get_order(size));
+ pages = alloc_pages(GFP_KERNEL | __GFP_ZERO, get_order(size));
if (!pages)
return NULL;
@@ -345,7 +344,7 @@ static void __tnode_free_rcu(struct rcu_
{
struct tnode *tn = container_of(head, struct tnode, rcu);
unsigned int size = sizeof(struct tnode) +
- (1 << tn->bits) * sizeof(struct node *);
+ (1 << tn->bits) * sizeof(struct node *);
if (size <= PAGE_SIZE)
kfree(tn);
@@ -356,7 +355,7 @@ static void __tnode_free_rcu(struct rcu_
static inline void tnode_free(struct tnode *tn)
{
if (IS_LEAF(tn)) {
- struct leaf *l = (struct leaf *) tn;
+ struct leaf *l = (struct leaf *)tn;
call_rcu_bh(&l->rcu, __leaf_free_rcu);
} else
call_rcu(&tn->rcu, __tnode_free_rcu);
@@ -364,7 +363,7 @@ static inline void tnode_free(struct tno
static struct leaf *leaf_new(void)
{
- struct leaf *l = kmalloc(sizeof(struct leaf), GFP_KERNEL);
+ struct leaf *l = kmalloc(sizeof(struct leaf), GFP_KERNEL);
if (l) {
l->parent = T_LEAF;
INIT_HLIST_HEAD(&l->list);
@@ -374,7 +373,7 @@ static struct leaf *leaf_new(void)
static struct leaf_info *leaf_info_new(int plen)
{
- struct leaf_info *li = kmalloc(sizeof(struct leaf_info), GFP_KERNEL);
+ struct leaf_info *li = kmalloc(sizeof(struct leaf_info), GFP_KERNEL);
if (li) {
li->plen = plen;
INIT_LIST_HEAD(&li->falh);
@@ -382,9 +381,9 @@ static struct leaf_info *leaf_info_new(i
return li;
}
-static struct tnode* tnode_new(t_key key, int pos, int bits)
+static struct tnode *tnode_new(t_key key, int pos, int bits)
{
- int nchildren = 1key = key;
tn->full_children = 0;
- tn->empty_children = 1pos + tn->bits;
+ return ((struct tnode *)n)->pos == tn->pos + tn->bits;
}
-static inline void put_child(struct trie *t, struct tnode *tn, int i, struct
node *n)
+static inline void put_child(struct trie *t, struct tnode *tn, int i,
+struct node *n)
{
tnode_put_child_reorg(tn, i, n, -1);
}
@@ -426,13 +426,13 @@ static inline void put_child(struct trie
* Update the value of full_children and empty_children.
*/
-static void tnode_put_child_reorg(struct tnode *tn, int i, struct node *n, int
wasfull)
+static void tnode_put_child_reorg(struct tnode *tn, int i, struct node *n,
+ int wasfull)
{
struct node *chi = tn->child[i];
int isfull;
- BUG_ON(i >= 1= 1 << tn->bits);
/* update empty
[RFT 1/4] fib_trie: use inline for node_parent references
The use of macro's for set/referencing node parent causes issues with
the rcu macros. Convert them to inline and fix a couple of spots
where node_parent() was being called multiple times which added unneeded
barriers.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/ipv4/fib_trie.c 2007-07-27 07:34:25.0 +0100
+++ b/net/ipv4/fib_trie.c 2007-07-27 08:00:30.0 +0100
@@ -93,15 +93,8 @@ typedef unsigned int t_key;
#define T_TNODE 0
#define T_LEAF 1
#define NODE_TYPE_MASK 0x1UL
-#define NODE_PARENT(node) \
- ((struct tnode *)rcu_dereference(((node)->parent & ~NODE_TYPE_MASK)))
-
#define NODE_TYPE(node) ((node)->parent & NODE_TYPE_MASK)
-#define NODE_SET_PARENT(node, ptr) \
- rcu_assign_pointer((node)->parent, \
- ((unsigned long)(ptr)) | NODE_TYPE(node))
-
#define IS_TNODE(n) (!(n->parent & T_LEAF))
#define IS_LEAF(n) (n->parent & T_LEAF)
@@ -174,6 +167,16 @@ static void tnode_free(struct tnode *tn)
static struct kmem_cache *fn_alias_kmem __read_mostly;
static struct trie *trie_local = NULL, *trie_main = NULL;
+static inline struct tnode *node_parent(struct node *node)
+{
+ struct tnode *parent = (struct tnode *)(node->parent & ~NODE_TYPE_MASK);
+ return rcu_dereference(parent);
+}
+
+static inline void node_set_parent(struct node *node, struct tnode *ptr)
+{
+ rcu_assign_pointer(node->parent, (unsigned long)ptr | NODE_TYPE(node));
+}
/* rcu_read_lock needs to be hold by caller from readside */
@@ -446,7 +449,7 @@ static void tnode_put_child_reorg(struct
tn->full_children++;
if (n)
- NODE_SET_PARENT(n, tn);
+ node_set_parent(n, tn);
rcu_assign_pointer(tn->child[i], n);
}
@@ -481,7 +484,7 @@ static struct node *resize(struct trie *
continue;
/* compress one level */
- NODE_SET_PARENT(n, NULL);
+ node_set_parent(n, NULL);
tnode_free(tn);
return n;
}
@@ -636,7 +639,7 @@ static struct node *resize(struct trie *
/* compress one level */
- NODE_SET_PARENT(n, NULL);
+ node_set_parent(n, NULL);
tnode_free(tn);
return n;
}
@@ -961,24 +964,21 @@ fib_find_node(struct trie *t, u32 key)
static struct node *trie_rebalance(struct trie *t, struct tnode *tn)
{
int wasfull;
- t_key cindex, key;
- struct tnode *tp = NULL;
-
- key = tn->key;
+ t_key cindex, key = tn->key;
+ struct tnode *tp;
- while (tn != NULL && NODE_PARENT(tn) != NULL) {
-
- tp = NODE_PARENT(tn);
+ while (tn && (tp = node_parent((struct node *)tn)) ) {
cindex = tkey_extract_bits(key, tp->pos, tp->bits);
wasfull = tnode_full(tp, tnode_get_child(tp, cindex));
tn = (struct tnode *) resize (t, (struct tnode *)tn);
tnode_put_child_reorg((struct tnode *)tp, cindex,(struct
node*)tn, wasfull);
- if (!NODE_PARENT(tn))
+ tp = node_parent((struct node *) tn);
+ if (!tp)
break;
-
- tn = NODE_PARENT(tn);
+ tn = tp;
}
+
/* Handle last (top) tnode */
if (IS_TNODE(tn))
tn = (struct tnode*) resize(t, (struct tnode *)tn);
@@ -1031,7 +1031,7 @@ fib_insert_node(struct trie *t, int *err
pos = tn->pos + tn->bits;
n = tnode_get_child(tn, tkey_extract_bits(key, tn->pos,
tn->bits));
- BUG_ON(n && NODE_PARENT(n) != tn);
+ BUG_ON(n && node_parent(n) != tn);
} else
break;
}
@@ -1083,7 +1083,7 @@ fib_insert_node(struct trie *t, int *err
if (t->trie && n == NULL) {
/* Case 2: n is NULL, and will just insert a new leaf */
- NODE_SET_PARENT(l, tp);
+ node_set_parent((struct node *)l, tp);
cindex = tkey_extract_bits(key, tp->pos, tp->bits);
put_child(t, (struct tnode *)tp, cindex, (struct node *)l);
@@ -1114,7 +1114,7 @@ fib_insert_node(struct trie *t, int *err
goto err;
}
- NODE_SET_PARENT(tn, tp);
+ node_set_parent((struct node *)tn, tp);
missbit = tkey_extract_bits(key, newpos, 1);
put_child(t, tn, missbit, (struct node *)l);
@@ -1495,12 +1495,13 @@ backtrace:
if (chopped_off <= pn->bits) {
cindex &= ~(1 << (chopped_off-1));
} else {
- if (NODE_PARENT(pn) == NULL)
+ struct tnode *parent = node_parent((struct
[RFT 0/4] fib_trie cleanup patches
Here is a slightly revised version of the FIB trie cleanup patches. I don't have a machine with anywhere near enough routes to test this, so would someone with many routes give it a go and make sure nothing got busted in the process. -- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT 3/4] fib_trie: fix sparse warnings
There were a couple of places where sparse found declarations that covered
earlier declarations.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/ipv4/fib_trie.c 2007-07-27 08:41:46.0 +0100
+++ b/net/ipv4/fib_trie.c 2007-07-27 08:47:05.0 +0100
@@ -651,7 +651,6 @@ static struct node *resize(struct trie *
static struct tnode *inflate(struct trie *t, struct tnode *tn)
{
- struct tnode *inode;
struct tnode *oldtnode = tn;
int olen = tnode_child_length(tn);
int i;
@@ -700,7 +699,7 @@ static struct tnode *inflate(struct trie
for (i = 0; i < olen; i++) {
struct node *node = tnode_get_child(oldtnode, i);
- struct tnode *left, *right;
+ struct tnode *left, *right, *inode;
int size, j;
/* An empty child */
@@ -1049,7 +1048,7 @@ fib_insert_node(struct trie *t, int *err
/* Case 1: n is a leaf. Compare prefixes */
if (n != NULL && IS_LEAF(n) && tkey_equals(key, n->key)) {
- struct leaf *l = (struct leaf *) n;
+ struct leaf *nl = (struct leaf *) n;
li = leaf_info_new(plen);
@@ -1059,7 +1058,7 @@ fib_insert_node(struct trie *t, int *err
}
fa_head = &li->falh;
- insert_leaf_info(&l->list, li);
+ insert_leaf_info(&nl->list, li);
goto done;
}
t->size++;
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFT 2/4] fib_trie: convert macros to inline
Get rid of some of the macro's in this code. If only used once, just
expand the usage in that spot. Otherwise convert to inline.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/ipv4/fib_trie.c 2007-07-27 08:00:30.0 +0100
+++ b/net/ipv4/fib_trie.c 2007-07-27 08:41:22.0 +0100
@@ -85,16 +85,12 @@
#define MAX_STAT_DEPTH 32
#define KEYLENGTH (8*sizeof(t_key))
-#define MASK_PFX(k, l) (((l)==0)?0:(k >> (KEYLENGTH-l)) << (KEYLENGTH-l))
-#define TKEY_GET_MASK(offset, bits) (((bits)==0)?0:((t_key)(-1) << (KEYLENGTH
- bits) >> offset))
typedef unsigned int t_key;
#define T_TNODE 0
#define T_LEAF 1
#define NODE_TYPE_MASK 0x1UL
-#define NODE_TYPE(node) ((node)->parent & NODE_TYPE_MASK)
-
#define IS_TNODE(n) (!(n->parent & T_LEAF))
#define IS_LEAF(n) (n->parent & T_LEAF)
@@ -175,7 +171,8 @@ static inline struct tnode *node_parent(
static inline void node_set_parent(struct node *node, struct tnode *ptr)
{
- rcu_assign_pointer(node->parent, (unsigned long)ptr | NODE_TYPE(node));
+ rcu_assign_pointer(node->parent,
+ (unsigned long)ptr | (node->parent &
NODE_TYPE_MASK));
}
/* rcu_read_lock needs to be hold by caller from readside */
@@ -192,6 +189,11 @@ static inline int tnode_child_length(con
return 1 << tn->bits;
}
+static inline t_key mask_pfx(t_key k, unsigned short l)
+{
+ return (l == 0) ? 0 : k >> (KEYLENGTH - l) << (KEYLENGTH - l);
+}
+
static inline t_key tkey_extract_bits(t_key a, int offset, int bits)
{
if (offset < KEYLENGTH)
@@ -676,7 +678,7 @@ static struct tnode *inflate(struct trie
inode->pos == oldtnode->pos + oldtnode->bits &&
inode->bits > 1) {
struct tnode *left, *right;
- t_key m = TKEY_GET_MASK(inode->pos, 1);
+ t_key m = ~0U << (KEYLENGTH - 1) >> inode->pos;
left = tnode_new(inode->key&(~m), inode->pos + 1,
inode->bits - 1);
@@ -942,7 +944,7 @@ fib_find_node(struct trie *t, u32 key)
pos = 0;
n = rcu_dereference(t->trie);
- while (n != NULL && NODE_TYPE(n) == T_TNODE) {
+ while (n && IS_TNODE(n)) {
tn = (struct tnode *) n;
check_tnode(tn);
@@ -1021,7 +1023,7 @@ fib_insert_node(struct trie *t, int *err
* If it doesn't, we need to replace it with a T_TNODE.
*/
- while (n != NULL && NODE_TYPE(n) == T_TNODE) {
+ while (n && IS_TNODE(n)) {
tn = (struct tnode *) n;
check_tnode(tn);
@@ -1364,7 +1366,8 @@ fn_trie_lookup(struct fib_table *tb, con
bits = pn->bits;
if (!chopped_off)
- cindex = tkey_extract_bits(MASK_PFX(key,
current_prefix_length), pos, bits);
+ cindex = tkey_extract_bits(mask_pfx(key,
current_prefix_length),
+ pos, bits);
n = tnode_get_child(pn, cindex);
@@ -1450,8 +1453,8 @@ fn_trie_lookup(struct fib_table *tb, con
* to find a matching prefix.
*/
- node_prefix = MASK_PFX(cn->key, cn->pos);
- key_prefix = MASK_PFX(key, cn->pos);
+ node_prefix = mask_pfx(cn->key, cn->pos);
+ key_prefix = mask_pfx(key, cn->pos);
pref_mismatch = key_prefix^node_prefix;
mp = 0;
@@ -2327,7 +2330,7 @@ static int fib_trie_seq_show(struct seq_
if (IS_TNODE(n)) {
struct tnode *tn = (struct tnode *) n;
- __be32 prf = htonl(MASK_PFX(tn->key, tn->pos));
+ __be32 prf = htonl(mask_pfx(tn->key, tn->pos));
seq_indent(seq, iter->depth-1);
seq_printf(seq, " +-- %d.%d.%d.%d/%d %d %d %d\n",
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sk98lin for 2.6.23-rc1
If anyone still has hang issues with sky2, please send me the hardware information (lspci, dmesg output), and capture the debugfs state after hang. At present the known open skge, sky2 issues are: 1) Skge doesn't work with dual port fiber 2) Sky2 (and vendor sk98lin) don't work on some MSI motherboards due to PCI issues 3) Skge and sky2 trigger problems with motherboards that don't do >4GB DMA correctly. Not a driver but a PCI quirk problem. 4) Sky2 does polling for lost irq even when interface not up 5) Sky2 polling rate for lost irq maybe greater than TCP timeout so connection may be lost even after link recovers 6) Sky2 Yukon extreme support is still experimental and fragile, but this hardware isn't in the wild yet 7) Sky2 Yukon EC-U not powering up PHY correctly on some revisions 8) Sky2 suspend to ram not working right on some chips Hardware nuisances that are being masked: a) hardware can't DMA to unaligned address b) polling for lost irq is a hack, but until the root cause is found it will have to stay. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
source interface ping bug ?
Hello there, I'm facing the following issue : when I try to ping using source interface instead of a source ip address the ping utility starts to send arp requests instead of icmp requests though the ip address I'm pinging it's not in the subnets directly connected to my linux box. I've noticed this situation since I upgraded from kernel 2.6.20 to 2.6.21. On 2.6.20 and lower I haven't had this problem. Now I upgraded to 2.6.22 but it's the same. I'm using latest iproute and iputils. Here is an output of tcpdump when I try to ping an outside ip address, like for example www.yahoo.com, using source interface : [EMAIL PROTECTED]:~# uname -a Linux darkstar 2.6.22 #1 Thu Jul 26 21:22:11 EEST 2007 i686 Pentium II (Deschutes) GenuineIntel GNU/Linux [EMAIL PROTECTED]:~# ip -V ip utility, iproute2-ss070710 [EMAIL PROTECTED]:~# [EMAIL PROTECTED]:~# ip address show dev eth2 3: eth2: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:90:27:0f:79:f3 brd ff:ff:ff:ff:ff:ff inet 86.106.19.75/23 brd 86.106.19.255 scope global eth2 [EMAIL PROTECTED]:~# ip route get 87.248.113.14 from 86.106.19.75 oif eth2 87.248.113.14 from 86.106.19.75 via 86.106.18.1 dev eth2 cache mtu 1500 advmss 1460 hoplimit 64 [EMAIL PROTECTED]:~# [EMAIL PROTECTED]:~/iputils# ./ping -V ping utility, iputils-sss20070202 [EMAIL PROTECTED]:~/iputils# ./ping -I 86.106.19.75 87.248.113.14 -c 2 PING 87.248.113.14 (87.248.113.14) from 86.106.19.75 : 56(84) bytes of data. 64 bytes from 87.248.113.14: icmp_seq=1 ttl=51 time=60.5 ms 64 bytes from 87.248.113.14: icmp_seq=2 ttl=51 time=63.2 ms --- 87.248.113.14 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 60.574/61.924/63.274/1.350 ms [EMAIL PROTECTED]:~/iputils# [EMAIL PROTECTED]:~# tcpdump -i eth2 -vvv -n host 87.248.113.14 and host 86.106.19.75 tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes 01:18:09.572603 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 86.106.19.75 > 87.248.113.14: ICMP echo request, id 27166, seq 1, length 64 01:18:09.632861 IP (tos 0x0, ttl 51, id 6100, offset 0, flags [none], proto: ICMP (1), length: 84) 87.248.113.14 > 86.106.19.75: ICMP echo reply, id 27166, seq 1, length 64 01:18:10.572746 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 86.106.19.75 > 87.248.113.14: ICMP echo request, id 27166, seq 2, length 64 01:18:10.634951 IP (tos 0x0, ttl 51, id 8790, offset 0, flags [none], proto: ICMP (1), length: 84) 87.248.113.14 > 86.106.19.75: ICMP echo reply, id 27166, seq 2, length 64 using source interface : [EMAIL PROTECTED]:~/iputils# ./ping -I eth2 87.248.113.14 PING 87.248.113.14 (87.248.113.14) from 86.106.19.75 eth2: 56(84) bytes of data. >From 86.106.19.75 icmp_seq=1 Destination Host Unreachable >From 86.106.19.75 icmp_seq=2 Destination Host Unreachable >From 86.106.19.75 icmp_seq=3 Destination Host Unreachable >From 86.106.19.75 icmp_seq=5 Destination Host Unreachable >From 86.106.19.75 icmp_seq=6 Destination Host Unreachable >From 86.106.19.75 icmp_seq=7 Destination Host Unreachable >From 86.106.19.75 icmp_seq=9 Destination Host Unreachable >From 86.106.19.75 icmp_seq=10 Destination Host Unreachable >From 86.106.19.75 icmp_seq=11 Destination Host Unreachable --- 87.248.113.14 ping statistics --- 13 packets transmitted, 0 received, +9 errors, 100% packet loss, time 12006ms , pipe 3 [EMAIL PROTECTED]:~/iputils# [EMAIL PROTECTED]:~# tcpdump -i eth2 -vvv -n host 87.248.113.14 and host 86.106.19.75 tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes 01:19:24.292911 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:25.292897 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:26.292901 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:27.302906 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:28.302911 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:29.302912 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:31.302917 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:32.302921 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:33.302923 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:35.302932 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:36.302932 arp who-has 87.248.113.14 tell 86.106.19.75 01:19:37.302939 arp who-has 87.248.113.14 tell 86.106.19.75 12 packets captured 12 packets received by filter 0 packets dropped by kernel [EMAIL PROTECTED]:~# There is one exception though, it works when using eth0. I'm administrating multiple linux boxes with 2 or 3 ethernet cards and if I try pinging with eth0 it does send icmp like it should but when specifying eth1 or eth2 is sends arp requests. The distro I'm using is Slackware 12.0. I already reported this to the iputils maintainer and he recommended to report it here. Thanks in advance. Regards. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info
Re: [PATCH 1/1]ixgbe: Driver for Intel 82598 based 10GbE PCI Express family of adapters
Stephen Hemminger wrote: Using module parameter for per device settings is bad idea. Please extend existing interfaces like ethtool, etc rather than committing to a bad inflexible API. I agreed with Stephen's comments here. In general, net driver policy is to use ethtool (per-interface granularity) rather than module options. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/1] lro: Generic Large Receive Offload for TCP traffic
Hi Drew,
thanks a lot for your good feedback. See comments below.
I'll try to provide an updated version next week. It would
be nice if you could post a patch for your driver once
we have addressed the issues you mentioned. Then we would
have the eHEA driver for the SKB interface, and your driver
for the "receive in pages" interface.
Thanks,
Jan-Bernd
On Wednesday 25 July 2007 19:17, Andrew Gallatin wrote:
> Code review / comments:
> ===
>
> 1) Checksum information for CHECKSUM_COMPLETE drivers.
>
> Our NIC passes partial checksums to our driver. In the current code,
> it seems impossible for page based CHECKSUM_COMPLETE drivers to behave
> correctly in the case of "rejected" frames. Eg, there is no way
> to pass the partial checksum to the LRO module so that it gets
> set in the skb header and passed up the stack.
>
> Further, there seems to be no (easy) way to use CHECKSUM_COMPLETE
> on an aggregated packet at LRO flush time. By the time a packet
> is aggregated, the partial checksum from the first segment is
> out of date.
>
> I think it would make sense to require that a CHECKSUM_COMPLETE style
> driver verify the checksum in its get_frag_header / get_skb_header
> callback. This allows the LRO code to unconditionally set
> CHECKSUM_UNNECESSARY.
I agree
> 2) Non-accelerated VLAN tags
>
> Our firmware currently does not do vlan tag insertion
> and removal. This causes a problem in __lro_proc_segment()
> where the tcp and ip headers are setup to point into the
> newly created skb. A frame containing an unstripped vlan
> tag will cause the headers to be garbage.
>
> The attached patch modifies __lro_proc_segment() to offset
> those pointers by VLAN_HLEN when required.
>
The modifications you propose are not sufficient to work with HW
which actually extracts the VLAN IDs but does not change the
eth protocol. Thus we have to add an additional field in
lro_mgr indicating how to interpret the eth protocol regarding
the VLAN header.
> 3) Padded frames.
>
> I may be missing something, but I don't see where you
> either strip padding from frames or reject padded frames.
> (see the pskb_trim_rcsum() in net/ipv4/ip_input.c:ip_rcv()
>
I think I missed something :-) Will fix that.
In lro_tcp_ip_check we check for the "SKB aggregation interface"
the skb->len against ip->tot_len. This catches padded frames as
eth_type_trans(skb, dev) reduces the length of the SKB.
However, the possible VLAN header is not taken into account.
And for the "receive in pages" interface a wrong length is passed
as argument as well.
I'd suggest to reject padded frames for aggregation as we do now
(when bugs are fixed) and thus keep the code simple.
I guess that padded frames don't occur too often in high load
situations. If we detect a real performance issue we can still
change that later.
> I did not add such a feature as I was confused about the intended
> use of len/true_size.
len: number of bytes received
true_size: used to fill the "truesize" field in the SKB. Thus this reflects
the amount of memory that is actually used by that SKB. If you
receive into pages und you have some space between packets, you
should take this into account. Example: you use 1 page for each
packet, then you pass 4096 as argument.
>
> Also, trimming is a pain when dealing with pure frags (without a
> containing skb). We have code in our out-of-kernel driver to deal
> with it which you are welcome to use.
>
>
> 4) LRO_MIN_PG_HLEN (== 80)
>
> This confuses me. Can you please explain what you're trying to do?
> Because of this, I kept getting crashes in the skb_pull() done by
> eth_type_trans() because I was passing segments which were 60 bytes
> and the skb->data_len of the skb constructed by lro_gen_skb() was -20.
> I added my own code to bump the length to a magic 80 bytes, and the
> panics disappeared. This may cause data corruption because of
> #3 above!
Yes, I see the point... I'm not sure in how far there are any requirements
that a certain amount of data (header) for other types of traffic
has to be in the skb->data field and not in frags. Maybe someone
can comment on this?
I suggest to remove LRO_MIN_PG_HLEN for tcp/ip packets that are aggregated,
but should we use a minimal length for other traffic (depending on the
number of received bytes)? Is that necessary?
>
> 5) NAPI/non-NAPI
>
> The LRO code assumes the underlying driver uses NAPI, and calls
> netif_receive_skb() rather than netif_rx(). Perhaps there should be a
> field in the lro_mgr struct to specify napi / non-napi.
>
Yes, if someone intends to use it without napi, we can add this.
> 6) The checks for when to stop aggregating and flush in
> __lro_proc_{segment|skb} need some improvement.
>
> The skb variant currently uses a pure count (max_aggr). In order to
> keep the resulting aggregated frame below 64KB, the underlying driver
> computes max_aggr as 0x / MTU. This reduces the effect
[PATCH 3/4] pass (host-endian) cmd length as explicit argument to l2cap_conf_req()
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
net/bluetooth/l2cap.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 09126bf..03309d2 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1530,7 +1530,7 @@ static inline int l2cap_connect_rsp(struct l2cap_conn
*conn, struct l2cap_cmd_hd
return 0;
}
-static inline int l2cap_config_req(struct l2cap_conn *conn, struct
l2cap_cmd_hdr *cmd, u8 *data)
+static inline int l2cap_config_req(struct l2cap_conn *conn, struct
l2cap_cmd_hdr *cmd, u16 cmd_len, u8 *data)
{
struct l2cap_conf_req *req = (struct l2cap_conf_req *) data;
u16 dcid, flags;
@@ -1550,7 +1550,7 @@ static inline int l2cap_config_req(struct l2cap_conn
*conn, struct l2cap_cmd_hdr
goto unlock;
/* Reject if config buffer is too small. */
- len = cmd->len - sizeof(*req);
+ len = cmd_len - sizeof(*req);
if (l2cap_pi(sk)->conf_len + len > sizeof(l2cap_pi(sk)->conf_req)) {
l2cap_send_cmd(conn, cmd->ident, L2CAP_CONF_RSP,
l2cap_build_conf_rsp(sk, rsp,
@@ -1748,15 +1748,17 @@ static inline void l2cap_sig_channel(struct l2cap_conn
*conn, struct sk_buff *sk
l2cap_raw_recv(conn, skb);
while (len >= L2CAP_CMD_HDR_SIZE) {
+ u16 cmd_len;
memcpy(&cmd, data, L2CAP_CMD_HDR_SIZE);
data += L2CAP_CMD_HDR_SIZE;
len -= L2CAP_CMD_HDR_SIZE;
- cmd.len = __le16_to_cpu(cmd.len);
+ cmd_len = le16_to_cpu(cmd.len);
+ cmd.len = cmd_len;
- BT_DBG("code 0x%2.2x len %d id 0x%2.2x", cmd.code, cmd.len,
cmd.ident);
+ BT_DBG("code 0x%2.2x len %d id 0x%2.2x", cmd.code, cmd_len,
cmd.ident);
- if (cmd.len > len || !cmd.ident) {
+ if (cmd_len > len || !cmd.ident) {
BT_DBG("corrupted command");
break;
}
@@ -1775,7 +1777,7 @@ static inline void l2cap_sig_channel(struct l2cap_conn
*conn, struct sk_buff *sk
break;
case L2CAP_CONF_REQ:
- err = l2cap_config_req(conn, &cmd, data);
+ err = l2cap_config_req(conn, &cmd, cmd_len, data);
break;
case L2CAP_CONF_RSP:
@@ -1791,7 +1793,7 @@ static inline void l2cap_sig_channel(struct l2cap_conn
*conn, struct sk_buff *sk
break;
case L2CAP_ECHO_REQ:
- l2cap_send_cmd(conn, cmd.ident, L2CAP_ECHO_RSP,
cmd.len, data);
+ l2cap_send_cmd(conn, cmd.ident, L2CAP_ECHO_RSP,
cmd_len, data);
break;
case L2CAP_ECHO_RSP:
@@ -1820,8 +1822,8 @@ static inline void l2cap_sig_channel(struct l2cap_conn
*conn, struct sk_buff *sk
l2cap_send_cmd(conn, cmd.ident, L2CAP_COMMAND_REJ,
sizeof(rej), &rej);
}
- data += cmd.len;
- len -= cmd.len;
+ data += cmd_len;
+ len -= cmd_len;
}
kfree_skb(skb);
--
1.5.3.GIT
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: D-Link DFE-580TX 4 port NIC problems
Hi, Mario! Mario Doering schrieb: Hello, are there any news or questions on this issue? Can you try the latest kernel to see if the same problem persists? Is there any kernel version where it was working fine? On Wed, 9 May 2007 03:27:00 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 9 May 2007 12:01:42 +0200 Mario Doering <[EMAIL PROTECTED]> wrote: Hello, we have a D-Link DFE-580TX 4 port network card in our main router. It works pretty well most of the time, even though an error message pops up in dmesg every now and then (sometimes once a day sometimes once every few hours). But every few weeks those error messages increase rapidly, spamming dmesg. When this happens the system does not react anymore and pushing the reset button is the only option left. I googled around and found out that other users have same problem, but no solution to this. Part of the message log is located here: http://test.dedenet.de/messages.gz or http://test.dedenet.de/messages.txt uname -a Linux router1 2.6.19-gentoo-r5 #1 Sat Feb 17 17:04:03 CET 2007 i686 AMD Athlon(tm) XP AuthenticAMD GNU/Linux driver: [ 17.364707] sundance.c:v1.2 11-Sep-2006 Written by Donald Becker [ 17.364711] http://www.scyld.com/network/sundance.html [ 17.364844] ACPI: PCI Interrupt :03:04.0[A] -> GSI 17 (level, low) -> IRQ 17 [ 17.365396] eth1: D-Link DFE-580TX 4 port Server Adapter at 0001bc00, 00:0d:88:cc:a5:f0, IRQ 17. [ 17.366350] eth1: MII PHY found at address 1, status 0x7829 advertising 01e1. [ 17.676491] ACPI: PCI Interrupt :03:05.0[A] -> GSI 18 (level, low) -> IRQ 18 [ 17.676912] eth2: D-Link DFE-580TX 4 port Server Adapter at 0001b800, 00:0d:88:cc:a5:f1, IRQ 18. [ 17.677864] eth2: MII PHY found at address 1, status 0x7809 advertising 01e1. [ 17.987730] ACPI: PCI Interrupt :03:06.0[A] -> GSI 19 (level, low) -> IRQ 16 [ 17.988107] eth3: D-Link DFE-580TX 4 port Server Adapter at 0001b400, 00:0d:88:cc:a5:f2, IRQ 16. [ 17.989059] eth3: MII PHY found at address 1, status 0x7829 advertising 01e1. [ 18.298910] ACPI: PCI Interrupt :03:07.0[A] -> GSI 16 (level, low) -> IRQ 19 [ 18.299320] eth4: D-Link DFE-580TX 4 port Server Adapter at 0001b000, 00:0d:88:cc:a5:f3, IRQ 19. [ 18.300272] eth4: MII PHY found at address 1, status 0x7809 advertising 01e1. No such error message appears for about 7-10 days after a reboot. Maybe there is some kind of buffer running full? Do you need any additional info? Please CC me :-) (cc netdev) Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sk98lin for 2.6.23-rc1
On Fri, 27 Jul 2007 08:58:45 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Stephen Hemminger wrote: > > If anyone still has hang issues with sky2, please send me the hardware > > information (lspci, dmesg output), and capture the debugfs state after hang. > > > > At present the known open skge, sky2 issues are: > > Did you add Chris Stromsoe's skge-hangs problem to the list? > > Jeff That is the #1 on list, it is the dual port fiber problem. Seems to be specific to dual port, since can't reproduce on my only skge fiber board (single port) connected to e1000. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/1] lro: Generic Large Receive Offload for TCP traffic
Just to chime in... In general, I like where this LRO effort is going, and I really appreciate you guys working on it. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] l2cap: don't mangle cmd.len
Since nobody uses it after we convert it to host-endian,
no need to do that at all. At that point l2cap is endian-clean.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
net/bluetooth/l2cap.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 03309d2..c4e4ce4 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1754,7 +1754,6 @@ static inline void l2cap_sig_channel(struct l2cap_conn
*conn, struct sk_buff *sk
len -= L2CAP_CMD_HDR_SIZE;
cmd_len = le16_to_cpu(cmd.len);
- cmd.len = cmd_len;
BT_DBG("code 0x%2.2x len %d id 0x%2.2x", cmd.code, cmd_len,
cmd.ident);
--
1.5.3.GIT
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] fix endianness bug in l2cap_sock_listen()
We loop through psm values, calling __l2cap_get_sock_by_addr(psm, ...)
until we get NULL; then we set ->psm of our socket to htobs(psm).
IOW, we find unused psm value and put it into our socket. So far, so
good, but... __l2cap_get_sock_by_addr() compares its argument with
->psm of sockets. IOW, the entire thing works correctly only on
little-endian. On big-endian we'll get "no socket with such psm"
on the first iteration, since we won't find a socket with ->psm == 0x1001.
We will happily conclude that 0x1001 is unused and slap htobs(0x1001)
(i.e. 0x110) into ->psm of our socket. Of course, the next time around
the same thing will repeat and we'll just get a fsckload of sockets
with the same ->psm assigned.
Fix: pass htobs(psm) to __l2cap_get_sock_by_addr() there. All other
callers are already passing little-endian values and all places that
store something in ->psm are storing little-endian.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
net/bluetooth/l2cap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 670ff95..b82cbdd 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -748,7 +748,7 @@ static int l2cap_sock_listen(struct socket *sock, int
backlog)
write_lock_bh(&l2cap_sk_list.lock);
for (psm = 0x1001; psm < 0x1100; psm += 2)
- if (!__l2cap_get_sock_by_addr(psm, src)) {
+ if (!__l2cap_get_sock_by_addr(htobs(psm), src)) {
l2cap_pi(sk)->psm = htobs(psm);
l2cap_pi(sk)->sport = htobs(psm);
err = 0;
--
1.5.3.GIT
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] l2cap: endianness annotations
no code changes, just documenting existing types
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
include/net/bluetooth/l2cap.h | 50
net/bluetooth/l2cap.c | 27 +++--
2 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 87df4e8..70e70f5 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -34,7 +34,7 @@
/* L2CAP socket address */
struct sockaddr_l2 {
sa_family_t l2_family;
- unsigned short l2_psm;
+ __le16 l2_psm;
bdaddr_tl2_bdaddr;
};
@@ -76,32 +76,32 @@ struct l2cap_conninfo {
/* L2CAP structures */
struct l2cap_hdr {
- __u16 len;
- __u16 cid;
+ __le16 len;
+ __le16 cid;
} __attribute__ ((packed));
#define L2CAP_HDR_SIZE 4
struct l2cap_cmd_hdr {
__u8 code;
__u8 ident;
- __u16 len;
+ __le16 len;
} __attribute__ ((packed));
#define L2CAP_CMD_HDR_SIZE 4
struct l2cap_cmd_rej {
- __u16 reason;
+ __le16 reason;
} __attribute__ ((packed));
struct l2cap_conn_req {
- __u16 psm;
- __u16 scid;
+ __le16 psm;
+ __le16 scid;
} __attribute__ ((packed));
struct l2cap_conn_rsp {
- __u16 dcid;
- __u16 scid;
- __u16 result;
- __u16 status;
+ __le16 dcid;
+ __le16 scid;
+ __le16 result;
+ __le16 status;
} __attribute__ ((packed));
/* connect result */
@@ -117,15 +117,15 @@ struct l2cap_conn_rsp {
#define L2CAP_CS_AUTHOR_PEND 0x0002
struct l2cap_conf_req {
- __u16 dcid;
- __u16 flags;
+ __le16 dcid;
+ __le16 flags;
__u8 data[0];
} __attribute__ ((packed));
struct l2cap_conf_rsp {
- __u16 scid;
- __u16 flags;
- __u16 result;
+ __le16 scid;
+ __le16 flags;
+ __le16 result;
__u8 data[0];
} __attribute__ ((packed));
@@ -149,23 +149,23 @@ struct l2cap_conf_opt {
#define L2CAP_CONF_MAX_SIZE22
struct l2cap_disconn_req {
- __u16 dcid;
- __u16 scid;
+ __le16 dcid;
+ __le16 scid;
} __attribute__ ((packed));
struct l2cap_disconn_rsp {
- __u16 dcid;
- __u16 scid;
+ __le16 dcid;
+ __le16 scid;
} __attribute__ ((packed));
struct l2cap_info_req {
- __u16 type;
+ __le16 type;
__u8data[0];
} __attribute__ ((packed));
struct l2cap_info_rsp {
- __u16 type;
- __u16 result;
+ __le16 type;
+ __le16 result;
__u8data[0];
} __attribute__ ((packed));
@@ -207,7 +207,7 @@ struct l2cap_conn {
struct l2cap_pinfo {
struct bt_sock bt;
- __u16 psm;
+ __le16 psm;
__u16 dcid;
__u16 scid;
@@ -225,7 +225,7 @@ struct l2cap_pinfo {
__u8ident;
- __u16 sport;
+ __le16 sport;
struct l2cap_conn *conn;
struct sock *next_c;
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index b82cbdd..09126bf 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -353,7 +353,7 @@ static inline int l2cap_send_cmd(struct l2cap_conn *conn,
u8 ident, u8 code, u16
}
/* Socket interface */
-static struct sock *__l2cap_get_sock_by_addr(u16 psm, bdaddr_t *src)
+static struct sock *__l2cap_get_sock_by_addr(__le16 psm, bdaddr_t *src)
{
struct sock *sk;
struct hlist_node *node;
@@ -368,7 +368,7 @@ found:
/* Find socket with psm and source bdaddr.
* Returns closest match.
*/
-static struct sock *__l2cap_get_sock_by_psm(int state, u16 psm, bdaddr_t *src)
+static struct sock *__l2cap_get_sock_by_psm(int state, __le16 psm, bdaddr_t
*src)
{
struct sock *sk = NULL, *sk1 = NULL;
struct hlist_node *node;
@@ -392,7 +392,7 @@ static struct sock *__l2cap_get_sock_by_psm(int state, u16
psm, bdaddr_t *src)
/* Find socket with given address (psm, src).
* Returns locked socket */
-static inline struct sock *l2cap_get_sock_by_psm(int state, u16 psm, bdaddr_t
*src)
+static inline struct sock *l2cap_get_sock_by_psm(int state, __le16 psm,
bdaddr_t *src)
{
struct sock *s;
read_lock(&l2cap_sk_list.lock);
@@ -586,7 +586,7 @@ static int l2cap_sock_bind(struct socket *sock, struct
sockaddr *addr, int addr_
goto done;
}
- if (la->l2_psm > 0 && btohs(la->l2_psm) < 0x1001 &&
+ if (la->l2_psm && btohs(la->l2_psm) < 0x1001 &&
!capable(CAP_NET_BIND_SERVICE)) {
err = -EACCES;
goto done;
@@ -873,7 +873,7 @@ st
RE: [FIX] NET: Fix sch_api and sch_prio to properly set and detect the root qdisc
> From: Patrick McHardy [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 24, 2007 5:36 PM > To: Waskiewicz Jr, Peter P > Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org > Subject: Re: [FIX] NET: Fix sch_api and sch_prio to properly > set and detect the root qdisc > [...] > Both look good, thanks. > > Acked-by: Patrick McHardy <[EMAIL PROTECTED]> > Dave, Are these queued for 2.6.24, or are they going to make it into 2.6.23? I know you're busy with patches and NAPI, but I was curious. Thanks! Cheers, -PJ Waskiewicz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] pass (host-endian) cmd length as explicit argument to l2cap_conf_req()
Hi All, > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Regards Marcel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: D-Link DFE-580TX 4 port NIC problems
Hello, are there any news or questions on this issue? Mario. On Wed, 9 May 2007 03:27:00 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 9 May 2007 12:01:42 +0200 Mario Doering <[EMAIL PROTECTED]> > wrote: > > > Hello, > > > > we have a D-Link DFE-580TX 4 port network card in our main router. > > > > It works pretty well most of the time, even though an error > > message pops up in dmesg every now and then (sometimes once a day > > sometimes once every few hours). > > > > > > But every few weeks those error messages increase rapidly, spamming > > dmesg. When this happens the system does not react anymore and > > pushing the reset button is the only option left. > > > > I googled around and found out that other users have same problem, > > but no solution to this. > > > > > > Part of the message log is located here: > > http://test.dedenet.de/messages.gz > > or > > http://test.dedenet.de/messages.txt > > > > > > uname -a > > Linux router1 2.6.19-gentoo-r5 #1 Sat Feb 17 17:04:03 CET 2007 i686 > > AMD Athlon(tm) XP AuthenticAMD GNU/Linux > > > > > > driver: > > [ 17.364707] sundance.c:v1.2 11-Sep-2006 Written by Donald Becker > > [ 17.364711] http://www.scyld.com/network/sundance.html > > [ 17.364844] ACPI: PCI Interrupt :03:04.0[A] -> GSI 17 (level, > > low) -> IRQ 17 [ 17.365396] eth1: D-Link DFE-580TX 4 port Server > > Adapter at 0001bc00, 00:0d:88:cc:a5:f0, IRQ 17. [ 17.366350] eth1: > > MII PHY found at address 1, status 0x7829 advertising 01e1. > > [ 17.676491] ACPI: PCI Interrupt :03:05.0[A] -> GSI 18 (level, > > low) -> IRQ 18 [ 17.676912] eth2: D-Link DFE-580TX 4 port Server > > Adapter at 0001b800, 00:0d:88:cc:a5:f1, IRQ 18. [ 17.677864] eth2: > > MII PHY found at address 1, status 0x7809 advertising 01e1. > > [ 17.987730] ACPI: PCI Interrupt :03:06.0[A] -> GSI 19 (level, > > low) -> IRQ 16 [ 17.988107] eth3: D-Link DFE-580TX 4 port Server > > Adapter at 0001b400, 00:0d:88:cc:a5:f2, IRQ 16. [ 17.989059] eth3: > > MII PHY found at address 1, status 0x7829 advertising 01e1. > > [ 18.298910] ACPI: PCI Interrupt :03:07.0[A] -> GSI 16 (level, > > low) -> IRQ 19 [ 18.299320] eth4: D-Link DFE-580TX 4 port Server > > Adapter at 0001b000, 00:0d:88:cc:a5:f3, IRQ 19. [ 18.300272] eth4: > > MII PHY found at address 1, status 0x7809 advertising 01e1. > > > > > > > > No such error message appears for about 7-10 days after a reboot. > > Maybe there is some kind of buffer running full? > > > > Do you need any additional info? > > > > > > Please CC me :-) > > (cc netdev) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] fix endianness bug in l2cap_sock_listen()
Hi Al, > We loop through psm values, calling __l2cap_get_sock_by_addr(psm, ...) > until we get NULL; then we set ->psm of our socket to htobs(psm). > IOW, we find unused psm value and put it into our socket. So far, so > good, but... __l2cap_get_sock_by_addr() compares its argument with > ->psm of sockets. IOW, the entire thing works correctly only on > little-endian. On big-endian we'll get "no socket with such psm" > on the first iteration, since we won't find a socket with ->psm == 0x1001. > We will happily conclude that 0x1001 is unused and slap htobs(0x1001) > (i.e. 0x110) into ->psm of our socket. Of course, the next time around > the same thing will repeat and we'll just get a fsckload of sockets > with the same ->psm assigned. > > Fix: pass htobs(psm) to __l2cap_get_sock_by_addr() there. All other > callers are already passing little-endian values and all places that > store something in ->psm are storing little-endian. > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Dave, all four patches are good and should go in sooner than later. If you want me to put them into my tree first, then I can do that or you can apply them directly. You choice. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] l2cap: endianness annotations
Hi Al, > no code changes, just documenting existing types > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Regards Marcel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] l2cap: don't mangle cmd.len
Hi Al, > Since nobody uses it after we convert it to host-endian, > no need to do that at all. At that point l2cap is endian-clean. > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Regards Marcel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: D-Link DFE-580TX 4 port NIC problems
On Fri, Jul 27, 2007 at 02:08:09PM +0200, Clemens Koller wrote:
> Can you try the latest kernel to see if the same problem
> persists?
> Is there any kernel version where it was working fine?
In my case, this is 'problem' occur when I do run snmpd on
the same machine, and I saw that snmpd doing something
like this:
...
} else if (ioctl(fd, SIOCDEVPRIVATE, &ifr) >= 0) {
new_ioctl_nums = 1;
}
That cause sundance printing a lot of debug messages (i.e netdev_ioctl()
in sundance.c) .. periodically, as long as snmpd running :-)
Regards,
P.Y. Adi Prasaja
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sk98lin for 2.6.23-rc1
Stephen Hemminger wrote: If anyone still has hang issues with sky2, please send me the hardware information (lspci, dmesg output), and capture the debugfs state after hang. At present the known open skge, sky2 issues are: Did you add Chris Stromsoe's skge-hangs problem to the list? Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] netxen: drop redudant spinlock
Some leftover code that makes use of adapter->lock in tx_timeout function,
which resets the interface under this lock. In close() when the workqueue
is flushed, prints the warning about sleeping with interrupts disabled
(when spinlock debug is enabled). The lock was required with private netxen
IOCTLs, which were removed a while ago.
Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -335,7 +335,6 @@ netxen_nic_probe(struct pci_dev *pdev, c
adapter->ahw.pdev = pdev;
adapter->ahw.pci_func = pci_func_id;
spin_lock_init(&adapter->tx_lock);
- spin_lock_init(&adapter->lock);
/* remap phys address */
mem_base = pci_resource_start(pdev, 0); /* 0 is for BAR 0 */
@@ -1228,15 +1227,12 @@ static void netxen_tx_timeout_task(struc
{
struct netxen_adapter *adapter =
container_of(work, struct netxen_adapter, tx_timeout_task);
- unsigned long flags;
printk(KERN_ERR "%s %s: transmit timeout, resetting.\n",
netxen_nic_driver_name, adapter->netdev->name);
- spin_lock_irqsave(&adapter->lock, flags);
netxen_nic_close(adapter->netdev);
netxen_nic_open(adapter->netdev);
- spin_unlock_irqrestore(&adapter->lock, flags);
adapter->netdev->trans_start = jiffies;
netif_wake_queue(adapter->netdev);
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Fri, 27 Jul 2007 18:57:20 +0200
Michael Buesch <[EMAIL PROTECTED]> wrote:
> The Sonics Silicon Backplane is a mini-bus used on
> various Broadcom chips and embedded devices.
> Devices using the SSB include b44, bcm43xx and various
> Broadcom based wireless routers.
> A b44 and bcm43xx port and a SSB based OHCI driver is available.
>
hm, slim pickings for me here. Nice looking code.
checkpatch finds a few coding style glitches. Lots of 80-col violations
which you might choose ignore (comments on #defines in headers are
especially hard) but these guys:
ERROR: "foo * bar" should be "foo *bar"
#4156: FILE: drivers/ssb/ssb_private.h:119:
+extern struct ssb_bus * ssb_pci_dev_to_bus(struct pci_dev *pdev);
are worth addressing.
> ...
>
> --- /dev/null
> +++ b/drivers/ssb/driver_pcicore.c
> @@ -0,0 +1,564 @@
>
> ...
>
> +u32 pci_iobase = 0x100;
> +u32 pci_membase = SSB_PCI_DMA;
These are quite poor names for global symbols.
> +static struct resource ssb_pcicore_mem_resource = {
> + .name = "SSB PCIcore external memory",
> + .start = SSB_PCI_DMA,
> + .end= (u32)SSB_PCI_DMA + (u32)SSB_PCI_DMA_SZ - 1,
> + .flags = IORESOURCE_MEM,
> +};
start and end here are resource_size_t. Forcing them to u32 seems
inappropriate.
> +void ssb_pcicore_init(struct ssb_pcicore *pc)
Please check that all newly-added global symbols do indeed need global scope.
> +static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
> + u8 address, u16 data)
> +{
> + const u16 mdio_control = 0x128;
> + const u16 mdio_data = 0x12C;
> + u32 v;
> + int i;
> +
> + v = 0x80; /* Enable Preamble Sequence */
> + v |= 0x2; /* MDIO Clock Divisor */
> + pcicore_write32(pc, mdio_control, v);
> +
> + v = (1 << 30); /* Start of Transaction */
> + v |= (1 << 28); /* Write Transaction */
> + v |= (1 << 17); /* Turnaround */
> + v |= (u32)device << 22;
> + v |= (u32)address << 18;
> + v |= data;
> + pcicore_write32(pc, mdio_data, v);
> + udelay(10);
mystery udelays are usually worth a comment.
> + for (i = 0; i < 10; i++) {
> + v = pcicore_read32(pc, mdio_control);
> + if (v & 0x100 /* Trans complete */)
> + break;
> + msleep(1);
> + }
> + pcicore_write32(pc, mdio_control, 0);
> +}
>
> ...
>
> +
> +static void ssb_buses_lock(void)
> +{
> + if (!ssb_is_early_boot)
> + mutex_lock(&buses_mutex);
> +}
> +
> +static void ssb_buses_unlock(void)
> +{
> + if (!ssb_is_early_boot)
> + mutex_unlock(&buses_mutex);
> +}
Some comments are neeeded here to explain why we're jumping through this
hoop. It's normally OK to take a mutex early in boot, so one wonders
what's happening.
> +EXPORT_SYMBOL(ssb_clockspeed);
Please check that all newly-added exports really need to be exported (I'm
sure they do, but..)
> +static int ssb_wait_bit(struct ssb_device *dev, u16 reg, u32 bitmask,
> + int timeout, int set)
> +{
> + int i;
> + u32 val;
> +
> + for (i = 0; i < timeout; i++) {
> + val = ssb_read32(dev, reg);
> + if (set) {
> + if (val & bitmask)
> + return 0;
> + } else {
> + if (!(val & bitmask))
> + return 0;
> + }
> + udelay(10);
> + }
> + printk(KERN_ERR PFX "Timeout waiting for bitmask %08X on "
> + "register %04X to %s.\n",
> +bitmask, reg, (set ? "set" : "clear"));
> +
> + return -ETIMEDOUT;
> +}
So `timeout' is in units of ten-microseconds. Unusual.
> +void ssb_device_disable(struct ssb_device *dev, u32 core_specific_flags)
> +{
> + u32 reject;
> +
> + if (ssb_read32(dev, SSB_TMSLOW) & SSB_TMSLOW_RESET)
> + return;
> +
> + reject = ssb_tmslow_reject_bitmask(dev);
> + ssb_write32(dev, SSB_TMSLOW, reject | SSB_TMSLOW_CLOCK);
> + ssb_wait_bit(dev, SSB_TMSLOW, reject, 1000, 1);
> + ssb_wait_bit(dev, SSB_TMSHIGH, SSB_TMSHIGH_BUSY, 1000, 0);
> + ssb_write32(dev, SSB_TMSLOW,
> + SSB_TMSLOW_FGC | SSB_TMSLOW_CLOCK |
> + reject | SSB_TMSLOW_RESET |
> + core_specific_flags);
> + /* flush */
> + ssb_read32(dev, SSB_TMSLOW);
> + udelay(1);
> +
> + ssb_write32(dev, SSB_TMSLOW,
> + reject | SSB_TMSLOW_RESET |
> + core_specific_flags);
> + /* flush */
> + ssb_read32(dev, SSB_TMSLOW);
> + udelay(1);
mystery udelay.
> +}
> +EXPORT_SYMBOL(ssb_device_disable);
>
> ...
>
> +const struct ssb_bus_ops ssb_pci_ops = {
> + .read16 = ssb_pci_read16,
> + .read32 = ssb_pci_read32,
> + .write16= ssb_pci_write16,
> + .write32= ssb_pci_write32,
> +};
static?
> +static ssize_t ssb_pci_attr_sprom_show(struct device *pcidev,
> +
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Fri, 27 Jul 2007 21:30:48 +0200
Michael Buesch <[EMAIL PROTECTED]> wrote:
> > ERROR: "foo * bar" should be "foo *bar"
> > #4156: FILE: drivers/ssb/ssb_private.h:119:
> > +extern struct ssb_bus * ssb_pci_dev_to_bus(struct pci_dev *pdev);
> >
> > are worth addressing.
>
> Well, I intentionally wrote that this way, as in my opinion
> it it easier to read. I only use this additional space for
> functions returning a pointer.
>
> struct foo * function(int a, int b);
>
> vs:
>
> struct foo *function(int a, int b);
>
> But I can change that, if that's really an issue and a
> style violation.
It's a microissue but yeah, no-space is more conventional.
> > > +static ssize_t ssb_pci_attr_sprom_show(struct device *pcidev,
> > > +struct device_attribute *attr,
> > > +char *buf)
> > > +{
> > > + struct pci_dev *pdev = container_of(pcidev, struct pci_dev, dev);
> > > + struct ssb_bus *bus;
> > > + u16 *sprom;
> > > + int err = -ENODEV;
> > > + ssize_t count = 0;
> > > +
> > > + bus = ssb_pci_dev_to_bus(pdev);
> > > + if (!bus)
> > > + goto out;
> > > + err = -ENOMEM;
> > > + sprom = kcalloc(SSB_SPROMSIZE_WORDS, sizeof(u16), GFP_KERNEL);
> > > + if (!sprom)
> > > + goto out;
> > > +
> > > + err = -ERESTARTSYS;
> > > + if (mutex_lock_interruptible(&bus->pci_sprom_mutex))
> > > + goto out_kfree;
> > > + sprom_do_read(bus, sprom);
> > > + mutex_unlock(&bus->pci_sprom_mutex);
> > > +
> > > + count = sprom2hex(sprom, buf, PAGE_SIZE);
> > > + err = 0;
> > > +
> > > +out_kfree:
> > > + kfree(sprom);
> > > +out:
> > > + return err ? err : count;
> > > +}
> >
> > The mutex_lock_interruptible() looks fishy. Some commented explanation of
> > what it's doing would be good here. It's quite unobvious to this reader.
> > Cheesy deadlock avoidance? Hope not.
>
> No, it's simply to avoid writing the SPROM concurrently.
> SPROM writing is hairy and we must make sure here that
> we are the only one accessing the whole bus. We do that
> by suspending all devices and taking a lock to protect
> the SPROM from write concurrency.
Sure, but why is the locking interruptible rather than plain old
mutex_lock()?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Friday 27 July 2007 21:21:20 John W. Linville wrote: > On Fri, Jul 27, 2007 at 06:57:20PM +0200, Michael Buesch wrote: > > The Sonics Silicon Backplane is a mini-bus used on > > various Broadcom chips and embedded devices. > > Devices using the SSB include b44, bcm43xx and various > > Broadcom based wireless routers. > > A b44 and bcm43xx port and a SSB based OHCI driver is available. > > > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > At first glance it looks like there might be some tab/space issues > in some of the #define blocks toward the end of the patch, although > those might be intentional. They are intentional. It's something like this: #define SSB_REGISTER_XX 0xF88 #define SSB_VALUE_FOR_REGISTER_XX 0x0001 #define SSB_MASK_FOR_REGISTER_XX 0xFF00 #define SSB_REGISTER_YY 0xF99 ... > Aside from whatever other style issues that might be identified, I'll > state that this code has been carried in wireless-dev for months and > thereby also spent a lot of time in -mm as well as Fedora (rawhide > and F-7). The code has proven to be reasonably stable and reliable. And it's in the OpenWRT trunk since quite some time. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed interface for per-packet mesh-ttl
On Tue, Jul 03, 2007 at 12:29:24PM -0700, Javier Cardona wrote: > I'm currently working on per-packet mesh ttl. My plan is to register > new mesh sockopts through netfilter. The user interface will be: NACK. Drivers should never add sockopt, and drivers should not abuse netfilter hooks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1]ixgbe: Driver for Intel 82598 based 10GbE PCI Express family of adapters
>-Original Message- >From: Jeff Garzik [mailto:[EMAIL PROTECTED] > >Stephen Hemminger wrote: >> Using module parameter for per device settings is bad idea. >> Please extend existing interfaces like ethtool, etc rather than >committing >> to a bad inflexible API. > > >I agreed with Stephen's comments here. > >In general, net driver policy is to use ethtool (per-interface >granularity) rather than module options. > Thanks Stephen and Jeff for the feedback. The flow control and InterruptThrottleRate parameters were carried over from e1000 and it was pointed out to me that some disros/customer's scripts used those parameters in the scripts. Ixgbe being a new driver, we can remove those. Yes the LLI parameters can be removed. > +RxQueues > + > +Valid Range: 1, 2, 4, 8 > +Default Value: 8 > +Number of RX queues. > + > + Ok. The present driver being NAPI only and supports one Rx queue only. So this parameter needs to be removed . But, once we have DaveM/Stephen work of NAPI struct work is done, driver will support multiple Rx queues and with Multi Tx queue patch already in the kernel, driver will support multiple Tx queues also shortly. So, with driver/device supporting multiple Tx and Rx queues, I think, it would be very useful to have ethtool interface to manage the number of Tx and Rx queues of the interface. Current ethtool interface supports managing the ring size so, we need similar interface for managing the number of Tx and Rx queues of the interface. Ayyappan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Friday 27 July 2007 21:03:18 Andrew Morton wrote:
> On Fri, 27 Jul 2007 18:57:20 +0200
> Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > The Sonics Silicon Backplane is a mini-bus used on
> > various Broadcom chips and embedded devices.
> > Devices using the SSB include b44, bcm43xx and various
> > Broadcom based wireless routers.
> > A b44 and bcm43xx port and a SSB based OHCI driver is available.
> >
>
> hm, slim pickings for me here. Nice looking code.
>
> checkpatch finds a few coding style glitches. Lots of 80-col violations
> which you might choose ignore (comments on #defines in headers are
> especially hard) but these guys:
I tried to fix most of the checkpatch warning, except these 80col
warnings.
I don't think it's worth the work to fix the 80col stuff, yet.
I develop kernel code in the real console, and I have no problems
with this. Though, I use a wider console than 80col.
Let's better fix the worst 80col violations over time and not now.
> ERROR: "foo * bar" should be "foo *bar"
> #4156: FILE: drivers/ssb/ssb_private.h:119:
> +extern struct ssb_bus * ssb_pci_dev_to_bus(struct pci_dev *pdev);
>
> are worth addressing.
Well, I intentionally wrote that this way, as in my opinion
it it easier to read. I only use this additional space for
functions returning a pointer.
struct foo * function(int a, int b);
vs:
struct foo *function(int a, int b);
But I can change that, if that's really an issue and a
style violation.
> > ...
> >
> > --- /dev/null
> > +++ b/drivers/ssb/driver_pcicore.c
> > @@ -0,0 +1,564 @@
> >
> > ...
> >
> > +u32 pci_iobase = 0x100;
> > +u32 pci_membase = SSB_PCI_DMA;
>
> These are quite poor names for global symbols.
Agreed. I will change this.
> > +static struct resource ssb_pcicore_mem_resource = {
> > + .name = "SSB PCIcore external memory",
> > + .start = SSB_PCI_DMA,
> > + .end= (u32)SSB_PCI_DMA + (u32)SSB_PCI_DMA_SZ - 1,
> > + .flags = IORESOURCE_MEM,
> > +};
>
> start and end here are resource_size_t. Forcing them to u32 seems
> inappropriate.
You're right. I'll fix that.
> > +void ssb_pcicore_init(struct ssb_pcicore *pc)
>
> Please check that all newly-added global symbols do indeed need global scope.
ok.
> > +static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
> > + u8 address, u16 data)
> > +{
> > + const u16 mdio_control = 0x128;
> > + const u16 mdio_data = 0x12C;
> > + u32 v;
> > + int i;
> > +
> > + v = 0x80; /* Enable Preamble Sequence */
> > + v |= 0x2; /* MDIO Clock Divisor */
> > + pcicore_write32(pc, mdio_control, v);
> > +
> > + v = (1 << 30); /* Start of Transaction */
> > + v |= (1 << 28); /* Write Transaction */
> > + v |= (1 << 17); /* Turnaround */
> > + v |= (u32)device << 22;
> > + v |= (u32)address << 18;
> > + v |= data;
> > + pcicore_write32(pc, mdio_data, v);
> > + udelay(10);
>
> mystery udelays are usually worth a comment.
Sure.
> > +static void ssb_buses_lock(void)
> > +{
> > + if (!ssb_is_early_boot)
> > + mutex_lock(&buses_mutex);
> > +}
> > +
> > +static void ssb_buses_unlock(void)
> > +{
> > + if (!ssb_is_early_boot)
> > + mutex_unlock(&buses_mutex);
> > +}
>
> Some comments are neeeded here to explain why we're jumping through this
> hoop.
I added a comment at the declaration of ssb_is_early_boot,
which tries to explain this in detail.
> It's normally OK to take a mutex early in boot, so one wonders
> what's happening.
Hm, I tried that. There were problems. I don't remember this in detail, though.
This is called _really_ early in boot.
> > +EXPORT_SYMBOL(ssb_clockspeed);
>
> Please check that all newly-added exports really need to be exported (I'm
> sure they do, but..)
>
> > +static int ssb_wait_bit(struct ssb_device *dev, u16 reg, u32 bitmask,
> > + int timeout, int set)
> > +{
> > + int i;
> > + u32 val;
> > +
> > + for (i = 0; i < timeout; i++) {
> > + val = ssb_read32(dev, reg);
> > + if (set) {
> > + if (val & bitmask)
> > + return 0;
> > + } else {
> > + if (!(val & bitmask))
> > + return 0;
> > + }
> > + udelay(10);
> > + }
> > + printk(KERN_ERR PFX "Timeout waiting for bitmask %08X on "
> > + "register %04X to %s.\n",
> > + bitmask, reg, (set ? "set" : "clear"));
> > +
> > + return -ETIMEDOUT;
> > +}
>
> So `timeout' is in units of ten-microseconds. Unusual.
>
> > +void ssb_device_disable(struct ssb_device *dev, u32 core_specific_flags)
> > +{
> > + u32 reject;
> > +
> > + if (ssb_read32(dev, SSB_TMSLOW) & SSB_TMSLOW_RESET)
> > + return;
> > +
> > + reject = ssb_tmslow_reject_bitmask(dev);
> > + ssb_write32(dev, SSB_TMSLOW, reject | SSB_TMSLOW_CLOCK);
> > + ssb_wait_bit(dev, SSB_TMSLOW, reject, 1000, 1);
> > + ssb_wait_bit(dev, SSB_TMSHIGH, SSB_TMSHIGH_BUSY, 1000, 0);
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Fri, Jul 27, 2007 at 06:57:20PM +0200, Michael Buesch wrote: > The Sonics Silicon Backplane is a mini-bus used on > various Broadcom chips and embedded devices. > Devices using the SSB include b44, bcm43xx and various > Broadcom based wireless routers. > A b44 and bcm43xx port and a SSB based OHCI driver is available. > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> At first glance it looks like there might be some tab/space issues in some of the #define blocks toward the end of the patch, although those might be intentional. Aside from whatever other style issues that might be identified, I'll state that this code has been carried in wireless-dev for months and thereby also spent a lot of time in -mm as well as Fedora (rawhide and F-7). The code has proven to be reasonably stable and reliable. Acked-by: John W. Linville <[EMAIL PROTECTED]> -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sk98lin for 2.6.23-rc1
> If anyone still has hang issues with sky2, please send me the hardware > information (lspci, dmesg output), and capture the debugfs state after hang. > > At present the known open skge, sky2 issues are: [snip] There is still this active issue which I believe is orthogonal from the interrupt hang. I just hit it again. The IRQ-hang recovery logic doesn't seem to kick in, so it's perhaps another issue: # ifconfig lan0 lan0 Link encap:Ethernet HWaddr 00:03:2D:05:9C:27 inet addr:192.168.0.250 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13304841 errors:1 dropped:1 overruns:0 frame:2 TX packets:7493765 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:232720755 (221.9 MiB) TX bytes:3964088142 (3.6 GiB) Interrupt:16 # ethtool -S lan0 NIC statistics: tx_bytes: 44342166229 rx_bytes: 28807483162 tx_broadcast: 20071 rx_broadcast: 3309 tx_multicast: 0 rx_multicast: 31 tx_unicast: 45095221 rx_unicast: 43331790 tx_mac_pause: 0 rx_mac_pause: 278 collisions: 0 late_collision: 0 aborted: 0 single_collisions: 0 multi_collisions: 0 rx_short: 0 rx_runt: 0 rx_64_byte_packets: 1815009 rx_65_to_127_byte_packets: 18626585 rx_128_to_255_byte_packets: 788459 rx_256_to_511_byte_packets: 4880174 rx_512_to_1023_byte_packets: 1016831 rx_1024_to_1518_byte_packets: 16208350 rx_1518_to_max_byte_packets: 0 rx_too_long: 0 rx_fifo_overflow: 0 rx_jabber: 0 rx_fcs_error: 0 tx_64_byte_packets: 1632797 tx_65_to_127_byte_packets: 11211285 tx_128_to_255_byte_packets: 1628446 tx_256_to_511_byte_packets: 2042646 tx_512_to_1023_byte_packets: 637342 tx_1024_to_1518_byte_packets: 27962776 tx_1519_to_max_byte_packets: 0 tx_fifo_underrun: 0 # dmesg [snip] sky2 :01:00.0: v1.16 addr 0xdfbfc000 irq 16 Yukon-EC (0xb6) rev 1 sky2 eth1: addr 00:03:2d:05:9c:27 sky2 lan0: enabling interface sky2 lan0: ram buffer 48K [snip] sky2 lan0: rx error, status 0xad78ad78 length 0 lan0: hw csum failure. [stack-trace snipped] lan0: hw csum failure. ... # cat /debug/sky2/lan0 IRQ src=0 mask=c01d control=0 Status ring (empty) Tx ring pending=424...424 report=424 done=424 Rx ring hw get=252 put=405 last=1023 # cat /debug/sky2/lan0 IRQ src=0 mask=c01d control=0 Status ring (empty) Tx ring pending=432...432 report=432 done=432 Rx ring hw get=252 put=415 last=1023 # cat /debug/sky2/lan0 IRQ src=0 mask=c01d control=0 Status ring (empty) Tx ring pending=451...451 report=451 done=451 Rx ring hw get=316 put=440 last=1023 -- Daniel J Blueman - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Friday 27 July 2007 21:38:53 Andrew Morton wrote:
> > > > +static ssize_t ssb_pci_attr_sprom_show(struct device *pcidev,
> > > > + struct device_attribute *attr,
> > > > + char *buf)
> > > > +{
> > > > + struct pci_dev *pdev = container_of(pcidev, struct pci_dev,
> > > > dev);
> > > > + struct ssb_bus *bus;
> > > > + u16 *sprom;
> > > > + int err = -ENODEV;
> > > > + ssize_t count = 0;
> > > > +
> > > > + bus = ssb_pci_dev_to_bus(pdev);
> > > > + if (!bus)
> > > > + goto out;
> > > > + err = -ENOMEM;
> > > > + sprom = kcalloc(SSB_SPROMSIZE_WORDS, sizeof(u16), GFP_KERNEL);
> > > > + if (!sprom)
> > > > + goto out;
> > > > +
> > > > + err = -ERESTARTSYS;
> > > > + if (mutex_lock_interruptible(&bus->pci_sprom_mutex))
> > > > + goto out_kfree;
> > > > + sprom_do_read(bus, sprom);
> > > > + mutex_unlock(&bus->pci_sprom_mutex);
> > > > +
> > > > + count = sprom2hex(sprom, buf, PAGE_SIZE);
> > > > + err = 0;
> > > > +
> > > > +out_kfree:
> > > > + kfree(sprom);
> > > > +out:
> > > > + return err ? err : count;
> > > > +}
> > >
> > > The mutex_lock_interruptible() looks fishy. Some commented explanation of
> > > what it's doing would be good here. It's quite unobvious to this reader.
> > > Cheesy deadlock avoidance? Hope not.
> >
> > No, it's simply to avoid writing the SPROM concurrently.
> > SPROM writing is hairy and we must make sure here that
> > we are the only one accessing the whole bus. We do that
> > by suspending all devices and taking a lock to protect
> > the SPROM from write concurrency.
>
> Sure, but why is the locking interruptible rather than plain old
> mutex_lock()?
Hm, well. We hold this mutex for several seconds, as writing takes
this long. So I simply thought it was worth allowing the waiter
to interrupt here. If you say that's not an issue, I'll be happy
to use mutex_lock() and reduce code complexity in this area.
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/1] lro: Generic Large Receive Offload for TCP traffic
Jan-Bernd Themann wrote: > On Wednesday 25 July 2007 19:17, Andrew Gallatin wrote: >> 3) Padded frames. >> >> I may be missing something, but I don't see where you >> either strip padding from frames or reject padded frames. >> (see the pskb_trim_rcsum() in net/ipv4/ip_input.c:ip_rcv() >> > I think I missed something :-) Will fix that. > In lro_tcp_ip_check we check for the "SKB aggregation interface" > the skb->len against ip->tot_len. This catches padded frames as > eth_type_trans(skb, dev) reduces the length of the SKB. > However, the possible VLAN header is not taken into account. > And for the "receive in pages" interface a wrong length is passed > as argument as well. > > I'd suggest to reject padded frames for aggregation as we do now > (when bugs are fixed) and thus keep the code simple. > I guess that padded frames don't occur too often in high load > situations. If we detect a real performance issue we can still > change that later. The one case where performance may be at issue is in aggregating Acks on connections w/o TCP timestamps where a frame size of 54 bytes is padded out to 60. I did some very quick measurements using netperf -tTCP_SENDFILE on the same athlons mentioned earlier using our 1.3.1 driver. I see a roughly 8% CPU increase (~17% -> ~25%) when I disable LRO (and hence Ack aggregation) on the sender. This works out to an increase in service demand from ~0.3 to ~0.44 according to netperf. With LRO enabled, our counters show we're aggregating acks at a roughly 3:1 ratio. This is probably an optimization that can be done later, but it is helpful. This reminds me.. what would you think about adding some sort of counters, ideally per-interface, to expose how well LRO is working? At the simplest level, you could add them to the lro mgr struct and let drivers export them via ethtool. I think a central approach might be more appropriate. At any rate, I'd prefer the final version to at least have counters to indicate how many packets were aggregated, how many packets were flushed, and how many times we failed to aggregate something due to insufficient net_lro_desc descriptors. Thanks again for taking the lead on this, Drew - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1]ixgbe: Driver for Intel 82598 based 10GbE PCI Express family of adapters
Veeraiyan, Ayyappan wrote: So, with driver/device supporting multiple Tx and Rx queues, I think, it would be very useful to have ethtool interface to manage the number of Tx and Rx queues of the interface. Absolutely! ethtool patches welcome :) git://git.kernel.org/pub/scm/network/ethtool/ethtool.git Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1]ixgbe: Driver for Intel 82598 based 10GbE PCI Express family of adapters
>-Original Message- >From: Jeff Garzik [mailto:[EMAIL PROTECTED] >Veeraiyan, Ayyappan wrote: >> So, with driver/device supporting multiple Tx and Rx queues, I think, it >> would be very useful to have ethtool interface to manage the number of >> Tx and Rx queues of the interface. > > >Absolutely! ethtool patches welcome :) > >git://git.kernel.org/pub/scm/network/ethtool/ethtool.git > We discussed this here today and we will try to come up with patches. Also, FWIW, I will be offline for next 2 months, and someone (Auke ? :)) from our team will submit updated driver shortly.. Ayyappan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Fri, 27 Jul 2007 21:43:59 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote: > > Sure, but why is the locking interruptible rather than plain old > > mutex_lock()? > > Hm, well. We hold this mutex for several seconds, as writing takes > this long. So I simply thought it was worth allowing the waiter > to interrupt here. If you say that's not an issue, I'll be happy > to use mutex_lock() and reduce code complexity in this area. So.. is that what the _interruptible() is for? To allow an impatient user to ^c a read? If so, that sounds reasonable. It's worth a comment explaining these decisions to future readers, because it is hard to work out this sort of thinking just from the bare C code. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] 2.6.23-rc1: known regressions v2
Hi all, Here is a list of some known regressions in 2.6.23-rc1. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions List of Aces NameRegressions fixed since 21-Jun-2007 Adrian Bunk6 Andi Kleen 4 Andrew Morton 4 Linus Torvalds 4 Al Viro3 Jens Axboe 3 Tejun Heo 3 David Woodhouse2 Hugh Dickins 2 Unclassified Subject : 2.6.23-rc1-git3 init failure References : http://lkml.org/lkml/2007/7/26/467 Last known good : ? Submitter : Sid Boyce <[EMAIL PROTECTED]> Caused-By : ? Handled-By : ? Status : unknown Subject : Time Problems with 2.6.23-rc1-gf695baf2 References : http://lkml.org/lkml/2007/7/23/486 Last known good : ? Submitter : Eric Sesterhenn <[EMAIL PROTECTED]> Caused-By : ? Handled-By : ? Status : problem is being debugged IDE Subject : ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not References : http://lkml.org/lkml/2007/7/27/298 Last known good : ? Submitter : dth <[EMAIL PROTECTED]> Caused-By : ? Handled-By : ? Status : unknown Networking Subject : sky2 boot crash in sky2_mac_intr References : http://lkml.org/lkml/2007/7/24/91 Last known good : ? Submitter : Florian Lohoff <[EMAIL PROTECTED]> Caused-By : Handled-By : Stephen Hemminger <[EMAIL PROTECTED]> Status : unknown Subject : New wake ups from sky2 References : http://lkml.org/lkml/2007/7/20/386 Last known good : ? Submitter : Thomas Meyer <[EMAIL PROTECTED]> Caused-By : Stephen Hemminger <[EMAIL PROTECTED]> commit eb35cf60e462491249166182e3e755d3d5d91a28 Handled-By : Stephen Hemminger <[EMAIL PROTECTED]> Status : unknown Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] HW VLAN filtering control
Add support to the VLAN subsystem for enabling/disabling hardware VLAN
filtering at runtime. This is useful for debugging purposes.
The existing vconfig utility can be used without modification.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.22.1-clean/include/linux/if_vlan.h
linux-2.6.22.1/include/linux/if_vlan.h
--- linux-2.6.22.1-clean/include/linux/if_vlan.h2007-07-10
11:56:30.0 -0700
+++ linux-2.6.22.1/include/linux/if_vlan.h 2007-07-26 16:29:00.0
-0700
@@ -106,7 +106,20 @@ struct vlan_priority_tci_mapping {
*/
struct vlan_priority_tci_mapping *next;
};
-
+#define VLAN_FLAG_REORDER 1/* (1 << 0) re_order_header This
option
will cause the
+* VLAN code to move around the
ethernet header on
+* ingress to make the skb look
**exactly** like it
+* came in from an ethernet port.
This destroys some of
+* the VLAN information in the skb,
but it fixes programs
+* like DHCP that use
packet-filtering and don't understand
+* 802.1Q
+*/
+
+#define VLAN_FLAG_DISABLE_FILTER 2 /* (1 << 1) disable HW filtering.
This flag allows
+* devices that perform hardware
filtering to
+* turn off filtering. This may be
useful for
+* debugging or for sniffer
applications.
+*/
/* Holds information that makes sense if this device is a VLAN device.
*/
struct vlan_dev_info {
/** This will be the mapping that correlates skb->priority to
@@ -116,14 +129,7 @@ struct vlan_dev_info {
struct vlan_priority_tci_mapping *egress_priority_map[16]; /* hash
table */
unsigned short vlan_id;/* The VLAN Identifier for this
interface. */
- unsigned short flags; /* (1 << 0) re_order_header This
option will cause the
-* VLAN code to move around
the ethernet header on
-* ingress to make the skb
look **exactly** like it
-* came in from an ethernet
port. This destroys some of
-* the VLAN information in the
skb, but it fixes programs
-* like DHCP that use
packet-filtering and don't understand
-* 802.1Q
-*/
+ unsigned short flags;
struct dev_mc_list *old_mc_list; /* old multi-cast list for the VLAN
interface..
* we save this so we can
tell what changes were
* made, in order to feed the
right changes down
diff -urpN -X dontdiff linux-2.6.22.1-clean/include/linux/netdevice.h
linux-2.6.22.1/include/linux/netdevice.h
--- linux-2.6.22.1-clean/include/linux/netdevice.h 2007-07-10
11:56:30.0 -0700
+++ linux-2.6.22.1/include/linux/netdevice.h2007-07-26
16:29:00.0 -0700
@@ -522,7 +522,9 @@ struct net_device
unsigned short vid);
void(*vlan_rx_kill_vid)(struct net_device *dev,
unsigned short vid);
-
+#define HAVE_VLAN_FLAGS
+ int (*vlan_set_flag)(struct net_device *dev,
+ unsigned int flag, int value);
int (*hard_header_parse)(struct sk_buff *skb,
unsigned char *haddr);
int (*neigh_setup)(struct net_device *dev, struct
neigh_parms *);
diff -urpN -X dontdiff linux-2.6.22.1-clean/net/8021q/vlan_dev.c
linux-2.6.22.1/net/8021q/vlan_dev.c
--- linux-2.6.22.1-clean/net/8021q/vlan_dev.c 2007-07-10
11:56:30.0 -0700
+++ linux-2.6.22.1/net/8021q/vlan_dev.c 2007-07-27 11:40:22.0
-0700
@@ -593,37 +593,58 @@ int vlan_dev_set_egress_priority(char *d
/* Flags are defined in the vlan_dev_info class in
include/linux/if_vlan.h file. */
int vlan_dev_set_vlan_flag(char *dev_name, __u32 flag, short flag_val)
{
+ struct net_device *real_dev;
struct net_device *dev = dev_get_by_name(dev_name);
+ int ret = 0;
- if (dev) {
- if (dev->priv_flags & IFF_802_1Q_VLAN) {
- /* verify flag is supported */
- if (flag == 1) {
- if (flag_val) {
- VLAN_DEV_INFO(dev)->flags |= 1;
Re: [PATCH] Merge the Sonics Silicon Backplane subsystem
On Friday 27 July 2007 22:12:49 Andrew Morton wrote: > On Fri, 27 Jul 2007 21:43:59 +0200 > Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > Sure, but why is the locking interruptible rather than plain old > > > mutex_lock()? > > > > Hm, well. We hold this mutex for several seconds, as writing takes > > this long. So I simply thought it was worth allowing the waiter > > to interrupt here. If you say that's not an issue, I'll be happy > > to use mutex_lock() and reduce code complexity in this area. > > So.. is that what the _interruptible() is for? To allow an impatient user > to ^c > a read? Yeah, I thought so. > If so, that sounds reasonable. It's worth a comment explaining these > decisions > to future readers, because it is hard to work out this sort of thinking just > from the bare C code. Ok, no problem. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] HW VLAN filtering control
This patchset adds the capability to disable hardware VLAN filtering at runtime via the existing vconfig utility. It's useful for debugging purposes. The first patch modifies the VLAN subsystem to define the flag, and to support passing the flag on to the base driver. The second patch modifies e1000 to support the flag. Since it's only one function, other drivers can be easily modified to support this functionality. vconfig is used without modification to enable or disable filtering: # vconfig [vlan-interface] 2 1 will disable filtering, and # vconfig [vlan-interface] 2 0 will enable filtering. Signed-off-by: Mitch Williams <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] HW VLAN filtering control
Add support to e1000 for enabling/disabling hardware VLAN filtering
at runtime.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff
linux-2.6.22.1-clean/drivers/net/e1000/e1000_main.c
linux-2.6.22.1/drivers/net/e1000/e1000_main.c
--- linux-2.6.22.1-clean/drivers/net/e1000/e1000_main.c 2007-07-10
11:56:30.0 -0700
+++ linux-2.6.22.1/drivers/net/e1000/e1000_main.c 2007-07-27
13:16:52.0 -0700
@@ -197,6 +197,9 @@ static void e1000_vlan_rx_register(struc
static void e1000_vlan_rx_add_vid(struct net_device *netdev, uint16_t
vid);
static void e1000_vlan_rx_kill_vid(struct net_device *netdev, uint16_t
vid);
static void e1000_restore_vlan(struct e1000_adapter *adapter);
+#ifdef HAVE_VLAN_FLAGS
+static int e1000_vlan_set_flag(struct net_device *netdev, unsigned int
flag, int value);
+#endif
static int e1000_suspend(struct pci_dev *pdev, pm_message_t state);
#ifdef CONFIG_PM
@@ -938,6 +941,10 @@ e1000_probe(struct pci_dev *pdev,
netdev->vlan_rx_register = e1000_vlan_rx_register;
netdev->vlan_rx_add_vid = e1000_vlan_rx_add_vid;
netdev->vlan_rx_kill_vid = e1000_vlan_rx_kill_vid;
+#ifdef HAVE_VLAN_FLAGS
+ netdev->vlan_set_flag = e1000_vlan_set_flag;
+#endif
+
#ifdef CONFIG_NET_POLL_CONTROLLER
netdev->poll_controller = e1000_netpoll;
#endif
@@ -4973,7 +4980,42 @@ e1000_vlan_rx_register(struct net_device
e1000_irq_enable(adapter);
}
+#ifdef HAVE_VLAN_FLAGS
+static int
+e1000_vlan_set_flag(struct net_device *netdev, unsigned int flag, int
value)
+{
+ struct e1000_adapter *adapter = netdev_priv(netdev);
+ uint32_t rctl;
+ /* The only flag we currently care about is bit 1,
+ which controls HW filtering. */
+ e1000_irq_disable(adapter);
+ if (adapter->hw.mac_type == e1000_ich8lan)
+ return -EPERM;
+
+ if (flag == VLAN_FLAG_DISABLE_FILTER) {
+ if (value) {
+ /* disable VLAN filtering */
+ rctl = E1000_READ_REG(&adapter->hw, RCTL);
+ rctl &= ~E1000_RCTL_VFE;
+ E1000_WRITE_REG(&adapter->hw, RCTL, rctl);
+ netdev->features &= ~NETIF_F_HW_VLAN_FILTER;
+ } else {
+ /* enable VLAN receive filtering */
+ rctl = E1000_READ_REG(&adapter->hw, RCTL);
+ rctl |= E1000_RCTL_VFE;
+ rctl &= ~E1000_RCTL_CFIEN;
+ E1000_WRITE_REG(&adapter->hw, RCTL, rctl);
+ netdev->features |= NETIF_F_HW_VLAN_FILTER;
+ e1000_restore_vlan(adapter);
+ e1000_update_mng_vlan(adapter);
+ }
+ }
+
+ e1000_irq_enable(adapter);
+ return 0;
+}
+#endif
static void
e1000_vlan_rx_add_vid(struct net_device *netdev, uint16_t vid)
{
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] HW VLAN filtering control
On Fri, 2007-07-27 at 14:06 -0700, Ben Greear wrote: > This looks fine to me. > > Ben > Grr. Except that Evolution mangled them. I'll have to repost. -Mitch - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] HW VLAN filtering control
Mitch Williams wrote: This patchset adds the capability to disable hardware VLAN filtering at runtime via the existing vconfig utility. It's useful for debugging purposes. The first patch modifies the VLAN subsystem to define the flag, and to support passing the flag on to the base driver. The second patch modifies e1000 to support the flag. Since it's only one function, other drivers can be easily modified to support this functionality. vconfig is used without modification to enable or disable filtering: # vconfig [vlan-interface] 2 1 will disable filtering, and # vconfig [vlan-interface] 2 0 will enable filtering. This looks fine to me. Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC/Progress update: e1000e pci-express -only e1000 driver
All, Here's a short update on progress with e1000e, the future pci-express -only version of the current e1000 driver. Since about a month ago, a lot has changed so I'd like to keep everyone posted on progress and solicit ideas. What happened since I posted "e1000new" ? Here's a summary: * e1000new was renamed to e1000e and all non-pcie hardware support was dropped from this driver (all 8254* chipsets). * after this stage, I removed all code that handled the flags (32 or so) that are no longer used or obsolete since they are always enabled (e.g. all devices have msi) * Removed non-essential module parameters (e.g. speed, duplex, flowcontrol) * Removed all multi-queue code * Filtered all unused macro's and define's out (about 700 or so) * converted the bitfields into other flag types * filtered out unreached code (for non-supported phy types, bus types in the pci-e adapters) Please note that I'm basically coding e1000e for all pcie adapters, but the first merge will only enable ich9 devices (by masking the device IDs). This will allow me to develop the code with an eye on all devices and structure, while not removing code that we might need later anyway. After that the main issue is the internal API. I've started to give it a diet mainly for two reasons: 1) lots of obfuscating wrappers and indirection 2) once I remove the lot of those where possible, things should become a bit more clear where we can go since it's going to be more easy to find the cases we can eliminate or cleanup. I'm now at this phase and still working on it, so this is all major work in progress. Since this obviously is going to take me more time, I hope to post these updates every two weeks or so, so people can give the driver a try (it's largely untested of course) and review the direction that I'm headed in. The patches are available on http: http://foo-projects.org/~sofar/e1000e-1.patch [585k] http://foo-projects.org/~sofar/e1000e-1.patch.bz2 [93k] Feel free to suggest and comment. Better now then later ;) Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] HW VLAN filtering control (resend)
This patchset adds the capability to disable hardware VLAN filtering at runtime via the existing vconfig utility. It's useful for debugging purposes. The first patch modifies the VLAN subsystem to define the flag, and to support passing the flag on to the base driver. The second patch modifies e1000 to support the flag. Since it's only one function, other drivers can be easily modified to support this functionality. vconfig is used without modification to enable or disable filtering: # vconfig [vlan-interface] 2 1 will disable filtering, and # vconfig [vlan-interface] 2 0 will enable filtering. (Now with non-mangled goodness.) Signed-off-by: Mitch Williams <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] HW VLAN filtering control (resend)
Add support to the VLAN subsystem for enabling/disabling hardware VLAN
filtering at runtime. This is useful for debugging purposes.
The existing vconfig utility can be used without modification.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.22.1-clean/include/linux/if_vlan.h
linux-2.6.22.1/include/linux/if_vlan.h
--- linux-2.6.22.1-clean/include/linux/if_vlan.h2007-07-10
11:56:30.0 -0700
+++ linux-2.6.22.1/include/linux/if_vlan.h 2007-07-26 16:29:00.0
-0700
@@ -106,7 +106,20 @@ struct vlan_priority_tci_mapping {
*/
struct vlan_priority_tci_mapping *next;
};
-
+#define VLAN_FLAG_REORDER 1/* (1 << 0) re_order_header This
option will cause the
+* VLAN code to move around the
ethernet header on
+* ingress to make the skb look
**exactly** like it
+* came in from an ethernet port.
This destroys some of
+* the VLAN information in the skb,
but it fixes programs
+* like DHCP that use
packet-filtering and don't understand
+* 802.1Q
+*/
+
+#define VLAN_FLAG_DISABLE_FILTER 2 /* (1 << 1) disable HW filtering. This
flag allows
+* devices that perform hardware
filtering to
+* turn off filtering. This may be
useful for
+* debugging or for sniffer
applications.
+*/
/* Holds information that makes sense if this device is a VLAN device. */
struct vlan_dev_info {
/** This will be the mapping that correlates skb->priority to
@@ -116,14 +129,7 @@ struct vlan_dev_info {
struct vlan_priority_tci_mapping *egress_priority_map[16]; /* hash
table */
unsigned short vlan_id;/* The VLAN Identifier for this
interface. */
- unsigned short flags; /* (1 << 0) re_order_header This
option will cause the
-* VLAN code to move around the
ethernet header on
-* ingress to make the skb look
**exactly** like it
-* came in from an ethernet port.
This destroys some of
-* the VLAN information in the skb,
but it fixes programs
-* like DHCP that use
packet-filtering and don't understand
-* 802.1Q
-*/
+ unsigned short flags;
struct dev_mc_list *old_mc_list; /* old multi-cast list for the VLAN
interface..
* we save this so we can tell what
changes were
* made, in order to feed the right
changes down
diff -urpN -X dontdiff linux-2.6.22.1-clean/include/linux/netdevice.h
linux-2.6.22.1/include/linux/netdevice.h
--- linux-2.6.22.1-clean/include/linux/netdevice.h 2007-07-10
11:56:30.0 -0700
+++ linux-2.6.22.1/include/linux/netdevice.h2007-07-26 16:29:00.0
-0700
@@ -522,7 +522,9 @@ struct net_device
unsigned short vid);
void(*vlan_rx_kill_vid)(struct net_device *dev,
unsigned short vid);
-
+#define HAVE_VLAN_FLAGS
+ int (*vlan_set_flag)(struct net_device *dev,
+ unsigned int flag, int value);
int (*hard_header_parse)(struct sk_buff *skb,
unsigned char *haddr);
int (*neigh_setup)(struct net_device *dev, struct
neigh_parms *);
diff -urpN -X dontdiff linux-2.6.22.1-clean/net/8021q/vlan_dev.c
linux-2.6.22.1/net/8021q/vlan_dev.c
--- linux-2.6.22.1-clean/net/8021q/vlan_dev.c 2007-07-10 11:56:30.0
-0700
+++ linux-2.6.22.1/net/8021q/vlan_dev.c 2007-07-27 11:40:22.0 -0700
@@ -593,37 +593,58 @@ int vlan_dev_set_egress_priority(char *d
/* Flags are defined in the vlan_dev_info class in include/linux/if_vlan.h
file. */
int vlan_dev_set_vlan_flag(char *dev_name, __u32 flag, short flag_val)
{
+ struct net_device *real_dev;
struct net_device *dev = dev_get_by_name(dev_name);
+ int ret = 0;
- if (dev) {
- if (dev->priv_flags & IFF_802_1Q_VLAN) {
- /* verify flag is supported */
- if (flag == 1) {
- if (flag_val) {
- VLAN_DEV_I
[PATCH 2/2] HW VLAN filtering control (resend)
Add support to e1000 for enabling/disabling hardware VLAN filtering
at runtime.
Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.22.1-clean/drivers/net/e1000/e1000_main.c
linux-2.6.22.1/drivers/net/e1000/e1000_main.c
--- linux-2.6.22.1-clean/drivers/net/e1000/e1000_main.c 2007-07-10
11:56:30.0 -0700
+++ linux-2.6.22.1/drivers/net/e1000/e1000_main.c 2007-07-27
13:16:52.0 -0700
@@ -197,6 +197,9 @@ static void e1000_vlan_rx_register(struc
static void e1000_vlan_rx_add_vid(struct net_device *netdev, uint16_t vid);
static void e1000_vlan_rx_kill_vid(struct net_device *netdev, uint16_t vid);
static void e1000_restore_vlan(struct e1000_adapter *adapter);
+#ifdef HAVE_VLAN_FLAGS
+static int e1000_vlan_set_flag(struct net_device *netdev, unsigned int flag,
int value);
+#endif
static int e1000_suspend(struct pci_dev *pdev, pm_message_t state);
#ifdef CONFIG_PM
@@ -938,6 +941,10 @@ e1000_probe(struct pci_dev *pdev,
netdev->vlan_rx_register = e1000_vlan_rx_register;
netdev->vlan_rx_add_vid = e1000_vlan_rx_add_vid;
netdev->vlan_rx_kill_vid = e1000_vlan_rx_kill_vid;
+#ifdef HAVE_VLAN_FLAGS
+ netdev->vlan_set_flag = e1000_vlan_set_flag;
+#endif
+
#ifdef CONFIG_NET_POLL_CONTROLLER
netdev->poll_controller = e1000_netpoll;
#endif
@@ -4973,7 +4980,42 @@ e1000_vlan_rx_register(struct net_device
e1000_irq_enable(adapter);
}
+#ifdef HAVE_VLAN_FLAGS
+static int
+e1000_vlan_set_flag(struct net_device *netdev, unsigned int flag, int value)
+{
+ struct e1000_adapter *adapter = netdev_priv(netdev);
+ uint32_t rctl;
+ /* The only flag we currently care about is bit 1,
+ which controls HW filtering. */
+ e1000_irq_disable(adapter);
+ if (adapter->hw.mac_type == e1000_ich8lan)
+ return -EPERM;
+
+ if (flag == VLAN_FLAG_DISABLE_FILTER) {
+ if (value) {
+ /* disable VLAN filtering */
+ rctl = E1000_READ_REG(&adapter->hw, RCTL);
+ rctl &= ~E1000_RCTL_VFE;
+ E1000_WRITE_REG(&adapter->hw, RCTL, rctl);
+ netdev->features &= ~NETIF_F_HW_VLAN_FILTER;
+ } else {
+ /* enable VLAN receive filtering */
+ rctl = E1000_READ_REG(&adapter->hw, RCTL);
+ rctl |= E1000_RCTL_VFE;
+ rctl &= ~E1000_RCTL_CFIEN;
+ E1000_WRITE_REG(&adapter->hw, RCTL, rctl);
+ netdev->features |= NETIF_F_HW_VLAN_FILTER;
+ e1000_restore_vlan(adapter);
+ e1000_update_mng_vlan(adapter);
+ }
+ }
+
+ e1000_irq_enable(adapter);
+ return 0;
+}
+#endif
static void
e1000_vlan_rx_add_vid(struct net_device *netdev, uint16_t vid)
{
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposed interface for per-packet mesh-ttl
On Fri, 2007-07-27 at 20:56 +0100, Christoph Hellwig wrote: > On Tue, Jul 03, 2007 at 12:29:24PM -0700, Javier Cardona wrote: > > I'm currently working on per-packet mesh ttl. My plan is to register > > new mesh sockopts through netfilter. The user interface will be: > > NACK. Drivers should never add sockopt, and drivers should not abuse > netfilter hooks. Do you have a suggestion for a better way to approach per-packet options that userspace programs can set? Thanks, Dan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: D-Link DFE-580TX 4 port NIC problems
On Fri, 27 Jul 2007 14:08:09 +0200 Clemens Koller <[EMAIL PROTECTED]> wrote: > Hi, Mario! > > Mario Doering schrieb: > > Hello, > > > > are there any news or questions on this issue? > > Can you try the latest kernel to see if the same problem > persists? > Is there any kernel version where it was working fine? Hello Clemens, I have tried different kernerls with no success so far. I have not tried a 2.6.22 kernel yet, but I can do so of course. It would take some time then again to wait for the error to arise ;-) Bye, Mario. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] forcedeth: mac address correct
In older chipsets, the mac address was stored in reversed order.
However, in newer chipsets, the mac address is in correct order. This
patch takes those newer chipsets into account and does not rely on a
special bit setup by BIOS'.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- old/drivers/net/forcedeth.c 2007-07-26 23:09:31.0 -0400
+++ new/drivers/net/forcedeth.c 2007-07-26 23:11:04.0 -0400
@@ -178,6 +178,7 @@
#define DEV_HAS_STATISTICS_V2 0x0800 /* device supports hw statistics
version 2 */
#define DEV_HAS_TEST_EXTENDED 0x1000 /* device supports extended diagnostic
test */
#define DEV_HAS_MGMT_UNIT 0x2000 /* device supports management unit */
+#define DEV_HAS_CORRECT_MACADDR 0x4000 /* device supports correct mac address
order */
enum {
NvRegIrqStatus = 0x000,
@@ -5172,7 +5173,8 @@
/* check the workaround bit for correct mac address order */
txreg = readl(base + NvRegTransmitPoll);
- if (txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) {
+ if ((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
+ (id->driver_data & DEV_HAS_CORRECT_MACADDR) {
/* mac address is already in correct order */
dev->dev_addr[0] = (np->orig_mac[0] >> 0) & 0xff;
dev->dev_addr[1] = (np->orig_mac[0] >> 8) & 0xff;
@@ -5500,67 +5502,67 @@
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_16),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_17),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_18),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_19),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_20),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_21),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENE
Re: [PATCH] forcedeth: mac address correct
On 27/07/07 04:33, Ayaz Abdulla wrote:
> In older chipsets, the mac address was stored in reversed order.
> However, in newer chipsets, the mac address is in correct order. This
> patch takes those newer chipsets into account and does not rely on a
> special bit setup by BIOS'.
>
> Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
>
>
- if (txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) {
+ if ((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
+ (id->driver_data & DEV_HAS_CORRECT_MACADDR) {
This will not compile.
--
Simon Arlott
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] forcedeth: mac address correct
Resending:
In older chipsets, the mac address was stored in reversed order.
However, in newer chipsets, the mac address is in correct order. This
patch takes those newer chipsets into account and does not rely on a
special bit setup by BIOS'.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- old/drivers/net/forcedeth.c 2007-07-26 23:09:31.0 -0400
+++ new/drivers/net/forcedeth.c 2007-07-26 23:43:09.0 -0400
@@ -178,6 +178,7 @@
#define DEV_HAS_STATISTICS_V2 0x0800 /* device supports hw statistics
version 2 */
#define DEV_HAS_TEST_EXTENDED 0x1000 /* device supports extended diagnostic
test */
#define DEV_HAS_MGMT_UNIT 0x2000 /* device supports management unit */
+#define DEV_HAS_CORRECT_MACADDR 0x4000 /* device supports correct mac address
order */
enum {
NvRegIrqStatus = 0x000,
@@ -5172,7 +5173,8 @@
/* check the workaround bit for correct mac address order */
txreg = readl(base + NvRegTransmitPoll);
- if (txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) {
+ if ((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
+ (id->driver_data & DEV_HAS_CORRECT_MACADDR)) {
/* mac address is already in correct order */
dev->dev_addr[0] = (np->orig_mac[0] >> 0) & 0xff;
dev->dev_addr[1] = (np->orig_mac[0] >> 8) & 0xff;
@@ -5500,67 +5502,67 @@
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_16),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_17),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_18),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP61 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_19),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_20),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_NVIDIA_NVENET_21),
- .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ .driver_data =
DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
{ /* MCP65 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
PCI_DEVICE_ID_
Re: Proposed interface for per-packet mesh-ttl
On Fri, 27 Jul 2007 18:22:22 -0400 Dan Williams <[EMAIL PROTECTED]> wrote: > On Fri, 2007-07-27 at 20:56 +0100, Christoph Hellwig wrote: > > On Tue, Jul 03, 2007 at 12:29:24PM -0700, Javier Cardona wrote: > > > I'm currently working on per-packet mesh ttl. My plan is to register > > > new mesh sockopts through netfilter. The user interface will be: > > > > NACK. Drivers should never add sockopt, and drivers should not abuse > > netfilter hooks. > > Do you have a suggestion for a better way to approach per-packet options > that userspace programs can set? > > Thanks, > Dan In this case perhaps you can have a table that maps skb->priority to mesh ttl? priorty can already by handled by existing setsockopt calls, and modified by netfilter and QoS managements. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
