* Re: mmotm 2010-03-23 - IPv6 warnings...
From: Stephen Hemminger @ 2010-03-28 3:32 UTC (permalink / raw)
To: David Miller; +Cc: Valdis.Kletnieks, akpm, netdev, linux-kernel
In-Reply-To: <20100325.232349.66185070.davem@davemloft.net>
On Thu, 25 Mar 2010 23:23:49 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Valdis.Kletnieks@vt.edu
> Date: Fri, 26 Mar 2010 02:18:22 -0400
>
> > Confirming looks like a good fix - no cruft in dmesg, and I have ipv6 addresses:
>
> Great, thanks for testing.
>
> Andrew your box should be good now too.
Thanks for fixing this.
--
^ permalink raw reply
* [PATCH RFC] inetpeer: Support ipv6 addresses.
From: David Miller @ 2010-03-28 3:31 UTC (permalink / raw)
To: netdev; +Cc: herbert
inetpeer: Support ipv6 addresses.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
This a first step based upon the talks we were having the other week
about potentially moving the dst metrics out into the inetpeer cache.
The next step would be to move the peer pointer into dst_entry (or
some common encapsulator datastructure that ipv4 and ipv6 could
share, inet_dst_entry or something like that), and provide the
necessary rt6_bind_peer() function for ipv6. A small set of changes
could then add timewait recycling support to ipv6 essentially for
free (commonize code, provide some wrapper for route type specific
code).
The limited dst metric usage in DecNET could then be moved into
the DecNET route entry struct. This way we don't have to support
DecNET in the inetpeer cache just for the sake of it's metrics. :-)
Finally, we can really move the metrics array into the inetpeer
entries.
How does this sound?
diff --git a/include/net/inetpeer.h b/include/net/inetpeer.h
index 87b1df0..2924302 100644
--- a/include/net/inetpeer.h
+++ b/include/net/inetpeer.h
@@ -13,10 +13,18 @@
#include <linux/spinlock.h>
#include <asm/atomic.h>
+typedef struct {
+ union {
+ __be32 a4;
+ __be32 a6[4];
+ };
+ __u16 family;
+} inet_peer_address_t;
+
struct inet_peer {
/* group together avl_left,avl_right,v4daddr to speedup lookups */
struct inet_peer *avl_left, *avl_right;
- __be32 v4daddr; /* peer's address */
+ inet_peer_address_t daddr;
__u32 avl_height;
struct list_head unused;
__u32 dtime; /* the time of last use of not
@@ -31,7 +39,7 @@ struct inet_peer {
void inet_initpeers(void) __init;
/* can be called with or without local BH being disabled */
-struct inet_peer *inet_getpeer(__be32 daddr, int create);
+struct inet_peer *inet_getpeer(inet_peer_address_t *daddr, int create);
/* can be called from BH context or outside */
extern void inet_putpeer(struct inet_peer *p);
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index 6bcfe52..87066eb 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -19,6 +19,7 @@
#include <linux/net.h>
#include <net/ip.h>
#include <net/inetpeer.h>
+#include <net/ipv6.h>
/*
* Theory of operations.
@@ -136,6 +137,47 @@ static void unlink_from_unused(struct inet_peer *p)
spin_unlock_bh(&inet_peer_unused_lock);
}
+static inline bool inet_peer_addr_equal(inet_peer_address_t *a, inet_peer_address_t *b)
+{
+ if (a->family == b->family) {
+ switch (a->family) {
+ case AF_INET:
+ if (a->a4 == b->a4)
+ return true;
+ break;
+ case AF_INET6:
+ if (!ipv6_addr_cmp((struct in6_addr *)a,
+ (struct in6_addr *)b))
+ return true;
+ break;
+ default:
+ break;
+ }
+ }
+ return false;
+}
+
+static inline u32 inet_peer_key(inet_peer_address_t *a)
+{
+ u32 key;
+
+ switch (a->family) {
+ case AF_INET:
+ key = (__force __u32) a->a4;
+ break;
+ case AF_INET6:
+ key = ((__force __u32)a->a6[0] ^
+ (__force __u32)a->a6[1] ^
+ (__force __u32)a->a6[2] ^
+ (__force __u32)a->a6[3]);
+ break;
+ default:
+ key = 0;
+ break;
+ }
+ return key;
+}
+
/*
* Called with local BH disabled and the pool lock held.
* _stack is known to be NULL or not at compile time,
@@ -143,15 +185,16 @@ static void unlink_from_unused(struct inet_peer *p)
*/
#define lookup(_daddr, _stack) \
({ \
+ u32 key = inet_peer_key(_daddr); \
struct inet_peer *u, **v; \
if (_stack != NULL) { \
stackptr = _stack; \
*stackptr++ = &peer_root; \
} \
for (u = peer_root; u != peer_avl_empty; ) { \
- if (_daddr == u->v4daddr) \
+ if (inet_peer_addr_equal(_daddr, &u->daddr)) \
break; \
- if ((__force __u32)_daddr < (__force __u32)u->v4daddr) \
+ if (key < inet_peer_key(&u->daddr)) \
v = &u->avl_left; \
else \
v = &u->avl_right; \
@@ -280,7 +323,7 @@ static void unlink_from_pool(struct inet_peer *p)
if (atomic_read(&p->refcnt) == 1) {
struct inet_peer **stack[PEER_MAXDEPTH];
struct inet_peer ***stackptr, ***delp;
- if (lookup(p->v4daddr, stack) != p)
+ if (lookup(&p->daddr, stack) != p)
BUG();
delp = stackptr - 1; /* *delp[0] == p */
if (p->avl_left == peer_avl_empty) {
@@ -292,7 +335,7 @@ static void unlink_from_pool(struct inet_peer *p)
t = lookup_rightempty(p);
BUG_ON(*stackptr[-1] != t);
**--stackptr = t->avl_left;
- /* t is removed, t->v4daddr > x->v4daddr for any
+ /* t is removed, t->daddr > x->daddr for any
* x in p->avl_left subtree.
* Put t in the old place of p. */
*delp[0] = t;
@@ -358,7 +401,7 @@ static int cleanup_once(unsigned long ttl)
}
/* Called with or without local BH being disabled. */
-struct inet_peer *inet_getpeer(__be32 daddr, int create)
+struct inet_peer *inet_getpeer(inet_peer_address_t *daddr, int create)
{
struct inet_peer *p, *n;
struct inet_peer **stack[PEER_MAXDEPTH], ***stackptr;
@@ -384,10 +427,11 @@ struct inet_peer *inet_getpeer(__be32 daddr, int create)
n = kmem_cache_alloc(peer_cachep, GFP_ATOMIC);
if (n == NULL)
return NULL;
- n->v4daddr = daddr;
+ n->daddr = *daddr;
atomic_set(&n->refcnt, 1);
atomic_set(&n->rid, 0);
- atomic_set(&n->ip_id_count, secure_ip_id(daddr));
+ if (daddr->family == AF_INET)
+ atomic_set(&n->ip_id_count, secure_ip_id(daddr->a4));
n->tcp_ts_stamp = 0;
write_lock_bh(&peer_pool_lock);
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index b59430b..681c8b9 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -142,8 +142,14 @@ static void ip4_frag_init(struct inet_frag_queue *q, void *a)
qp->saddr = arg->iph->saddr;
qp->daddr = arg->iph->daddr;
qp->user = arg->user;
- qp->peer = sysctl_ipfrag_max_dist ?
- inet_getpeer(arg->iph->saddr, 1) : NULL;
+ if (sysctl_ipfrag_max_dist) {
+ inet_peer_address_t addr;
+
+ addr.a4 = arg->iph->saddr;
+ addr.family = AF_INET;
+ qp->peer = inet_getpeer(&addr, 1);
+ } else
+ qp->peer = NULL;
}
static __inline__ void ip4_frag_free(struct inet_frag_queue *q)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 32d3961..9334e29 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1287,9 +1287,12 @@ skip_hashing:
void rt_bind_peer(struct rtable *rt, int create)
{
static DEFINE_SPINLOCK(rt_peer_lock);
+ inet_peer_address_t addr;
struct inet_peer *peer;
- peer = inet_getpeer(rt->rt_dst, create);
+ addr.a4 = rt->rt_dst;
+ addr.family = AF_INET;
+ peer = inet_getpeer(&addr, create);
spin_lock_bh(&rt_peer_lock);
if (rt->peer == NULL) {
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index f4df5f9..9de6a12 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1350,7 +1350,7 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
tcp_death_row.sysctl_tw_recycle &&
(dst = inet_csk_route_req(sk, req)) != NULL &&
(peer = rt_get_peer((struct rtable *)dst)) != NULL &&
- peer->v4daddr == saddr) {
+ peer->daddr.a4 == saddr) {
if ((u32)get_seconds() - peer->tcp_ts_stamp < TCP_PAWS_MSL &&
(s32)(peer->tcp_ts - req->ts_recent) >
TCP_PAWS_WINDOW) {
@@ -1770,7 +1770,11 @@ int tcp_v4_remember_stamp(struct sock *sk)
int release_it = 0;
if (!rt || rt->rt_dst != inet->inet_daddr) {
- peer = inet_getpeer(inet->inet_daddr, 1);
+ inet_peer_address_t addr;
+
+ addr.a4 = inet->inet_daddr;
+ addr.family = AF_INET;
+ peer = inet_getpeer(&addr, 1);
release_it = 1;
} else {
if (!rt->peer)
@@ -1795,8 +1799,12 @@ int tcp_v4_remember_stamp(struct sock *sk)
int tcp_v4_tw_remember_stamp(struct inet_timewait_sock *tw)
{
- struct inet_peer *peer = inet_getpeer(tw->tw_daddr, 1);
+ inet_peer_address_t addr;
+ struct inet_peer *peer;
+ addr.a4 = tw->tw_daddr;
+ addr.family = AF_INET;
+ peer = inet_getpeer(&addr, 1);
if (peer) {
const struct tcp_timewait_sock *tcptw = tcp_twsk((struct sock *)tw);
^ permalink raw reply related
* Re: [PATCH] r8169: fix broken register writes
From: David Miller @ 2010-03-28 2:38 UTC (permalink / raw)
To: romieu; +Cc: ben, timo.teras, ivecera, netdev
In-Reply-To: <20100328003143.GA8501@electric-eye.fr.zoreil.com>
From: François Romieu <romieu@fr.zoreil.com>
Date: Sun, 28 Mar 2010 01:31:43 +0100
> This is quite similar to b39fe41f481d20c201012e4483e76c203802dda7
> though said registers are not even documented as 64-bit registers
> - as opposed to the initial TxDescStartAddress ones - but as single
> bytes which must be combined into 32 bits at the MMIO read/write
> level before being merged into a 64 bit logical entity.
>
> Credits go to Ben Hutchings <ben@decadent.org.uk> for the MAR
> registers (aka "multicast is broken for ages on ARM) and to
> Timo Teräs <timo.teras@iki.fi> for the MAC registers.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Applied, thanks Francois.
Probably the rest of the driver should be audited for other
areas where we may end up having this problem.
Or, we should create readq/writeq macros (like other drivers do on
32-bit platforms, f.e. see drivers/net/niu.c) which write the two
32-bit parts in this required order. Then access the registers using
readq/writeq entities throughout the driver.
This would have two benefits:
1) Coverage for all possible bug cases.
2) Real 64-bit accesses on 64-bit platforms.
Just some suggestions.
Thanks.
^ permalink raw reply
* [PATCH] decnet: Remove unused FIB metric macros.
From: David Miller @ 2010-03-28 2:26 UTC (permalink / raw)
To: netdev
Unlike the ipv4 side, these are completely unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Committed to net-next-2.6
include/net/dn_fib.h | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/include/net/dn_fib.h b/include/net/dn_fib.h
index 52da6c3..bbcde32 100644
--- a/include/net/dn_fib.h
+++ b/include/net/dn_fib.h
@@ -50,10 +50,6 @@ struct dn_fib_info {
__le16 fib_prefsrc;
__u32 fib_priority;
__u32 fib_metrics[RTAX_MAX];
-#define dn_fib_mtu fib_metrics[RTAX_MTU-1]
-#define dn_fib_window fib_metrics[RTAX_WINDOW-1]
-#define dn_fib_rtt fib_metrics[RTAX_RTT-1]
-#define dn_fib_advmss fib_metrics[RTAX_ADVMSS-1]
int fib_nhs;
int fib_power;
struct dn_fib_nh fib_nh[0];
--
1.7.0.3
^ permalink raw reply related
* Re: [PATCH] r8169: fix broken register writes
From: Ben Hutchings @ 2010-03-28 0:47 UTC (permalink / raw)
To: François Romieu; +Cc: David Miller, timo.teras, ivecera, netdev
In-Reply-To: <20100328003143.GA8501@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
On Sun, 2010-03-28 at 02:31 +0100, François Romieu wrote:
> This is quite similar to b39fe41f481d20c201012e4483e76c203802dda7
> though said registers are not even documented as 64-bit registers
> - as opposed to the initial TxDescStartAddress ones - but as single
> bytes which must be combined into 32 bits at the MMIO read/write
> level before being merged into a 64 bit logical entity.
[...]
Thanks François. Which hardware have you tested this on so far? I was
hesitant to make changes because of the huge number of variants.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH] r8169: fix broken register writes
From: François Romieu @ 2010-03-28 0:31 UTC (permalink / raw)
To: David Miller; +Cc: ben, timo.teras, ivecera, netdev
In-Reply-To: <20100327.163005.28815553.davem@davemloft.net>
This is quite similar to b39fe41f481d20c201012e4483e76c203802dda7
though said registers are not even documented as 64-bit registers
- as opposed to the initial TxDescStartAddress ones - but as single
bytes which must be combined into 32 bits at the MMIO read/write
level before being merged into a 64 bit logical entity.
Credits go to Ben Hutchings <ben@decadent.org.uk> for the MAR
registers (aka "multicast is broken for ages on ARM) and to
Timo Teräs <timo.teras@iki.fi> for the MAC registers.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/r8169.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9d3ebf3..966407c 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2821,8 +2821,8 @@ static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr)
spin_lock_irq(&tp->lock);
RTL_W8(Cfg9346, Cfg9346_Unlock);
- RTL_W32(MAC0, low);
RTL_W32(MAC4, high);
+ RTL_W32(MAC0, low);
RTL_W8(Cfg9346, Cfg9346_Lock);
spin_unlock_irq(&tp->lock);
@@ -4754,8 +4754,8 @@ static void rtl_set_rx_mode(struct net_device *dev)
mc_filter[1] = swab32(data);
}
- RTL_W32(MAR0 + 0, mc_filter[0]);
RTL_W32(MAR0 + 4, mc_filter[1]);
+ RTL_W32(MAR0 + 0, mc_filter[0]);
RTL_W32(RxConfig, tmp);
--
1.6.6.1
^ permalink raw reply related
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: David Miller @ 2010-03-28 0:17 UTC (permalink / raw)
To: jengelh; +Cc: schwab, tony.luck, netdev
In-Reply-To: <alpine.LSU.2.01.1003280107420.14977@obet.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Sun, 28 Mar 2010 01:11:13 +0100 (CET)
> On Sunday 2010-03-28 00:37, David Miller wrote:
>>
>>> net: fix unaligned access in IFLA_STATS64
>>
>>Applied to net-next-2.6, thanks Jan.
>>
>>Hey, don't we need some adjustments to if_nlmsg_size()? I don't see
>>it accounting for IFLA_STATS64/"struct rtnl_link_stats64" there.
>
> If I am not mistaken, the answer is "not strictly". But of course it's
> nicer if we don't need to realloc just because we were too conservative
> in the initial calculation.
Right.
> net: increase preallocated size of nlmsg to accomodate for IFLA_STATS64
>
> When more data is stuffed into an nlmsg than initially projected, an
> extra allocation needs to be done. Reserve enough for IFLA_STATS64 so
> that this does not to needlessy happen.
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Applied, thanks a lot!
^ permalink raw reply
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: Jan Engelhardt @ 2010-03-28 0:11 UTC (permalink / raw)
To: David Miller; +Cc: schwab, tony.luck, netdev
In-Reply-To: <20100327.163730.179928738.davem@davemloft.net>
On Sunday 2010-03-28 00:37, David Miller wrote:
>
>> net: fix unaligned access in IFLA_STATS64
>
>Applied to net-next-2.6, thanks Jan.
>
>Hey, don't we need some adjustments to if_nlmsg_size()? I don't see
>it accounting for IFLA_STATS64/"struct rtnl_link_stats64" there.
If I am not mistaken, the answer is "not strictly". But of course it's
nicer if we don't need to realloc just because we were too conservative
in the initial calculation.
git://dev.medozas.de/linux net
parent c5c57d7c7837858aa499610a3ee760b39f1de937 (v2.6.34-rc1-1276-gc5c57d7)
commit 305876b7c1c720db30239d08d56b3a058d56aa21
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Sun Mar 28 01:03:32 2010 +0100
net: increase preallocated size of nlmsg to accomodate for IFLA_STATS64
When more data is stuffed into an nlmsg than initially projected, an
extra allocation needs to be done. Reserve enough for IFLA_STATS64 so
that this does not to needlessy happen.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
net/core/rtnetlink.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index ed0766f..bf919b6 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -653,6 +653,7 @@ static inline size_t if_nlmsg_size(const struct net_device *dev)
+ nla_total_size(IFNAMSIZ) /* IFLA_QDISC */
+ nla_total_size(sizeof(struct rtnl_link_ifmap))
+ nla_total_size(sizeof(struct rtnl_link_stats))
+ + nla_total_size(sizeof(struct rtnl_link_stats64))
+ nla_total_size(MAX_ADDR_LEN) /* IFLA_ADDRESS */
+ nla_total_size(MAX_ADDR_LEN) /* IFLA_BROADCAST */
+ nla_total_size(4) /* IFLA_TXQLEN */
--
# Created with git-export-patch
^ permalink raw reply related
* Re: [PATCH kernel 2.6.34-rc2] pcnet_cs: add new id
From: David Miller @ 2010-03-27 23:56 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20100328055537.13ef6c01.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sun, 28 Mar 2010 05:55:37 +0900
>
> pcnet_cs:
> *add new id (Allied Telesis LM33-PCM-T Lan&Modem multifunction card)
> *use PROD_ID for LA-PCM.(because LA-PCM and LM33-PCM-T use the same MANF_ID).
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied, thanks Ken.
^ permalink raw reply
* Re: bonding: fix broken multicast with round-robin mode
From: David Miller @ 2010-03-27 23:40 UTC (permalink / raw)
To: andy; +Cc: netdev
Applied, thanks Andy.
^ permalink raw reply
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: David Miller @ 2010-03-27 23:37 UTC (permalink / raw)
To: jengelh; +Cc: schwab, tony.luck, netdev
In-Reply-To: <alpine.LSU.2.01.1003271313230.2740@obet.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Sat, 27 Mar 2010 13:14:46 +0100 (CET)
> net: fix unaligned access in IFLA_STATS64
Applied to net-next-2.6, thanks Jan.
Hey, don't we need some adjustments to if_nlmsg_size()? I don't see
it accounting for IFLA_STATS64/"struct rtnl_link_stats64" there.
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: David Miller @ 2010-03-27 23:30 UTC (permalink / raw)
To: ben; +Cc: romieu, timo.teras, ivecera, netdev
In-Reply-To: <1269732054.8653.155.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sat, 27 Mar 2010 23:20:54 +0000
> I wonder whether there are special rules that need to be followed
> for updating such registers and which the driver is not following,
> or a more general bug in the Realtek chips that should be
> consistently worked-around for all 64-bit registers.
I suspect that MMIO to 64-bit registers in 32-bit chunks is not
reliable with these parts, given all of the information we have so
far.
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Ben Hutchings @ 2010-03-27 23:20 UTC (permalink / raw)
To: François Romieu; +Cc: Timo Teräs, Ivan Vecera, netdev
In-Reply-To: <20100327211133.GA3624@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
On Sat, 2010-03-27 at 22:11 +0100, François Romieu wrote:
> Timo Teräs <timo.teras@iki.fi> :
> [...]
> > Any ideas how to check this?
>
> Check the datasheet of VIA's chipset for a WC control bit - there
> ought to be one - and disable it.
>
> > Or is swapping MAC0/MAC4 writes, or adding the extra read an
> > acceptable fix/workaround?
>
> swapping should reliably disable WC. It would be fine.
This bug was also reported by a Debian user in
<http://bugs.debian.org/573007>, also using a VIA chipset.
This sort of behaviour has been seen before with 64-bit registers
written in two 32-bit chunks, on some ARM platforms. You worked around
that for the descriptor pointers with:
ommit b39fe41f481d20c201012e4483e76c203802dda7
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Mon Sep 11 20:10:58 2006 +0200
r8169: quirk for the 8110sb on arm platform
A similar problem seems to afflict the multicast hash register on this
platform - see <http://bugs.debian.org/407217>, and sorry I didn't
report this earlier when I got confirmation of my hypothesis.
I wonder whether there are special rules that need to be followed for
updating such registers and which the driver is not following, or a more
general bug in the Realtek chips that should be consistently
worked-around for all 64-bit registers.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)
From: J�rn Engel @ 2010-03-27 22:00 UTC (permalink / raw)
To: Robert Hancock; +Cc: David Miller, torvalds, linux-kernel, netdev, romieu
In-Reply-To: <4BAE4464.9060909@gmail.com>
On Sat, 27 March 2010 11:46:12 -0600, Robert Hancock wrote:
>
> Hm, do you recall/have the details of what happened with the other card?
It lost interrupts. I had a testcase that should have received three
interrupts and only two were received by the driver. 100%
reproducable. Card used MSI-Interrupts (no MSI-X) and worked
reasonably well otherwise. But it is a prototype, so the card is just
as likely to be the cause as the motherboard.
> It's possible this is some general problem with that machine/motherboard
> and not actually an issue with what the driver is doing. What kind of
> board is that?
Possible, yes. But I wouldn't know how to prove it.
Asrock G31M-S with Intel E5200.
J�rn
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: François Romieu @ 2010-03-27 21:11 UTC (permalink / raw)
To: Timo Teräs; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BAE6C92.2060801@iki.fi>
Timo Teräs <timo.teras@iki.fi> :
[...]
> Any ideas how to check this?
Check the datasheet of VIA's chipset for a WC control bit - there
ought to be one - and disable it.
> Or is swapping MAC0/MAC4 writes, or adding the extra read an
> acceptable fix/workaround?
swapping should reliably disable WC. It would be fine.
--
Ueimor
^ permalink raw reply
* [PATCH kernel 2.6.34-rc2] pcnet_cs: add new id
From: Ken Kawasaki @ 2010-03-27 20:55 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100228083420.9ca8e285.ken_kawasaki@spring.nifty.jp>
pcnet_cs:
*add new id (Allied Telesis LM33-PCM-T Lan&Modem multifunction card)
*use PROD_ID for LA-PCM.(because LA-PCM and LM33-PCM-T use the same MANF_ID).
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-2.6.34-rc2/drivers/net/pcmcia/pcnet_cs.c.orig 2010-03-21 20:39:59.000000000 +0900
+++ linux-2.6.34-rc2/drivers/net/pcmcia/pcnet_cs.c 2010-03-27 14:42:34.000000000 +0900
@@ -1549,6 +1549,7 @@ static struct pcmcia_device_id pcnet_ids
PCMCIA_PFC_DEVICE_MANF_CARD(0, 0x021b, 0x0101),
PCMCIA_PFC_DEVICE_MANF_CARD(0, 0x08a1, 0xc0ab),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "AnyCom", "Fast Ethernet + 56K COMBO", 0x578ba6e7, 0xb0ac62c4),
+ PCMCIA_PFC_DEVICE_PROD_ID12(0, "ATKK", "LM33-PCM-T", 0xba9eb7e2, 0x077c174e),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "D-Link", "DME336T", 0x1a424a1c, 0xb23897ff),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "Grey Cell", "GCS3000", 0x2a151fac, 0x48b932ae),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "Linksys", "EtherFast 10&100 + 56K PC Card (PCMLM56)", 0x0733cc81, 0xb3765033),
@@ -1740,7 +1741,7 @@ static struct pcmcia_device_id pcnet_ids
PCMCIA_MFC_DEVICE_CIS_PROD_ID12(0, "DAYNA COMMUNICATIONS", "LAN AND MODEM MULTIFUNCTION", 0x8fdf8f89, 0xdd5ed9e8, "cis/DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_PROD_ID4(0, "NSC MF LAN/Modem", 0x58fc6056, "cis/DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_MANF_CARD(0, 0x0175, 0x0000, "cis/DP83903.cis"),
- PCMCIA_DEVICE_CIS_MANF_CARD(0xc00f, 0x0002, "cis/LA-PCM.cis"),
+ PCMCIA_DEVICE_CIS_PROD_ID12("Allied Telesis,K.K", "Ethernet LAN Card", 0x2ad62f3c, 0x9fd2f0a2, "cis/LA-PCM.cis"),
PCMCIA_DEVICE_CIS_PROD_ID12("KTI", "PE520 PLUS", 0xad180345, 0x9d58d392, "cis/PE520.cis"),
PCMCIA_DEVICE_CIS_PROD_ID12("NDC", "Ethernet", 0x01c43ae1, 0x00b2e941, "cis/NE2K.cis"),
PCMCIA_DEVICE_CIS_PROD_ID12("PMX ", "PE-200", 0x34f3f1c8, 0x10b59f8c, "cis/PE-200.cis"),
--- linux-2.6.34-rc2/drivers/serial/serial_cs.c.orig 2010-03-22 06:53:31.000000000 +0900
+++ linux-2.6.34-rc2/drivers/serial/serial_cs.c 2010-03-27 14:42:53.000000000 +0900
@@ -745,6 +745,7 @@ static struct pcmcia_device_id serial_id
PCMCIA_PFC_DEVICE_PROD_ID13(1, "Xircom", "REM10", 0x2e3ee845, 0x76df1d29),
PCMCIA_PFC_DEVICE_PROD_ID13(1, "Xircom", "XEM5600", 0x2e3ee845, 0xf1403719),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "AnyCom", "Fast Ethernet + 56K COMBO", 0x578ba6e7, 0xb0ac62c4),
+ PCMCIA_PFC_DEVICE_PROD_ID12(1, "ATKK", "LM33-PCM-T", 0xba9eb7e2, 0x077c174e),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "D-Link", "DME336T", 0x1a424a1c, 0xb23897ff),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "Gateway 2000", "XJEM3336", 0xdd9989be, 0x662c394c),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "Grey Cell", "GCS3000", 0x2a151fac, 0x48b932ae),
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 20:37 UTC (permalink / raw)
To: François Romieu; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BADFAE4.5040906@iki.fi>
Timo Teräs wrote:
> François Romieu wrote:
>> Timo Teräs <timo.teras@iki.fi> :
>> [...]
>>> It seems that adding single printk between writing MAC0 and MAC4
>>> fixes it.
>>> I guess it needs a bit of delay between the writes or something.
>>
>> Can you test with a single RTL_R32 after each MACx write ?
>
> Adding reading back of the written value fixes it too. Though,
> disassembly says that it added an extra instructions also (needs to
> load the 'high' from stack before writing it) so the added delay is
> probably slightly more than just the io read.
I'm not too familiar with PCI details, but this smells a bit
like that write-combining is happening and the NIC does not like
that.
Any ideas how to check this?
The system experiencing this is a "VIA Eden 1.2Ghz" box.
Or is swapping MAC0/MAC4 writes, or adding the extra read an
acceptable fix/workaround?
- Timo
^ permalink raw reply
* Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)
From: Robert Hancock @ 2010-03-27 17:46 UTC (permalink / raw)
To: � Engel; +Cc: David Miller, torvalds, linux-kernel, netdev, romieu
In-Reply-To: <20100327063838.GB11959@Dublin.logfs.org>
On 03/27/2010 12:38 AM, � Engel wrote:
> On Fri, 26 March 2010 19:55:44 -0600, Robert Hancock wrote:
>>
>> Well, that one's 36 bits, but it's unclear whether that driver would
>> actually be likely to access anything over 4GB. It's possible that
>> there's just some general problem with 64-bit DMA on that machine.
>
> That may very well be. I've had trouble using a PCIe card in that
> machine as well. "Solution" was to buy a different computer. Sad, I
> know, but not my money.
Hm, do you recall/have the details of what happened with the other card?
It's possible this is some general problem with that machine/motherboard
and not actually an issue with what the driver is doing. What kind of
board is that?
>
>> The fact that even stuff like lspci and MII is breaking seems odd,
>> though. It could be that model of card doesn't like the PCIDAC register
>> bit being set (maybe it means something different on that model, or
>> something).
>>
>> I suppose a publicly accessible datasheet for these chips is too much to
>> hope for?
>
> Which chips?
>
> J�rn
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: CVE-2009-4537
From: David Miller @ 2010-03-27 17:36 UTC (permalink / raw)
To: michael.s.gilbert; +Cc: linux-kernel, netdev, nhorman
In-Reply-To: <20100327.103407.260084965.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 27 Mar 2010 10:34:07 -0700 (PDT)
> From: Michael Gilbert <michael.s.gilbert@gmail.com>
> Date: Sat, 27 Mar 2010 14:21:00 -0400
>
>> Hi,
>>
>> CVE-2009-4537 has been disclosed without any upstream activity for a
>> while now. Discussion about the issue dried up in January [0], and a
>> patch had been proposed [1], but no arguments were seen either for or
>> against it. Note that redhat has already shipped that in their various
>> kernel security updates. Would it make sense to merge those changes
>> officially?
>
> A different version of the fix went into the tree.
Ignore me, that was a fix for a different problem.
I was waiting for Francois to come up with a cleaner fix
but he stopped working on it, so yes I should put in
the fix you mention or something similar.
Neil, can you formally submit a version of the r8169
CVE for upstream?
Thanks.
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Martin Sustrik @ 2010-03-27 16:54 UTC (permalink / raw)
To: Andi Kleen; +Cc: Christoph Lameter, David Miller, netdev, linux-kernel
In-Reply-To: <20100327131138.GD20695@one.firstfloor.org>
Andi Kleen wrote:
> I did a quick read and the manpage/interface seem reasonable to me.
You may also have a look at original PGM implementation by Luigi Rizzo
(FreeBSD). It's not maintained, but it might give you broader view.
http://info.iet.unipi.it/~luigi/pgm-code/
Martin
^ permalink raw reply
* Re: [PATCH 6/9] drivers/net: Fix continuation lines
From: David Miller @ 2010-03-27 15:34 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, jcliburn, chris.snook, jie.yang, atl1-devel, netdev
In-Reply-To: <6b7a0c43891d5af5796b681898d901bbf2e1cda1.1269655208.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 26 Mar 2010 19:27:55 -0700
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] e1000: do not modify tx_queue_len on link speed change
From: David Miller @ 2010-03-27 15:34 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, franco, emil.s.tantilov, jesse.brandeburg
In-Reply-To: <20100326212557.18793.62063.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 26 Mar 2010 14:25:58 -0700
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> Previously the driver tweaked txqueuelen to avoid false Tx hang reports
> seen at half duplex. This had the effect of overriding user set values
> on link change/reset. Testing shows that adjusting only the timeout
> factor is sufficient to prevent Tx hang reports at half duplex.
>
> This patch removes all instances of tx_queue_len in the driver.
>
> Based on e1000e patch by Franco Fichtner <franco@lastsummer.de>
>
> CC: Franco Fichtner <franco@lastsummer.de>
> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ipmr/ip6mr: prevent out-of-bounds vif_table access
From: David Miller @ 2010-03-27 15:34 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4BACECA6.2050506@dev.6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
Date: Fri, 26 Mar 2010 18:19:34 +0100
> When a multicast packet arrived in ip6_mr_input(), if there is no
> cache ip6mr_cache_unresolved() will be called and this function will
> add an entry with parent == 65535.
>
> And the second problem is that when a vif is removed, no cleanup is
> made in cache entry. Hence, we can have a cache entry which points to
> an invalid vif (dev is set ot NULL).
I've applied your fix, thanks Nicolas.
^ permalink raw reply
* Re: [net-2.6 PATCH] ixgbe: Do not run all Diagnostic offline tests when VFs are active
From: David Miller @ 2010-03-27 15:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100326030647.10085.16720.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 25 Mar 2010 20:06:48 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> When running the offline diagnostic tests check to see if any VFs are
> online. If so then only run the link test. This is necessary because
> the VFs running in guest VMs aren't aware of when the PF is taken
> offline for a diagnostic test. Also put a message to the system log
> telling the system administrator to take the VFs offline manually if
> (s)he wants to run a full diagnostic. Return 1 on each of the tests
> not run to alert the user of the condition.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] igb: use correct bits to identify if managability is enabled
From: David Miller @ 2010-03-27 15:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20100326031506.10368.40559.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 25 Mar 2010 20:15:06 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> igb was previously checking the wrong bits in the MANC register to determine
> if managability was enabled. As a result it was incorrectly powering down and
> resetting the phy when it didn't need to.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox