* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: Herbert Xu @ 2010-03-28 13:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100328.064012.193708716.davem@davemloft.net>
On Sun, Mar 28, 2010 at 06:40:12AM -0700, David Miller wrote:
>
> Same for all the other metrics at the TCP level.
I don't think they are quite the same. The TCP time stamp is
an attribute of the destination host, it doesn't vary depending
on which route you take to reach the host. The MTU on the other
hand is an attribute of the route that reaches the host.
BTW, it appears that the inetpeer cache doesn't take namespaces
into account. This means that information could potentially leak
from one namespace into another. I'm not sure whether that's a
big deal or not but it's something for the namespaces folks to
consider.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: David Miller @ 2010-03-28 13:40 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20100328131112.GA15984@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 28 Mar 2010 21:11:12 +0800
> On Sun, Mar 28, 2010 at 05:53:12AM -0700, David Miller wrote:
>> From: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Sun, 28 Mar 2010 16:22:50 +0800
>>
>> > My main question is how do we deal with source-address policy
>> > routing in a host cache?
>>
>> We don't, the same like how we don't handle fully specified
>> IPSEC policies deciding upon the route.
>
> I thought we did handle source-address policy routing for PMTU
> messages at least. I just checked ip_rt_frag_needed and it does
Same for all the other metrics at the TCP level.
I guess this is the decision we have to make, what does
"host level" metrics mean for us if we decide to move
things into the inetpeer cache.
^ permalink raw reply
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: Herbert Xu @ 2010-03-28 13:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100328.055312.58421329.davem@davemloft.net>
On Sun, Mar 28, 2010 at 05:53:12AM -0700, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sun, 28 Mar 2010 16:22:50 +0800
>
> > My main question is how do we deal with source-address policy
> > routing in a host cache?
>
> We don't, the same like how we don't handle fully specified
> IPSEC policies deciding upon the route.
I thought we did handle source-address policy routing for PMTU
messages at least. I just checked ip_rt_frag_needed and it does
if (rth->fl.fl4_dst != daddr ||
rth->fl.fl4_src != skeys[i] ||
rth->rt_dst != daddr ||
rth->rt_src != iph->saddr ||
rth->fl.oif != ikeys[k] ||
rth->fl.iif != 0 ||
dst_metric_locked(&rth->u.dst, RTAX_MTU) ||
!net_eq(dev_net(rth->u.dst.dev), net) ||
rt_is_expired(rth))
continue;
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: David Miller @ 2010-03-28 12:53 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20100328082250.GA14053@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun, 28 Mar 2010 16:22:50 +0800
> On Sat, Mar 27, 2010 at 08:31:20PM -0700, David Miller wrote:
>>
>> Finally, we can really move the metrics array into the inetpeer
>> entries.
>
> My main question is how do we deal with source-address policy
> routing in a host cache?
We don't, the same like how we don't handle fully specified
IPSEC policies deciding upon the route.
^ permalink raw reply
* [patch] iwlwifi: range checking issue
From: Dan Carpenter @ 2010-03-28 11:55 UTC (permalink / raw)
To: Zhu Yi
Cc: Reinette Chatre, Intel Linux Wireless, John W. Linville,
Abhijeet Kolekar, Johannes Berg, Wey-Yi Guy, linux-wireless,
netdev, linux-kernel, kernel-janitors
IWL_RATE_COUNT is 13 and IWL_RATE_COUNT_LEGACY is 12.
IWL_RATE_COUNT_LEGACY is the right one here because iwl3945_rates
doesn't support 60M and also that's how "rates" is defined in
iwlcore_init_geos() from drivers/net/wireless/iwlwifi/iwl-core.c.
rates = kzalloc((sizeof(struct ieee80211_rate) * IWL_RATE_COUNT_LEGACY),
GFP_KERNEL);
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 54daa38..7d3806a 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -1955,7 +1955,7 @@ static void iwl3945_init_hw_rates(struct iwl_priv *priv,
{
int i;
- for (i = 0; i < IWL_RATE_COUNT; i++) {
+ for (i = 0; i < IWL_RATE_COUNT_LEGACY; i++) {
rates[i].bitrate = iwl3945_rates[i].ieee * 5;
rates[i].hw_value = i; /* Rate scaling will work on indexes */
rates[i].hw_value_short = i;
^ permalink raw reply related
* Re: [ANNOUNCEMENT] NET: usb: sierra_net.c driver
From: Sergei Shtylyov @ 2010-03-28 10:38 UTC (permalink / raw)
To: Elina Pasheva
Cc: David Brownell, Rory Filer, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb
In-Reply-To: <1269652919.30630.1.camel@Linuxdev3>
Hello.
Elina Pasheva wrote:
> Subject: [ANNOUNCEMENT] NET: usb: sierra_net.c driver
> From: Elina Pasheva <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
>
> The following is a new Linux driver which exposes certain models of Sierra
> Wireless modems to the operating system as Network Interface Cards (NICs).
>
> This driver requires a version of the sierra.c driver which supports
> blacklisting to work properly. The blacklist in sierra.c rejects the interfaces
> claimed by sierra_net.c. Likewise, the sierra_net.c driver only accepts
> (i.e. whitelists) the interface(s) used for Direct IP traffic.
> The term "Direct IP" is used within Sierra Wireless to refer to these alternate
> data interfaces. The version of sierra.c which supports blacklisting is
> available from the sierra wireless knowledge base page for older kernels. It is
> also available in Linux kernel starting from version 2.6.31.
>
> This driver works with all Sierra Wireless devices configured with PID=68A3
> like USB305, USB306 provided the corresponding firmware version is I2.0
> (for USB305) or M3.0 (for USB306) and later.
> This driver will not work with earlier firmware versions than the ones shown
> above. In this case the driver will issue an error message indicating
> incompatibility and will not serve the device's DirectIP interface.
>
> Sierra_net.c sits atop a pre-existing Linux driver called usbnet.c.
> A series of hook functions are provided in sierra_net.c which are called by
> usbnet.c in response to a particular condition such as receipt or transmission
> of a data packet. As such, usbnet.c does most of the work of making
> a modem appear to the system as a network device and for properly exchanging
> traffic between the USB subsystem and the Network card interface.
> Sierra_net.c is concerned with managing the data exchanged between the
> so-called Direct-IP interface and the upper layers of the operating system.
>
> The version number of sierra_net.c driver is set to 2.0.
> This patch has been tested on the latest stable kernel-2.6.33.1.
> Signed-off-by: Elina Pasheva <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Rory Filer <epasheva-ywE8TTl5eJHWpu6QEFMNjNBPR1lH4CV8@public.gmane.org>
>
I doubt that it's Rory's email address. :-)
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: UDP path MTU discovery
From: Andi Kleen @ 2010-03-28 8:50 UTC (permalink / raw)
To: Glen Turner; +Cc: netdev
In-Reply-To: <1269561751.2891.8.camel@ilion>
Glen Turner <gdt@gdt.id.au> writes:
> In IPv6 routers do not fragment packets, so there is no work
> around. Transactional servers which use UDP over IPv6 encounter
> exponential backoffs within the application and the client
> abandons the transaction. There is no way for the server to
> know that the packet was lost due to Path MTU Discovery and
> to immediately re-transmit it (without an exponential penalty)
> so that the MTU can be probed again.
You can still turn path mtu discovery off and Linux will
fragment based on the known path MTU (I believe when
the too big fragment gets a icmp back the pmtu gets updated)
However you might lose a few packets in the process until the path MTU
is known, but at least it will stay cached (unless you thrash the
routing cache)
In theory one could probably add some hack in the the kernel UDP code
to hold one packet and retransmit it immediately with fragments when
the ICMP comes in. However that would be quite far in behaviour from
traditional UDP and be considered very ugly. It could also mess up
congestion avoidance schemes done by the application.
Still might be preferable over rewriting zillions of applications?
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: UDP path MTU discovery
From: Andi Kleen @ 2010-03-28 8:41 UTC (permalink / raw)
To: David Miller; +Cc: gdt, netdev
In-Reply-To: <20100325.202424.201654947.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Glen Turner <gdt@gdt.id.au>
> Date: Fri, 26 Mar 2010 10:32:31 +1030
>
>> This differs from TCP, where it is the kernel -- and not
>> the application -- which organises retransmission. On
>> receiving a ICMP Fragmentation Needed the kernel can
>> immediately re-probe the path MTU wiht no waiting for
>> an exponential timer to expire.
>
> So the argument is, the kernel TCP does retransmission smart,
> userspace UDP apps do it stupidly, so let's turn off the feature
> instead of fixing userspace.
>
> Right?
>
> Sorry, fix this correctly in the user apps. Putting the
> blame on UDP path MTU discovery is placing it in the
> wrong spot.
It means though that all IPv6 UDP applications essentially have
to implement path mtu discovery support (which is non trivial)
Will be likely a long time until they're all fixed.
Seems like a big hole not considered by the IPv6 designers?
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: Herbert Xu @ 2010-03-28 8:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100327.203120.98894145.davem@davemloft.net>
On Sat, Mar 27, 2010 at 08:31:20PM -0700, David Miller wrote:
>
> Finally, we can really move the metrics array into the inetpeer
> entries.
My main question is how do we deal with source-address policy
routing in a host cache?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Bugme-new] [Bug 15571] New: TCP madness - some packets are shunned.
From: Stephen Hemminger @ 2010-03-28 4:26 UTC (permalink / raw)
To: Arnd Hannemann
Cc: Jasen Betts, netdev, bugzilla-daemon, bugme-daemon, Andrew Morton
In-Reply-To: <4BAC733A.1070403@nets.rwth-aachen.de>
On Fri, 26 Mar 2010 09:41:30 +0100
Arnd Hannemann <hannemann@nets.rwth-aachen.de> wrote:
> [re-adding CCs] please reply to all
>
> Am 26.03.2010 06:31, schrieb Jasen Betts:
> > On Thu, Mar 25, 2010 at 04:34:25PM +0100, Arnd Hannemann wrote:
> >> Am 22.03.2010 22:37, schrieb Andrew Morton:
> >>>
> >>> (switched to email. Please respond via emailed reply-to-all, not via the
> >>> bugzilla web interface).
> >>>
> >>> On Thu, 18 Mar 2010 02:46:29 GMT
> >>> bugzilla-daemon@bugzilla.kernel.org wrote:
> >>>
> >>>> http://bugzilla.kernel.org/show_bug.cgi?id=15571
> >>>>
> >>>> URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=53646
> >>>> 2
> >>>> Summary: TCP madness - some packets are shunned.
> >>>> Product: Networking
> >>>> Version: 2.5
> >>>> Kernel Version: 2.6.30
> >>>> Platform: All
> >>>> OS/Version: Linux
> >>>> Tree: Mainline
> >>>> Status: NEW
> >>>> Severity: normal
> >>>> Priority: P1
> >>>> Component: Other
> >>>> AssignedTo: acme@ghostprotocols.net
> >>>> ReportedBy: jasen@treshna.com
> >>>> Regression: No
> >>>>
> >>>>
> >>>> The host http://www.cv-it.com is virtually unreachable with kernel 2.6.26
> >>>> (and later) slow with kernel 2.6.18 and just fine with windows XP.
> >>>>
> >>>> I used telnet to port 80 for testing.
> >>>>
> >>>> it seems to be a TCP issue, as the having the XP machine behind a linux based
> >>>> iptables firewall pc causes no problems, but telnet from the firewall pc itself
> >>>> to port 80 on www.cv-it.com does not work
> >>
> >> For me it seems to be the host is messing up with the window scale option.
> >> Although it claims to support window scaling:
> >> 16:23:17.466592 IP x.x.x.x.51151 > 121.199.32.220.80: Flags [S], seq 2159265664, win 5840, options [mss 1460,sackOK,TS val 8382141 ecr 0,nop,wscale 7], length 0
> >> 16:23:17.761697 IP 121.199.32.220.80 > x.x.x.x.51151: Flags [S.], seq 3910885479, ack 2159265665, win 65535, options [mss 1448,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 8], length 0
> >>
> >> My host (linux 2.6.32) is offering a window of 5888 (46<<7):
> >> 16:23:17.761740 IP x.x.x.x.51151 > 121.199.32.220.80: Flags [.], ack 1, win 46, length 0
> >>
> >> And cv-it.com seems to think there is only a window of 46 ignoring the previously negotiated window scaling:
> >> 16:23:23.066318 IP 121.199.32.220.80 > x.x.x.x.51151: Flags [.], seq 1:47, ack 112, win 65160, length 46
> >>
> >> You can disable window scaling with:
> >> sysctl -w "net.ipv4.tcp_window_scaling=0"
> >>
> >
> > yeah, that works for me.
> >
> > I don't know a lot about this stuff. wikipedia says windows XP does window
> > scaling also, yet it's not a problem with XP only with linux.
>
> This may be pure coincidence that XP "works".
> For instance if XP is only using a window scale of 1 or 2, the effect of
> ignoring the window scale may not be so drastic. However, the problem is:
> once you negotiated the window scale for a connection you must not change
> it and you may actually need a big window for performance reasons.
> So you have to pick a window scale value, so you can express the
> largest window you are going to use.
> In Linux the maximum tcp receive window can be manipulated with the
> "net.ipv4.tcp_rmem" sysctl. (The max is the third value)
> Recent linux kernels use the amount of ram your machine has to calculate
> the default value for this.
>
> >
> >> My host (linux 2.6.32) is offering a window of 5888 (46<<7):
> >> 16:23:17.761740 IP x.x.x.x.51151 > 121.199.32.220.80: Flags [.], ack 1, win 46, length 0
> >
> > so you mean it seems to see '46' as '46' instead of 46<<7 == 5888
The window is also settable on a per route basis as well.
http://lwn.net/Articles/92727/
--
^ permalink raw reply
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: David Miller @ 2010-03-28 4:06 UTC (permalink / raw)
To: netdev; +Cc: herbert
In-Reply-To: <20100327.203120.98894145.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 27 Mar 2010 20:31:20 -0700 (PDT)
> 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. :-)
And this is what that patch would look like:
decnet: Move route metrics into struct dn_route
This way we can move ipv4/ipv6 metrics into the inetpeer cache.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/dn_route.h | 23 +++++++++++++++++++++++
net/decnet/af_decnet.c | 4 ++--
net/decnet/dn_route.c | 35 ++++++++++++++++++-----------------
3 files changed, 43 insertions(+), 19 deletions(-)
diff --git a/include/net/dn_route.h b/include/net/dn_route.h
index 60c9f22..62b04db 100644
--- a/include/net/dn_route.h
+++ b/include/net/dn_route.h
@@ -80,8 +80,31 @@ struct dn_route {
unsigned rt_flags;
unsigned rt_type;
+
+ u32 metrics[RTAX_MAX];
};
+static inline u32 dn_dst_metric(const struct dst_entry *dst, int metric)
+{
+ struct dn_route *rt = (struct dn_route *) dst;
+ return rt->metrics[metric - 1];
+}
+
+static inline int dn_dst_metric_locked(const struct dst_entry *dst, int metric)
+{
+ return dn_dst_metric(dst, RTAX_LOCK) & (1 << metric);
+}
+
+static inline u32 dn_dst_mtu(const struct dst_entry *dst)
+{
+ u32 mtu = dn_dst_metric(dst, RTAX_MTU);
+ /*
+ * Alexey put it here, so ask him about it :)
+ */
+ barrier();
+ return mtu;
+}
+
extern void dn_route_init(void);
extern void dn_route_cleanup(void);
diff --git a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
index 2b494fa..83228a2 100644
--- a/net/decnet/af_decnet.c
+++ b/net/decnet/af_decnet.c
@@ -829,7 +829,7 @@ static int dn_confirm_accept(struct sock *sk, long *timeo, gfp_t allocation)
return -EINVAL;
scp->state = DN_CC;
- scp->segsize_loc = dst_metric(__sk_dst_get(sk), RTAX_ADVMSS);
+ scp->segsize_loc = dn_dst_metric(__sk_dst_get(sk), RTAX_ADVMSS);
dn_send_conn_conf(sk, allocation);
prepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE);
@@ -958,7 +958,7 @@ static int __dn_connect(struct sock *sk, struct sockaddr_dn *addr, int addrlen,
sk->sk_route_caps = sk->sk_dst_cache->dev->features;
sock->state = SS_CONNECTING;
scp->state = DN_CI;
- scp->segsize_loc = dst_metric(sk->sk_dst_cache, RTAX_ADVMSS);
+ scp->segsize_loc = dn_dst_metric(sk->sk_dst_cache, RTAX_ADVMSS);
dn_nsp_send_conninit(sk, NSP_CI);
err = -EINPROGRESS;
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index a7bf03c..ff62012 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -234,15 +234,16 @@ static void dn_dst_update_pmtu(struct dst_entry *dst, u32 mtu)
else
min_mtu -= 21;
- if (dst_metric(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
- if (!(dst_metric_locked(dst, RTAX_MTU))) {
- dst->metrics[RTAX_MTU-1] = mtu;
+ if (dn_dst_metric(dst, RTAX_MTU) > mtu && mtu >= min_mtu) {
+ struct dn_route *rt = (struct dn_route *) dst;
+ if (!(dn_dst_metric_locked(dst, RTAX_MTU))) {
+ rt->metrics[RTAX_MTU-1] = mtu;
dst_set_expires(dst, dn_rt_mtu_expires);
}
- if (!(dst_metric_locked(dst, RTAX_ADVMSS))) {
+ if (!(dn_dst_metric_locked(dst, RTAX_ADVMSS))) {
u32 mss = mtu - DN_MAX_NSP_DATA_HEADER;
- if (dst_metric(dst, RTAX_ADVMSS) > mss)
- dst->metrics[RTAX_ADVMSS-1] = mss;
+ if (dn_dst_metric(dst, RTAX_ADVMSS) > mss)
+ rt->metrics[RTAX_ADVMSS-1] = mss;
}
}
}
@@ -788,8 +789,8 @@ static int dn_rt_set_next_hop(struct dn_route *rt, struct dn_fib_res *res)
if (DN_FIB_RES_GW(*res) &&
DN_FIB_RES_NH(*res).nh_scope == RT_SCOPE_LINK)
rt->rt_gateway = DN_FIB_RES_GW(*res);
- memcpy(rt->u.dst.metrics, fi->fib_metrics,
- sizeof(rt->u.dst.metrics));
+ memcpy(rt->metrics, fi->fib_metrics,
+ sizeof(rt->metrics));
}
rt->rt_type = res->type;
@@ -800,13 +801,13 @@ static int dn_rt_set_next_hop(struct dn_route *rt, struct dn_fib_res *res)
rt->u.dst.neighbour = n;
}
- if (dst_metric(&rt->u.dst, RTAX_MTU) == 0 ||
- dst_metric(&rt->u.dst, RTAX_MTU) > rt->u.dst.dev->mtu)
- rt->u.dst.metrics[RTAX_MTU-1] = rt->u.dst.dev->mtu;
- mss = dn_mss_from_pmtu(dev, dst_mtu(&rt->u.dst));
- if (dst_metric(&rt->u.dst, RTAX_ADVMSS) == 0 ||
- dst_metric(&rt->u.dst, RTAX_ADVMSS) > mss)
- rt->u.dst.metrics[RTAX_ADVMSS-1] = mss;
+ if (dn_dst_metric(&rt->u.dst, RTAX_MTU) == 0 ||
+ dn_dst_metric(&rt->u.dst, RTAX_MTU) > rt->u.dst.dev->mtu)
+ rt->metrics[RTAX_MTU-1] = rt->u.dst.dev->mtu;
+ mss = dn_mss_from_pmtu(dev, dn_dst_mtu(&rt->u.dst));
+ if (dn_dst_metric(&rt->u.dst, RTAX_ADVMSS) == 0 ||
+ dn_dst_metric(&rt->u.dst, RTAX_ADVMSS) > mss)
+ rt->metrics[RTAX_ADVMSS-1] = mss;
return 0;
}
@@ -1485,7 +1486,7 @@ static int dn_rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq,
RTA_PUT(skb, RTA_PREFSRC, 2, &rt->rt_local_src);
if (rt->rt_daddr != rt->rt_gateway)
RTA_PUT(skb, RTA_GATEWAY, 2, &rt->rt_gateway);
- if (rtnetlink_put_metrics(skb, rt->u.dst.metrics) < 0)
+ if (rtnetlink_put_metrics(skb, rt->metrics) < 0)
goto rtattr_failure;
expires = rt->u.dst.expires ? rt->u.dst.expires - jiffies : 0;
if (rtnl_put_cacheinfo(skb, &rt->u.dst, 0, 0, 0, expires,
@@ -1712,7 +1713,7 @@ static int dn_rt_cache_seq_show(struct seq_file *seq, void *v)
dn_addr2asc(le16_to_cpu(rt->rt_saddr), buf2),
atomic_read(&rt->u.dst.__refcnt),
rt->u.dst.__use,
- (int) dst_metric(&rt->u.dst, RTAX_RTT));
+ (int) dn_dst_metric(&rt->u.dst, RTAX_RTT));
return 0;
}
--
1.7.0.3
^ permalink raw reply related
* 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
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