* [RFC][PATCH 0/3][XFRM]: Support packet processing error statistics.
From: Masahide NAKAMURA @ 2007-10-22 6:11 UTC (permalink / raw)
To: Herbert Xu, David Miller; +Cc: netdev, Masahide NAKAMURA
In-Reply-To: <20071017.213523.58458049.davem@davemloft.net>
This patch introduces statistics about transformation error (or almost error)
factor at packet processing for developer.
It is not a SNMP/MIB specification from IPsec/MIPv6 but a counter
designed from current transformation source code.
Comment please.
^ permalink raw reply
* [RFC][PATCH 3/3][XFRM]: Add packet processing statistics option.
From: Masahide NAKAMURA @ 2007-10-22 6:11 UTC (permalink / raw)
To: Herbert Xu, David Miller; +Cc: netdev, Masahide NAKAMURA
In-Reply-To: <20071017.213523.58458049.davem@davemloft.net>
Signed-off-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
---
net/xfrm/Kconfig | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index 577a4f8..6b5b50f 100644
--- a/net/xfrm/Kconfig
+++ b/net/xfrm/Kconfig
@@ -35,6 +35,16 @@ config XFRM_MIGRATE
If unsure, say N.
+config XFRM_STATISTICS
+ bool "Transformation statistics (EXPERIMENTAL)"
+ depends on XFRM && PROC_FS && EXPERIMENTAL
+ ---help---
+ This statistics is not a SNMP/MIB specification but shows
+ statistics about transformation error (or almost error) factor
+ at packet processing for developer.
+
+ If unsure, say N.
+
config NET_KEY
tristate "PF_KEY sockets"
select XFRM
--
1.4.4.2
^ permalink raw reply related
* [PATCH] [IPSEC] IPV6: Fix to add tunnel mode SA correctly.
From: Masahide NAKAMURA @ 2007-10-22 6:09 UTC (permalink / raw)
To: Herbert Xu, David Miller; +Cc: netdev, Masahide NAKAMURA
In-Reply-To: <20071017.213523.58458049.davem@davemloft.net>
Signed-off-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
---
net/ipv6/ah6.c | 1 +
net/ipv6/esp6.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index 67cd066..66a9139 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -483,6 +483,7 @@ static int ah6_init_state(struct xfrm_state *x)
break;
case XFRM_MODE_TUNNEL:
x->props.header_len += sizeof(struct ipv6hdr);
+ break;
default:
goto error;
}
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index b071543..72a6598 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -360,6 +360,7 @@ static int esp6_init_state(struct xfrm_state *x)
break;
case XFRM_MODE_TUNNEL:
x->props.header_len += sizeof(struct ipv6hdr);
+ break;
default:
goto error;
}
--
1.4.4.2
^ permalink raw reply related
* Re: [PATCH 2.4.35.3] Fix the "InAddrErrors" increasing problem
From: Krishna Kumar2 @ 2007-10-22 6:28 UTC (permalink / raw)
To: Gui Jianfeng; +Cc: davem, netdev
In-Reply-To: <471C3E0B.2070602@cn.fujitsu.com>
Gui Jianfeng wrote on 10/22/2007 11:37:07 AM:
> @@ -310,8 +310,12 @@ static inline int ip_rcv_finish(struct s
> * how the packet travels inside Linux networking.
> */
> if (skb->dst == NULL) {
> - if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
> - goto drop;
> + int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
dev);
> + if (unlikely(err)) {
> + if (err == -EHOSTUNREACH)
> + IP_INC_STATS_BH(IpInAddrErrors);
> + }
> + goto drop;
> }
Shouldn't the "goto drop" be inside the "if (unlikely(err)) {" case?
And normally it is nice to have a blank line after variable declaration.
- KK
^ permalink raw reply
* Re: [PATCH 2.4.35.3] Fix the "InAddrErrors" increasing problem
From: David Miller @ 2007-10-22 6:16 UTC (permalink / raw)
To: guijianfeng; +Cc: netdev
In-Reply-To: <471C3E0B.2070602@cn.fujitsu.com>
From: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Date: Mon, 22 Oct 2007 14:07:07 +0800
> When kernel receives a package with a wrong destination ipv4 address, it can't increase "InAddrErrors" number correctly.
> InAddrErrors is located in /proc/net/snmp.
>
> This is a patch for fixing this problem.
>
> Signed-off-by: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
This patch looks fine, but I really don't handle 2.4.x
kernel patches for networking as 2.6.x takes enough of
my time and effort.
^ permalink raw reply
* [PATCH 2.4.35.3] Fix the "InAddrErrors" increasing problem
From: Gui Jianfeng @ 2007-10-22 6:07 UTC (permalink / raw)
To: netdev; +Cc: davem
Hi,
When kernel receives a package with a wrong destination ipv4 address, it can't increase "InAddrErrors" number correctly.
InAddrErrors is located in /proc/net/snmp.
This is a patch for fixing this problem.
Signed-off-by: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
---
diff -Narup linux-2.4.35.3/net/ipv4/ip_input.c linux-2.4.35.3-prep/net/ipv4/ip_input.c
--- linux-2.4.35.3/net/ipv4/ip_input.c 2007-09-24 06:02:58.000000000 +0800
+++ linux-2.4.35.3-prep/net/ipv4/ip_input.c 2007-09-26 01:24:08.000000000 +0800
@@ -310,8 +310,12 @@ static inline int ip_rcv_finish(struct s
* how the packet travels inside Linux networking.
*/
if (skb->dst == NULL) {
- if (ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev))
- goto drop;
+ int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos, dev);
+ if (unlikely(err)) {
+ if (err == -EHOSTUNREACH)
+ IP_INC_STATS_BH(IpInAddrErrors);
+ }
+ goto drop;
}
#ifdef CONFIG_NET_CLS_ROUTE
diff -Narup linux-2.4.35.3/net/ipv4/route.c linux-2.4.35.3-prep/net/ipv4/route.c
--- linux-2.4.35.3/net/ipv4/route.c 2007-09-24 06:02:58.000000000 +0800
+++ linux-2.4.35.3-prep/net/ipv4/route.c 2007-09-26 01:26:15.000000000 +0800
@@ -1450,7 +1450,7 @@ int ip_route_input_slow(struct sk_buff *
*/
if ((err = fib_lookup(&key, &res)) != 0) {
if (!IN_DEV_FORWARD(in_dev))
- goto e_inval;
+ goto e_hostunreach;
goto no_route;
}
free_res = 1;
@@ -1499,7 +1499,7 @@ int ip_route_input_slow(struct sk_buff *
}
if (!IN_DEV_FORWARD(in_dev))
- goto e_inval;
+ goto e_hostunreach;
if (res.type != RTN_UNICAST)
goto martian_destination;
@@ -1668,6 +1668,11 @@ martian_destination:
"%u.%u.%u.%u, dev %s\n",
NIPQUAD(daddr), NIPQUAD(saddr), dev->name);
#endif
+
+e_hostunreach:
+ err = -EHOSTUNREACH;
+ goto done;
+
e_inval:
err = -EINVAL;
goto done;
^ permalink raw reply
* Re: [PATCH] flush_work_sync vs. flush_scheduled_work Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
From: Jarek Poplawski @ 2007-10-22 6:11 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Maciej W. Rozycki, Andy Fleming, Andrew Morton, Jeff Garzik,
netdev, linux-kernel
In-Reply-To: <20071019075014.GA1765@ff.dom.local>
On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
> On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote:
> > On 10/18, Jarek Poplawski wrote:
> > >
> > > +/**
> > > + * flush_work_sync - block until a work_struct's callback has terminated
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Hmm...
> >
> > > + * Similar to cancel_work_sync() but will only busy wait (without cancel)
> > > + * if the work is queued.
> >
> > Yes, it won't block, but will spin in busy-wait loop until all other works
> > scheduled before this work are finished. Not good. After that it really
> > blocks waiting for this work to complete.
> >
> > And I am a bit confused. We can't use flush_workqueue() because some of the
> > queued work_structs may take rtnl_lock, yes? But in that case we can't use
> > the new flush_work_sync() helper as well, no?
OK, I know I'm dumber and dumber everyday, but it seems in a hurry I
got it wrong again or miss something (as usual): these all flushes are
rtnl lockup vulnerable wrt. other work functions, but cancel_work_sync
looks perfectly fine... (Or am I wrong because: ...?)
Then, if by any chance I'm right, something like flush_work_sync
(or changed flush_scheduled_work, if there is no problem with such
a change of implementation) could be safely (if it's called without
locks used by flushed work only) done cancel_work_sync() way, by
running a work function after try_to_grab_pending() returns 1 (after
list_del_init - of course without respecting a queue order).
Regards,
Jarek P.
^ permalink raw reply
* Re: net: alignment problem in icmp code
From: David Miller @ 2007-10-22 5:15 UTC (permalink / raw)
To: drzeus; +Cc: netdev
In-Reply-To: <20071022065443.2f3c1b8a@poseidon.drzeus.cx>
From: Pierre Ossman <drzeus@drzeus.cx>
Date: Mon, 22 Oct 2007 06:54:43 +0200
> On Sun, 21 Oct 2007 16:02:15 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
> > You will get a 64-bit load and a 64-bit store emitted by
> > the compiler. Here is what we get on sparc64:
>
> I assume those ops cause a bus error on unaligned addresses?
Sure. But the language defines that the types in question
must be 64-bit aligned, so it is legal for the compiler to
emit this code.
It's not a GCC bug.
If you want to let the compiler know that a pointer to a type might
not be aligned, you have to tell it so.
^ permalink raw reply
* Re: net: alignment problem in icmp code
From: Pierre Ossman @ 2007-10-22 4:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20071021.160215.115679567.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]
On Sun, 21 Oct 2007 16:02:15 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Pierre Ossman <drzeus@drzeus.cx>
> Date: Sun, 21 Oct 2007 23:21:13 +0200
>
> > Not sure that would be valid. memcpy() is defined as having void*
> > arguments, and the compiler cannot just ignore that if it chooses to
> > inline it.
>
> Yes it can, there are C language rules about the alignment of types
> that the compiler completely can take advantage of in those kinds of
> situations.
>
I'm not debating that. What I'm saying is that calling memcpy() casts your pointers to void* with the included semantical changes. It can't just ignore that because it decides to inline the function. It would be the same thing as when gcc decided to ignore the volatile qualifier on a pointer just because it could optimize away to the real object and discover it wasn't marked with volatile. Something that was considered a bug and was fixed.
> If you don't believe me, compile something like the following
> with optimizations enabled:
gcc has had bugs in the past.
> You will get a 64-bit load and a 64-bit store emitted by
> the compiler. Here is what we get on sparc64:
>
I assume those ops cause a bus error on unaligned addresses?
>
> However, instead of relying upon magic like this, let's just tell the
> compiler explicitly what it going on by using get_unaligned().
>
It wouldn't be magic:
memcpy(&icmp_param.data.icmph, skb_transport_header(skb), sizeof(struct icmphdr));
I believe platforms without alignment requirements could optimize this better than the series of assignments. Not that I think this will be a potential bottle neck, but still.
> Next, there are redundant stores being done here since the code and
> type are explicitly overwritten in various ways.
Indeed.
Rgds
Pierre
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: David Miller @ 2007-10-22 4:45 UTC (permalink / raw)
To: mchan; +Cc: mcarlson, netdev, linux-pci, linas
In-Reply-To: <1551EAE59135BE47B544934E30FC4FC002AABB04@nt-irva-0751.brcm.ad.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Sun, 21 Oct 2007 21:01:17 -0700
> David Miller wrote:
>
> > I'm not so sure about this.
> >
> > Perhaps, instead, you should do a pci_msi_disable() and
> > pci_msi_enable() in the error detection and recovery sequence.
>
> If we just detected PCI errors on this slot, I don't think it's
> a good idea to continue writing to the config space to disable
> MSI. Perhaps we can disable/enable after the slot reset.
Right, it would have to be after the slot reset.
> > Or, alternatively, save/restore those MSI registers by hand.
>
> We can do that, but we'll have to do it ahead of time when we enable
> MSI, not after errors have been detected. But the address/data can
> change as the CPU affinity changes during run time, right?
Yes, it can.
The core issue is that the ARCH level MSI code invokes
write_msi_msg(), not the generic code, exactly because there
are platform level issues wherein the firmware is the only
legal way to write the MSI settings in PCI config space.
However, the MSI state restore code was not architected similarly. It
does the write_msi_msg() directly, instead of letting platform level
code is in ARCH hooks.
Therefore I think we need to attack this in two stages:
1) First changeset moves the write_msi_msg() call currently in
__pci_restore_msi_state() into an ARCH overridable handler.
This would allow powerpc to deal with this properly.
pci_restor_msi_state() can get exported to modules in this
change
2) The Tigon3 error recovery changes, as they were.
But I have to ask, can anyone see how e1000 handles MSI properly
in it's PCI error support?
^ permalink raw reply
* Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Michael Chan @ 2007-10-22 4:01 UTC (permalink / raw)
To: David Miller, Matthew Carlson; +Cc: netdev, linux-pci, linas
In-Reply-To: <20071021.162131.43417026.davem@davemloft.net>
David Miller wrote:
> I'm not so sure about this.
>
> Perhaps, instead, you should do a pci_msi_disable() and
> pci_msi_enable() in the error detection and recovery sequence.
If we just detected PCI errors on this slot, I don't think it's
a good idea to continue writing to the config space to disable
MSI. Perhaps we can disable/enable after the slot reset.
>
> Or, alternatively, save/restore those MSI registers by hand.
We can do that, but we'll have to do it ahead of time when we enable
MSI, not after errors have been detected. But the address/data can
change as the CPU affinity changes during run time, right?
^ permalink raw reply
* Re: [PATCH 2/7] tg3: MII => TP
From: David Miller @ 2007-10-22 4:00 UTC (permalink / raw)
To: mchan; +Cc: mcarlson, netdev, andy
In-Reply-To: <1551EAE59135BE47B544934E30FC4FC002AABB03@nt-irva-0751.brcm.ad.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Sun, 21 Oct 2007 20:49:25 -0700
> MII in this ethtool context means an MII connector on the card
> that can connect to an external transceiver, right?
>
> Or does it mean internal MII interface to the PHY?
Good question. Looking at drivers it's set randomly.
Probably you are right and it's supposed to mean you can specify
PORT_MII in ethtool_cmd->port to select the external MII connector.
Please resubmit this change after the PCI error recovery
issues are resolved.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/7] tg3: MII => TP
From: Michael Chan @ 2007-10-22 3:49 UTC (permalink / raw)
To: David Miller, Matthew Carlson; +Cc: netdev, andy
In-Reply-To: <20071021.161442.22476508.davem@davemloft.net>
David Miller wrote:
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Fri, 19 Oct 2007 14:36:42 -0700
>
> > This patch changes the PHY type reported through ethtool for copper
> > devices from MII to TP. The latter is more accurate.
> >
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> You should set both MII and TP, since these copper interfaces
> have a MII based twisted-pair physical layer.
>
>
MII in this ethtool context means an MII connector on the card
that can connect to an external transceiver, right?
Or does it mean internal MII interface to the PHY?
^ permalink raw reply
* Re: e100 problems in .23rc8 ?
From: Herbert Xu @ 2007-10-22 3:10 UTC (permalink / raw)
To: Dave Jones; +Cc: Kok, Auke, David Mack, netdev, esandeen
In-Reply-To: <20071022010440.GA11165@redhat.com>
On Sun, Oct 21, 2007 at 09:04:40PM -0400, Dave Jones wrote:
>
> I included the patch below in the latest build, but I've not had
> chance to try it on an e100 box yet..
Looks good to me. Thanks Dave!
--
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
* [ofa-general] Re: [PATCH 13/14 v2] nes: kernel build infrastructure
From: Roland Dreier @ 2007-10-22 2:23 UTC (permalink / raw)
To: ggrundstrom; +Cc: netdev, ewg, general
In-Reply-To: <200710192027.l9JKR197021855@neteffect.com>
> +config INFINIBAND_NES_DEBUG
> + bool "Verbose debugging output"
> + depends on INFINIBAND_NES
> + default n
> + ---help---
> + This option causes the NetEffect RNIC driver to produce debug
> + messages. Select this if you are developing the driver
> + or trying to diagnose a problem.
If you make this default n then no distro will have it enabled and
you'll have to rebuild to debug anything. Better to have the default
be enabled and make it controllable at runtime too with a module
parameter. (you can look at what mthca does for an example of what I mean)
^ permalink raw reply
* Re: [ofa-general] [PATCH 14/14 v2] nes: kernel build infrastructure
From: Roland Dreier @ 2007-10-22 2:22 UTC (permalink / raw)
To: ggrundstrom; +Cc: netdev, ewg, general
In-Reply-To: <200710192028.l9JKSnZG021867@neteffect.com>
> +
> +EXTRA_CFLAGS += -DNES_MINICM
I don't see anyplace NES_MINICM is used. Delete this line?
> +
> +obj-$(CONFIG_INFINIBAND_NES) += iw_nes.o
> +
> +iw_nes-objs := nes.o nes_hw.o nes_nic.o nes_utils.o nes_verbs.o nes_cm.o
> +
Also the file has an extra blank line at the beginning and end. Might
as well kill them.
^ permalink raw reply
* Re: about multiple network interface
From: wit @ 2007-10-22 2:09 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev
In-Reply-To: <20071018132836.GA15906@2ka.mipt.ru>
Thanks very much
But this does work until I add a ifcfg-eth0 in
sysconfig/network-script with the following content:
DEVICE=eth0
ONBOOT=yes
What is the relationship between these two files? And sometimes, I see
this message:
Bringing up interface eth0: e100 device does not seem to be present, delaying e
th0 initialization.
Why??
2007/10/18, Evgeniy Polyakov <johnpol@2ka.mipt.ru>:
> On Thu, Oct 18, 2007 at 09:06:40PM +0800, wit (is01kzh@gmail.com) wrote:
> > Hi all,
> >
> > Sorry, I don't know if this is the right mail list. I got the
> > following question:
> > I have a e100 card and a e1000 card. Whenever I boot the system, I
> > found the eth0 matches the e1000 card, and the eth2 matches the other.
> > How can I force the eth0 to match the e100 card and the eth2 to match
> > e1000?
>
> Hi.
>
> Check your /etc/modprobe.conf and put there
>
> alias eth0 e100
> alias eth2 e1000
>
>
> --
> Evgeniy Polyakov
>
^ permalink raw reply
* Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Michael Ellerman @ 2007-10-22 1:49 UTC (permalink / raw)
To: David Miller; +Cc: mcarlson, netdev, linux-pci, linas, mchan, linuxppc-dev list
In-Reply-To: <20071021.162131.43417026.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
On Sun, 2007-10-21 at 16:21 -0700, David Miller wrote:
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Fri, 19 Oct 2007 14:36:56 -0700
>
> > This patch exports the pci_restore_msi_state() function. This function
> > is needed to restore the MSI state during PCI error recovery.
> >
> > Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> I'm not so sure about this.
On pseries there's a chance it will work for PCI error recovery, but if
so it's just lucky that firmware has left everything configured the same
way. For actual suspend/resume it will never work, we need to ask
firmware to configure things.
> Perhaps, instead, you should do a pci_msi_disable() and
> pci_msi_enable() in the error detection and recovery sequence.
Yes I think so. That way we can properly reconfigure via the firmware
interface. The other option would be to design some new arch hook to do
resume, but just doing a disable/enable seems simpler to me.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: e100 problems in .23rc8 ?
From: Dave Jones @ 2007-10-22 1:04 UTC (permalink / raw)
To: Kok, Auke; +Cc: David Mack, Herbert Xu, netdev, esandeen
In-Reply-To: <47179F1F.3030202@intel.com>
On Thu, Oct 18, 2007 at 10:59:59AM -0700, Kok, Auke wrote:
> David Mack wrote:
> > It appears that the needed e100 fix made it into the Fedora
> > 2.6.23.1-23.fc8 kernel. Boots reliably now.
> >
> > Huge thanks and great work, guys.
>
> DaveJ, I didn't push anything upstream. Can you verify this now works?
There was no e100 changes in the kernel above, so David just
got lucky. (The race doesn't always occur, so it sometimes appears
something got fixed.).
I included the patch below in the latest build, but I've not had
chance to try it on an e100 box yet..
Dave
--- linux-2.6.23.noarch/drivers/net/e100.c~ 2007-10-18 16:10:40.000000000 -0400
+++ linux-2.6.23.noarch/drivers/net/e100.c 2007-10-18 16:16:02.000000000 -0400
@@ -2682,6 +2682,8 @@ static int __devinit e100_probe(struct p
if (err)
DPRINTK(PROBE, ERR, "Error clearing wake event\n");
+ netif_poll_disable(netdev);
+
strcpy(netdev->name, "eth%d");
if((err = register_netdev(netdev))) {
DPRINTK(PROBE, ERR, "Cannot register net device, aborting.\n");
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Regression in current git - Network Manager fails (bisected)
From: Joseph Fannin @ 2007-10-22 0:58 UTC (permalink / raw)
To: netdev; +Cc: Denis V. Lunev, David S. Miller, Alexey Kuznetsov
Network Manager (the freedesktop.org one) fails to work with Linus's
current git on a couple of different boxes I have here. All the boxes
have different NIC types, with different drivers.
I've bisected it down to cd40b7d3983c708aabe3d3008ec64ffce56d33b0 ,
"[NET]: make netlink user -> kernel interface synchronious". I've
double checked this by testing the kernel as of the immediately
previous commit; Network Manager works with that one, as it did on all
my machines in 2.6.23-mm1.
The netlink change seems to confuse N-M, and it somehow decides that
there's no link beat, so doesn't try to bring up the interface. If I
run "ifconfig eth0 up", N-M will decide there's a carrier after all
and takes over. Ethtool detects the link state correctly even with
the interface down.
If I down the interface again with ifconfig, N-M brings it right back
up without a problem, but if I kill N-M, it'll down the interface
before it exits, and fail in the same way as before when restarted.
N-M also emits this error:
"-- Error: Invalid message: type=DONE length=20 flags=<MULTI> sequence-nr=1193012574 pid=1185943630"
...which it doesn't do on kernels where it works normally.
strace'ing NetworkManager shows that it prints that message just after
talking over a netlink socket.
Networking otherwise works fine here with the latest git and N-M, if I
use the ifconfig "trick" to get the link up.
--
Joseph Fannin
jfannin@gmail.com
^ permalink raw reply
* CC2420 (802.15.4) Speed Issue
From: Michael Whyte @ 2007-10-22 0:47 UTC (permalink / raw)
To: netdev
Hi Guys,
I'm currently writing my first bit of Linux kernel code so be gentle.
It's a driver for TI CC2420 802.15.4 radio and I'm observing strange
behavior. I am currently testing just by transferring a ~300kb file
over HTTP between two of these devices.
The strange thing is, when ever you start the transfer it starts
humming along at 5k/s which is not far off what I'd expect these
devices to achieve, then at some random point along the transfer or
sometimes not at all... it suddenly drops fairly deterministically to
150byte/s and finishes the transfer at that speed, maybe rising to
170bytes/s by the end of the transfer is I'm lucky.
I don't really know where to start looking to solve the problem, it
seems everything is functioning as it should at least some of the time
as in some cases it will complete the whole transfer at the 5k/s
speed. Is it just tcp throttling very harshly (i.e. 50x) when it loses
a packet? Is it the Xscale chip scaling down the CPU frequency
mid-transfer, I've got no idea how to check this? It is some sort of
resonance affect happening with the two radios CCA although I'm not
seeing any CCA timeouts.
Can any one give any hints what to play with or where to look to try
find the cause and get the transfers to run reliabily without the
sudden bottoming out of speeds? (if you stop the transfer and initiate
a new one immediately it will start at full speed again)
Thanks,
-YT
^ permalink raw reply
* Re: [PATCH 4/4] Cut off the queue_mapping field from sk_buff
From: David Miller @ 2007-10-22 0:02 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47187364.9050102@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Fri, 19 Oct 2007 13:05:40 +0400
> Just hide it behind the #ifdef, because nobody wants
> it now.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Also applied, thanks!
^ permalink raw reply
* Re: [PATCH 3/4] Hide the queue_mapping field inside netif_subqueue_stopped
From: David Miller @ 2007-10-22 0:02 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <4718730D.1030801@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Fri, 19 Oct 2007 13:04:13 +0400
> Many places get the queue_mapping field from skb to pass it
> to the netif_subqueue_stopped() which will be 0 in any case.
>
> Make the helper that works with sk_buff
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/4] Make and use skb_get_queue_mapping
From: David Miller @ 2007-10-22 0:01 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <471872A7.7070101@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Fri, 19 Oct 2007 13:02:31 +0400
> Make the helper for getting the field, symmetrical to
> the "set" one. Return 0 if CONFIG_NETDEVICES_MULTIQUEUE=n
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/4] Use the skb_set_queue_mapping where appropriate
From: David Miller @ 2007-10-22 0:01 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47187244.1010603@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Fri, 19 Oct 2007 13:00:52 +0400
> There's already such a helper to initialize this field.
> Use it.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
> /* reset queue_mapping to zero */
> - skb->queue_mapping = 0;
> + skb_set_queue_mapping(skb, 0);
This right here is a great example why I add next to no comments to
the code I write. They are %99.999 of the time stating the obvious,
and where a comment is needed it's the code's fault and the code in
such cases could be rewritten to make what's going on more clear thus
making any commentary, again, redundant and stating the obvious.
Here the case is the former, it's of the form:
/* Add one to 'a'! */
a += 1;
Gee thanks for letting me know! How insightful! :-))
^ 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