* [2.6 patch] let USB_USBNET always select MII
From: Adrian Bunk @ 2007-11-01 22:25 UTC (permalink / raw)
To: Toralf Förster, dbrownell, jgarzik; +Cc: linux-kernel, netdev
In-Reply-To: <200711012024.57412.toralf.foerster@gmx.de>
All this USB_USBNET_MII trickery is simply not worth it considering how
few code it saves.
As a side effect, this also fixes the following compile error reported
by Toralf Förster:
<-- snip -->
...
LD .tmp_vmlinux1
drivers/built-in.o: In function `usbnet_set_settings':
(.text+0xf1876): undefined reference to `mii_ethtool_sset'
drivers/built-in.o: In function `usbnet_get_settings':
(.text+0xf1836): undefined reference to `mii_ethtool_gset'
drivers/built-in.o: In function `usbnet_get_link':
(.text+0xf18d6): undefined reference to `mii_link_ok'
drivers/built-in.o: In function `usbnet_nway_reset':
(.text+0xf18f6): undefined reference to `mii_nway_restart'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
drivers/net/usb/Kconfig | 9 +--------
drivers/net/usb/usbnet.c | 7 -------
2 files changed, 1 insertion(+), 15 deletions(-)
3b7f6290c639b9042fead1698fdbe1c84132c953
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 5a96d74..a12c9c4 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -93,13 +93,9 @@ config USB_RTL8150
To compile this driver as a module, choose M here: the
module will be called rtl8150.
-config USB_USBNET_MII
- tristate
- default n
-
config USB_USBNET
tristate "Multi-purpose USB Networking Framework"
- select MII if USB_USBNET_MII != n
+ select MII
---help---
This driver supports several kinds of network links over USB,
with "minidrivers" built around a common network driver core
@@ -135,7 +131,6 @@ config USB_NET_AX8817X
tristate "ASIX AX88xxx Based USB 2.0 Ethernet Adapters"
depends on USB_USBNET && NET_ETHERNET
select CRC32
- select USB_USBNET_MII
default y
help
This option adds support for ASIX AX88xxx based USB 2.0
@@ -190,7 +185,6 @@ config USB_NET_DM9601
tristate "Davicom DM9601 based USB 1.1 10/100 ethernet devices"
depends on USB_USBNET
select CRC32
- select USB_USBNET_MII
help
This option adds support for Davicom DM9601 based USB 1.1
10/100 Ethernet adapters.
@@ -225,7 +219,6 @@ config USB_NET_PLUSB
config USB_NET_MCS7830
tristate "MosChip MCS7830 based Ethernet adapters"
depends on USB_USBNET
- select USB_USBNET_MII
help
Choose this option if you're using a 10/100 Ethernet USB2
adapter based on the MosChip 7830 controller. This includes
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index acd5f1c..8ed1fc5 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -683,9 +683,6 @@ done_nopm:
* they'll probably want to use this base set.
*/
-#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
-#define HAVE_MII
-
int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
{
struct usbnet *dev = netdev_priv(net);
@@ -744,8 +741,6 @@ int usbnet_nway_reset(struct net_device *net)
}
EXPORT_SYMBOL_GPL(usbnet_nway_reset);
-#endif /* HAVE_MII */
-
void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
{
struct usbnet *dev = netdev_priv(net);
@@ -776,12 +771,10 @@ EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
/* drivers may override default ethtool_ops in their bind() routine */
static struct ethtool_ops usbnet_ethtool_ops = {
-#ifdef HAVE_MII
.get_settings = usbnet_get_settings,
.set_settings = usbnet_set_settings,
.get_link = usbnet_get_link,
.nway_reset = usbnet_nway_reset,
-#endif
.get_drvinfo = usbnet_get_drvinfo,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
^ permalink raw reply related
* Re: [Bugme-new] [Bug 9270] New: sunhme requires lower MTU to handle 802.1q frames
From: Chris Poon @ 2007-11-01 20:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, netdev, bugme-daemon, jeff
In-Reply-To: <20071101121239.d0e67bd3.akpm@linux-foundation.org>
Forgot to add that only changing BMAC_TXMAX & BMAC_RXMAX wouldn't work
for me, until I changed 2 skb_put as well (which is in the patch that
I submitted in bugzilla). Dug up some really old threads on the net
and found out that this was reported before
Quoting Andrew Morton <akpm@linux-foundation.org>:
> On Wed, 31 Oct 2007 16:35:57 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
> > From: Andrew Morton <akpm@linux-foundation.org>
> > Date: Wed, 31 Oct 2007 15:43:01 -0700
> >
> > > > sunhme requires lower MTU to handle 802.1q frames - even though the
> PCI
> > > > driver supported VLAN tagging, you cannot do full MTU @ 1500 because
> the
> > > > driver doesn't set the card to transfer more the extra bytes for a
> 802.1q
> > > > frame at 1500 MTU.
> >
> > It supports VLAN tagging by accident, the NETIF_F_VLAN_CHALLENGED
> > flag should be set both in the PCI and non-PCI cases.
> >
> > Jeff, please apply, thanks:
> >
> > [SUNHME]: Fix missing NETIF_F_VLAN_CHALLENGED on PCI happy meals.
> >
> > No HME parts can do VLANs correctly.
> >
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > diff --git a/drivers/net/sunhme.c b/drivers/net/sunhme.c
> > index 120c8af..c20a3bd 100644
> > --- a/drivers/net/sunhme.c
> > +++ b/drivers/net/sunhme.c
> > @@ -3143,8 +3143,8 @@ static int __devinit happy_meal_pci_probe(struct
> pci_dev *pdev,
> > dev->irq = pdev->irq;
> > dev->dma = 0;
> >
> > - /* Happy Meal can do it all... */
> > - dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM;
> > + /* Happy Meal can do it all... except VLAN. */
> > + dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_VLAN_CHALLENGED;
> >
> > #if defined(CONFIG_SBUS) && defined(CONFIG_PCI)
> > /* Hook up PCI register/dma accessors. */
>
> I forgot to add my standard "please reply via emailed reply-to-all, not via
> the bugzilla web interface", so Chris has gone and attempted to communicate
> with us via the bugzilla UI (sigh).
>
> He asked
>
> "Even though it appears to work after I bumped the BMAC_TXMAX / BMAC_RXMAX?"
>
>
>
^ permalink raw reply
* Re: expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?
From: Rick Jones @ 2007-11-01 23:26 UTC (permalink / raw)
To: David Miller
Cc: djohnson+linux-kernel, greearb, shemminger, linux-kernel, netdev,
bguo
In-Reply-To: <20071101.150723.30590053.davem@davemloft.net>
David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
>>I'll try to go pester folks in tcpdump-workers then.
>
>
> The thing to check is "TP_STATUS_CSUMNOTREADY".
>
> When using mmap(), it will be provided in the descriptor. When using
> recvmsg() it will be provided via a PACKET_AUXDATA control message
> when enabled via the PACKET_AUXDATA socket option.
Figures... the "dailies" and "weeklies" for tar files of tcpdump and libpcap
source are fubar... again. I've email in to tcpdump-workers on that one. If
that isn't resolved quickly I'll learn how to access their CVS (pick an SCM, any
SCM...)
I did an apt-get of debian lenny's tcpdump and sources:
hpcpc103:~# tcpdump -V
tcpdump version 3.9.8
libpcap version 0.9.8
and that seems to show the false checksum failure and not use the
TP_STATUS_CSUMNOTREADY - at least that didn't appear in a grepping of the
sources. At first I thought it might be, but then I realized that my snaplen
was too short to get the whole TSO'ed frame so tcpdump wasn't even trying to
verify. After disabling TSO on the NIC, leaving CKO on, and making my snaplen >
1500 I could see it was doing undesirable stuff.
I'll see what top of trunk has at some point and what the folks there think of
adding-in a change.
rick jones
^ permalink raw reply
* Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':
From: David Brownell @ 2007-11-01 23:32 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Toralf Förster, linux-kernel, netdev
In-Reply-To: <20071101141124.0cbe2897.randy.dunlap@oracle.com>
On Thursday 01 November 2007, Randy Dunlap wrote:
> The MII functions aren't available unless NET_ETHERNET=y.
> Howver, the MII functions aren't always needed...
>
> David, any ideas on this one?
It's been several years since I looked at this. It
used to behave just fine.
Something must have changed in the not-too-distant
past to have broken this mechanism...
> config USB_USBNET
> tristate "Multi-purpose USB Networking Framework"
> + depends on NET_ETHERNET if USB_USBNET_MII != n
> select MII if USB_USBNET_MII != n
>
> would be handy. But invalid.
>
> Hm, wait. Haven't we seen this before and decided that MII should
> be made more generally available? I.e., not depend on NET_ETHERNET?
Some of us keep wanting to see "select" work properly,
not omitting dependencies...
Re interdependencies MII and NET_ETHERNET, I'll leave
that up to the netedev folk.
- Dave
^ permalink raw reply
* Re: [patch 2/2] ipvs: Syncrhonise Closing of Connections
From: Julian Anastasov @ 2007-11-01 23:36 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, Wensong Zhang, Rumen G. Bogdanovski,
Graeme Fowler, Joseph Mack NA3T, David S. Miller
In-Reply-To: <20071101093022.688977274@vergenet.net>
Hello,
On Thu, 1 Nov 2007, Simon Horman wrote:
> --- net-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c 2007-11-01 18:17:55.000000000 +0900
> +++ net-2.6/net/ipv4/ipvs/ip_vs_sync.c 2007-11-01 18:20:30.000000000 +0900
> @@ -332,7 +332,7 @@ static void ip_vs_process_message(const
> s->daddr, s->dport,
> flags, dest);
> if (dest)
Is that correct? Sorry, I was flooded with different versions
of this patch and I'm not sure if it is the final one.
> - atomic_dec(&dest->refcnt);
> + ip_vs_dest_get(dest);
> if (!cp) {
> IP_VS_ERR("ip_vs_conn_new failed\n");
> return;
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':
From: Adrian Bunk @ 2007-11-01 23:44 UTC (permalink / raw)
To: David Brownell; +Cc: Randy Dunlap, Toralf Förster, linux-kernel, netdev
In-Reply-To: <200711011632.18333.david-b@pacbell.net>
On Thu, Nov 01, 2007 at 04:32:18PM -0700, David Brownell wrote:
> On Thursday 01 November 2007, Randy Dunlap wrote:
> > The MII functions aren't available unless NET_ETHERNET=y.
The setting of CONFIG_NET_ETHERNET doesn't matter for this bug.
> > Howver, the MII functions aren't always needed...
> >
> > David, any ideas on this one?
>
> It's been several years since I looked at this. It
> used to behave just fine.
>
> Something must have changed in the not-too-distant
> past to have broken this mechanism...
>...
It seems to be an old bug.
The following combination of options is simply an unusual one:
CONFIG_MII=m
CONFIG_USB_USBNET=y
CONFIG_USB_USBNET_MII=n
> - Dave
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: [2.6 patch] let USB_USBNET always select MII
From: David Brownell @ 2007-11-01 23:52 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Toralf Förster, jgarzik, linux-kernel, netdev
In-Reply-To: <20071101222524.GB7227@stusta.de>
On Thursday 01 November 2007, Adrian Bunk wrote:
> All this USB_USBNET_MII trickery is simply not worth it considering how
> few code it saves.
Depends on what systems you're talking about. Forcing unused
code into the kernel is not free, especially if that's made into
a design policy and applied repeatedly to many subsystems.
> As a side effect, this also fixes the following compile error reported
> by Toralf Förster:
Why not just fix the thing which changed and broke the build?
Or if reverse dependencies can't be made to work sanely, then
have those Ethernet-adapter minidrivers depend on NET_ETHERNET
and then select MII. (To make the relationships be simple
enough that current Kconfig can handle them.)
I have a fair number of usbnet devices. Not one of them needs
MII or NET_ETHERNET.
- Dave
^ permalink raw reply
* Re: [patch 2/2] ipvs: Syncrhonise Closing of Connections
From: Simon Horman @ 2007-11-02 0:53 UTC (permalink / raw)
To: Julian Anastasov
Cc: lvs-devel, netdev, Wensong Zhang, Rumen G. Bogdanovski,
Graeme Fowler, Joseph Mack NA3T, David S. Miller
In-Reply-To: <Pine.LNX.4.58.0711020119580.2992@u.domain.uli>
On Fri, Nov 02, 2007 at 01:36:07AM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 1 Nov 2007, Simon Horman wrote:
>
> > --- net-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c 2007-11-01 18:17:55.000000000 +0900
> > +++ net-2.6/net/ipv4/ipvs/ip_vs_sync.c 2007-11-01 18:20:30.000000000 +0900
> > @@ -332,7 +332,7 @@ static void ip_vs_process_message(const
> > s->daddr, s->dport,
> > flags, dest);
> > if (dest)
>
> Is that correct? Sorry, I was flooded with different versions
> of this patch and I'm not sure if it is the final one.
>
> > - atomic_dec(&dest->refcnt);
> > + ip_vs_dest_get(dest);
> > if (!cp) {
> > IP_VS_ERR("ip_vs_conn_new failed\n");
> > return;
The ip_vs_dest_get() call shouldn't be there.
I'll double check the rest of the patch.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Michael Ellerman @ 2007-11-02 6:30 UTC (permalink / raw)
To: Christoph Raisch
Cc: Jan-Bernd Themann, Jeff Garzik, linux-kernel, linux-ppc,
Marcus Eder, netdev, ossthema, Stefan Roscher, Thomas Q Klein
In-Reply-To: <OF59B5FFD2.0294206F-ONC1257385.006A802D-C1257385.006CB6BB@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> Michael Ellerman <michael@ellerman.id.au> wrote on 30.10.2007 23:50:36:
> >
> > On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote:
> > >
> > > Michael Ellerman <michael@ellerman.id.au> wrote on 28.10.2007 23:32:17:
> > > Hope I didn't miss anything here...
> >
> > Perhaps. When we kdump the kernel does not call the reboot notifiers, so
> > the code Jan-Bernd just added won't get called. So the eHEA resources
> > won't be freed. When the kdump kernel tries to load the eHEA driver what
> > will happen?
> >
> Good point.
>
> If the device driver tries to allocate resources again (in the kdump
> kernel),
> which have been allocated before (in the crashed kernel) the hcalls will
> fail because from the hypervisor view the resources are still in use.
> Currently there's no method to find out the resource handles for these
> HEA resources allocated by the crashed kernel within the hypervisor...
So the hypervisor can't allocate more resources, because they're already
allocated, but it can't free the ones that are allocated because it
doesn't know what they are? I don't think I understand.
If that's really the way it works then eHEA is more or less broken for
kdump I'm afraid.
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
* [PATCH] net: Add 405EX support to new EMAC driver
From: Stefan Roese @ 2007-11-02 7:14 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, Benjamin Herrenschmidt, Josh Boyer
This patch adds support for the 405EX to the new EMAC driver. Some as on
AXON, the 405EX handles the MDIO via the RGMII bridge.
Tested on AMCC Kilauea.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/core.c | 3 ++-
drivers/net/ibm_newemac/rgmii.c | 16 +++++++++++-----
drivers/net/ibm_newemac/rgmii.h | 2 +-
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 0de3aa2..fd0a585 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2466,7 +2466,8 @@ static int __devinit emac_init_config(struct emac_instance *dev)
if (of_device_is_compatible(np, "ibm,emac4"))
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-axon")
- || of_device_is_compatible(np, "ibm,emac-440epx"))
+ || of_device_is_compatible(np, "ibm,emac-440epx")
+ || of_device_is_compatible(np, "ibm,emac-405ex"))
dev->features |= EMAC_FTR_HAS_AXON_STACR
| EMAC_FTR_STACR_OC_INVERT;
if (of_device_is_compatible(np, "ibm,emac-440spe"))
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index de41695..b9a4ce7 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -140,7 +140,12 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
- if (dev->type != RGMII_AXON)
+ /*
+ * Some platforms (e.g. 440GX) have RGMII support but don't use it for
+ * MDIO access. Only continue if platforms is using MDIO over the RGMII
+ * interface (e.g. AXON, 405EX).
+ */
+ if (dev->type != RGMII_HAS_MDIO)
return;
mutex_lock(&dev->lock);
@@ -161,7 +166,7 @@ void rgmii_put_mdio(struct of_device *ofdev, int input)
RGMII_DBG2(dev, "put_mdio(%d)" NL, input);
- if (dev->type != RGMII_AXON)
+ if (dev->type != RGMII_HAS_MDIO)
return;
fer = in_be32(&p->fer);
@@ -251,8 +256,9 @@ static int __devinit rgmii_probe(struct of_device *ofdev,
}
/* Check for RGMII type */
- if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon"))
- dev->type = RGMII_AXON;
+ if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon") ||
+ of_device_is_compatible(ofdev->node, "ibm,rgmii-405ex"))
+ dev->type = RGMII_HAS_MDIO;
else
dev->type = RGMII_STANDARD;
@@ -264,7 +270,7 @@ static int __devinit rgmii_probe(struct of_device *ofdev,
printk(KERN_INFO
"RGMII %s %s initialized\n",
- dev->type == RGMII_STANDARD ? "standard" : "axon",
+ dev->type == RGMII_STANDARD ? "standard" : "has-mdio",
ofdev->node->full_name);
wmb();
diff --git a/drivers/net/ibm_newemac/rgmii.h b/drivers/net/ibm_newemac/rgmii.h
index 5780683..f1b0ef5 100644
--- a/drivers/net/ibm_newemac/rgmii.h
+++ b/drivers/net/ibm_newemac/rgmii.h
@@ -23,7 +23,7 @@
/* RGMII bridge type */
#define RGMII_STANDARD 0
-#define RGMII_AXON 1
+#define RGMII_HAS_MDIO 1
/* RGMII bridge */
struct rgmii_regs {
--
1.5.3.4.498.g9c514
^ permalink raw reply related
* Re: TCP_DEFER_ACCEPT issues
From: Eric Dumazet @ 2007-11-02 7:24 UTC (permalink / raw)
To: Felix von Leitner; +Cc: linux-kernel, Linux Netdev List
In-Reply-To: <20071102013321.GA30893@codeblau.de>
Felix von Leitner a écrit :
> I am trying to use TCP_DEFER_ACCEPT in my web server.
>
> There are some operational problems. First of all: timeout handling. I
> would like to be able to set a timeout in seconds (or better:
> milliseconds) for how long the socket is allowed to sit there without
> data coming in. For high load situations, I have been enforcing
> timeouts in the range of 15 seconds, otherwise someone can DoS the
> server by opening a lot of connections and tying up data structures.
>
> It is still possible, of course, to tie up kernel memory this way, by
> not reacting to the FIN or RST packets and running into a timeout there,
> too, but that is partially tunable via sysctl.
>
> According to tcp(7) the int argument to TCP_DEFER_ACCEPT is in seconds.
> In the kernel code, it's converted to TCP timeout units. When I ran my
> server, and connected without sending any data, nothing happened. No
> timeout. Minutes later, the connection was still there. Even worse:
> when I killed (!) the server process (thus closing the server socket),
> the client did not get a reset. Only when I type something in the
> telnet, I get a reset. This appears to be very broken.
>
> My suggestion:
>
> 1. make the argument to the setsockopt be in seconds, or milliseconds.
> 2. if the server socket is closed, reset all pending connections.
>
> Comments?
>
I agree TCP_DEFER_ACCEPT is not worth it at the current time, if you take into
account the bad guys, or very slow networks.
1) Setting a timeout in a millisecond range (< 1000) is not very good because
some clients may need much more time to send your server the data (very long
distance). So a second granularity is OK.
2) After timeout is elapsed, the server tcp stack has no socket associated to
your client attempt. So closing the server listening socket wont be able to
send RST. I agree a RST *should* be sent by the server once the timeout is
triggered.
A typical tcpdump of what is happening for a tcp_defer_accept timeout of 20
seconds is :
[1]08:52:47.480291 IP client.60930 > server.http: S 2498995442:2498995442(0)
win 5840 <mss 1460,sackOK,timestamp 2685904595 0,nop,wscale 2>
[2]08:52:47.480302 IP server.http > client.60930: S 1173302644:1173302644(0)
ack 2498995443 win 5840 <mss 1460>
[3]08:52:47.481669 IP client.60930 > server.http: . ack 1 win 5840
[4]08:52:50.757543 IP server.http > client.60930: S 1173302644:1173302644(0)
ack 2498995443 win 5840 <mss 1460>
[5]08:52:50.758953 IP client.60930 > server.http: . ack 1 win 5840
[6]08:52:56.760611 IP server.http > client.60930: S 1173302644:1173302644(0)
ack 2498995443 win 5840 <mss 1460>
[7]08:52:56.761886 IP client.60930 > server.http: . ack 1 win 5840
[8]08:53:08.771254 IP server.http > client.60930: S 1173302644:1173302644(0)
ack 2498995443 win 5840 <mss 1460>
[9]08:53:08.772514 IP client.60930 > server.http: . ack 1 win 5840
[10]08:53:32.782488 IP server.http > client.60930: S 1173302644:1173302644(0)
ack 2498995443 win 5840 <mss 1460>
[11]08:53:32.783754 IP client.60930 > server.http: . ack 1 win 5840
<a very long time, then client finally sends 2 bytes>
[12]08:59:30.509097 IP client.60930 > server.http: P 1:3(2) ack 1 win 5840
[13]08:59:30.509125 IP server.http > client.60930: R 1173302645:1173302645(0)
win 0
So TCP_DEFER_ACCEPT might send way more packets than needed. Packets 4,6,8,10
(and their corresponding acks 5,7,9,11) seem un-necessary, since (1,2,3) has
engaged a normal TCP session (three way handshake).
We only should wait for the data coming from the client to be able to pass the
new socket to the listening application.
^ permalink raw reply
* Re: [PATCH 00/33] Swap over NFS -v14
From: Pavel Machek @ 2007-11-02 8:54 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Jeff Garzik, Nick Piggin, Linus Torvalds, Andrew Morton,
linux-kernel, linux-mm, netdev, trond.myklebust
In-Reply-To: <1193835413.27652.205.camel@twins>
Hi!
> > 2) Nonetheless, swap over NFS is a pretty rare case. I view this work
> > as interesting, but I really don't see a huge need, for swapping over
> > NBD or swapping over NFS. I tend to think swapping to a remote resource
> > starts to approach "migration" rather than merely swapping. Yes, we can
> > do it... but given the lack of burning need one must examine the price.
>
> There is a large corporate demand for this, which is why I'm doing this.
>
> The typical usage scenarios are:
> - cluster/blades, where having local disks is a cost issue (maintenance
> of failures, heat, etc)
> - virtualisation, where dumping the storage on a networked storage unit
> makes for trivial migration and what not..
>
> But please, people who want this (I'm sure some of you are reading) do
> speak up. I'm just the motivated corporate drone implementing the
> feature :-)
I have wyse thin client here, geode (or something) cpu, 128MB flash,
256MB RAM (IIRC). You want to swap on this one, and no, you don't want
to swap to flash.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [BUG] in inet6_create
From: Pavel Emelyanov @ 2007-11-02 9:15 UTC (permalink / raw)
To: Roel Kluin; +Cc: netdev, linux-net
In-Reply-To: <472A41AF.2030704@tiscali.nl>
Roel Kluin wrote:
> Roel Kluin wrote:
>> I got this bug recently, I am not sure whether this is related to any previously
>> reported ones. It was a recently pulled git kernel. Also I have been hacking my
>> kernel a bit lately, but I think that I haven't got any changes in the currently
>> running kernel.
>>
>> FYI: my network card was not running (module not loaded, and I just started
>> thunderbird)
>>
>> Roel
>>
>> More information needed?
Yes, please.
Can you send us the disasm (objdump -dr) of your ipv6 module.
More precisely - I need the disassembled inet6_create() function to
figure out where exactly this thing happened.
Thanks,
Pavel
>> --
>
> probably mailing to linux-net was more appropriate
>
>> NET: Registered protocol family 10
>> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
>> printing eip: f881034f *pde = 00000000
>> Oops: 0000 [#1]
>> Modules linked in: ipv6
>>
>> Pid: 17080, comm: modprobe Not tainted (2.6.24-rc1 #1)
>> EIP: 0060:[<f881034f>] EFLAGS: 00010293 CPU: 0
>> EIP is at inet6_create+0x5f/0x340 [ipv6]
>> EAX: 00000000 EBX: 00000000 ECX: f7621fd5 EDX: f8842e78
>> ESI: ffffffff EDI: 0000003a EBP: ffffff9f ESP: d780de74
>> DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
>> Process modprobe (pid: 17080, ti=d780c000 task=c3a86000 task.ti=d780c000)
>> Stack: 00000000 00000246 00000246 00000003 c60e22a0 00000246 00000000 00000000
>> f88410fc ffffffea 00000003 c063f680 c028d597 00000002 00000001 c028d52c
>> c60e22a0 00000003 f8842d00 00000032 00000000 c028d6a7 0000003a f88438c0
>> Call Trace:
>> [<c028d597>] __sock_create+0xf7/0x1e0
>> [<c028d52c>] __sock_create+0x8c/0x1e0
>> [<c028d6a7>] sock_create_kern+0x27/0x30
>> [<f88457af>] icmpv6_init+0x1f/0xa0 [ipv6]
>> [<f884513f>] inet6_init+0x13f/0x2f0 [ipv6]
>> [<c0144f73>] sys_init_module+0x173/0x16c0
>> [<c0132860>] autoremove_wake_function+0x0/0x50
>> [<c0171ef1>] sys_read+0x41/0x70
>> [<c010818e>] syscall_call+0x7/0xb
>> =======================
>> Code: c0 85 c9 0f 84 12 02 00 00 c7 44 24 18 00 00 00 00 0f bf c6 c1 e0 03 8b 98 80 2e 84 f8 8d 90 80 2e 84 f8 89 5c 24 1c 8b 44 24 1c <8b> 00 0f 18 00 90 39 d3 bd a2 ff ff ff 75 36 e9 f3 01 00 00 85
>> EIP: [<f881034f>] inet6_create+0x5f/0x340 [ipv6] SS:ESP 0068:d780de74
>> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
>> printing eip: f881034f *pde = 00000000
>> Oops: 0000 [#2]
>> Modules linked in: ipv6
>>
>> Pid: 17078, comm: thunderbird-bin Tainted: G D (2.6.24-rc1 #1)
>> EIP: 0060:[<f881034f>] EFLAGS: 00210293 CPU: 0
>> EIP is at inet6_create+0x5f/0x340 [ipv6]
>> EAX: 00000000 EBX: 00000000 ECX: f7621fd5 EDX: f8842e78
>> ESI: ffffffff EDI: 00000000 EBP: ffffff9f ESP: c2801f00
>> DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
>> Process thunderbird-bin (pid: 17078, ti=c2800000 task=c20bf000 task.ti=c2800000)
>> Stack: c0185024 00200246 00200246 00000001 c60e2000 00200246 00000000 00000000
>> f88410fc ffffffea 00000001 c063f680 c028d597 00000002 00000001 c028d52c
>> c60e2000 00000001 0000000a 08b095bc c2800000 c028d6e9 00000000 c2801f74
>> Call Trace:
>> [<c0185024>] new_inode+0x24/0x90
>> [<c028d597>] __sock_create+0xf7/0x1e0
>> [<c028d52c>] __sock_create+0x8c/0x1e0
>> [<c028d6e9>] sock_create+0x39/0x50
>> [<c028d89c>] sys_socket+0x1c/0x50
>> [<c028e248>] sys_socketcall+0x68/0x280
>> [<c013da9b>] trace_hardirqs_on+0xbb/0x160
>> [<c011b80d>] do_sched_setscheduler+0xad/0xc0
>> [<c01081fb>] restore_nocheck+0x12/0x15
>> [<c010818e>] syscall_call+0x7/0xb
>> =======================
>> Code: c0 85 c9 0f 84 12 02 00 00 c7 44 24 18 00 00 00 00 0f bf c6 c1 e0 03 8b 98 80 2e 84 f8 8d 90 80 2e 84 f8 89 5c 24 1c 8b 44 24 1c <8b> 00 0f 18 00 90 39 d3 bd a2 ff ff ff 75 36 e9 f3 01 00 00 85
>> EIP: [<f881034f>] inet6_create+0x5f/0x340 [ipv6] SS:ESP 0068:c2801f00
>> -
>> 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
>>
>
> -
> 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: [lvs-devel] [patch 2/2] ipvs: Syncrhonise Closing of Connections
From: Rumen Bogdanovski @ 2007-11-02 9:47 UTC (permalink / raw)
To: LVS Development mailing list
Cc: Julian Anastasov, Wensong Zhang, netdev, Graeme Fowler,
Joseph Mack NA3T, David S. Miller
In-Reply-To: <20071102005348.GA20398@verge.net.au>
I should have been very tired to miss this one when I looked at the
patch...
I looked again in the version I have tested. For some
reason/net/ipv4/ipvs/ip_vs_sync.c is not patched at all, this is what I
have missed.
Rumen
On Fri, 2007-11-02 at 09:53 +0900, Simon Horman wrote:
> On Fri, Nov 02, 2007 at 01:36:07AM +0200, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Thu, 1 Nov 2007, Simon Horman wrote:
> >
> > > --- net-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c 2007-11-01 18:17:55.000000000 +0900
> > > +++ net-2.6/net/ipv4/ipvs/ip_vs_sync.c 2007-11-01 18:20:30.000000000 +0900
> > > @@ -332,7 +332,7 @@ static void ip_vs_process_message(const
> > > s->daddr, s->dport,
> > > flags, dest);
> > > if (dest)
> >
> > Is that correct? Sorry, I was flooded with different versions
> > of this patch and I'm not sure if it is the final one.
> >
> > > - atomic_dec(&dest->refcnt);
> > > + ip_vs_dest_get(dest);
> > > if (!cp) {
> > > IP_VS_ERR("ip_vs_conn_new failed\n");
> > > return;
>
> The ip_vs_dest_get() call shouldn't be there.
> I'll double check the rest of the patch.
>
^ permalink raw reply
* Re: [BUG] in inet6_create
From: Pavel Emelyanov @ 2007-11-02 9:59 UTC (permalink / raw)
To: Roel Kluin, David Miller; +Cc: netdev
In-Reply-To: <472A3218.20708@tiscali.nl>
Roel Kluin wrote:
> I got this bug recently, I am not sure whether this is related to any previously
> reported ones. It was a recently pulled git kernel. Also I have been hacking my
> kernel a bit lately, but I think that I haven't got any changes in the currently
> running kernel.
>
> FYI: my network card was not running (module not loaded, and I just started
> thunderbird)
>
> Roel
>
> More information needed?
I've tried to objdump my ipv6.ko, and found (at the different offset,
but) the same codeline. It showed that the buggy place was in:
list_for_each_rcu(p, &inetsw6[sock->type]) {
some list_head pointer was NULL.
I looked at the inet6_init (which seems to run at the moment of the
oops according to the calltrace) and found that the ipv6 protocol
is first registered and only after this the inetsw6 lists are
properly initialized.
I suspect that this is a race: we create the socket right after
the new protocol is registered, but before the list heads are
ready. The ->init call is called without the stopmachine, so
other process run in parallel with it.
This patch should help, but I don't think that such a situation
is easily reproducible.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index ecbd388..f9bd26f 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -769,6 +769,10 @@ static int __init inet6_init(void)
#endif
#endif
+ /* Register the socket-side information for inet6_create. */
+ for(r = &inetsw6[0]; r < &inetsw6[SOCK_MAX]; ++r)
+ INIT_LIST_HEAD(r);
+
err = proto_register(&tcpv6_prot, 1);
if (err)
goto out;
@@ -786,10 +790,6 @@ static int __init inet6_init(void)
goto out_unregister_udplite_proto;
- /* Register the socket-side information for inet6_create. */
- for(r = &inetsw6[0]; r < &inetsw6[SOCK_MAX]; ++r)
- INIT_LIST_HEAD(r);
-
/* We MUST register RAW sockets before we create the ICMP6,
* IGMP6, or NDISC control sockets.
*/
^ permalink raw reply related
* Re: [PATCH] ehea: add kexec support
From: Christoph Raisch @ 2007-11-02 10:19 UTC (permalink / raw)
To: michael
Cc: Jan-Bernd Themann, Jeff Garzik, linux-kernel, linux-ppc,
Marcus Eder, netdev, ossthema, Stefan Roscher, Thomas Q Klein
In-Reply-To: <1193985008.1782.7.camel@concordia>
Michael Ellerman <michael@ellerman.id.au> wrote on 02.11.2007 07:30:08:
> On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> > Michael Ellerman <michael@ellerman.id.au> wrote on 30.10.2007 23:50:36:
> If that's really the way it works then eHEA is more or less broken for
> kdump I'm afraid.
We think we have a way to workaround this, but let me first try to
explain the base problem.
DD allocates HEA resources and gets firmware_handles for these resources.
To free the resources DD needs to use exactly these handles.
There's no generic firmware call "clean out all resources".
Allocating the same resources twice does not work.
So a new kernel can't free the resources allocated by an old kernel,
because the numeric values of the handles aren't known anymore.
Potential Solution:
Hea driver cleanup function hooks into ppc_md.machine_crash_shutdown
and frees all firmware resources at shutdown time of the crashed kernel.
crash_kexec continues and loads new kernel.
The new kernel restarts the HEA driver within kdump kernel, which will work
because resources have been freed before.
Michael, would this work?
Gruss / Regards
Christoph R.
^ permalink raw reply
* Re: [PATCH 1/2][NETFILTER] Consolidate nf_sockopt and compat_nf_sockopt
From: Patrick McHardy @ 2007-11-02 10:57 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Linux Netdev List, devel
In-Reply-To: <4729F6F7.2020705@openvz.org>
Pavel Emelyanov wrote:
> Both lookup the nf_sockopt_ops object to call the get/set callbacks
> from, but they perform it in a completely similar way.
>
> Introduce the helper for finding the ops.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org >
This conflicts with a cleanup patch from Alexey Dobriyan. I'll
push it upstream today, please resend after rediffing. Thanks.
^ permalink raw reply
* Re: [PATCH 1/2][NETFILTER] Consolidate nf_sockopt and compat_nf_sockopt
From: Pavel Emelyanov @ 2007-11-02 11:07 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David Miller, Linux Netdev List, devel
In-Reply-To: <472B02A1.40601@trash.net>
Patrick McHardy wrote:
> Pavel Emelyanov wrote:
>> Both lookup the nf_sockopt_ops object to call the get/set callbacks
>> from, but they perform it in a completely similar way.
>>
>> Introduce the helper for finding the ops.
>>
>> Signed-off-by: Pavel Emelyanov <xemul@openvz.org >
>
>
> This conflicts with a cleanup patch from Alexey Dobriyan. I'll
> push it upstream today, please resend after rediffing. Thanks.
>
Amazing :) Alexey's patch does the same thing as my 2nd
one does :) I will resend this one :)
Thanks,
Pavel
^ permalink raw reply
* Re: [BUG] in inet6_create
From: Pavel Emelyanov @ 2007-11-02 12:54 UTC (permalink / raw)
To: Roel Kluin, David Miller; +Cc: netdev
In-Reply-To: <472AF50A.5070706@openvz.org>
Pavel Emelyanov wrote:
> Roel Kluin wrote:
>> I got this bug recently, I am not sure whether this is related to any previously
>> reported ones. It was a recently pulled git kernel. Also I have been hacking my
>> kernel a bit lately, but I think that I haven't got any changes in the currently
>> running kernel.
>>
>> FYI: my network card was not running (module not loaded, and I just started
>> thunderbird)
>>
>> Roel
>>
>> More information needed?
>
> I've tried to objdump my ipv6.ko, and found (at the different offset,
> but) the same codeline. It showed that the buggy place was in:
>
> list_for_each_rcu(p, &inetsw6[sock->type]) {
>
> some list_head pointer was NULL.
>
> I looked at the inet6_init (which seems to run at the moment of the
> oops according to the calltrace) and found that the ipv6 protocol
> is first registered and only after this the inetsw6 lists are
> properly initialized.
Hm... A deeper look at the code showed that the proto_register() is
OK to be called before the list initialization.
Nevertheless, the faulty place is found correctly (providing that
Roel's objdump looks similar to mine, but it should - this codeline
is unique in the ipv6.ko).
Roel, are you sure, that the kernel you're running is not hacked
by some of you patches :)
> I suspect that this is a race: we create the socket right after
> the new protocol is registered, but before the list heads are
> ready. The ->init call is called without the stopmachine, so
> other process run in parallel with it.
>
> This patch should help, but I don't think that such a situation
> is easily reproducible.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> ---
>
> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
> index ecbd388..f9bd26f 100644
> --- a/net/ipv6/af_inet6.c
> +++ b/net/ipv6/af_inet6.c
> @@ -769,6 +769,10 @@ static int __init inet6_init(void)
> #endif
> #endif
>
> + /* Register the socket-side information for inet6_create. */
> + for(r = &inetsw6[0]; r < &inetsw6[SOCK_MAX]; ++r)
> + INIT_LIST_HEAD(r);
> +
> err = proto_register(&tcpv6_prot, 1);
> if (err)
> goto out;
> @@ -786,10 +790,6 @@ static int __init inet6_init(void)
> goto out_unregister_udplite_proto;
>
>
> - /* Register the socket-side information for inet6_create. */
> - for(r = &inetsw6[0]; r < &inetsw6[SOCK_MAX]; ++r)
> - INIT_LIST_HEAD(r);
> -
> /* We MUST register RAW sockets before we create the ICMP6,
> * IGMP6, or NDISC control sockets.
> */
>
^ permalink raw reply
* [PATCH] Fix e100 on systems that have cache incoherent DMA
From: David Acker @ 2007-11-02 13:27 UTC (permalink / raw)
To: Auke Kok
Cc: e1000-devel, netdev, Jesse Brandeburg, Milton Miller,
Scott Feldman, John Ronciak, Jeff Kirsher, Jeff Garzik
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next link equal to 0.
When hardware encounters this buffer it attempts to write data to it and
then update Status Word bits and Actual Count in the RFD. At the same time
software may try to clear the el-bit and set the link address to a new buffer.
Since the entire RFD is once cache-line, the two write operations can collide.
This can lead to the receive unit stalling or interpreting random memory as
its receive area.
The fix is to set the el-bit on and the size to 0 on the next to last buffer
in the chain. When the hardware encounters this buffer it stops and does not
write to it at all. The hardware issues an RNR interrupt with the receive
unit in the No Resources state. Software can write to the tail of the list
because it knows hardware will stop on the previous descriptor that was
marked as the end of list.
Once it has a new next to last buffer prepared, it can clear the el-bit and
set the size on the previous one. The race on this buffer is safe since
the link already points to a valid next buffer and the software can handle
the race setting the size (assuming aligned 16 bit writes are atomic with
respect to the DMA read). If the hardware sees the el-bit cleared without
the size set, it will move on to the next buffer and skip this one. If it
sees the size set but the el-bit still set, it will complete that buffer
and then RNR interrupt and wait.
This is a patch for 2.6.24-rc1.
Signed-off-by: David Acker <dacker@roinet.com>
---
This version is based on the simpler patch I did in May. The algorithm I tried
after that never worked correctly under load. It would hang the RU and the
transmit unit sometimes and if the card was restarted it would often crash the
system with memory corruption. This patch was tested on my embedded system
using pktgen. I had it sending while a PC sent at it. I also ran it as
wireless access point with a 12-hour bidirectional 20 mbps UDP going between an
ethernet host on the e100 and a wireless client.
--- linux-2.6.24-rc1/drivers/net/e100.c.orig 2007-11-01 11:42:35.000000000 -0400
+++ linux-2.6.24-rc1/drivers/net/e100.c 2007-11-02 09:09:47.000000000 -0400
@@ -106,6 +106,13 @@
* the RFD, the RFD must be dma_sync'ed to maintain a consistent
* view from software and hardware.
*
+ * In order to keep updates to the RFD link field from colliding with
+ * hardware writes to mark packets complete, we use the feature that
+ * hardware will not write to a size 0 descriptor and mark the previous
+ * packet as end-of-list (EL). After updating the link, we remove EL
+ * and only then restore the size such that hardware may use the
+ * previous-to-end RFD.
+ *
* Under typical operation, the receive unit (RU) is start once,
* and the controller happily fills RFDs as frames arrive. If
* replacement RFDs cannot be allocated, or the RU goes non-active,
@@ -281,14 +288,15 @@ struct csr {
};
enum scb_status {
+ rus_no_res = 0x08,
rus_ready = 0x10,
rus_mask = 0x3C,
};
enum ru_state {
- RU_SUSPENDED = 0,
- RU_RUNNING = 1,
- RU_UNINITIALIZED = -1,
+ ru_stopped = 0,
+ ru_running = 1,
+ ru_uninitialized = -1,
};
enum scb_stat_ack {
@@ -952,7 +960,7 @@ static void e100_get_defaults(struct nic
((nic->mac >= mac_82558_D101_A4) ? cb_cid : cb_i));
/* Template for a freshly allocated RFD */
- nic->blank_rfd.command = cpu_to_le16(cb_el);
+ nic->blank_rfd.command = 0;
nic->blank_rfd.rbd = 0xFFFFFFFF;
nic->blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
@@ -1759,7 +1767,7 @@ static int e100_alloc_cbs(struct nic *ni
static inline void e100_start_receiver(struct nic *nic, struct rx *rx)
{
if(!nic->rxs) return;
- if(RU_SUSPENDED != nic->ru_running) return;
+ if (ru_stopped != nic->ru_running) return;
/* handle init time starts */
if(!rx) rx = nic->rxs;
@@ -1767,7 +1775,7 @@ static inline void e100_start_receiver(s
/* (Re)start RU if suspended or idle and RFA is non-NULL */
if(rx->skb) {
e100_exec_cmd(nic, ruc_start, rx->dma_addr);
- nic->ru_running = RU_RUNNING;
+ nic->ru_running = ru_running;
}
}
@@ -1791,15 +1799,12 @@ static int e100_rx_alloc_skb(struct nic
}
/* Link the RFD to end of RFA by linking previous RFD to
- * this one, and clearing EL bit of previous. */
+ * this one. We are safe to touch the previous RFD because
+ * it is protected by the before last buffer's el bit being set */
if(rx->prev->skb) {
struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data;
put_unaligned(cpu_to_le32(rx->dma_addr),
(u32 *)&prev_rfd->link);
- wmb();
- prev_rfd->command &= ~cpu_to_le16(cb_el);
- pci_dma_sync_single_for_device(nic->pdev, rx->prev->dma_addr,
- sizeof(struct rfd), PCI_DMA_TODEVICE);
}
return 0;
@@ -1824,8 +1829,20 @@ static int e100_rx_indicate(struct nic *
DPRINTK(RX_STATUS, DEBUG, "status=0x%04X\n", rfd_status);
/* If data isn't ready, nothing to indicate */
- if(unlikely(!(rfd_status & cb_complete)))
+ if (unlikely(!(rfd_status & cb_complete))) {
+ /* If the next buffer has the el bit, but we think the receiver
+ * is still running, check to see if it really stopped while
+ * we had interrupts off.
+ * This allows for a fast restart without re-enabling
+ * interrupts */
+ if ((le16_to_cpu(rfd->command) & cb_el) &&
+ (ru_running == nic->ru_running)) {
+
+ if (readb(&nic->csr->scb.status) & rus_no_res)
+ nic->ru_running = ru_stopped;
+ }
return -ENODATA;
+ }
/* Get actual data size */
actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF;
@@ -1836,9 +1853,18 @@ static int e100_rx_indicate(struct nic *
pci_unmap_single(nic->pdev, rx->dma_addr,
RFD_BUF_LEN, PCI_DMA_FROMDEVICE);
- /* this allows for a fast restart without re-enabling interrupts */
- if(le16_to_cpu(rfd->command) & cb_el)
- nic->ru_running = RU_SUSPENDED;
+ /* If this buffer has the el bit, but we think the receiver
+ * is still running, check to see if it really stopped while
+ * we had interrupts off.
+ * This allows for a fast restart without re-enabling interrupts.
+ * This can happen when the RU sees the size change but also sees
+ * the el bit set. */
+ if ((le16_to_cpu(rfd->command) & cb_el) &&
+ (ru_running == nic->ru_running)) {
+
+ if (readb(&nic->csr->scb.status) & rus_no_res)
+ nic->ru_running = ru_stopped;
+ }
/* Pull off the RFD and put the actual data (minus eth hdr) */
skb_reserve(skb, sizeof(struct rfd));
@@ -1870,31 +1896,30 @@ static void e100_rx_clean(struct nic *ni
unsigned int work_to_do)
{
struct rx *rx;
- int restart_required = 0;
- struct rx *rx_to_start = NULL;
-
- /* are we already rnr? then pay attention!!! this ensures that
- * the state machine progression never allows a start with a
- * partially cleaned list, avoiding a race between hardware
- * and rx_to_clean when in NAPI mode */
- if(RU_SUSPENDED == nic->ru_running)
- restart_required = 1;
+ int restart_required = 0, err = 0;
+ struct rx *old_before_last_rx, *new_before_last_rx;
+ struct rfd *old_before_last_rfd, *new_before_last_rfd;
/* Indicate newly arrived packets */
for(rx = nic->rx_to_clean; rx->skb; rx = nic->rx_to_clean = rx->next) {
- int err = e100_rx_indicate(nic, rx, work_done, work_to_do);
- if(-EAGAIN == err) {
- /* hit quota so have more work to do, restart once
- * cleanup is complete */
- restart_required = 0;
+ err = e100_rx_indicate(nic, rx, work_done, work_to_do);
+ /* Hit quota or no more to clean */
+ if (-EAGAIN == err || -ENODATA == err)
break;
- } else if(-ENODATA == err)
- break; /* No more to clean */
}
- /* save our starting point as the place we'll restart the receiver */
- if(restart_required)
- rx_to_start = nic->rx_to_clean;
+
+ /* On EAGAIN, hit quota so have more work to do, restart once
+ * cleanup is complete.
+ * Else, are we already rnr? then pay attention!!! this ensures that
+ * the state machine progression never allows a start with a
+ * partially cleaned list, avoiding a race between hardware
+ * and rx_to_clean when in NAPI mode */
+ if (-EAGAIN != err && ru_stopped == nic->ru_running)
+ restart_required = 1;
+
+ old_before_last_rx = nic->rx_to_use->prev->prev;
+ old_before_last_rfd = (struct rfd *)old_before_last_rx->skb->data;
/* Alloc new skbs to refill list */
for(rx = nic->rx_to_use; !rx->skb; rx = nic->rx_to_use = rx->next) {
@@ -1902,10 +1927,42 @@ static void e100_rx_clean(struct nic *ni
break; /* Better luck next time (see watchdog) */
}
+ new_before_last_rx = nic->rx_to_use->prev->prev;
+ if (new_before_last_rx != old_before_last_rx) {
+ /* Set the el-bit on the buffer that is before the last buffer.
+ * This lets us update the next pointer on the last buffer
+ * without worrying about hardware touching it.
+ * We set the size to 0 to prevent hardware from touching this
+ * buffer.
+ * When the hardware hits the before last buffer with el-bit
+ * and size of 0, it will RNR interrupt, the RUS will go into
+ * the No Resources state. It will not complete nor write to
+ * this buffer. */
+ new_before_last_rfd =
+ (struct rfd *)new_before_last_rx->skb->data;
+ new_before_last_rfd->size = 0;
+ new_before_last_rfd->command |= cpu_to_le16(cb_el);
+ pci_dma_sync_single_for_device(nic->pdev,
+ new_before_last_rx->dma_addr, sizeof(struct rfd),
+ PCI_DMA_TODEVICE);
+
+ /* Now that we have a new stopping point, we can clear the old
+ * stopping point. We must sync twice to get the proper
+ * ordering on the hardware side of things. */
+ old_before_last_rfd->command &= ~cpu_to_le16(cb_el);
+ pci_dma_sync_single_for_device(nic->pdev,
+ old_before_last_rx->dma_addr, sizeof(struct rfd),
+ PCI_DMA_TODEVICE);
+ old_before_last_rfd->size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
+ pci_dma_sync_single_for_device(nic->pdev,
+ old_before_last_rx->dma_addr, sizeof(struct rfd),
+ PCI_DMA_TODEVICE);
+ }
+
if(restart_required) {
// ack the rnr?
writeb(stat_ack_rnr, &nic->csr->scb.stat_ack);
- e100_start_receiver(nic, rx_to_start);
+ e100_start_receiver(nic, nic->rx_to_clean);
if(work_done)
(*work_done)++;
}
@@ -1916,7 +1973,7 @@ static void e100_rx_clean_list(struct ni
struct rx *rx;
unsigned int i, count = nic->params.rfds.count;
- nic->ru_running = RU_UNINITIALIZED;
+ nic->ru_running = ru_uninitialized;
if(nic->rxs) {
for(rx = nic->rxs, i = 0; i < count; rx++, i++) {
@@ -1937,9 +1994,10 @@ static int e100_rx_alloc_list(struct nic
{
struct rx *rx;
unsigned int i, count = nic->params.rfds.count;
+ struct rfd *before_last;
nic->rx_to_use = nic->rx_to_clean = NULL;
- nic->ru_running = RU_UNINITIALIZED;
+ nic->ru_running = ru_uninitialized;
if(!(nic->rxs = kcalloc(count, sizeof(struct rx), GFP_ATOMIC)))
return -ENOMEM;
@@ -1952,9 +2010,22 @@ static int e100_rx_alloc_list(struct nic
return -ENOMEM;
}
}
+ /* Set the el-bit on the buffer that is before the last buffer.
+ * This lets us update the next pointer on the last buffer without
+ * worrying about hardware touching it.
+ * We set the size to 0 to prevent hardware from touching this buffer.
+ * When the hardware hits the before last buffer with el-bit and size
+ * of 0, it will RNR interrupt, the RU will go into the No Resources
+ * state. It will not complete nor write to this buffer. */
+ rx = nic->rxs->prev->prev;
+ before_last = (struct rfd *)rx->skb->data;
+ before_last->command |= cpu_to_le16(cb_el);
+ before_last->size = 0;
+ pci_dma_sync_single_for_device(nic->pdev, rx->dma_addr,
+ sizeof(struct rfd), PCI_DMA_TODEVICE);
nic->rx_to_use = nic->rx_to_clean = nic->rxs;
- nic->ru_running = RU_SUSPENDED;
+ nic->ru_running = ru_stopped;
return 0;
}
@@ -1976,7 +2047,7 @@ static irqreturn_t e100_intr(int irq, vo
/* We hit Receive No Resource (RNR); restart RU after cleaning */
if(stat_ack & stat_ack_rnr)
- nic->ru_running = RU_SUSPENDED;
+ nic->ru_running = ru_stopped;
if(likely(netif_rx_schedule_prep(netdev, &nic->napi))) {
e100_disable_irq(nic);
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* [2.6 patch] drivers/net/chelsio/: #if 0 unused functions
From: Adrian Bunk @ 2007-11-02 15:43 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
This patch #if 0's the following unused functions:
- espi.c:t1_espi_set_misc_ctrl()
- sge.c:t1_sched_set_max_avail_bytes()
- sge.c:t1_sched_set_drain_bits_per_us()
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
drivers/net/chelsio/espi.c | 2 ++
drivers/net/chelsio/espi.h | 1 -
drivers/net/chelsio/sge.c | 4 ++++
drivers/net/chelsio/sge.h | 2 --
4 files changed, 6 insertions(+), 3 deletions(-)
21c8ac8bf68a9ca84d7548003294535484140b59
diff --git a/drivers/net/chelsio/espi.c b/drivers/net/chelsio/espi.c
index d7c5406..1e0749e 100644
--- a/drivers/net/chelsio/espi.c
+++ b/drivers/net/chelsio/espi.c
@@ -297,6 +297,7 @@ struct peespi *t1_espi_create(adapter_t *adapter)
return espi;
}
+#if 0
void t1_espi_set_misc_ctrl(adapter_t *adapter, u32 val)
{
struct peespi *espi = adapter->espi;
@@ -309,6 +310,7 @@ void t1_espi_set_misc_ctrl(adapter_t *adapter, u32 val)
writel(espi->misc_ctrl, adapter->regs + A_ESPI_MISC_CONTROL);
spin_unlock(&espi->lock);
}
+#endif /* 0 */
u32 t1_espi_get_mon(adapter_t *adapter, u32 addr, u8 wait)
{
diff --git a/drivers/net/chelsio/espi.h b/drivers/net/chelsio/espi.h
index 84f2c98..5694aad 100644
--- a/drivers/net/chelsio/espi.h
+++ b/drivers/net/chelsio/espi.h
@@ -62,7 +62,6 @@ void t1_espi_intr_disable(struct peespi *);
int t1_espi_intr_handler(struct peespi *);
const struct espi_intr_counts *t1_espi_get_intr_counts(struct peespi *espi);
-void t1_espi_set_misc_ctrl(adapter_t *adapter, u32 val);
u32 t1_espi_get_mon(adapter_t *adapter, u32 addr, u8 wait);
int t1_espi_get_mon_t204(adapter_t *, u32 *, u8);
diff --git a/drivers/net/chelsio/sge.c b/drivers/net/chelsio/sge.c
index ffa7e64..e3668d7 100644
--- a/drivers/net/chelsio/sge.c
+++ b/drivers/net/chelsio/sge.c
@@ -330,6 +330,8 @@ unsigned int t1_sched_update_parms(struct sge *sge, unsigned int port,
return max_avail_segs * (p->mtu - 40);
}
+#if 0
+
/*
* t1_sched_max_avail_bytes() tells the scheduler the maximum amount of
* data that can be pushed per port.
@@ -357,6 +359,8 @@ void t1_sched_set_drain_bits_per_us(struct sge *sge, unsigned int port,
t1_sched_update_parms(sge, port, 0, 0);
}
+#endif /* 0 */
+
/*
* get_clock() implements a ns clock (see ktime_get)
diff --git a/drivers/net/chelsio/sge.h b/drivers/net/chelsio/sge.h
index 713d9c5..e1cbded 100644
--- a/drivers/net/chelsio/sge.h
+++ b/drivers/net/chelsio/sge.h
@@ -89,8 +89,6 @@ void t1_sge_intr_disable(struct sge *);
void t1_sge_intr_clear(struct sge *);
const struct sge_intr_counts *t1_sge_get_intr_counts(const struct sge *sge);
void t1_sge_get_port_stats(const struct sge *sge, int port, struct sge_port_stats *);
-void t1_sched_set_max_avail_bytes(struct sge *, unsigned int);
-void t1_sched_set_drain_bits_per_us(struct sge *, unsigned int, unsigned int);
unsigned int t1_sched_update_parms(struct sge *, unsigned int, unsigned int,
unsigned int);
^ permalink raw reply related
* [2.6 patch] usbnet.c: check for the right MII variable
From: Adrian Bunk @ 2007-11-02 15:46 UTC (permalink / raw)
To: David Brownell; +Cc: Toralf Förster, jgarzik, linux-kernel, netdev
In-Reply-To: <200711011652.39601.david-b@pacbell.net>
On Thu, Nov 01, 2007 at 04:52:39PM -0700, David Brownell wrote:
> On Thursday 01 November 2007, Adrian Bunk wrote:
> > All this USB_USBNET_MII trickery is simply not worth it considering how
> > few code it saves.
>
> Depends on what systems you're talking about. Forcing unused
> code into the kernel is not free, especially if that's made into
> a design policy and applied repeatedly to many subsystems.
If it was turned into a design policy...
My impression is that in some parts of the kernel every byte gets
counted, while in other parts noone would notice a few kilobytes more or
less.
> > As a side effect, this also fixes the following compile error reported
> > by Toralf Förster:
>
> Why not just fix the thing which changed and broke the build?
Today it's exactly one year since your commit entered the tree.
Dear bug, happy birthday! ;-)
> Or if reverse dependencies can't be made to work sanely, then
> have those Ethernet-adapter minidrivers depend on NET_ETHERNET
> and then select MII. (To make the relationships be simple
> enough that current Kconfig can handle them.)
It's not Kconfig's fault that you test for the wrong variable in
usbnet.c ...
> I have a fair number of usbnet devices. Not one of them needs
> MII or NET_ETHERNET.
I don't understand why you think this bug was in any way related to
NET_ETHERNET - set NET_ETHERNET=y and the bug is still present.
If you insist on the #ifdef's take the patch below - it even saves a few
additional bytes if you have non-usbnet net drivers requiring MII
enabled statically or as modules in your .config but no usbnet drivers
requiring MII.
> - Dave
cu
Adrian
<-- snip -->
This patch fixes the following compile error with CONFIG_MII=m,
CONFIG_USB_USBNET=y, CONFIG_USB_USBNET_MII=n:
<-- snip -->
...
LD .tmp_vmlinux1
drivers/built-in.o: In function `usbnet_set_settings':
(.text+0xf1876): undefined reference to `mii_ethtool_sset'
drivers/built-in.o: In function `usbnet_get_settings':
(.text+0xf1836): undefined reference to `mii_ethtool_gset'
drivers/built-in.o: In function `usbnet_get_link':
(.text+0xf18d6): undefined reference to `mii_link_ok'
drivers/built-in.o: In function `usbnet_nway_reset':
(.text+0xf18f6): undefined reference to `mii_nway_restart'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
This bug was introduced by commit 18ee91fa9815fa3bb4e51cdcb8229bd0a0f11a70
and reported by Toralf Förster.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
BTW:
The Kconfig part of this patch is not really required, but testing for
#if defined(CONFIG_USB_USBNET_MII) || defined(CONFIG_USB_USBNET_MII_MODULE)
would look needlessly ugly.
drivers/net/usb/Kconfig | 5 ++---
drivers/net/usb/usbnet.c | 7 +++----
2 files changed, 5 insertions(+), 7 deletions(-)
a421e4910eb30b140a315e274632e87c7a218df6
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 5a96d74..9261371 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -94,12 +94,11 @@ config USB_RTL8150
module will be called rtl8150.
config USB_USBNET_MII
- tristate
- default n
+ bool
config USB_USBNET
tristate "Multi-purpose USB Networking Framework"
- select MII if USB_USBNET_MII != n
+ select MII if USB_USBNET_MII
---help---
This driver supports several kinds of network links over USB,
with "minidrivers" built around a common network driver core
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index acd5f1c..7393ab0 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -683,8 +683,7 @@ done_nopm:
* they'll probably want to use this base set.
*/
-#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
-#define HAVE_MII
+#ifdef CONFIG_USB_USBNET_MII
int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
{
@@ -744,7 +743,7 @@ int usbnet_nway_reset(struct net_device *net)
}
EXPORT_SYMBOL_GPL(usbnet_nway_reset);
-#endif /* HAVE_MII */
+#endif /* CONFIG_USB_USBNET_MII */
void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
{
@@ -776,7 +775,7 @@ EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
/* drivers may override default ethtool_ops in their bind() routine */
static struct ethtool_ops usbnet_ethtool_ops = {
-#ifdef HAVE_MII
+#ifdef CONFIG_USB_USBNET_MII
.get_settings = usbnet_get_settings,
.set_settings = usbnet_set_settings,
.get_link = usbnet_get_link,
^ permalink raw reply related
* Re: [PATCH 5/5] introduce udp_rmem and udp_wmem
From: Hideo AOKI @ 2007-11-02 15:42 UTC (permalink / raw)
To: Bill Fink
Cc: David Miller, netdev, Satoshi Oshima, Herbert Xu, Andi Kleen,
Stephen Hemminger, Evgeniy Polyakov, yoshfuji, Yumiko Sugita
In-Reply-To: <20071030005248.b0e6e9d2.billfink@mindspring.com>
Hello,
I'm sorry to not respond quickly.
Bill Fink wrote:
> On Mon, 29 Oct 2007, Hideo AOKI wrote:
>
>> This patch added /proc/sys/net/udp_rmem and /proc/sys/net/udp_rmem.
>> Each UDP packet is drooped when the number of pages for socket buffer
>> is beyond the limit and the socket already consumes minimum buffer.
>
> I think you meant /proc/sys/net/ipv4/udp_{r,w}mem above.
You're right. New parameters are added to /proc/sys/net/ipv4.
> Patch not in-lined making replying more difficult.
I apologize for the inconvenient. I'll send patch as in-line next time.
>>> +udp_rmem - INTEGER
>> + Minimal size of receive buffer used by UDP sockets. Each UDP socket
>> + is able to use the size for receiving data, even if total pages of UDP
>> + sockets exceed udp_mem. The unit is byte.
>> + Default: 4096
>> +
>> +udp_wmem - INTEGER
>> + Minimal size of send buffer used by UDP sockets. Each UDP socket is
>> + able to use the size for sending data, even if total pages of UDP
>> + sockets exceed udp_mem. The unit is byte.
>> + Default: 4096
>> +
>> CIPSOv4 Variables:
>>
>> cipso_cache_enable - BOOLEAN
>
> I think either the above should be renamed to udp_{r,w}mem_min, or
> they should be changed to a 3-tuple like tcp_{r,w}mem, and the code
> refactored accordingly (but then what to do about
> /proc/sys/net/core/{r,w}mem_max).
>
> -Bill
I understood. Then, I'll rename them to udp_{r,w}mem_min next take.
Please let me know if there is any suggestions.
Many thanks,
Hideo
--
Hitachi Computer Products (America) Inc.
^ permalink raw reply
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Olof Johansson @ 2007-11-02 16:03 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev, benh, jwboyer
In-Reply-To: <200711020814.43524.sr@denx.de>
On Fri, Nov 02, 2007 at 08:14:43AM +0100, Stefan Roese wrote:
> This patch adds support for the 405EX to the new EMAC driver. Some as on
> AXON, the 405EX handles the MDIO via the RGMII bridge.
Hi,
This isn't feedback on your patch as much as on "new-emac" in general:
Isn't this the case where there should really be device tree properties
instead? If you had an "ibm,emac-has-axon-stacr" property in the device
node, then you don't have to modify the driver for every new board out
there. Same for the other device properties, of course.
I thought this was what having the device tree was all about. :(
-Olof
^ permalink raw reply
* [PATCH 1/2][IPV4] Consolidate the ip cork destruction in ip_output.c
From: Pavel Emelyanov @ 2007-11-02 16:04 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
The ip_push_pending_frames and ip_flush_pending_frames do the
same things to flush the sock's cork. Move this into a separate
function and save ~80 bytes from the .text
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index e5f7dc2..fd99fbd 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1183,6 +1183,17 @@ error:
return err;
}
+static void ip_cork_release(struct inet_sock *inet)
+{
+ inet->cork.flags &= ~IPCORK_OPT;
+ kfree(inet->cork.opt);
+ inet->cork.opt = NULL;
+ if (inet->cork.rt) {
+ ip_rt_put(inet->cork.rt);
+ inet->cork.rt = NULL;
+ }
+}
+
/*
* Combined all pending IP fragments on the socket as one IP datagram
* and push them out.
@@ -1276,13 +1287,7 @@ int ip_push_pending_frames(struct sock *sk)
}
out:
- inet->cork.flags &= ~IPCORK_OPT;
- kfree(inet->cork.opt);
- inet->cork.opt = NULL;
- if (inet->cork.rt) {
- ip_rt_put(inet->cork.rt);
- inet->cork.rt = NULL;
- }
+ ip_cork_release(inet);
return err;
error:
@@ -1295,19 +1300,12 @@ error:
*/
void ip_flush_pending_frames(struct sock *sk)
{
- struct inet_sock *inet = inet_sk(sk);
struct sk_buff *skb;
while ((skb = __skb_dequeue_tail(&sk->sk_write_queue)) != NULL)
kfree_skb(skb);
- inet->cork.flags &= ~IPCORK_OPT;
- kfree(inet->cork.opt);
- inet->cork.opt = NULL;
- if (inet->cork.rt) {
- ip_rt_put(inet->cork.rt);
- inet->cork.rt = NULL;
- }
+ ip_cork_release(inet_sk(sk));
}
^ permalink raw reply related
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