Hi, I recently discovered the ioctl implementation in natsemi.c had a few bugs in dealing with the user ioctls to send and receive MII commands (SIOCGMIIPHY and SIOCSMIIPHY). The specific problems noted and fixed: 1. The if_mii macro casts it's return to be (struct mii_ioctl_data *) but in reality it returns a pointer to the user space pointer (struct mii_ioctl_data**). This looks to be a problem with the mii_macro to me. I changed this to use the ifr_data macro instead. 2. Since the mii_ioc...

-------------------------------------------------- From: "Jarek Poplawski" <jarkao2@gmail.com> Sent: Friday, May 16, 2008 4:16 AM To: "Patrick McHardy" <kaber@trash.net> Cc: "Kingsley Foreman" <kingsley@internode.com.au>; "Eric Dumazet" <dada1@cosmosbay.com>; "Andrew Morton" <akpm@linux-foundation.org>; <linux-kernel@vger.kernel.org>; <netdev@vger.kernel.org> running tc qdisc add dev bond0 root pfifo limit 1000 or tc qdisc add dev bond0 root ...

On Thu, 15 May 2008 23:26:22 +0200 good catch! Acked-by: Arjan van de Ven <arjan@linux.intel.com> --

From: William Seppeler <wrs@pt.com> Date: Thu, 15 May 2008 15:21:14 -0400 You'll get a lot more feedback from the networking developers if you actually send it to the list they subscribe to. --

When setting arp_interval parameter to a very low value, delta_in_ticks for next arp might become 0, causing an infinite loop. See http://bugzilla.kernel.org/show_bug.cgi?id=10680 Same problem for miimon parameter already fixed, but fix might be enhanced, by using msecs_to_jiffies() function. Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr> --- /usr/src/linux/drivers/net/bonding/bond_main_orig.c 2008-05-13 02:00:01.000000000 +0200 +++ /usr/src/linux/drivers/net/bondin...

Hi. Usual non-subscriber CC replies request please. There is a problem with 2.6.25(.4) using IPSEC on ipv4. You seem to need to have ipv6 available otherwise a protocol not supported error is returned when trying to set a Security Association Database. I'm using setkey on a file but another user on the ipsec-tools-devel list reported the same issue using racoon. http://marc.info/?l=ipsec-tools-devel&m=121015164014761&w=2 So with modules loaded you expect to work. $ lsmod Module...

Bad type/protocol specified result in sk leak. Fix is simple - release the sk if bad values are given, but to make it possible just to call sk_free(), I move some sk initialization a bit lower. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- diff --git a/net/irda/af_irda.c b/net/irda/af_irda.c index ae54b20..3eb5bcc 100644 --- a/net/irda/af_irda.c +++ b/net/irda/af_irda.c @@ -1093,11 +1093,6 @@ static int irda_create(struct net *net, struct socket *sock, int protocol) ini...

On Thu, 15 May 2008 19:49:27 +0200 The underlying reason for this is the Linux kernel developers hatred of abstraction layers is long term maintenance. Once a driver is accepted into the mainline, the kernel developers may have to do maintenance on the driver to fix API's or if the original hardware vendor abandons it. All the abstraction layer just makes this harder. Some drivers do have some OS independent portions but they are rare, and usually abstract the hardware not the device model. --

Hello Anton, You do not need to wrap this function into the ifdef, since setting the poll callback is between ifdef. Otherwise patch looks good. -- Cordialement, Florian Fainelli ------------------------------ --

Don't we need the same type of fix applied to rtl8187_iowrite_async as well? Would you like to resubmit (or submit a second patch) with that fix included? Also, a nit: I would prefer "rc" instead of "rv" just for idiomatic purposes. John -- John W. Linville linville@tuxdriver.com --

Hi, I managed to panic two local net-2.6 UML instances right after another by sending possibly bad IPv6 UDP packets to them. A couple of points to note: - tcpdump was running in promiscuous mode on the crashed hosts at the time - "nc6 -u -l -p 80" was running on the crashed hosts and the packets were addressed to this port - the address used to receive the packets was not a valid IPv6 unicast address, it was 1::1 on dummy0 - no iptables rules I sadly couldn't reproduce the problem after rebo...

If you were to start with the original file, does the following patch fix the problem? diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c index 07b3f77..4c248d7 100644 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -3168,8 +3168,7 @@ static int tg3_setup_fiber_mii_phy(struct tg3 *tp, int force_reset) err |= tg3_readphy(tp, MII_BMCR, &bmcr); if ((tp->link_config.autoneg == AUTONEG_ENABLE) && !force_reset && - (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT...

Are you using eth0 or eth1? The dmesg below shows that If you're using eth0 and link did not come up, please provide mii-tool -vvv eth0. Thanks. --

In that case, please re-apply the patch and provide mii-tool -vvv eth1. --

That might explain things, although it shouldn't have worked before either. CBQ creates default pfifo qdiscs for its leaves, these use a limit of txqueuelen or 1 if it is zero. So even small bursts will cause drops. Do things improve if you set txqueuelen to a larger value *before* configuring the qdiscs? Another thing is that CBQ on bond will probably not work properly at all, it needs a real device since it measures the timing between dequeue events for idle time estimation. On software devi...

Yes, CBQ uses pfifo, not pfifo_fast. pfifo uses txqueuelen to inialize q->limit, but thats whats used during ->enqueue(). --

Kingsley wrote to me that even after changing txqueuelen to 1000 the "dropped" number didn't change much. A debugging patch with printks around all "sch->qstats.dropps++" showed only the end of cbq_enqueue(). Right, but these drops without any sign of overactions or overlimits seem to show it's not about shaping (or it's not counted/documented enough). Regards, Jarek P. --

Did you also update iproute when moving to a newer kernel? --

Signed-off-by: Subbu Seetharaman <subbus@serverengines.com> --- MAINTAINERS | 7 +++++++ drivers/net/Kconfig | 17 +++++++++++++++++ drivers/net/Makefile | 1 + 3 files changed, 25 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index bc1c008..95de067 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3593,6 +3593,13 @@ L: linux-ide@vger.kernel.org T: git kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git S: Supported +SERVER ENGINES 1...

Signed-off-by: Subbu Seetharaman <subbus@serverengines.com> --- drivers/message/beclib/fw/bmap/be_common_bmap.h | 99 +++ drivers/message/beclib/fw/bmap/ioctl_common_bmap.h | 921 ++++++++++++++++++++ drivers/message/beclib/fw/bmap/ioctl_hdr_bmap.h | 68 ++ drivers/message/beclib/fw/bmap/ioctl_types_bmap.h | 43 + 4 files changed, 1131 insertions(+), 0 deletions(-) create mode 100644 drivers/message/beclib/fw/bmap/be_common_bmap.h create mode 100644 drivers/message/beclib/fw/b...

On Thu, 15 May 2008 02:46:14 -0700 No, a large device specific management interface using ioctl's (with no documentation) is not going to be accepted. --

Signed-off-by: Subbu Seetharaman <subbus@serverengines.com> --- drivers/message/beclib/fw/amap/asyncmesg.h | 98 ++++++++++ drivers/message/beclib/fw/amap/be_cm.h | 148 +++++++++++++++ drivers/message/beclib/fw/amap/be_common.h | 67 +++++++ drivers/message/beclib/fw/amap/cev.h | 261 ++++++++++++++++++++++++++ drivers/message/beclib/fw/amap/descriptors.h | 85 +++++++++ drivers/message/beclib/fw/amap/doorbells.h | 193 +++++++++++++++++++ drivers/message/beclib/...

Sorry, pretty much this complete file has to go and the callers be fixed to use the native Linux functions directly. Some of it was even wrong, like it's not legal to cast atomic_t like you did. Also a lot of facilities you reimplement here exist already in Linux Hmm was i even allowed to read it? -Andi --

Allow longer lifetimes (>= 0x7fffffff/HZ) on 64bit archs by using unsigned long. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> --- net/ipv6/addrconf.c | 22 +++++++++++++++++++--- net/ipv6/route.c | 4 +++- 2 files changed, 22 insertions(+), 4 deletions(-) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 3a78021..0d89370 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -731,8 +731,11 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp)...

We could not see appropriate lifetime if the route had been scheduled to expired at 0 (in jiffies). We should check rt6i_flags instead of rt6i_expires to determine whether lifetime is valid or not. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> --- net/ipv6/route.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 98aa50c..b45a7c0 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -2200,7 +2200,9 @@ st...