* [PATCH 2.6.24 1/1]S2io: Check for register initialization completion before accesing device registers
From: Sreenivasa Honnur @ 2007-12-06 4:59 UTC (permalink / raw)
To: netdev, jeff; +Cc: support
- Making sure register initialisation is complete before proceeding further.
The driver must wait until initialization is complete before attempting to
access any other device registers.
Signed-off-by: Surjit Reang <surjit.reang@neterion.com>
Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
---
diff -Nurp patch_9/drivers/net/s2io.c patch_10/drivers/net/s2io.c
--- patch_9/drivers/net/s2io.c 2007-12-04 23:29:22.000000000 +0530
+++ patch_10/drivers/net/s2io.c 2007-12-04 23:36:48.000000000 +0530
@@ -84,7 +84,7 @@
#include "s2io.h"
#include "s2io-regs.h"
-#define DRV_VERSION "2.0.26.6"
+#define DRV_VERSION "2.0.26.10"
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion";
@@ -1100,6 +1100,20 @@ static int init_nic(struct s2io_nic *nic
msleep(500);
val64 = readq(&bar0->sw_reset);
+ /* Ensure that it's safe to access registers by checking
+ * RIC_RUNNING bit is reset. Check is valid only for XframeII.
+ */
+ if (nic->device_type == XFRAME_II_DEVICE) {
+ for (i = 0; i < 50; i++) {
+ val64 = readq(&bar0->adapter_status);
+ if (!(val64 & ADAPTER_STATUS_RIC_RUNNING))
+ break;
+ msleep(10);
+ }
+ if (i == 50)
+ return -ENODEV;
+ }
+
/* Enable Receiving broadcasts */
add = &bar0->mac_cfg;
val64 = readq(&bar0->mac_cfg);
diff -Nurp patch_9/drivers/net/s2io-regs.h patch_10/drivers/net/s2io-regs.h
--- patch_9/drivers/net/s2io-regs.h 2007-12-04 23:29:22.000000000 +0530
+++ patch_10/drivers/net/s2io-regs.h 2007-12-04 23:38:24.000000000 +0530
@@ -66,6 +66,7 @@ struct XENA_dev_config {
#define ADAPTER_STATUS_RC_PRC_QUIESCENT vBIT(0xFF,16,8)
#define ADAPTER_STATUS_MC_DRAM_READY s2BIT(24)
#define ADAPTER_STATUS_MC_QUEUES_READY s2BIT(25)
+#define ADAPTER_STATUS_RIC_RUNNING s2BIT(26)
#define ADAPTER_STATUS_M_PLL_LOCK s2BIT(30)
#define ADAPTER_STATUS_P_PLL_LOCK s2BIT(31)
^ permalink raw reply
* Re: [PATCH net-2.6 0/3]: Three TCP fixes
From: David Miller @ 2007-12-06 4:56 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: jheffner, netdev
In-Reply-To: <Pine.LNX.4.64.0712051248380.18529@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Wed, 5 Dec 2007 13:30:32 +0200 (EET)
> On Wed, 5 Dec 2007, David Miller wrote:
>
> > Anyways, someone please enlighten me and please also cook
> > up a patch to add the descriptive comment :-)
>
> Not sure if a too simple patch here is correct thing to do... Matt has a
> point regarding slow-start cwnd behavior.
...
> ...I've not yet decided what is the best way to deal with it but I'll try
> to figure something out.
Ok.
^ permalink raw reply
* Re: [PATCH 4/4] udp: memory accounting in IPv4
From: Hideo AOKI @ 2007-12-06 4:28 UTC (permalink / raw)
To: Herbert Xu, netdev, David Miller
Cc: Eric Dumazet, Satoshi Oshima, Bill Fink, Andi Kleen,
Evgeniy Polyakov, Stephen Hemminger, yoshfuji, Yumiko Sugita,
haoki
In-Reply-To: <20071204002644.GA28982@gondor.apana.org.au>
Herbert Xu wrote:
> On Mon, Dec 03, 2007 at 07:14:26PM -0500, Hideo AOKI wrote:
>> Let me try to use sk_forward_alloc at first, while percpu storage
>> is an interesting idea.
>
> Actually I don't think sk_forward_alloc would work for UDP because
> it runs lockless (unlike TCP which is run under a the socket lock).
>
> So it's either going to be the atomic op or per-cpu counters. For
> me the atomic op isn't the issue, it's the SMP cache-line bouncing
> that's more important so having something that did atomic ops on a
> socket counter which then feeds into the global counter would solve
> my concerns.
>
> But let's wait and see what Dave has to say about this too.
Hello,
I suppose that he also wants to have per-socket accounting to avoid
global counter access.
To achieve this, I think I have three ideas at present. I'd
appreciate if you let me know acceptable idea or any suggestions.
1. Using sk_forward_alloc and adding socket lock
UDP already uses a socket lock to send message. However, it doesn't
use the lock to receive message. I wonder if we can also use the
lock when sk_forward_alloc is updated in receive processing.
I understand performance issue might occur, but ...
2. Adding new atomic_t variable for memory accounting
Datagram protocols will use the variable for per-socket memory
accounting. Stream protocols continue to use sk_forward_alloc.
3. Replacing current sk_forward_alloc with union type
Stream protocols use the union as int, and datagram protocols use
it as atomic_t.
Best regards,
Hideo
--
Hitachi Computer Products (America) Inc.
^ permalink raw reply
* Re: TCP event tracking via netlink...
From: Stephen Hemminger @ 2007-12-06 4:06 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Joe Perches, David Miller, Netdev
In-Reply-To: <Pine.LNX.4.64.0712052336240.9572@kivilampi-30.cs.helsinki.fi>
On Thu, 6 Dec 2007 00:15:49 +0200 (EET)
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> wrote:
> On Wed, 5 Dec 2007, Stephen Hemminger wrote:
>
> > On Wed, 05 Dec 2007 08:53:07 -0800
> > Joe Perches <joe@perches.com> wrote:
> >
> > > > it occurred to me that we might want to do something
> > > > like a state change event generator.
> > >
> > > This could be a basis for an interesting TCP
> > > performance tester.
> >
> > That is what tcpprobe does but it isn't detailed enough to address SACK
> > issues.
>
> ...It would be nice if that could be generalized so that the probe could
> be attached to some other functions than tcp_rcv_established instead.
>
> If we convert remaining functions that don't have sk or tp as first
> argument so that sk is listed first (should be many with wrong ordering
> if any), then maybe a generic handler could be of type:
>
> jtcp_entry(struct sock *sk, ...)
>
> or when available:
>
> jtcp_entry(struct sock *sk, struct sk_buff *ack, ...)
>
>
> --
> i.
An earlier version had hooks in send as well, it is trivial to extend. as long as
the prototypes match, any function arg ordering is okay.
^ permalink raw reply
* Re: [BRIDGE] warning message when add an interface to bridge
From: Stephen Hemminger @ 2007-12-06 3:56 UTC (permalink / raw)
To: Chung-Chi Lo; +Cc: netdev, Eric W. Biederman
In-Reply-To: <3f696b20712041844h7c049b71reda92edd7b8cb16e@mail.gmail.com>
On Wed, 5 Dec 2007 10:44:17 +0800
"Chung-Chi Lo" <linolo@gmail.com> wrote:
> My kernel is Linxu 2.6.22.1. SYSFS is off.
> When adding an interface to bridge, console will show WARNING message.
> If turn SYSFS to on, then the WARNING message is gone.
> Any suggestion how to debug this problem? Thanks.
>
> # ifconfig eth0 0.0.0.0
> eth0: starting interface.
> # brctl addbr br0
> # brctl addif br0 eth0
> WARNING: at lib/kref.c:33 kref_get()
> Call Trace:
> [<80027844>] dump_stack+0x8/0x38
> [<8011f348>] kref_get+0xdc/0xe4
> [<8011ee20>] kobject_get+0x20/0x34
> [<8011e910>] kobject_shadow_add+0x5c/0x170
> [<8011ea34>] kobject_add+0x10/0x20
> [<8020aac0>] br_add_if+0xb4/0x1b4
> [<8020b354>] add_del_if+0x5c/0x118
> [<8020bcc4>] br_dev_ioctl+0x6c/0x88
> [<80182edc>] dev_ifsioc+0x334/0x3c0
> [<80183184>] dev_ioctl+0x21c/0x2ec
> [<8016f76c>] sock_ioctl+0x130/0x2e4
> [<800b3b2c>] do_ioctl+0x6c/0x84
> [<800b3d40>] vfs_ioctl+0x80/0x248
> [<800b3f58>] sys_ioctl+0x50/0x98
> [<8002a8a8>] stack_done+0x20/0x3c
> --
> 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
This is an an artifact of the kobject_shadow code which was reverted in later kernels.
It is gone in 2.6.23
^ permalink raw reply
* Re: [PATCH] sky2: RX lockup fix
From: Stephen Hemminger @ 2007-12-06 3:52 UTC (permalink / raw)
To: Peter Tyser; +Cc: netdev
In-Reply-To: <1196900326.21996.1.camel@localhost.localdomain>
On Wed, 05 Dec 2007 18:18:46 -0600
Peter Tyser <ptyser@xes-inc.com> wrote:
> On Wed, 2007-12-05 at 16:40 -0500, Stephen Hemminger wrote:
> > > I looked over Marvell's most recent sk98lin driver and it looks like
> > > they had a "workaround" for the Yukon XL that the sky2 doesn't have yet.
> > > The sk98lin driver disables the RX MAC FIFO flush feature for all
> > > revisions of the Yukon XL.
> > >
> > > According to skgeinit.c of the sk98lin driver, "Flushing must be enabled
> > > (needed for ASF see dev. #4.29), but the flushing mask should be
> > > disabled (see dev. #4.115)". Nice. I implemented this same change in
> > > the sky2 driver and verified that the RX lockup I was seeing was
> > > resolved.
> > >
> >
> >
> > Without the flush, does flow control still work? My concern is that
> > integrating this would cause pause packets (and over/under length packets)
> > to not be handled correctly.
>
> My understanding is that "bad" packets should still be filtered in
> sky2_receive() when a packet's status is compared against
> GMR_FS_ANY_ERR. This comparison should prevent over/under length
> packets from making their way up the stack. This comparison also uses
> the same value that was previous programmed to the RX MAC FIFO Flush
> Mask, so there shouldn't be any change in the types of bad packets that
> are discarded.
>
> I don't believe that disabling RX filtering should affect the handling
> of flow control packets specifically either. The comparison in
> sky2_receive() to GMR_FS_ANY_ERR does allow valid flow control packets
> to be received. (I'm not intimately familiar with sky2/Linux's handling
> of flow control packets, so take the above with a grain of salt)
>
> As I understand it, the only real downside of disabling RX filtering at
> the hardware level is that the CPU has to investigate every incoming
> packet's status, even the ones that it is going to drop due to length,
> crc, etc. This adds some overhead, but I don't believe it should affect
> the driver's operation.
>
I have ways to generate errors, so I'll check
^ permalink raw reply
* [patch-RFC 6/7] LTTng instrumentation net
From: Mathieu Desnoyers @ 2007-12-06 2:26 UTC (permalink / raw)
To: akpm, Ingo Molnar, linux-kernel; +Cc: Mathieu Desnoyers, netdev
In-Reply-To: <20071206022555.150400591@polymtl.ca>
[-- Attachment #1: lttng-instrumentation-net.patch --]
[-- Type: text/plain, Size: 3739 bytes --]
Network core events.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: netdev@vger.kernel.org
---
net/core/dev.c | 5 +++++
net/ipv4/devinet.c | 5 +++++
net/socket.c | 18 ++++++++++++++++++
3 files changed, 28 insertions(+)
Index: linux-2.6-lttng/net/core/dev.c
===================================================================
--- linux-2.6-lttng.orig/net/core/dev.c 2007-11-19 08:07:04.000000000 -0500
+++ linux-2.6-lttng/net/core/dev.c 2007-11-19 08:07:11.000000000 -0500
@@ -1639,6 +1639,8 @@ int dev_queue_xmit(struct sk_buff *skb)
}
gso:
+ trace_mark(net_dev_xmit, "skb %p protocol #2u%hu", skb, skb->protocol);
+
spin_lock_prefetch(&dev->queue_lock);
/* Disable soft irqs for various locks below. Also
@@ -2039,6 +2041,9 @@ int netif_receive_skb(struct sk_buff *sk
__get_cpu_var(netdev_rx_stat).total++;
+ trace_mark(net_dev_receive, "skb %p protocol #2u%hu",
+ skb, skb->protocol);
+
skb_reset_network_header(skb);
skb_reset_transport_header(skb);
skb->mac_len = skb->network_header - skb->mac_header;
Index: linux-2.6-lttng/net/ipv4/devinet.c
===================================================================
--- linux-2.6-lttng.orig/net/ipv4/devinet.c 2007-11-19 08:07:04.000000000 -0500
+++ linux-2.6-lttng/net/ipv4/devinet.c 2007-11-19 08:07:11.000000000 -0500
@@ -262,6 +262,8 @@ static void __inet_del_ifa(struct in_dev
struct in_ifaddr **ifap1 = &ifa1->ifa_next;
while ((ifa = *ifap1) != NULL) {
+ trace_mark(net_del_ifa_ipv4, "label %s",
+ ifa->ifa_label);
if (!(ifa->ifa_flags & IFA_F_SECONDARY) &&
ifa1->ifa_scope <= ifa->ifa_scope)
last_prim = ifa;
@@ -368,6 +370,9 @@ static int __inet_insert_ifa(struct in_i
}
ifa->ifa_flags |= IFA_F_SECONDARY;
}
+ trace_mark(net_insert_ifa_ipv4, "label %s address #4u%lu",
+ ifa->ifa_label,
+ (unsigned long)ifa->ifa_address);
}
if (!(ifa->ifa_flags & IFA_F_SECONDARY)) {
Index: linux-2.6-lttng/net/socket.c
===================================================================
--- linux-2.6-lttng.orig/net/socket.c 2007-11-19 08:07:04.000000000 -0500
+++ linux-2.6-lttng/net/socket.c 2007-11-19 08:07:11.000000000 -0500
@@ -563,6 +563,11 @@ int sock_sendmsg(struct socket *sock, st
struct sock_iocb siocb;
int ret;
+ trace_mark(net_socket_sendmsg,
+ "sock %p family %d type %d protocol %d size %zu",
+ sock, sock->sk->sk_family, sock->sk->sk_type,
+ sock->sk->sk_protocol, size);
+
init_sync_kiocb(&iocb, NULL);
iocb.private = &siocb;
ret = __sock_sendmsg(&iocb, sock, msg, size);
@@ -646,7 +651,13 @@ int sock_recvmsg(struct socket *sock, st
struct sock_iocb siocb;
int ret;
+ trace_mark(net_socket_recvmsg,
+ "sock %p family %d type %d protocol %d size %zu",
+ sock, sock->sk->sk_family, sock->sk->sk_type,
+ sock->sk->sk_protocol, size);
+
init_sync_kiocb(&iocb, NULL);
+
iocb.private = &siocb;
ret = __sock_recvmsg(&iocb, sock, msg, size, flags);
if (-EIOCBQUEUED == ret)
@@ -1212,6 +1223,11 @@ asmlinkage long sys_socket(int family, i
if (retval < 0)
goto out_release;
+ trace_mark(net_socket_create,
+ "sock %p family %d type %d protocol %d fd %d",
+ sock, sock->sk->sk_family, sock->sk->sk_type,
+ sock->sk->sk_protocol, retval);
+
out:
/* It may be already another descriptor 8) Not kernel problem. */
return retval;
@@ -2021,6 +2037,8 @@ asmlinkage long sys_socketcall(int call,
a0 = a[0];
a1 = a[1];
+ trace_mark(net_socket_call, "call %d a0 %lu", call, a0);
+
switch (call) {
case SYS_SOCKET:
err = sys_socket(a0, a1, a[2]);
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: sockets affected by IPsec always block (2.6.23)
From: David Miller @ 2007-12-06 2:25 UTC (permalink / raw)
To: stefan; +Cc: herbert, simon, linux-kernel, netdev
In-Reply-To: <200712051939.08384.stefan@loplof.de>
From: Stefan Rompf <stefan@loplof.de>
Date: Wed, 5 Dec 2007 19:39:07 +0100
> I'd strongly suggest doing so. AFAIK, behaviour of connect() on nonblocking
> sockets is quite well defined in POSIX.
You are entitled to your opinion.
POSIX says nothing about the semantics of route resolution.
Non-blocking doesn't mean "cannot sleep no matter what".
> If this is changed for some IP sockets, event-driven applications
> will randomly and subtly break.
If this was such a clear cut case we'd have changed things
a long time ago, but it isn't so don't pretend this is the
case.
^ permalink raw reply
* Re: Reproducible data corruption with sendfile+vsftp - splice regression?
From: Francois Romieu @ 2007-12-06 1:13 UTC (permalink / raw)
To: Holger Hoffstaette; +Cc: netdev, linux-kernel
In-Reply-To: <20071205225429.GA10186@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
> Holger Hoffstaette <holger@wizards.de> :
> [...]
> > Should I file this in bugzilla?
>
> Yes.
5326 5585327 5585328 5585329 5585330 5585331 5585332 5585333 5585334 5585335 558
5336 5585337 5585338 5585339 5585340 5585341 5585342 5585343 5589440 5589441 558
^^^^^^^ ^^^^^^^
9442 5589443 5589444 5589445 5589446 5589447 5589448 5589449 5589450 5589451 558
9452 5589453 5589454 5589455 5589456 5589457 5589458 5589459 5589460 5589461 558
It misses 8*4096 bytes.
8443 9068442 9068441 9068440 9068439 9068438 9068437 9068436 9068435 9068434 906
8433 9068432 9068431 9068430 9068429 9068428 9068427 9064330 9064329 9064328 906
^^^^^^^ ^^^^^^^
4327 9064326 9064325 9064324 9064323 9064322 9064321 9064320 9064319 9064318 906
Same thing later.
But the amount of data transmitted is fine.
Could you locate the offsets were the sequence is broken ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH] sky2: RX lockup fix
From: Peter Tyser @ 2007-12-06 0:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20071205164058.157275a9@shemminger-laptop>
On Wed, 2007-12-05 at 16:40 -0500, Stephen Hemminger wrote:
> > I looked over Marvell's most recent sk98lin driver and it looks like
> > they had a "workaround" for the Yukon XL that the sky2 doesn't have yet.
> > The sk98lin driver disables the RX MAC FIFO flush feature for all
> > revisions of the Yukon XL.
> >
> > According to skgeinit.c of the sk98lin driver, "Flushing must be enabled
> > (needed for ASF see dev. #4.29), but the flushing mask should be
> > disabled (see dev. #4.115)". Nice. I implemented this same change in
> > the sky2 driver and verified that the RX lockup I was seeing was
> > resolved.
> >
>
>
> Without the flush, does flow control still work? My concern is that
> integrating this would cause pause packets (and over/under length packets)
> to not be handled correctly.
My understanding is that "bad" packets should still be filtered in
sky2_receive() when a packet's status is compared against
GMR_FS_ANY_ERR. This comparison should prevent over/under length
packets from making their way up the stack. This comparison also uses
the same value that was previous programmed to the RX MAC FIFO Flush
Mask, so there shouldn't be any change in the types of bad packets that
are discarded.
I don't believe that disabling RX filtering should affect the handling
of flow control packets specifically either. The comparison in
sky2_receive() to GMR_FS_ANY_ERR does allow valid flow control packets
to be received. (I'm not intimately familiar with sky2/Linux's handling
of flow control packets, so take the above with a grain of salt)
As I understand it, the only real downside of disabling RX filtering at
the hardware level is that the CPU has to investigate every incoming
packet's status, even the ones that it is going to drop due to length,
crc, etc. This adds some overhead, but I don't believe it should affect
the driver's operation.
^ permalink raw reply
* Re: [PATCH net-2.6.25 10/11][INET] Eliminate difference in actions of sysctl and proc handler for conf.all.forwarding
From: Herbert Xu @ 2007-12-06 0:13 UTC (permalink / raw)
To: David Miller; +Cc: xemul, netdev, devel
In-Reply-To: <20071205.020645.171664472.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
>
> The user is pretty much screwed in one way or the other.
> For example:
>
> 1) If 'default' propagates to all devices, any specific
> setting for a device is lost.
>
> 2) If 'default' does not propagate, there is no way to
> have 'default' influence devices which have already
> been loaded.
Well the way it works on IPv4 currently (for most options) is
that we'll propagate default settings to a device until either:
1) the user modifies the setting for that device;
2) or that an IPv4 address has been added to the device.
2) was done to preserve backwards compatibility as the controls
were previously only available after address addition and we did
not propagate default settings in that case..
We could easily extend this so that the default propagation
worked until the user modified the setting, with an ioctl to
revert to the current behaviour for compatibility.
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: TCP event tracking via netlink...
From: Ilpo Järvinen @ 2007-12-05 23:18 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
In-Reply-To: <20071205.053031.87154402.davem@davemloft.net>
On Wed, 5 Dec 2007, David Miller wrote:
> Ilpo, I was pondering the kind of debugging one does to find
> congestion control issues and even SACK bugs and it's currently too
> painful because there is no standard way to track state changes.
That's definately true.
> I assume you're using something like carefully crafted printk's,
> kprobes, or even ad-hoc statistic counters. That's what I used to do
> :-)
No, that's not at all what I do :-). I usually look time-seq graphs
expect for the cases when I just find things out by reading code (or
by just thinking of it). I'm so used to all things in the graphs that
I can quite easily spot any inconsistencies & TCP events and then look
interesting parts in greater detail, very rarely something remains
uncertain... However, instead of directly going to printks, etc. I almost
always read the code first (usually it's not just couple of lines but tens
of potential TCP execution paths involving more than a handful of
functions to check what the end result would be). This has a nice
side-effect that other things tend to show up as well. Only when things
get nasty and I cannot figure out what it does wrong, only then I add
specially placed ad-hoc printks.
One trick I also use, is to get the vars of the relevant flow from
/proc/net/tcp in a while loop but it only works for my case because
I use links that are slow (even a small value sleep in the loop does
not hide much).
For other people reports, I occasionally have to write a validator patches
like you might have notice because in a typical miscount case our
BUG_TRAPs are too late because they occur only after outstanding window
becomes zero that might be very distant point in time already from the
cause.
Also, I'm planning an experiment with those markers thing to see if
they are of any use when trying to gather some latency data about
SACK processing because they seem light weight enough to not be
disturbing.
> With that in mind it occurred to me that we might want to do something
> like a state change event generator.
>
> Basically some application or even a daemon listens on this generic
> netlink socket family we create. The header of each event packet
> indicates what socket the event is for and then there is some state
> information.
>
> Then you can look at a tcpdump and this state dump side by side and
> see what the kernel decided to do.
Much of the info is available in tcpdump already, it's just hard to read
without graphing it first because there are some many overlapping things
to track in two-dimensional space.
...But yes, I have to admit that couple of problems come to my mind
where having some variable from tcp_sock would have made the problem
more obvious.
> Now there is the question of granularity.
>
> A very important consideration in this is that we want this thing to
> be enabled in the distributions, therefore it must be cheap. Perhaps
> one test at the end of the packet input processing.
Not sure what is the benefit of having distributions with it because
those people hardly report problems anyway to here, they're just too
happy with TCP performance unless we print something to their logs,
which implies that we must setup a *_ON() condition :-(.
Yes, often negleted problem is that most people are just too happy even
something like TCP Tahoe or something as prehistoric. I've been surprised
how badly TCP can break without nobody complaining as long as it doesn't
crash (even any of the devs). Two key things seems to surface the most of
the TCP related bugs: research people really staring at strange packet
patterns (or code) and automatic WARN/BUG_ON checks triggered reports.
The latter reports include also corner cases which nobody would otherwise
ever noticed (or at least before Linus releases 3.0 :-/).
IMHO, those invariant WARN/BUG_ON are the only alternative that scales to
normal users well enough. The checks are simple enough so that it can be
always on and then we just happen to print something to their log, and
that's offensive enough for somebody to come up with a report... ;-)
> So I say we pick some state to track (perhaps start with tcp_info)
> and just push that at the end of every packet input run. Also,
> we add some minimal filtering capability (match on specific IP
> address and/or port, for example).
>
> Maybe if we want to get really fancy we can have some more-expensive
> debug mode where detailed specific events get generated via some
> macros we can scatter all over the place.
>
> This won't be useful for general user problem analysis, but it will be
> excellent for developers.
I would say that it to be generic enough, most function entrys and exits
should have to be covered because the need varies a lot, the processing in
general is so complex that things would get too easily shadowed otherwise!
In addition we need expensive mode++ which goes all the way down to the
dirty details of the write queue, they're now dirtier than ever because
the queue is split I dared to do.
Some problems are simply such that things cannot be accurately verified
without high processing overhead until it's far too late (eg skb bits vs
*_out counters). Maybe we should start to build an expensive state
validator as well which would automatically check invariants of the write
queue and tcp_sock in a straight forward, unoptimized manner? That would
definately do a lot of work for us, just ask people to turn it on and it
spits out everything that went wrong :-) (unless they really depend on
very high-speed things and are therefore unhappy if we scan thousands of
packets unnecessarily per ACK :-)). ...Early enough! ...That would work
also for distros but there's always human judgement needed to decide
whether the bug reporter will be happy when his TCP processing does no
longer scale ;-).
For the simpler thing, why not just taking all TCP functions and doing
some automated tool using kprobes to collect the information we need
through the sk/tp available on almost every function call, some TCP
specific code could then easily produce what we want from it? Ah, this is
almost done already as noted by Stephen, would just need some
generalization to be pluggable to other functions as well and more
variables.
> Let me know if you think this is useful enough and I'll work on
> an implementation we can start playing with.
...Hopefully you found any of my comments useful.
--
i.
^ permalink raw reply
* Re: bonding sysfs output
From: Jean Delvare @ 2007-12-05 22:59 UTC (permalink / raw)
To: Wagner Ferenc; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <87lk8lflzf.fsf@szonett.ki.iif.hu>
Hi Wagner,
On Mon, 26 Nov 2007 09:29:40 +0100, Wagner Ferenc wrote:
> On the policy side: some files are not applicable to some types of
> bonds, and return a single linefeed in that case. Except for one
> single case, which returns 'NA\n'. The patch changes these cases into
> emtpy files.
IMHO a better approach would be to not create the files at all when
they make no sense for a given type of bond.
--
Jean Delvare
^ permalink raw reply
* Re: Reproducible data corruption with sendfile+vsftp - splice regression?
From: Francois Romieu @ 2007-12-05 22:54 UTC (permalink / raw)
To: Holger Hoffstaette; +Cc: netdev, linux-kernel
In-Reply-To: <pan.2007.12.02.20.49.42.675000@wizards.de>
Holger Hoffstaette <holger@wizards.de> :
[...]
> Should I file this in bugzilla?
Yes.
--
Ueimor
^ permalink raw reply
* Re: TCP event tracking via netlink...
From: Ilpo Järvinen @ 2007-12-05 22:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Joe Perches, David Miller, Netdev
In-Reply-To: <20071205163338.50aff45d@shemminger-laptop>
On Wed, 5 Dec 2007, Stephen Hemminger wrote:
> On Wed, 05 Dec 2007 08:53:07 -0800
> Joe Perches <joe@perches.com> wrote:
>
> > > it occurred to me that we might want to do something
> > > like a state change event generator.
> >
> > This could be a basis for an interesting TCP
> > performance tester.
>
> That is what tcpprobe does but it isn't detailed enough to address SACK
> issues.
...It would be nice if that could be generalized so that the probe could
be attached to some other functions than tcp_rcv_established instead.
If we convert remaining functions that don't have sk or tp as first
argument so that sk is listed first (should be many with wrong ordering
if any), then maybe a generic handler could be of type:
jtcp_entry(struct sock *sk, ...)
or when available:
jtcp_entry(struct sock *sk, struct sk_buff *ack, ...)
--
i.
^ permalink raw reply
* Re: Pull request for 'ipg' branch
From: Francois Romieu @ 2007-12-05 21:51 UTC (permalink / raw)
To: Joe Perches
Cc: jeff, Pekka Enberg, Sorbica Shieh, Jesse Huang, Andrew Morton,
netdev
In-Reply-To: <1196806495.10819.16.camel@localhost>
Joe Perches <joe@perches.com> :
[...]
> > - if ((sp->LED_Mode & 0x01) == 1)
> > + if ((sp->led_mode & 0x01) == 1)
>
> I think the use of hex and decimal constants is odd.
> I think "if (sp->led_mode & 0x01)" is better.
Yes, the whole context of this code in the driver is a bit special.
[...]
> > /* Assign IPG_APPEND_FCS_ON_TX > 0 for auto FCS append on TX. */
> > -#define IPG_APPEND_FCS_ON_TX TRUE
> > +#define IPG_APPEND_FCS_ON_TX 1
>
> Why not true and false?
No objection. Both can be used.
[...]
> > @@ -753,8 +732,7 @@ enum ipg_regs {
> > * Miscellaneous macros.
> > */
> >
> > -/* Marco for printing debug statements.
> > -# define IPG_DDEBUG_MSG(args...) printk(KERN_DEBUG "IPG: " ## args) */
> > +/* Marco for printing debug statements. */
>
> Macros
I actively ignored it. It was not easy. :o)
--
Ueimor
^ permalink raw reply
* Re: [PATCH] sky2: RX lockup fix
From: Stephen Hemminger @ 2007-12-05 21:40 UTC (permalink / raw)
To: Peter Tyser; +Cc: netdev
In-Reply-To: <1196880663.2816.149.camel@localhost.localdomain>
On Wed, 05 Dec 2007 12:51:03 -0600
Peter Tyser <ptyser@xes-inc.com> wrote:
> Hello,
> I'm using a Marvell 88E8062 on a custom PPC64 blade and ran into RX
> lockups while validating the sky2 driver. The receive MAC FIFO would
> become stuck during testing with high traffic. One port of the 88E8062
> would lockup, while the other port remained functional. Re-inserting
> the sky2 module would not fix the problem - only a power cycle would.
>
> I looked over Marvell's most recent sk98lin driver and it looks like
> they had a "workaround" for the Yukon XL that the sky2 doesn't have yet.
> The sk98lin driver disables the RX MAC FIFO flush feature for all
> revisions of the Yukon XL.
>
> According to skgeinit.c of the sk98lin driver, "Flushing must be enabled
> (needed for ASF see dev. #4.29), but the flushing mask should be
> disabled (see dev. #4.115)". Nice. I implemented this same change in
> the sky2 driver and verified that the RX lockup I was seeing was
> resolved.
>
Without the flush, does flow control still work? My concern is that
integrating this would cause pause packets (and over/under length packets)
to not be handled correctly.
^ permalink raw reply
* Re: TCP event tracking via netlink...
From: Stephen Hemminger @ 2007-12-05 21:33 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, ilpo.jarvinen, netdev
In-Reply-To: <1196873587.10819.30.camel@localhost>
On Wed, 05 Dec 2007 08:53:07 -0800
Joe Perches <joe@perches.com> wrote:
> > it occurred to me that we might want to do something
> > like a state change event generator.
>
> This could be a basis for an interesting TCP
> performance tester.
That is what tcpprobe does but it isn't detailed enough to address SACK
issues.
^ permalink raw reply
* [PATCH 2/2] e100: cleanup unneeded math
From: Auke Kok @ 2007-12-05 19:57 UTC (permalink / raw)
To: jeff; +Cc: netdev, 12o3l
In-Reply-To: <20071205195729.6859.97796.stgit@localhost.localdomain>
No need to convert to bytes and back - cleanup unneeded code.
Adapted from fix from 'Roel Kluin <12o3l@tiscali.nl>'
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e100.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 9189aff..27f4d4a 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2284,13 +2284,11 @@ static void e100_get_drvinfo(struct net_device *netdev,
strcpy(info->bus_info, pci_name(nic->pdev));
}
+#define E100_PHY_REGS 0x1C
static int e100_get_regs_len(struct net_device *netdev)
{
struct nic *nic = netdev_priv(netdev);
-#define E100_PHY_REGS 0x1C
-#define E100_REGS_LEN 1 + E100_PHY_REGS + \
- sizeof(nic->mem->dump_buf) / sizeof(u32)
- return E100_REGS_LEN * sizeof(u32);
+ return 1 + E100_PHY_REGS + sizeof(nic->mem->dump_buf);
}
static void e100_get_regs(struct net_device *netdev,
^ permalink raw reply related
* [PATCH 1/2] e1000: fix memcpy in e1000_get_strings
From: Auke Kok @ 2007-12-05 19:57 UTC (permalink / raw)
To: jeff; +Cc: netdev, 12o3l
From: Roel Kluin <12o3l@tiscali.nl>
drivers/net/e1000/e1000_ethtool.c:113:
#define E1000_TEST_LEN sizeof(e1000_gstrings_test) / ETH_GSTRING_LEN
drivers/net/e1000e/ethtool.c:106:
#define E1000_TEST_LEN sizeof(e1000_gstrings_test) / ETH_GSTRING_LEN
E1000_TEST_LEN*ETH_GSTRING_LEN will expand to
sizeof(e1000_gstrings_test) / (ETH_GSTRING_LEN * ETH_GSTRING_LEN)
A lack of parentheses around defines causes unexpected results due to
operator precedences.
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000/e1000_ethtool.c | 2 +-
drivers/net/e1000e/ethtool.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index 0542b10..d876787 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -1949,7 +1949,7 @@ e1000_get_strings(struct net_device *netdev, uint32_t stringset, uint8_t *data)
switch (stringset) {
case ETH_SS_TEST:
memcpy(data, *e1000_gstrings_test,
- E1000_TEST_LEN*ETH_GSTRING_LEN);
+ sizeof(e1000_gstrings_test));
break;
case ETH_SS_STATS:
for (i = 0; i < E1000_GLOBAL_STATS_LEN; i++) {
diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
index d824914..6d9c27f 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -1760,7 +1760,7 @@ static void e1000_get_strings(struct net_device *netdev, u32 stringset,
switch (stringset) {
case ETH_SS_TEST:
memcpy(data, *e1000_gstrings_test,
- E1000_TEST_LEN*ETH_GSTRING_LEN);
+ sizeof(e1000_gstrings_test));
break;
case ETH_SS_STATS:
for (i = 0; i < E1000_GLOBAL_STATS_LEN; i++) {
^ permalink raw reply related
* [PATCH] sky2: RX lockup fix
From: Peter Tyser @ 2007-12-05 18:51 UTC (permalink / raw)
To: shemminger; +Cc: netdev
Hello,
I'm using a Marvell 88E8062 on a custom PPC64 blade and ran into RX
lockups while validating the sky2 driver. The receive MAC FIFO would
become stuck during testing with high traffic. One port of the 88E8062
would lockup, while the other port remained functional. Re-inserting
the sky2 module would not fix the problem - only a power cycle would.
I looked over Marvell's most recent sk98lin driver and it looks like
they had a "workaround" for the Yukon XL that the sky2 doesn't have yet.
The sk98lin driver disables the RX MAC FIFO flush feature for all
revisions of the Yukon XL.
According to skgeinit.c of the sk98lin driver, "Flushing must be enabled
(needed for ASF see dev. #4.29), but the flushing mask should be
disabled (see dev. #4.115)". Nice. I implemented this same change in
the sky2 driver and verified that the RX lockup I was seeing was
resolved.
I didn't see the problem mentioned in the netdev list, so I've included
a patch against the
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 tree
which disables RX flushing for the Yukon XL chips.
Please CC replies to me as I am not subscribed to the list.
Thanks,
Peter Tyser
Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -822,8 +822,13 @@ static void sky2_mac_init(struct sky2_hw *hw,
unsigned port)
sky2_write32(hw, SK_REG(port, RX_GMF_CTRL_T), rx_reg);
- /* Flush Rx MAC FIFO on any flow control or error */
- sky2_write16(hw, SK_REG(port, RX_GMF_FL_MSK), GMR_FS_ANY_ERR);
+ if (hw->chip_id == CHIP_ID_YUKON_XL) {
+ /* Hardware errata - clear flush mask */
+ sky2_write16(hw, SK_REG(port, RX_GMF_FL_MSK), 0);
+ } else {
+ /* Flush Rx MAC FIFO on any flow control or error */
+ sky2_write16(hw, SK_REG(port, RX_GMF_FL_MSK), GMR_FS_ANY_ERR);
+ }
/* Set threshold to 0xa (64 bytes) + 1 to workaround pause bug */
reg = RX_GMF_FL_THR_DEF + 1;
^ permalink raw reply
* Re: [PATCH] [TCP]: Make invariant check complain about invalid sacked_out
From: Ilpo Järvinen @ 2007-12-05 19:36 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
In-Reply-To: <Pine.LNX.4.64.0712052133490.9572@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 304 bytes --]
On Wed, 5 Dec 2007, Ilpo Järvinen wrote:
>
> Earlier resolution for NewReno's sacked_out should now keep
> it small enough for this to become invariant-like check.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Forgot to modify it to the subject, this one to net-2.6.25 please.
--
i.
^ permalink raw reply
* [PATCH] [TCP]: Make invariant check complain about invalid sacked_out
From: Ilpo Järvinen @ 2007-12-05 19:35 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 854 bytes --]
Earlier resolution for NewReno's sacked_out should now keep
it small enough for this to become invariant-like check.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_input.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index fef1191..f1eee2d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2510,11 +2510,8 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
(tcp_fackets_out(tp) > tp->reordering));
int fast_rexmit = 0;
- /* Some technical things:
- * 1. Reno does not count dupacks (sacked_out) automatically. */
- if (!tp->packets_out)
+ if (WARN_ON(!tp->packets_out && tp->sacked_out))
tp->sacked_out = 0;
-
if (WARN_ON(!tp->sacked_out && tp->fackets_out))
tp->fackets_out = 0;
--
1.5.0.6
^ permalink raw reply related
* Re: sockets affected by IPsec always block (2.6.23)
From: Stefan Rompf @ 2007-12-05 18:39 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, simon, linux-kernel, netdev
In-Reply-To: <20071205065132.GA11476@gondor.apana.org.au>
Am Mittwoch, 5. Dezember 2007 07:51 schrieb Herbert Xu:
> > If he sets this sysctl to "1" as I detailed in my reply, he'll
> > get the behavior he wants.
>
> Does anybody actually need the 0 setting? What would we break if
> the default became 1?
I'd strongly suggest doing so. AFAIK, behaviour of connect() on nonblocking
sockets is quite well defined in POSIX. If this is changed for some IP
sockets, event-driven applications will randomly and subtly break.
Stefan
^ permalink raw reply
* Re: sockets affected by IPsec always block (2.6.23)
From: Stefan Rompf @ 2007-12-05 18:42 UTC (permalink / raw)
To: David Miller; +Cc: herbert, simon, linux-kernel, netdev
In-Reply-To: <20071204.231200.117152338.davem@davemloft.net>
Am Mittwoch, 5. Dezember 2007 08:12 schrieb David Miller:
> Actually, consider even a case like DNS. Let's say the timeout
> is set to 2 seconds or something and you have 3 DNS servers
> listed, on different IPSEC destinations, in your resolv.conf
>
> Each IPSEC route that isn't currently resolved will cause packet loss
> of the DNS lookup request with xfrm_larval_drop set to '1'.
>
> If all 3 need to be resolved, the DNS lookup will fully fail
> which defeats the purpose of listing 3 servers for redundancy
> don't you think? :-)
In your example, the DNS server might actually stop responding to other
clients while waiting for the (expected to be non-blocking) connect() to
return. This is much much worse.
Stefan
^ 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