* [2.6 patch] bonding/bond_main.c: fix cut'n'paste error
From: Adrian Bunk @ 2007-10-24 16:27 UTC (permalink / raw)
To: Andy Gospodarek, Jay Vosburgh, Jeff Garzik; +Cc: netdev, linux-kernel
This patch fixes a cut'n'paste error in
commit 1b76b31693d4a6088dec104ff6a6ead54081a3c2.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
4888742f8d7fe3b97fbc2911aa46375048173d01
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index e5fab4b..6937ef0 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3682,7 +3682,7 @@ static int bond_open(struct net_device *bond_dev)
}
if (bond->params.mode == BOND_MODE_8023AD) {
- INIT_DELAYED_WORK(&bond->ad_work, bond_alb_monitor);
+ INIT_DELAYED_WORK(&bond->ad_work, bond_3ad_state_machine_handler);
queue_delayed_work(bond->wq, &bond->ad_work, 0);
/* register to receive LACPDUs */
bond_register_lacpdu(bond);
^ permalink raw reply related
* [PATCH 2/2] forcedeth new device ids
From: Ayaz Abdulla @ 2007-10-23 21:09 UTC (permalink / raw)
To: Jeff Garzik, Andrew Morton, Manfred Spraul, nedev, stable
[-- Attachment #1: Type: text/plain, Size: 141 bytes --]
This patch adds new device ids and features for mcp77 devices into the
forcedeth driver.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-forcedeth-mcp77 --]
[-- Type: text/plain, Size: 1724 bytes --]
--- old/drivers/net/forcedeth.c 2007-10-23 16:47:08.000000000 -0400
+++ new/drivers/net/forcedeth.c 2007-10-23 16:47:11.000000000 -0400
@@ -5597,6 +5597,22 @@
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_31),
.driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
},
+ { /* MCP77 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_32),
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
+ { /* MCP77 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_33),
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
+ { /* MCP77 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_34),
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
+ { /* MCP77 Ethernet Controller */
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_35),
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA|DEV_HAS_MSI|DEV_HAS_POWER_CNTRL|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
+ },
{0,},
};
^ permalink raw reply
* [PATCH 1/2] forcedeth new device ids
From: Ayaz Abdulla @ 2007-10-23 21:08 UTC (permalink / raw)
To: Jeff Garzik, Andrew Morton, Manfred Spraul, nedev, stable
[-- Attachment #1: Type: text/plain, Size: 101 bytes --]
This patch adds new device ids for mcp77 devices.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
[-- Attachment #2: patch-device-ids-mcp77 --]
[-- Type: text/plain, Size: 657 bytes --]
--- old/include/linux/pci_ids.h 2007-10-23 16:49:46.000000000 -0400
+++ new/include/linux/pci_ids.h 2007-10-23 16:50:50.000000000 -0400
@@ -1236,6 +1236,10 @@
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP67_IDE 0x0560
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP73_IDE 0x056C
#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP77_IDE 0x0759
+#define PCI_DEVICE_ID_NVIDIA_NVENET_32 0x0760
+#define PCI_DEVICE_ID_NVIDIA_NVENET_33 0x0761
+#define PCI_DEVICE_ID_NVIDIA_NVENET_34 0x0762
+#define PCI_DEVICE_ID_NVIDIA_NVENET_35 0x0763
#define PCI_VENDOR_ID_IMS 0x10e0
#define PCI_DEVICE_ID_IMS_TT128 0x9128
^ permalink raw reply
* Re: [2.6 patch] make sunrpc/xprtsock.c:xs_setup_{udp,tcp}() static
From: Chuck Lever @ 2007-10-24 18:41 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Tom Talpey, Trond Myklebust, netdev, linux-kernel
In-Reply-To: <20071024162402.GB30533@stusta.de>
[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]
Adrian Bunk wrote:
> xs_setup_{udp,tcp}() can now become static.
ACK. Sorry this was overlooked.
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
>
> include/linux/sunrpc/xprtsock.h | 6 ------
> net/sunrpc/xprtsock.c | 4 ++--
> 2 files changed, 2 insertions(+), 8 deletions(-)
>
> 833a31c8caef70589f33be8e3a1fc9d8e01ce3c2
> diff --git a/include/linux/sunrpc/xprtsock.h b/include/linux/sunrpc/xprtsock.h
> index 2c6c2c2..c2a46c4 100644
> --- a/include/linux/sunrpc/xprtsock.h
> +++ b/include/linux/sunrpc/xprtsock.h
> @@ -9,12 +9,6 @@
>
> #ifdef __KERNEL__
>
> -/*
> - * Socket transport setup operations
> - */
> -struct rpc_xprt *xs_setup_udp(struct xprt_create *args);
> -struct rpc_xprt *xs_setup_tcp(struct xprt_create *args);
> -
> int init_socket_xprt(void);
> void cleanup_socket_xprt(void);
>
> diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
> index 02298f5..2f630a5 100644
> --- a/net/sunrpc/xprtsock.c
> +++ b/net/sunrpc/xprtsock.c
> @@ -1828,7 +1828,7 @@ static struct rpc_xprt *xs_setup_xprt(struct xprt_create *args,
> * @args: rpc transport creation arguments
> *
> */
> -struct rpc_xprt *xs_setup_udp(struct xprt_create *args)
> +static struct rpc_xprt *xs_setup_udp(struct xprt_create *args)
> {
> struct sockaddr *addr = args->dstaddr;
> struct rpc_xprt *xprt;
> @@ -1894,7 +1894,7 @@ struct rpc_xprt *xs_setup_udp(struct xprt_create *args)
> * @args: rpc transport creation arguments
> *
> */
> -struct rpc_xprt *xs_setup_tcp(struct xprt_create *args)
> +static struct rpc_xprt *xs_setup_tcp(struct xprt_create *args)
> {
> struct sockaddr *addr = args->dstaddr;
> struct rpc_xprt *xprt;
>
[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 327 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
email;internet:chuck dot lever at nospam oracle dot com
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* Re: [2.6 patch] unexport icmpmsg_statistics
From: David Stevens @ 2007-10-24 19:07 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel, netdev, netdev-owner
In-Reply-To: <20071024162410.GE30533@stusta.de>
netdev-owner@vger.kernel.org wrote on 10/24/2007 09:24:10 AM:
> This patch removes the unused EXPORT_SYMBOL(icmpmsg_statistics).
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
> 4ce74657ac0b1bdcb4c7bc359d05643f8cc4a08b
> diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> index 272c69e..233de06 100644
> --- a/net/ipv4/icmp.c
> +++ b/net/ipv4/icmp.c
> @@ -1104,5 +1104,4 @@ void __init icmp_init(struct net_proto_family
*ops)
> EXPORT_SYMBOL(icmp_err_convert);
> EXPORT_SYMBOL(icmp_send);
> EXPORT_SYMBOL(icmp_statistics);
> -EXPORT_SYMBOL(icmpmsg_statistics);
> EXPORT_SYMBOL(xrlim_allow);
"icmpmsg_statistics" belongs with (and replaces some of the
old...)
"icmp_statistics". I'm not sure that any modules use it, but I think you
should remove both or neither.
+-DLS
^ permalink raw reply
* Re: stateless 1:1 NAT
From: Florin Andrei @ 2007-10-24 19:12 UTC (permalink / raw)
To: netdev
In-Reply-To: <E1IhxQo-0004hF-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> Florin Andrei <florin@andrei.myip.org> wrote:
>> I've heard that stateless 1:1 NAT will be possible with the upcoming
>> 2.6.24 kernel.
>> I'd like to test that feature, but I'm not sure when it will actually be
>> included. Will it be present in the release candidates for 2.6.24?
>> I just need a somewhat stable kernel tree to play with.
>
> Yes it will be.
OK, if I download 2.6.24-rc1, will it have this feature already?
If not, when is it supposed to be included in the main kernel?
Thanks,
--
Florin Andrei
http://florin.myip.org/
^ permalink raw reply
* Re: [2.6 patch] unexport icmpmsg_statistics
From: Adrian Bunk @ 2007-10-24 19:14 UTC (permalink / raw)
To: David Stevens; +Cc: linux-kernel, netdev
In-Reply-To: <OFD68B1480.9D9C7453-ON8825737E.0068B005-8825737E.0068FB84@us.ibm.com>
On Wed, Oct 24, 2007 at 12:07:45PM -0700, David Stevens wrote:
> netdev-owner@vger.kernel.org wrote on 10/24/2007 09:24:10 AM:
>
> > This patch removes the unused EXPORT_SYMBOL(icmpmsg_statistics).
> >
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> >
> > ---
> > 4ce74657ac0b1bdcb4c7bc359d05643f8cc4a08b
> > diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> > index 272c69e..233de06 100644
> > --- a/net/ipv4/icmp.c
> > +++ b/net/ipv4/icmp.c
> > @@ -1104,5 +1104,4 @@ void __init icmp_init(struct net_proto_family
> *ops)
> > EXPORT_SYMBOL(icmp_err_convert);
> > EXPORT_SYMBOL(icmp_send);
> > EXPORT_SYMBOL(icmp_statistics);
> > -EXPORT_SYMBOL(icmpmsg_statistics);
> > EXPORT_SYMBOL(xrlim_allow);
>
> "icmpmsg_statistics" belongs with (and replaces some of the
> old...)
> "icmp_statistics". I'm not sure that any modules use it, but I think you
> should remove both or neither.
icmp_statistics is used by the dccp_ipv4 and sctp modules.
icmpmsg_statistics is not used by any modules.
> +-DLS
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 1/2] NFS: change the ip_map cache code to handle IPv6 addresses
From: Brian Haley @ 2007-10-24 19:22 UTC (permalink / raw)
To: Aurélien Charbon; +Cc: netdev ML, Mailing list NFSv4
In-Reply-To: <471C892F.3000206@ext.bull.net>
Hi Aurelien,
I think you're almost there, at least with my comments :)
> linux-2.6.23-ipmap/include/net/ipv6.h
> --- linux-2.6.23-haley/include/net/ipv6.h 2007-10-22
> 09:42:58.000000000 +0200
> +++ linux-2.6.23-ipmap/include/net/ipv6.h 2007-10-22
> 10:10:59.000000000 +0200
> @@ -21,6 +21,7 @@
> #include <net/ndisc.h>
> #include <net/flow.h>
> #include <net/snmp.h>
> +#include <linux/in.h>
>
> #define SIN6_LEN_RFC2133 24
>
> @@ -167,6 +168,12 @@ DECLARE_SNMP_STAT(struct udp_mib, udplit
> if (is_udplite) SNMP_INC_STATS_USER(udplite_stats_in6,
> field); \
> else SNMP_INC_STATS_USER(udp_stats_in6, field); } while(0)
>
> +#define IS_ADDR_MAPPED(a) \
> + (((uint32_t *) (a))[0] == 0 \
> + && ((uint32_t *) (a))[1] == 0 \
> + && (((uint32_t *) (a))[2] == 0 \
> + || ((uint32_t *) (a))[2] == htonl(0xffff)))
> +
> struct ip6_ra_chain
> {
> struct ip6_ra_chain *next;
> @@ -380,7 +387,7 @@ static inline int ipv6_addr_any(const st
> static inline int ipv6_addr_v4mapped(const struct in6_addr *a)
> {
> return ((a->s6_addr32[0] | a->s6_addr32[1]) == 0 &&
> - a->s6_addr32[2] == htonl(0x0000ffff));
> + a->s6_addr32[2] == htonl(0x0000ffff));
> }
You don't need to touch ipv6.h at all, IS_ADDR_MAPPED is unused and the
other is removing a space.
> static void ip_map_init(struct cache_head *cnew, struct cache_head *citem)
> {
> @@ -125,7 +133,7 @@ static void ip_map_init(struct cache_hea
> struct ip_map *item = container_of(citem, struct ip_map, h);
>
> strcpy(new->m_class, item->m_class);
> - new->m_addr.s_addr = item->m_addr.s_addr;
> + ipv6_addr_copy(&(new->m_addr), &(item->m_addr));
Extra () here.
> @@ -651,7 +694,7 @@ svcauth_unix_set_client(struct svc_rqst
> ipm = ip_map_cached_get(rqstp);
> if (ipm == NULL)
> ipm = ip_map_lookup(rqstp->rq_server->sv_program->pg_class,
> - sin->sin_addr);
> + &(sin6->sin6_addr));
Extra () here.
-Brian
^ permalink raw reply
* Re: [PATCH 2/2] NFS: handle IPv6 addresses in nfs ctl
From: Brian Haley @ 2007-10-24 19:22 UTC (permalink / raw)
To: Aurélien Charbon; +Cc: Mailing list NFSv4, netdev ML
In-Reply-To: <471C893F.6000306@ext.bull.net>
Hi Aurelien,
Again, a few more comments.
I might just modify these in my own tree and send out a patch that
combines both into one, it might be less work.
> @@ -229,9 +229,20 @@ static ssize_t write_getfs(struct file *
> return -EINVAL;
> data = (struct nfsctl_fsparm*)buf;
> err = -EPROTONOSUPPORT;
> - if (data->gd_addr.sa_family != AF_INET)
> + switch (data->gd_addr.sa_family) {
> + case AF_INET6:
> + sin6 = &sin6_storage;
This should be:
in6 = &sin6_storage;
> + sin6 = (struct sockaddr_in6 *)&data->gd_addr;
> + ipv6_addr_copy(&in6, &(sin6->sin6_addr));
Extra () here.
> - if (!(clp = auth_unix_lookup(in6)))
> + switch (data->gd_addr.sa_family) {
> + case AF_INET:
> + /* IPv6 address mapping */
> + ipv6_addr_set(&in6, 0, 0, htonl(0x0000FFFF), ((struct sockaddr_in *)&data->gd_addr)->sin_addr.s_addr);
> + break;
> + case AF_INET6:
> + sin6 = &sin6_storage;
This should be:
in6 = &sin6_storage;
> + sin6 = (struct sockaddr_in6 *)&data->gd_addr;
> + ipv6_addr_copy(&in6, &(sin6->sin6_addr));
Extra () here.
-Brian
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Valentine Barshak @ 2007-10-24 19:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, netdev, jwboyer, jeff, Stefan Roese
In-Reply-To: <1193196718.2085.35.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Tue, 2007-10-23 at 20:57 -0500, Valentine Barshak wrote:
>
>> +static int m88e1111_init(struct mii_phy *phy)
>> +{
>> + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
>> + phy_write(phy, 0x14, 0x0ce3);
>> + phy_write(phy, 0x18, 0x4101);
>> + phy_write(phy, 0x09, 0x0e00);
>> + phy_write(phy, 0x04, 0x01e1);
>> + phy_write(phy, 0x00, 0x9140);
>> + phy_write(phy, 0x00, 0x1140);
>> +
>> + return 0;
>> +}
>
> Care to put a few comments on why the above is necessary and what it
> does ?
I think this set's up Marvell ext control (0x14) and led control (0x18)
registers with some default values, Also sets some bits in the
CTRL1000, ADVERTISE and basic mode control registers and resets the phy
for the changes to take effect. Unfortunately, I don't have a detailed
88E1111 description and can't tell anything about it. Looks like the
code was originally ported from u-boot and is needed to init the phy :)
Stefan, do you have any info on this?
Thanks,
Valentine.
>
> Thanks !
> Ben.
>
>> +static struct mii_phy_ops m88e1111_phy_ops = {
>> + .init = m88e1111_init,
>> + .setup_aneg = genmii_setup_aneg,
>> + .setup_forced = genmii_setup_forced,
>> + .poll_link = genmii_poll_link,
>> + .read_link = genmii_read_link
>> +};
>> +
>> +static struct mii_phy_def m88e1111_phy_def = {
>> +
>> + .phy_id = 0x01410CC0,
>> + .phy_id_mask = 0x0ffffff0,
>> + .name = "Marvell 88E1111 Ethernet",
>> + .ops = &m88e1111_phy_ops,
>> +};
>> +
>> static struct mii_phy_def *mii_phy_table[] = {
>> &cis8201_phy_def,
>> + &bcm5248_phy_def,
>> + &m88e1111_phy_def,
>> &genmii_phy_def,
>> NULL
>> };
>
^ permalink raw reply
* Re: [2.6 patch] unexport icmpmsg_statistics
From: David Stevens @ 2007-10-24 19:29 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-kernel, netdev, netdev-owner
In-Reply-To: <20071024191437.GF30533@stusta.de>
netdev-owner@vger.kernel.org wrote on 10/24/2007 12:14:37 PM:
> On Wed, Oct 24, 2007 at 12:07:45PM -0700, David Stevens wrote:
> > netdev-owner@vger.kernel.org wrote on 10/24/2007 09:24:10 AM:
> >
> > > This patch removes the unused EXPORT_SYMBOL(icmpmsg_statistics).
> > >
> > > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > >
> > > ---
> > > 4ce74657ac0b1bdcb4c7bc359d05643f8cc4a08b
> > > diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> > > index 272c69e..233de06 100644
> > > --- a/net/ipv4/icmp.c
> > > +++ b/net/ipv4/icmp.c
> > > @@ -1104,5 +1104,4 @@ void __init icmp_init(struct net_proto_family
> > *ops)
> > > EXPORT_SYMBOL(icmp_err_convert);
> > > EXPORT_SYMBOL(icmp_send);
> > > EXPORT_SYMBOL(icmp_statistics);
> > > -EXPORT_SYMBOL(icmpmsg_statistics);
> > > EXPORT_SYMBOL(xrlim_allow);
> >
> > "icmpmsg_statistics" belongs with (and replaces some of the
> > old...)
> > "icmp_statistics". I'm not sure that any modules use it, but I think
you
> > should remove both or neither.
>
> icmp_statistics is used by the dccp_ipv4 and sctp modules.
The only items left in icmp_statistics are "InMsgs, InErrs,
OutMsgs, OutErrs",
so if dccp and sctp are sending or receiving any in or out ICMP messages,
they
should be using the new macros (which reference icmpmsg_statistics, not
icmp_statistics) to count them.
I took a quick look at SCTP. I don't know if that's going through
icmp_rcv()
or not; if so, I think it's double-counting; if not, then it isn't
counting the
individual types (as it should), and it should have ICMPMSG macros doing
that.
So, again, icmpmsg_statistics either should stay exported, or
neither
icmpmsg_statistics nor icmp_statistics should be exported (depending on
how
SCTP and DCCP code is resolved). It's incorrect in the current code to
incrememnt ICMP_MIB_INMSGS without incrementing one of the types too.
+-DLS
^ permalink raw reply
* Re: [2.6 patch] unexport icmpmsg_statistics
From: David Stevens @ 2007-10-24 20:11 UTC (permalink / raw)
To: David Stevens; +Cc: Adrian Bunk, linux-kernel, netdev, netdev-owner
In-Reply-To: <OF621D1730.3D3366AC-ON8825737E.0069CDD5-8825737E.006AEDF9@us.ibm.com>
I took a look at the DCCP references, and I think they're just
incrementing the wrong MIB variable -- e.g., it's incrementing
ICMP_MIB_INERRORS when the skb length is less than the
header indicates. That's not an ICMP_MIB_INERRORS error,
that's an IPSTATS_MIB_INHDRERRORS error. ICMP_MIB_INERRORS
is when you receive an ICMP error packet; an IP header error
is something else entirely.
That's followed by a failed lookup incrementing ICMP_MIB_INERRORS
which should be an unknown port error in the transport MIB (assuming
it has one-- it's not an ICMP error; could be an IP error, if the address
isn't local, rather than unknown port).
In SCTP, it appears to have similar problems. SCTP errors are not
ICMP errors, though it perhaps should be calling icmp_send() to
send one to the offending host for some of the cases.
I haven't seen any ICMP-relevant stats correctly referenced in
these yet.
I don't want to patch them directly, since I can't easily test them;
if someone who works with DCCP and SCTP would like to, I'd
be happy to review. Any volunteers?
+-DLS
^ permalink raw reply
* Re: [2.6 patch] unexport icmpmsg_statistics
From: Vlad Yasevich @ 2007-10-24 20:24 UTC (permalink / raw)
To: David Stevens; +Cc: Adrian Bunk, linux-kernel, netdev, netdev-owner
In-Reply-To: <OF4D25AE59.ADF06793-ON8825737E.006DD213-8825737E.006EC6C3@us.ibm.com>
David Stevens wrote:
> I took a look at the DCCP references, and I think they're just
> incrementing the wrong MIB variable -- e.g., it's incrementing
> ICMP_MIB_INERRORS when the skb length is less than the
> header indicates. That's not an ICMP_MIB_INERRORS error,
> that's an IPSTATS_MIB_INHDRERRORS error. ICMP_MIB_INERRORS
> is when you receive an ICMP error packet; an IP header error
> is something else entirely.
>
> That's followed by a failed lookup incrementing ICMP_MIB_INERRORS
> which should be an unknown port error in the transport MIB (assuming
> it has one-- it's not an ICMP error; could be an IP error, if the address
> isn't local, rather than unknown port).
>
> In SCTP, it appears to have similar problems. SCTP errors are not
> ICMP errors, though it perhaps should be calling icmp_send() to
> send one to the offending host for some of the cases.
>
> I haven't seen any ICMP-relevant stats correctly referenced in
> these yet.
>
> I don't want to patch them directly, since I can't easily test them;
> if someone who works with DCCP and SCTP would like to, I'd
> be happy to review. Any volunteers?
I'll take a look at the SCTP ones. Thanks for review.
-vlad
>
> +-DLS
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [2.6 patch] net/sctp/auth.c: make 3 functions static
From: Vlad Yasevich @ 2007-10-24 20:27 UTC (permalink / raw)
To: Adrian Bunk; +Cc: sri, lksctp-developers, linux-kernel, netdev
In-Reply-To: <20071024162428.GJ30533@stusta.de>
Adrian Bunk wrote:
> This patch makes three needlessly global functions static.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
ACK. Thanks for catching these..
-vlad
^ permalink raw reply
* Re: [2.6 patch] #if 0 sctp_update_copy_cksum()
From: Vlad Yasevich @ 2007-10-24 20:30 UTC (permalink / raw)
To: Adrian Bunk; +Cc: sri, lksctp-developers, linux-kernel, netdev
In-Reply-To: <20071024162407.GD30533@stusta.de>
Adrian Bunk wrote:
> sctp_update_copy_cksum() is no longer used.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
ACK.
-vlad
>
> ---
>
> include/net/sctp/sctp.h | 1 -
> net/sctp/crc32c.c | 2 ++
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> fc6646f84c07666228166c678ff2b5916db925ed
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 119f5a1..93eb708 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -156,7 +156,6 @@ int sctp_primitive_ASCONF(struct sctp_association *, void *arg);
> __u32 sctp_start_cksum(__u8 *ptr, __u16 count);
> __u32 sctp_update_cksum(__u8 *ptr, __u16 count, __u32 cksum);
> __u32 sctp_end_cksum(__u32 cksum);
> -__u32 sctp_update_copy_cksum(__u8 *, __u8 *, __u16 count, __u32 cksum);
>
> /*
> * sctp/input.c
> diff --git a/net/sctp/crc32c.c b/net/sctp/crc32c.c
> index 59cf7b0..181edab 100644
> --- a/net/sctp/crc32c.c
> +++ b/net/sctp/crc32c.c
> @@ -170,6 +170,7 @@ __u32 sctp_update_cksum(__u8 *buffer, __u16 length, __u32 crc32)
> return crc32;
> }
>
> +#if 0
> __u32 sctp_update_copy_cksum(__u8 *to, __u8 *from, __u16 length, __u32 crc32)
> {
> __u32 i;
> @@ -186,6 +187,7 @@ __u32 sctp_update_copy_cksum(__u8 *to, __u8 *from, __u16 length, __u32 crc32)
>
> return crc32;
> }
> +#endif /* 0 */
>
> __u32 sctp_end_cksum(__u32 crc32)
> {
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [2.6 patch] unexport icmpmsg_statistics
From: David Stevens @ 2007-10-24 20:43 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Adrian Bunk, linux-kernel, netdev, netdev-owner
In-Reply-To: <471FAA03.9090003@hp.com>
My bad -- I see what it's doing, and it looks ok after all.
I thought I saw an INMSGS (but didn't). These are ICMP errors that
went through icmp_rcv() and were counted correctly before getting
to the protocol error handlers. These are failures due mostly to not
having enough, or the right protocol info in the error packet being
handled. I'm not sure I'd count those as ICMP errors, since the
ICMP header itself is correct, but ok...
SCTP doesn't look so bad, though I think the references are
still questionable (but debatable) as ICMP errors.
sctp_v4_err is incrementing ICMP_MIB_INERRORS if there
isn't enough IP header to find the ports, I see. I'm not sure
that counts as an ICMP error, but it's not so terrible.
It's doing the same thing if a lookup fails to match "vtag" from
the encapsulated error packet. Again, I don't know that those
are ICMP errors (which normally are something wrong with
the ICMP header).
So, I stand corrected, and sorry about the histrionics. Since
these are arguably ICMP errors, and since errors is the only
thing being MIB-counted in DCCP and SCTP, then it now looks
ok to me as-is, and also ok to remove icmpmsg_statistics from
exporting.
+-DLS
^ permalink raw reply
* Re: [2.6 patch] unexport icmpmsg_statistics
From: Vlad Yasevich @ 2007-10-24 20:52 UTC (permalink / raw)
To: David Stevens; +Cc: Adrian Bunk, linux-kernel, netdev, netdev-owner
In-Reply-To: <OF4D25AE59.ADF06793-ON8825737E.006DD213-8825737E.006EC6C3@us.ibm.com>
David Stevens wrote:
> I took a look at the DCCP references, and I think they're just
> incrementing the wrong MIB variable -- e.g., it's incrementing
> ICMP_MIB_INERRORS when the skb length is less than the
> header indicates. That's not an ICMP_MIB_INERRORS error,
> that's an IPSTATS_MIB_INHDRERRORS error. ICMP_MIB_INERRORS
> is when you receive an ICMP error packet; an IP header error
> is something else entirely.
Looking at icmp_rcv(), ICMP_MIB_INERRORS is incremented if:
a) checksum fails
b) no enough room in skb for icmp header
c) type out of bound
and other error conditions while processing ICMP packet.
Are all of these wrong as well?
There are other places that increment this statistic for errors
during processing.
>
> That's followed by a failed lookup incrementing ICMP_MIB_INERRORS
> which should be an unknown port error in the transport MIB (assuming
> it has one-- it's not an ICMP error; could be an IP error, if the address
> isn't local, rather than unknown port).
>
> In SCTP, it appears to have similar problems. SCTP errors are not
> ICMP errors, though it perhaps should be calling icmp_send() to
> send one to the offending host for some of the cases.
I'll skip the insufficient buffer space statistic yet, since, per above,
it's not clear which one should be used.
Others, I agree are move ULP errors, but the mibs don't account for those
yet.
-vlad
^ permalink raw reply
* Re: [2.6 patch] unexport icmpmsg_statistics
From: Vlad Yasevich @ 2007-10-24 20:54 UTC (permalink / raw)
To: David Stevens; +Cc: Adrian Bunk, linux-kernel, netdev, netdev-owner
In-Reply-To: <OF03E20988.736A2E51-ON8825737E.007067FE-8825737E.0071B902@us.ibm.com>
David Stevens wrote:
> My bad -- I see what it's doing, and it looks ok after all.
>
jinx, crossed in flight. ;)
^ permalink raw reply
* Re: [2.6 patch] unexport icmpmsg_statistics
From: Vlad Yasevich @ 2007-10-24 21:00 UTC (permalink / raw)
To: David Stevens; +Cc: Adrian Bunk, linux-kernel, netdev, netdev-owner
In-Reply-To: <OF03E20988.736A2E51-ON8825737E.007067FE-8825737E.0071B902@us.ibm.com>
David Stevens wrote:
> My bad -- I see what it's doing, and it looks ok after all.
>
> I thought I saw an INMSGS (but didn't). These are ICMP errors that
> went through icmp_rcv() and were counted correctly before getting
> to the protocol error handlers. These are failures due mostly to not
> having enough, or the right protocol info in the error packet being
> handled. I'm not sure I'd count those as ICMP errors, since the
> ICMP header itself is correct, but ok...
>
> SCTP doesn't look so bad, though I think the references are
> still questionable (but debatable) as ICMP errors.
>
> sctp_v4_err is incrementing ICMP_MIB_INERRORS if there
> isn't enough IP header to find the ports, I see. I'm not sure
> that counts as an ICMP error, but it's not so terrible.
>
> It's doing the same thing if a lookup fails to match "vtag" from
> the encapsulated error packet. Again, I don't know that those
> are ICMP errors (which normally are something wrong with
> the ICMP header).
This particular case is the one that bugs the most, but that
error matches best.
Seems like all ULPs treat socket lookup error as ICMP_MIB_INERRORS
(tcp, udp, sctp, dccp).
SCTP is a little special in that in needs to check one one piece
of data (the 'vtag') to correctly identify the connection.
If that piece doesn't match, we treat that as the same error.
-vlad
^ permalink raw reply
* Re: [2.6 patch] make tcp_match_skb_to_sack() static
From: Ilpo Järvinen @ 2007-10-24 21:39 UTC (permalink / raw)
To: Adrian Bunk, David Miller; +Cc: LKML, Netdev
In-Reply-To: <20071024162358.GA30533@stusta.de>
On Wed, 24 Oct 2007, Adrian Bunk wrote:
> tcp_match_skb_to_sack() can become static.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
[...snip...]
Thanks, I should have noticed that right from the beginning...
Added DaveM to recipients.
--
i.
^ permalink raw reply
* Re: [PATCH 13/13] r8169: more phy init for the 8168
From: Francois Romieu @ 2007-10-24 22:14 UTC (permalink / raw)
To: Glen Gray; +Cc: jgarzik, netdev, Edward Hsu
In-Reply-To: <471F1067.50403@lincor.com>
Glen Gray <glen.gray@lincor.com> :
> Are any of these likely to fix the Ethernet multicast issues a few of us
> have seen with 8110sc cards ?
No, this serie is not expected to.
I have planned to work on it again during the bugfix phase of 2.6.24-rc.
Is it still an option for you to use the old realtek driver + bandaid
(no pun) in the meantime ?
--
Ueimor
^ permalink raw reply
* Re: [2.6 patch] bonding/bond_main.c: fix cut'n'paste error
From: Jay Vosburgh @ 2007-10-24 22:51 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andy Gospodarek, Jeff Garzik, netdev, linux-kernel
In-Reply-To: <20071024162743.GV30533@stusta.de>
Adrian Bunk <bunk@kernel.org> wrote:
>This patch fixes a cut'n'paste error in
>commit 1b76b31693d4a6088dec104ff6a6ead54081a3c2.
>
>Signed-off-by: Adrian Bunk <bunk@kernel.org>
Please apply.
-J
Acked-by: Jay Vosburgh <fubar@us.ibm.com>
>---
>4888742f8d7fe3b97fbc2911aa46375048173d01
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index e5fab4b..6937ef0 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -3682,7 +3682,7 @@ static int bond_open(struct net_device *bond_dev)
> }
>
> if (bond->params.mode == BOND_MODE_8023AD) {
>- INIT_DELAYED_WORK(&bond->ad_work, bond_alb_monitor);
>+ INIT_DELAYED_WORK(&bond->ad_work, bond_3ad_state_machine_handler);
> queue_delayed_work(bond->wq, &bond->ad_work, 0);
> /* register to receive LACPDUs */
> bond_register_lacpdu(bond);
>
^ permalink raw reply
* Re: [PATCH 1/3] [IPSEC]: Forbid BEET + ipcomp for now
From: Herbert Xu @ 2007-10-25 1:06 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: David S. Miller, YOSHIFUJI Hideaki, Joakim Koskela, netdev
In-Reply-To: <471F67AE.5010301@6wind.com>
On Wed, Oct 24, 2007 at 05:41:34PM +0200, Nicolas Dichtel wrote:
>
> >+ x->props.header_len = 0;
> >+ switch (x->props.mode) {
> >+ case XFRM_MODE_TRANSPORT:
> >+ break;
> >+ case XFRM_MODE_TUNNEL:
> >+ x->props.header_len += sizeof(struct iphdr);
> I think, the break statement is missing, is it ?
Indeed it is. I'm going to fix this and repost all 3 patches.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: stateless 1:1 NAT
From: Herbert Xu @ 2007-10-25 1:54 UTC (permalink / raw)
To: netdev; +Cc: netdev
In-Reply-To: <471F9916.1090404@andrei.myip.org>
Florin Andrei <florin@andrei.myip.org> wrote:
>
> OK, if I download 2.6.24-rc1, will it have this feature already?
Yes.
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
* [PATCH] napi: use non-interruptible sleep in napi_disable
From: Benjamin Herrenschmidt @ 2007-10-25 3:59 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
The current napi_disable() uses msleep_interruptible() but doesn't
(and can't) exit in case there's a signal, thus ending up doing a
hot spin without a cpu_relax. Use uninterruptible sleep instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
include/linux/netdevice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-work/include/linux/netdevice.h
===================================================================
--- linux-work.orig/include/linux/netdevice.h 2007-10-17 12:39:16.000000000 +1000
+++ linux-work/include/linux/netdevice.h 2007-10-17 12:45:00.000000000 +1000
@@ -390,7 +390,7 @@ static inline void napi_complete(struct
static inline void napi_disable(struct napi_struct *n)
{
while (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
- msleep_interruptible(1);
+ msleep(1);
}
/**
^ 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