* Re: Reproducible data corruption with sendfile+vsftp - splice regression?
From: Holger Hoffstaette @ 2007-12-13 2:19 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20071206184426.GA32599@electric-eye.fr.zoreil.com>
On Thu, 06 Dec 2007 19:44:26 +0100, Francois Romieu wrote:
> Holger Hoffstaette <holger@wizards.de> : [...]
>> Maybe turning off sendfile or NAPI just lead to random success - so far
>> it really looks like tso on the r8169 is the common cause.
>
> TSO on the r8169 is the magic switch but the regression makes imvho more
> sense from a VM pov:
>
> - the corrupted file has the same size as the expected file - the
> corrupted file exhibits holes which come as a multiple of 4096 bytes
> (8*4k, 2 places, there may be more)
> - the r8169 driver does not know what a page is - the 8169 hardware has a
> small 8192 bytes Tx buffer
>
> It would be nice if someone could do a sendfile + vsftp test with TSO on a
> different hardware. While I could not reproduce the corruption when simply
> downloading a file that I had copied on the server with scp, it triggered
> almost immediately after I copied it locally and tried to download the
> copy.
Here's an update - sorry for the delay but I need that machine for everyday work.
I have now gone back to enable TSO since vsftp with sendfile really seems
to be the only app that causes this. I have simply set it to
use_sendfile=NO and no corruption occurs at all; the machine is stable and
fast.
FWIW the corruption can still be reproduced with 2.6.24-rc5. For kicks I
have also tried -rc5 with SLAB instead of SLUB, but that didn't help
either.
The directory with the tcpdump & test data now also contains a few more
corrupted files; maybe comparing the corruption offsets gives someone a
better idea.
thanks
Holger
^ permalink raw reply
* [IPSEC]: Fix reversed ICMP6 policy check
From: Herbert Xu @ 2007-12-13 1:58 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, ilpo.jarvinen, netdev
In-Reply-To: <20071212173951.4f1eb99a.akpm@linux-foundation.org>
On Wed, Dec 12, 2007 at 05:39:51PM -0800, Andrew Morton wrote:
>
> Here's the screen-shot (actually more like a reen-hot):
> http://userweb.kernel.org/~akpm/pc121694.jpg
>
> I'm awaiting a reoccurrence with the screen in 50-row mode.
Sorry, I didn't test IPv6.
[IPSEC]: Fix reversed ICMP6 policy check
The policy check I added for ICMP on IPv6 is reversed. This
patch fixes that.
It also adds an skb->sp check so that unprotected packets that
fail the policy check do not crash the machine.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
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
--
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 4e3bfcd..132e879 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -978,7 +978,7 @@ int icmp_rcv(struct sk_buff *skb)
struct icmphdr *icmph;
struct rtable *rt = (struct rtable *)skb->dst;
- if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb) &&
+ if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb) && skb->sp &&
skb->sp->xvec[skb->sp->len - 1]->props.flags & XFRM_STATE_ICMP) {
int nh;
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 478ee77..64d78c9 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -646,7 +646,7 @@ static int icmpv6_rcv(struct sk_buff *skb)
struct icmp6hdr *hdr;
int type;
- if (xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb) &&
+ if (!xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb) && skb->sp &&
skb->sp->xvec[skb->sp->len - 1]->props.flags & XFRM_STATE_ICMP) {
int nh;
^ permalink raw reply related
* [IPSEC]: Make callers of xfrm_lookup to use XFRM_LOOKUP_WAIT
From: Herbert Xu @ 2007-12-13 1:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20071212.104342.206132994.davem@davemloft.net>
On Wed, Dec 12, 2007 at 10:43:42AM -0800, David Miller wrote:
>
> Begrudgingly, I've applied this, but only to make the merging of your
> work easier. I think this flag is totally wrong and you need to
> fix this up.
Well I did do a grep to make sure it's safe. But yeah relying
on ip_route_connect to pass the right value through isn't nice.
[IPSEC]: Make callers of xfrm_lookup to use XFRM_LOOKUP_WAIT
This patch converts all callers of xfrm_lookup that used an
explicit value of 1 to indiciate blocking to use the new flag
XFRM_LOOKUP_WAIT.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
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
--
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 87c98fb..a08e2cb 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -994,7 +994,7 @@ static int dccp_v6_connect(struct sock *sk, struct sockaddr *uaddr,
if (final_p)
ipv6_addr_copy(&fl.fl6_dst, final_p);
- err = __xfrm_lookup(&dst, &fl, sk, 1);
+ err = __xfrm_lookup(&dst, &fl, sk, XFRM_LOOKUP_WAIT);
if (err < 0) {
if (err == -EREMOTE)
err = ip6_dst_blackhole(sk, &dst, &fl);
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index eb07df9..62f3ae7 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -1196,7 +1196,8 @@ int dn_route_output_sock(struct dst_entry **pprt, struct flowi *fl, struct sock
err = __dn_route_output_key(pprt, fl, flags & MSG_TRYHARD);
if (err == 0 && fl->proto) {
- err = xfrm_lookup(pprt, fl, sk, !(flags & MSG_DONTWAIT));
+ err = xfrm_lookup(pprt, fl, sk, (flags & MSG_DONTWAIT) ?
+ XFRM_LOOKUP_WAIT : 0);
}
return err;
}
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 245f5cf..f00edae 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2536,7 +2536,8 @@ int ip_route_output_flow(struct rtable **rp, struct flowi *flp, struct sock *sk,
flp->fl4_src = (*rp)->rt_src;
if (!flp->fl4_dst)
flp->fl4_dst = (*rp)->rt_dst;
- err = __xfrm_lookup((struct dst_entry **)rp, flp, sk, flags);
+ err = __xfrm_lookup((struct dst_entry **)rp, flp, sk,
+ flags ? XFRM_LOOKUP_WAIT : 0);
if (err == -EREMOTE)
err = ipv4_dst_blackhole(rp, flp, sk);
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 2ed689a..707ba45 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -177,7 +177,7 @@ ipv4_connected:
if (final_p)
ipv6_addr_copy(&fl.fl6_dst, final_p);
- if ((err = __xfrm_lookup(&dst, &fl, sk, 1)) < 0) {
+ if ((err = __xfrm_lookup(&dst, &fl, sk, XFRM_LOOKUP_WAIT)) < 0) {
if (err == -EREMOTE)
err = ip6_dst_blackhole(sk, &dst, &fl);
if (err < 0)
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 850b83e..2663fd1 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -871,7 +871,7 @@ static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk,
if (final_p)
ipv6_addr_copy(&fl.fl6_dst, final_p);
- if ((err = __xfrm_lookup(&dst, &fl, sk, 1)) < 0) {
+ if ((err = __xfrm_lookup(&dst, &fl, sk, XFRM_LOOKUP_WAIT)) < 0) {
if (err == -EREMOTE)
err = ip6_dst_blackhole(sk, &dst, &fl);
if (err < 0)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 0604d9d..d576833 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -265,7 +265,7 @@ static int tcp_v6_connect(struct sock *sk, struct sockaddr *uaddr,
if (final_p)
ipv6_addr_copy(&fl.fl6_dst, final_p);
- if ((err = __xfrm_lookup(&dst, &fl, sk, 1)) < 0) {
+ if ((err = __xfrm_lookup(&dst, &fl, sk, XFRM_LOOKUP_WAIT)) < 0) {
if (err == -EREMOTE)
err = ip6_dst_blackhole(sk, &dst, &fl);
if (err < 0)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 1e3bd39..8cbdcc9 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -757,7 +757,7 @@ do_udp_sendmsg:
if (final_p)
ipv6_addr_copy(&fl.fl6_dst, final_p);
- if ((err = __xfrm_lookup(&dst, &fl, sk, 1)) < 0) {
+ if ((err = __xfrm_lookup(&dst, &fl, sk, XFRM_LOOKUP_WAIT)) < 0) {
if (err == -EREMOTE)
err = ip6_dst_blackhole(sk, &dst, &fl);
if (err < 0)
^ permalink raw reply related
* Re: net-2.6.25 splat
From: Andrew Morton @ 2007-12-13 1:39 UTC (permalink / raw)
To: David Miller; +Cc: ilpo.jarvinen, netdev, herbert
In-Reply-To: <20071212.162613.186792052.davem@davemloft.net>
On Wed, 12 Dec 2007 16:26:13 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
> Date: Wed, 12 Dec 2007 16:21:40 -0800
>
> > I don't know why it was doing ipv6 things at all.
>
> When you bring up any interface, with explicit IPV6
> addresses or not, the IPV6 stack seeks out local routers
> and whatnot using multicast and assigns the interface
> a link-local IPV6 address.
>
> So no matter what you're doing IPV6.
>
> I suspect the OOPS you hit might be related to
> IPSEC stack work done recently by Herbert Xu who
> has been added to the CC:.
>
> I doubt poor Ilpo should be contacted as I doubt his
> TCP work is involved :-)
Here's the screen-shot (actually more like a reen-hot):
http://userweb.kernel.org/~akpm/pc121694.jpg
I'm awaiting a reoccurrence with the screen in 50-row mode.
^ permalink raw reply
* [PATCH] ethtool: update license field in specfile to be correctly defined
From: Auke Kok @ 2007-12-13 0:37 UTC (permalink / raw)
To: jeff; +Cc: netdev, jesse.brandeburg
RPM uses "License" as field and not "Copyright".
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
ethtool.spec.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ethtool.spec.in b/ethtool.spec.in
index 1705d7f..4ff736a 100644
--- a/ethtool.spec.in
+++ b/ethtool.spec.in
@@ -5,7 +5,7 @@ Group : Utilities
Summary : A tool for setting ethernet parameters
-Copyright : GPL
+License : GPL
URL : http://sourceforge.net/projects/gkernel/
Buildroot : %{_tmppath}/%{name}-%{version}
^ permalink raw reply related
* [PATCH] e100: free IRQ to remove warningwhenrebooting
From: Auke Kok @ 2007-12-13 0:30 UTC (permalink / raw)
To: jeff; +Cc: netdev, jesse.brandeburg, ianw
Adapted from Ian Wienand <ianw@gelato.unsw.edu.au>
Explicitly free the IRQ before removing the device to remove a
warning "Destroying IRQ without calling free_irq"
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Cc: Ian Wienand <ianw@gelato.unsw.edu.au>
---
drivers/net/e100.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 27f4d4a..f630ea9 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2807,8 +2807,9 @@ static int e100_suspend(struct pci_dev *pdev, pm_message_t state)
pci_enable_wake(pdev, PCI_D3cold, 0);
}
- pci_disable_device(pdev);
free_irq(pdev->irq, netdev);
+
+ pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
return 0;
@@ -2850,6 +2851,8 @@ static void e100_shutdown(struct pci_dev *pdev)
pci_enable_wake(pdev, PCI_D3cold, 0);
}
+ free_irq(pdev->irq, netdev);
+
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
}
^ permalink raw reply related
* Re: net-2.6.25 splat
From: David Miller @ 2007-12-13 0:26 UTC (permalink / raw)
To: akpm; +Cc: ilpo.jarvinen, netdev, herbert
In-Reply-To: <20071212162140.6b81328d.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Wed, 12 Dec 2007 16:21:40 -0800
> I don't know why it was doing ipv6 things at all.
When you bring up any interface, with explicit IPV6
addresses or not, the IPV6 stack seeks out local routers
and whatnot using multicast and assigns the interface
a link-local IPV6 address.
So no matter what you're doing IPV6.
I suspect the OOPS you hit might be related to
IPSEC stack work done recently by Herbert Xu who
has been added to the CC:.
I doubt poor Ilpo should be contacted as I doubt his
TCP work is involved :-)
^ permalink raw reply
* net-2.6.25 splat
From: Andrew Morton @ 2007-12-13 0:21 UTC (permalink / raw)
To: David S. Miller, Ilpo Järvinen; +Cc: netdev
Pulled the tree a couple of hours ago. The machine was running the full
-mm lineup, had been compiling kernels for an hour or so then oopsed in
icmpv6_rcv+0x5b/0x832.
I have a partial photo of the scrolled-off backtrace but the camera cable
is at home.
I don't know why it was doing ipv6 things at all. Maybe there's ip6 stuff
running around google's corp network, dunno.
gdb says:
(gdb) l *0x17387
0x17387 is in icmpv6_rcv (net/ipv6/icmp.c:649).
644 struct in6_addr *saddr, *daddr;
645 struct ipv6hdr *orig_hdr;
646 struct icmp6hdr *hdr;
647 int type;
648
649 if (xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb) &&
650 skb->sp->xvec[skb->sp->len - 1]->props.flags & XFRM_STATE_ICMP) {
651 int nh;
652
653 if (!pskb_may_pull(skb, sizeof(*hdr) + sizeof(*orig_hdr)))
I'll set the display to 80x50 and retry..
^ permalink raw reply
* Re: [RFC PATCH net-2.6.25 uncompilable] [TCP]: Avoid breaking GSOed skbs when SACKed one-by-one
From: Stephen Hemminger @ 2007-12-13 0:00 UTC (permalink / raw)
To: Lachlan Andrew
Cc: David Miller, ilpo.jarvinen, netdev, quetchen, Darryl Veitch
In-Reply-To: <aa7d2c6d0712121535y31bea3a6v14e270293c272e6f@mail.gmail.com>
On Wed, 12 Dec 2007 15:35:49 -0800
"Lachlan Andrew" <lachlan.andrew@gmail.com> wrote:
> Greetings Dave,
>
> On 12/12/2007, David Miller <davem@davemloft.net> wrote:
> > From: "Lachlan Andrew" <lachlan.andrew@gmail.com>
> > Date: Tue, 11 Dec 2007 16:14:36 -0800
> >
> > > This thread started because TCP processing interferes with RTT
> > > estimation. This problem would be eliminated if time-stamping were
> > > done as soon as the packet comes off the NIC.
> >
> > We don't do that because such timestamping is too expensive.
> > It used to be the case that we did this, but we stopped doing
> > that a long time ago.
> >
> > On x86 for example, timestamping can involve touching a slow
> > I/O device to read the timestamp. We do not want to do that
> > for every packet.
>
> OK. Thanks for the background.
>
> I thought that a TSC read was fairly cheap. Any messing around to
> interpret it could be the responsibility of any task which actually
> needs a high-resolution timestamp, couldn't it? If TSC is disabled,
> then the timestamp field could be set to "invalid".
>
> > Also, we timestamp differently for TCP, the global high
> > resolution timestamp is overkill for this purpose.
>
> Overkill for Reno and Cubic, but useful for Vegas, LP, veno, Illinois
> and YeAH which are all in the kernel. They currently use "high
> resolution" timestamps which are effectively quantized to the
> scheduler resolution because of the way timestamping is done --
> reading a high-resolution time source when a task is scheduled.
>
> > Really, this is a silly idea
>
> Oh... :(
>
> > and would only be a bandaid
> > for the problem at hand, that TCP input processing is
> > too expensive in certain circumstances.
>
> That problem should certainly be fixed as well -- I wasn't suggesting
> this as an alternative. Will fixing it fix the problem of those TCP
> modules suffering from CPU load from other sources?
>
> (I'm Cc'ing this to Darryl Veitch who has often wanted driver-level
> time-stamping for achieving high-resolution synchronization between
> hosts.)
>
> Cheers,
> Lachlan
>
In current kernel, the congestion control can choose the desired accuracy.
The units are always the same (microseconds),
but if the flag value "TCP_CONG_RTT_STAMP" is set, then TCP
tries to the high resolution real time clock. This is relatively
expensive so only vegas, veno, LP, and YeAH use it. It would be
worth an experiment to see whether it is worth it.
All the delay based congestion control algorithms are impractical
in the real world, but everyone keeps trying :-)
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [RFC PATCH net-2.6.25 uncompilable] [TCP]: Avoid breaking GSOed skbs when SACKed one-by-one
From: David Miller @ 2007-12-12 23:38 UTC (permalink / raw)
To: lachlan.andrew; +Cc: ilpo.jarvinen, netdev, quetchen, d.veitch
In-Reply-To: <aa7d2c6d0712121535y31bea3a6v14e270293c272e6f@mail.gmail.com>
From: "Lachlan Andrew" <lachlan.andrew@gmail.com>
Date: Wed, 12 Dec 2007 15:35:49 -0800
> I thought that a TSC read was fairly cheap.
The TSC is cheap, but on the vast majority of systems it
isn't usable as a stable time source, and we have to read
the ACPI timer instead.
^ permalink raw reply
* Re: [RFC PATCH net-2.6.25 uncompilable] [TCP]: Avoid breaking GSOed skbs when SACKed one-by-one
From: Lachlan Andrew @ 2007-12-12 23:35 UTC (permalink / raw)
To: David Miller; +Cc: ilpo.jarvinen, netdev, quetchen, Darryl Veitch
In-Reply-To: <20071212.071136.26499607.davem@davemloft.net>
Greetings Dave,
On 12/12/2007, David Miller <davem@davemloft.net> wrote:
> From: "Lachlan Andrew" <lachlan.andrew@gmail.com>
> Date: Tue, 11 Dec 2007 16:14:36 -0800
>
> > This thread started because TCP processing interferes with RTT
> > estimation. This problem would be eliminated if time-stamping were
> > done as soon as the packet comes off the NIC.
>
> We don't do that because such timestamping is too expensive.
> It used to be the case that we did this, but we stopped doing
> that a long time ago.
>
> On x86 for example, timestamping can involve touching a slow
> I/O device to read the timestamp. We do not want to do that
> for every packet.
OK. Thanks for the background.
I thought that a TSC read was fairly cheap. Any messing around to
interpret it could be the responsibility of any task which actually
needs a high-resolution timestamp, couldn't it? If TSC is disabled,
then the timestamp field could be set to "invalid".
> Also, we timestamp differently for TCP, the global high
> resolution timestamp is overkill for this purpose.
Overkill for Reno and Cubic, but useful for Vegas, LP, veno, Illinois
and YeAH which are all in the kernel. They currently use "high
resolution" timestamps which are effectively quantized to the
scheduler resolution because of the way timestamping is done --
reading a high-resolution time source when a task is scheduled.
> Really, this is a silly idea
Oh... :(
> and would only be a bandaid
> for the problem at hand, that TCP input processing is
> too expensive in certain circumstances.
That problem should certainly be fixed as well -- I wasn't suggesting
this as an alternative. Will fixing it fix the problem of those TCP
modules suffering from CPU load from other sources?
(I'm Cc'ing this to Darryl Veitch who has often wanted driver-level
time-stamping for achieving high-resolution synchronization between
hosts.)
Cheers,
Lachlan
--
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan
^ permalink raw reply
* Re: [PATCH 0/2] netem: trace enhancement
From: Stephen Hemminger @ 2007-12-12 23:13 UTC (permalink / raw)
To: Ariane Keller
Cc: Patrick McHardy, Ariane Keller, Ben Greear, netdev, herbert,
Rainer Baumann
In-Reply-To: <475D4DEE.2080308@ee.ethz.ch>
On Mon, 10 Dec 2007 15:32:14 +0100
Ariane Keller <ariane.keller@tik.ee.ethz.ch> wrote:
> I finally managed to rewrite the netem trace extension to use rtnetlink
> communication for the data transfer for user space to kernel space.
>
> The kernel patch is available here:
> http://www.tcn.hypert.net/tcn_kernel_2_6_23_rtnetlink
>
> and the iproute patch is here:
> http://www.tcn.hypert.net/tcn_iproute2_2_6_23_rtnetlink
>
> Whenever new data is needed the kernel module sends a notification to
> the user space process. Thereupon the user space process sends a data
> package to the kernel module.
I wonder if it wouldn't be possible to enhance/extend netlink
to use sendfile/splice to get the data. It is rather more work than
needed for just this, but it would be useful for large configuration.
> I had to write a new qdisc_notify function (qdisc_notify_pid) since the
> other was acquiring a lock, which we already hold in this situation.
> I hope everything works as expected and I'm looking forward for your
> comments.
>
> Thanks!
> Ariane
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [2.6 patch] drivers/net/sis190.c section fix
From: Francois Romieu @ 2007-12-12 22:56 UTC (permalink / raw)
To: Adrian Bunk; +Cc: jgarzik, netdev, linux-kernel
In-Reply-To: <20071211222356.GA14204@stusta.de>
Adrian Bunk <bunk@kernel.org> :
> This patch fixes the following section mismatch with CONFIG_HOTPLUG=n:
[...]
> WARNING: vmlinux.o(.init.text.20+0x4cb25): Section mismatch: reference to .exit.text:sis190_mii_remove (between 'sis190_init_one' and 'read_eeprom')
Thanks. Applied at:
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git sis190
--
Ueimor
^ permalink raw reply
* Re: [PATCH] r6040 various cleanups
From: Francois Romieu @ 2007-12-12 22:35 UTC (permalink / raw)
To: Florian Fainelli; +Cc: jeff, Andrew Morton, Sten Wang, netdev
In-Reply-To: <200712121044.01820.florian.fainelli@telecomint.eu>
Florian Fainelli <florian.fainelli@telecomint.eu> :
[r6040 changes]
> - remove unused private structure members
> - functions to allocate/free TX and RX buffers
> - recover from transmit timeout
> - use netdev_alloc_skb instead of dev_alloc_skb
> - do not use a private stats structure to store statistics
> - break each TX/RX error to a separate line for better reading
> - better control of the timer
> - clean the IRQ handler
> - fix typos and spelling mistakes in the driver
Thanks, I have split it in parts. The serie should be available shortly at:
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git r6040
Please note that:
1. TIMER_WUT has been removed as it was not used any more
2. I have kept the difference below. Was the patch really supposed to update
the same error counter twice ?
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 19184e4..ff72c51 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -518,7 +519,9 @@ static int r6040_rx(struct net_device *dev, int limit)
if (err & 0x0020)
dev->stats.rx_over_errors++;
/* Received packet with too long or short */
- if (err & (0x0010 | 0x0008))
+ if (err & 0x0010)
+ dev->stats.rx_length_errors++;
+ if (err & 0x0008)
dev->stats.rx_length_errors++;
/* Received packet with CRC errors */
if (err & 0x0004) {
@@ -579,7 +582,9 @@ static void r6040_tx(struct net_device *dev)
if (err & 0x0200)
dev->stats.rx_fifo_errors++;
- if (err & (0x2000 | 0x4000))
+ if (err & 0x2000)
+ dev->stats.tx_carrier_errors++;
+ if (err & 0x4000)
dev->stats.tx_carrier_errors++;
if (descptr->status & 0x8000)
--
Ueimor
^ permalink raw reply related
* Re: "ip neigh show" not showing arp cache entries?
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-12-12 22:06 UTC (permalink / raw)
To: cfriesen; +Cc: dada1, netdev, linux-kernel, yoshfuji
In-Reply-To: <47605934.2060604@nortel.com>
In article <47605934.2060604@nortel.com> (at Wed, 12 Dec 2007 15:57:08 -0600), "Chris Friesen" <cfriesen@nortel.com> says:
> > You may try other versions of this command
> >
> > http://devresources.linux-foundation.org/dev/iproute2/download/
>
> They appear to be numbered by kernel version, and the above version is
> the most recent one for 2.6.14. Will more recent ones (for newer
> kernels) work with my kernel?
It should work; if it doesn't, please make a report. Thanks.
--yoshfuji
^ permalink raw reply
* [RFT] cpmac: napi fix
From: Stephen Hemminger @ 2007-12-12 22:01 UTC (permalink / raw)
To: Eugene Konev, Jeff Garzik, David S. Miller; +Cc: netdev
The NAPI changes for 2.6.24 would break this driver. It doesn't return
correct value and has error if exactly "budget" packets are received.
Don't have ARM so this is by inspection only. Please test.
--- a/drivers/net/cpmac.c 2007-10-26 11:56:12.000000000 -0700
+++ b/drivers/net/cpmac.c 2007-12-12 13:48:40.000000000 -0800
@@ -439,14 +439,14 @@ static int cpmac_poll(struct napi_struct
if (unlikely(netif_msg_rx_status(priv)))
printk(KERN_DEBUG "%s: poll processed %d packets\n",
priv->dev->name, received);
- if (desc->dataflags & CPMAC_OWN) {
+
+ if (received < budget) {
netif_rx_complete(priv->dev, napi);
cpmac_write(priv->regs, CPMAC_RX_PTR(0), (u32)desc->mapping);
cpmac_write(priv->regs, CPMAC_RX_INT_ENABLE, 1);
- return 0;
}
- return 1;
+ return received;
}
static int cpmac_start_xmit(struct sk_buff *skb, struct net_device *dev)
^ permalink raw reply
* [RFT] tehuti: napi fix
From: Stephen Hemminger @ 2007-12-12 21:58 UTC (permalink / raw)
To: David Miller; +Cc: joonwpark81, netdev, jgarzik, baum, andy
In-Reply-To: <20071212.071832.07747779.davem@davemloft.net>
This should fix the tehuti napi fence post problems by getting
rid of priv->napi_stop, and setting weight to 32 (like other 10G).
Also, used the wierd entry/exit macro's like rest of driver.
--- a/drivers/net/tehuti.c 2007-11-13 22:19:14.000000000 -0800
+++ b/drivers/net/tehuti.c 2007-12-12 13:37:01.000000000 -0800
@@ -295,18 +295,12 @@ static int bdx_poll(struct napi_struct *
ENTER;
bdx_tx_cleanup(priv);
work_done = bdx_rx_receive(priv, &priv->rxd_fifo0, budget);
- if ((work_done < budget) ||
- (priv->napi_stop++ >= 30)) {
+ if (work_done < budget) {
DBG("rx poll is done. backing to isr-driven\n");
-
- /* from time to time we exit to let NAPI layer release
- * device lock and allow waiting tasks (eg rmmod) to advance) */
- priv->napi_stop = 0;
-
netif_rx_complete(dev, napi);
bdx_enable_interrupts(priv);
}
- return work_done;
+ RET(work_done);
}
/* bdx_fw_load - loads firmware to NIC
@@ -2022,7 +2016,7 @@ bdx_probe(struct pci_dev *pdev, const st
priv->nic = nic;
priv->msg_enable = BDX_DEF_MSG_ENABLE;
- netif_napi_add(ndev, &priv->napi, bdx_poll, 64);
+ netif_napi_add(ndev, &priv->napi, bdx_poll, 32);
if ((readl(nic->regs + FPGA_VER) & 0xFFF) == 308) {
DBG("HW statistics not supported\n");
--- a/drivers/net/tehuti.h 2007-10-16 16:48:17.000000000 -0700
+++ b/drivers/net/tehuti.h 2007-12-12 13:25:25.000000000 -0800
@@ -257,7 +257,6 @@ struct bdx_priv {
struct rxd_fifo rxd_fifo0;
struct rxf_fifo rxf_fifo0;
struct rxdb *rxdb; /* rx dbs to store skb pointers */
- int napi_stop;
struct vlan_group *vlgrp;
/* Tx FIFOs: 1 for data desc, 1 for empty (acks) desc */
^ permalink raw reply
* Re: "ip neigh show" not showing arp cache entries?
From: Chris Friesen @ 2007-12-12 21:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel
In-Reply-To: <47602DD0.8070402@cosmosbay.com>
Eric Dumazet wrote:
> And what is the version of "ip" command you have on this machine ?
>
> ip -V
iproute2-ss051107
> You may try other versions of this command
>
> http://devresources.linux-foundation.org/dev/iproute2/download/
They appear to be numbered by kernel version, and the above version is
the most recent one for 2.6.14. Will more recent ones (for newer
kernels) work with my kernel?
Chris
^ permalink raw reply
* Re: [PATCH] XFRM: Display the audited SPI value in host byte order
From: Steve Grubb @ 2007-12-12 21:14 UTC (permalink / raw)
To: linux-audit; +Cc: netdev
In-Reply-To: <20071212190542.20699.96051.stgit@flek.americas.hpqcorp.net>
On Wednesday 12 December 2007 14:05:42 Paul Moore wrote:
> This patch corrects this inconsistency by writing the SPI values to the
> audit record in host byte order.
Looks OK, to me, too.
-Steve
^ permalink raw reply
* [PATCH] net: remove remaining fastcall occurances in drivers/net
From: Harvey Harrison @ 2007-12-12 20:48 UTC (permalink / raw)
To: linux-netdev, David Miller; +Cc: LKML
fastcall is always defined to empty, remove it
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
drivers/net/ns83820.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ns83820.c b/drivers/net/ns83820.c
index 972acc3..5eed99e 100644
--- a/drivers/net/ns83820.c
+++ b/drivers/net/ns83820.c
@@ -612,7 +612,7 @@ static inline int rx_refill(struct net_device *ndev, gfp_t gfp)
}
static void rx_refill_atomic(struct net_device *ndev));
-static void fastcall rx_refill_atomic(struct net_device *ndev)
+static void rx_refill_atomic(struct net_device *ndev)
{
rx_refill(ndev, GFP_ATOMIC);
}
@@ -633,7 +633,7 @@ static inline void clear_rx_desc(struct ns83820 *dev, unsigned i)
build_rx_desc(dev, dev->rx_info.descs + (DESC_SIZE * i), 0, 0, CMDSTS_OWN, 0);
}
-static void fastcall phy_intr(struct net_device *ndev)
+static void phy_intr(struct net_device *ndev)
{
struct ns83820 *dev = PRIV(ndev);
static const char *speeds[] = { "10", "100", "1000", "1000(?)", "1000F" };
@@ -831,7 +831,7 @@ static void ns83820_cleanup_rx(struct ns83820 *dev)
}
}
-static void fastcall ns83820_rx_kick(struct net_device *ndev)
+static void ns83820_rx_kick(struct net_device *ndev)
{
struct ns83820 *dev = PRIV(ndev);
/*if (nr_rx_empty(dev) >= NR_RX_DESC/4)*/ {
@@ -852,7 +852,7 @@ static void fastcall ns83820_rx_kick(struct net_device *ndev)
/* rx_irq
*
*/
-static void fastcall rx_irq(struct net_device *ndev)
+static void rx_irq(struct net_device *ndev)
{
struct ns83820 *dev = PRIV(ndev);
struct rx_info *info = &dev->rx_info;
--
1.5.3.7.2212.gd092
^ permalink raw reply related
* [PATCH] net: remove fastcall
From: Harvey Harrison @ 2007-12-12 20:34 UTC (permalink / raw)
To: linux-netdev; +Cc: LKML, Ingo Molnar
fastcall is always empty, remove it from net/
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
net/bluetooth/rfcomm/core.c | 4 ++--
net/core/dev.c | 2 +-
net/core/sock.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index e7ac6ba..fc98883 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -467,7 +467,7 @@ int rfcomm_dlc_send(struct rfcomm_dlc *d, struct sk_buff *skb)
return len;
}
-void fastcall __rfcomm_dlc_throttle(struct rfcomm_dlc *d)
+void __rfcomm_dlc_throttle(struct rfcomm_dlc *d)
{
BT_DBG("dlc %p state %ld", d, d->state);
@@ -478,7 +478,7 @@ void fastcall __rfcomm_dlc_throttle(struct rfcomm_dlc *d)
rfcomm_schedule(RFCOMM_SCHED_TX);
}
-void fastcall __rfcomm_dlc_unthrottle(struct rfcomm_dlc *d)
+void __rfcomm_dlc_unthrottle(struct rfcomm_dlc *d)
{
BT_DBG("dlc %p state %ld", d, d->state);
diff --git a/net/core/dev.c b/net/core/dev.c
index 86d6261..acf71ba 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2138,7 +2138,7 @@ static int process_backlog(struct napi_struct *napi, int quota)
*
* The entry's receive function will be scheduled to run
*/
-void fastcall __napi_schedule(struct napi_struct *n)
+void __napi_schedule(struct napi_struct *n)
{
unsigned long flags;
diff --git a/net/core/sock.c b/net/core/sock.c
index c519b43..c536149 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1613,7 +1613,7 @@ void sock_init_data(struct socket *sock, struct sock *sk)
atomic_set(&sk->sk_refcnt, 1);
}
-void fastcall lock_sock_nested(struct sock *sk, int subclass)
+void lock_sock_nested(struct sock *sk, int subclass)
{
might_sleep();
spin_lock_bh(&sk->sk_lock.slock);
@@ -1630,7 +1630,7 @@ void fastcall lock_sock_nested(struct sock *sk, int subclass)
EXPORT_SYMBOL(lock_sock_nested);
-void fastcall release_sock(struct sock *sk)
+void release_sock(struct sock *sk)
{
/*
* The sk_lock has mutex_unlock() semantics:
--
1.5.3.7.2212.gd092
^ permalink raw reply related
* Re: [PATCH 3/4] ixp2000: rtnl_lock out of loop will be faster
From: Lennert Buytenhek @ 2007-12-12 20:01 UTC (permalink / raw)
To: Wang Chen; +Cc: David S. Miller, Jeff Garzik, netdev
In-Reply-To: <475FA05C.1060705@cn.fujitsu.com>
On Wed, Dec 12, 2007 at 04:48:28PM +0800, Wang Chen wrote:
> [PATCH 3/4] [NETDEV] ixp2000: rtnl_lock out of loop will be faster
>
> Before this patch, it gets and releases the lock at each
> iteration of the loop. Changing unregister_netdev to
> unregister_netdevice and locking outside of the loop will
> be faster for this approach.
Since the number of net devices is typically either 2 or 3 (depending
on the specific model card you're using), and this is not in any kind
of hot path at all, I don't see a whole lot of benefit of acquiring
the RTNL separately. Besides, I'm slightly worried about putting
knowledge of the RTNL into the driver directly.
^ permalink raw reply
* Re: [patch 1/1] Convert the semaphore to a mutex in net/tipc/socket.c
From: David Miller @ 2007-12-12 19:24 UTC (permalink / raw)
To: akpm
Cc: jon.maloy, per.liden, netdev, linux-kernel, tipc-discussion,
allan.stephens, kjwinchester, mingo
In-Reply-To: <20071211164445.752431ec.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Tue, 11 Dec 2007 16:44:45 -0800
> So I'd propose this:
I've applied this to net-2.6, thanks Andrew.
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
^ permalink raw reply
* Re: 2.6.24-rc4-mm1
From: Cedric Le Goater @ 2007-12-12 19:21 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Andrew Morton, Reuben Farrelly, David Miller, LKML,
Linux Netdev List, Auke Kok
In-Reply-To: <Pine.LNX.4.64.0712101136190.18529@kivilampi-30.cs.helsinki.fi>
Ilpo Järvinen wrote:
> On Wed, 5 Dec 2007, Andrew Morton wrote:
>
>> On Thu, 06 Dec 2007 17:59:37 +1100 Reuben Farrelly <reuben-linuxkernel@reub.net> wrote:
>>
>>> This non fatal oops which I have just noticed may be related to this change then
>>> - certainly looks networking related.
>> yep, but it isn't e1000. It's core TCP.
>>
>>> WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
>>> Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
>> Ilpo, Reuben's kernel is talking to you ;)
>
> ...Please try the patch below. Andrew, this probably fixes your problem
> (the packets <= tp->packets_out) as well.
nah. I got the WARNINGs again with this patch.
C.
> Dave, please include this one to net-2.6.25.
>
>
^ permalink raw reply
* Re: [PATCH 8/8][BNX2]: Update version to 1.6.9.
From: David Miller @ 2007-12-12 19:20 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1197486022.16386.33.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 12 Dec 2007 11:00:22 -0800
> [BNX2]: Update version to 1.6.9.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks.
^ 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