Netdev List
 help / color / mirror / Atom feed
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Michael Chan @ 2010-06-17  3:53 UTC (permalink / raw)
  To: 'Mike Frysinger', James Bottomley
  Cc: netdev@vger.kernel.org, linux-parisc@vger.kernel.org,
	linux-kernel@vger.kernel.org, FUJITA Tomonori
In-Reply-To: <AANLkTilSfOwwT87mgDcWBogL4gPnM7VBTOALKpZv_upN@mail.gmail.com>

Mike Frysinger wrote:

> On Wed, Jun 16, 2010 at 9:13 PM, James Bottomley wrote:
> > I'm not quite sure whose fault this one is.
> >
> > However, this code in bnx2.c:
> >
> >                if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
> >                        next_rx_buf =
> >                                &rxr->rx_buf_ring[
> >                                        RX_RING_IDX(NEXT_RX_BD(sw_cons))];
> >                        prefetch(next_rx_buf->desc);
> >                }
> >
> > Looks remarkably fragile: what exactly is it trying to do?

If sync_single is not defined, that means the CPU has a consistent
view of next_rx_buf and so it makes sense to prefetch it.

> >
> > The commit that causes the problem:
> >
> > commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
> > Author: Michael Chan <mchan@broadcom.com>
> > Date:   Thu May 6 08:58:13 2010 +0000
> >
> >    bnx2: Add prefetches to rx path.
> >
> > Looks fairly innocuous by the description.
> >
> > Should parisc have a get_dma_ops()?  We don't need one
> because our dma
> > ops are per platform not per bus.
>
> looks like it'll be broken on more than just parisc:
> $ grep get_dma_ops arch/*/include/asm/ -rl | cut -d/ -f 2
> alpha
> ia64
> microblaze
> powerpc
> sh
> sparc
> x86

Most of these archs use the dma functions in:

<asm-genric/dma-mapping-common.h>

so it's not a problem.

I think I'll send in a patch to remove that part of the code
from bnx2.c for now.

Thanks.

^ permalink raw reply

* Re: ftp on udp and tcp .
From: Narendra Choyal @ 2010-06-17  2:31 UTC (permalink / raw)
  To: Ben Hutchings; +Cc: ratheesh k, netdev, linux-net
In-Reply-To: <1276602615.14011.464.camel@localhost>

TCP handles segmentation and bandwidth/congestion management.  It
recovers from packet loss and reordering. Recent implementations are
also quite resilient to address spoofing.  The downsides are higher
latency (potentially very high when recovering from packet loss), higher
setup cost (3-way handshake), and lack of multicast support.

UDP does none of that.  It gives you flexibility and control, but the
downside is you have to handle all of those problems yourself.

Its nice but.
Initial checking of availability for both active port & passive port.

^ permalink raw reply

* [PATCH] sky2: enable rx/tx in sky2_phy_reinit()
From: Brandon Philips @ 2010-06-17  2:21 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: netdev, davem

sky2_phy_reinit is called by the ethtool helpers sky2_set_settings,
sky2_nway_reset and sky2_set_pauseparam when netif_running.

However, at the end of sky2_phy_init GM_GP_CTRL has GM_GPCR_RX_ENA and
GM_GPCR_TX_ENA cleared. So, doing these commands causes the device to
stop working:

$ ethtool -r eth0
$ ethtool -A eth0 autoneg off

Fix this issue by enabling Rx/Tx after running sky2_phy_init in
sky2_phy_reinit.

Signed-off-by: Brandon Philips <bphilips@suse.de>
Tested-by: Brandon Philips <bphilips@suse.de>
Cc: stable@kernel.org

---
 drivers/net/sky2.c |   19 ++++++++++++++-----
 1 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 2111c7b..7985165 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -717,11 +717,24 @@ static void sky2_phy_power_down(struct sky2_hw *hw, unsigned port)
 	sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
 }
 
+/* Enable Rx/Tx */
+static void sky2_enable_rx_tx(struct sky2_port *sky2)
+{
+	struct sky2_hw *hw = sky2->hw;
+	unsigned port = sky2->port;
+	u16 reg;
+
+	reg = gma_read16(hw, port, GM_GP_CTRL);
+	reg |= GM_GPCR_RX_ENA | GM_GPCR_TX_ENA;
+	gma_write16(hw, port, GM_GP_CTRL, reg);
+}
+
 /* Force a renegotiation */
 static void sky2_phy_reinit(struct sky2_port *sky2)
 {
 	spin_lock_bh(&sky2->phy_lock);
 	sky2_phy_init(sky2->hw, sky2->port);
+	sky2_enable_rx_tx(sky2);
 	spin_unlock_bh(&sky2->phy_lock);
 }
 
@@ -2040,7 +2053,6 @@ static void sky2_link_up(struct sky2_port *sky2)
 {
 	struct sky2_hw *hw = sky2->hw;
 	unsigned port = sky2->port;
-	u16 reg;
 	static const char *fc_name[] = {
 		[FC_NONE]	= "none",
 		[FC_TX]		= "tx",
@@ -2048,10 +2060,7 @@ static void sky2_link_up(struct sky2_port *sky2)
 		[FC_BOTH]	= "both",
 	};
 
-	/* enable Rx/Tx */
-	reg = gma_read16(hw, port, GM_GP_CTRL);
-	reg |= GM_GPCR_RX_ENA | GM_GPCR_TX_ENA;
-	gma_write16(hw, port, GM_GP_CTRL, reg);
+	sky2_enable_rx_tx(sky2);
 
 	gm_phy_write(hw, port, PHY_MARV_INT_MASK, PHY_M_DEF_MSK);
 
-- 
1.7.1



^ permalink raw reply related

* Re: iputils flowlabel
From: YOSHIFUJI Hideaki @ 2010-06-17  2:20 UTC (permalink / raw)
  To: Jiri Skala; +Cc: netdev
In-Reply-To: <1272444708.3035.39.camel@localhost.localdomain>

Jiri Skala wrote:
> I'd like to ask about current state of FLOWLABEL functionality. This is
> currently wrapped into define and disabled by default.
> 
> Trying to enable it means to define (somehow = in proprietary header)
> in6_flowlabel_req structure because usage of linux/in6.h conflicts with
> glibc's headers.
> 
> Is flowlabel fnc inside ifdef due to described 'header' issue? Any other
> comment to this topic?

Yes, that's right.

--yoshfuji


^ permalink raw reply

* Re: [PATCH] iputils/ping_common.c: avoid gethostbyaddr during ping flood
From: YOSHIFUJI Hideaki @ 2010-06-17  2:08 UTC (permalink / raw)
  To: Chris Caputo; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.1006170104000.26819@nacho.alt.net>

Chris Caputo wrote:
> On Wed, 6 Feb 2008, Chris Caputo wrote:
>> Unless a destination is specified by IP address, a ping flood results in a 
>> gethostbyaddr() for every echo reply.  Thus a DNS flood can accompany a 
>> ping flood.
> 
> Updated for iputils-s20100418...  Can someone review and work into next 
> release?

Applied, thanks.

--yoshfuji


^ permalink raw reply

* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Mike Frysinger @ 2010-06-17  1:17 UTC (permalink / raw)
  To: James Bottomley
  Cc: netdev, linux-parisc, linux-kernel, FUJITA Tomonori, Michael Chan
In-Reply-To: <1276737229.2847.853.camel@mulgrave.site>

On Wed, Jun 16, 2010 at 9:13 PM, James Bottomley wrote:
> I'm not quite sure whose fault this one is.
>
> However, this code in bnx2.c:
>
>                if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
>                        next_rx_buf =
>                                &rxr->rx_buf_ring[
>                                        RX_RING_IDX(NEXT_RX_BD(sw_cons))];
>                        prefetch(next_rx_buf->desc);
>                }
>
> Looks remarkably fragile: what exactly is it trying to do?
>
> The commit that causes the problem:
>
> commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
> Author: Michael Chan <mchan@broadcom.com>
> Date:   Thu May 6 08:58:13 2010 +0000
>
>    bnx2: Add prefetches to rx path.
>
> Looks fairly innocuous by the description.
>
> Should parisc have a get_dma_ops()?  We don't need one because our dma
> ops are per platform not per bus.

looks like it'll be broken on more than just parisc:
$ grep get_dma_ops arch/*/include/asm/ -rl | cut -d/ -f 2
alpha
ia64
microblaze
powerpc
sh
sparc
x86
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" 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: [PATCH v2] ucc_geth: fix for RX skb buffers recycling
From: David Miller @ 2010-06-17  1:17 UTC (permalink / raw)
  To: geomatsi; +Cc: netdev, leoli, avorontsov
In-Reply-To: <20100614203520.23a02c25@realm>

From: Sergey Matyukevich <geomatsi@gmail.com>
Date: Mon, 14 Jun 2010 20:35:20 +0400

> This patch implements a proper modification of RX skb buffers before
> recycling. Adjusting only skb->data is not enough because after that
> skb->tail and skb->len become incorrect.
> 
> Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>

Applied, thanks.

^ permalink raw reply

* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: David Miller @ 2010-06-17  1:16 UTC (permalink / raw)
  To: JBottomley; +Cc: netdev, linux-parisc, linux-kernel, fujita.tomonori, mchan
In-Reply-To: <1276737229.2847.853.camel@mulgrave.site>

From: James Bottomley <JBottomley@Novell.com>
Date: Wed, 16 Jun 2010 20:13:49 -0500

> However, this code in bnx2.c:
> 
> 		if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
> 			next_rx_buf =
> 				&rxr->rx_buf_ring[
> 					RX_RING_IDX(NEXT_RX_BD(sw_cons))];
> 			prefetch(next_rx_buf->desc);
> 		}
> 
> Looks remarkably fragile: what exactly is it trying to do?
> 
> The commit that causes the problem:
> 
> commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
> Author: Michael Chan <mchan@broadcom.com>
> Date:   Thu May 6 08:58:13 2010 +0000
> 
>     bnx2: Add prefetches to rx path.
> 
> Looks fairly innocuous by the description.
> 
> Should parisc have a get_dma_ops()?  We don't need one because our dma
> ops are per platform not per bus.

I think asking for get_dma_ops() directly in a driver is dodgy at
best, especially one that is meant to compile on any PCI supporting
system.  At least right now.

^ permalink raw reply

* Re: [PATCH] iputils/ping_common.c: avoid gethostbyaddr during ping flood
From: Chris Caputo @ 2010-06-17  1:08 UTC (permalink / raw)
  To: netdev, Yoshifuji Hideaki
In-Reply-To: <Pine.LNX.4.64.0802061401370.31285@nacho.alt.net>

On Wed, 6 Feb 2008, Chris Caputo wrote:
> Unless a destination is specified by IP address, a ping flood results in a 
> gethostbyaddr() for every echo reply.  Thus a DNS flood can accompany a 
> ping flood.

Updated for iputils-s20100418...  Can someone review and work into next 
release?

Thanks,
Chris

---
Unless a destination is specified by IP address, a ping flood results in a
gethostbyaddr() for every echo reply.  Thus a DNS flood can accompany a
ping flood.

This patch makes it so a gethostbyaddr() is not performed with each echo
reply during a ping flood.

Signed-off-by: Chris Caputo <ccaputo@alt.net>
-------
--- iputils-s20100418/ping_common.c	2010-04-18 04:45:45.000000000 +0000
+++ iputils-dev/ping_common.c	2010-06-17 01:00:59.000000000 +0000
@@ -118,10 +118,6 @@ void common_options(int ch)
 	case 'D':
 		options |= F_PTIMEOFDAY;
 		break;
-	case 'f':
-		options |= F_FLOOD;
-		setbuf(stdout, (char *)NULL);
-		break;
 	case 'i':		/* wait between sending packets */
 	{
 		if (strchr(optarg, '.')) {
@@ -183,6 +179,10 @@ void common_options(int ch)
 			exit(2);
 		}
 		break;
+	case 'f':
+		options |= F_FLOOD;
+		setbuf(stdout, (char *)NULL);
+		/* fallthrough to numeric - avoid gethostbyaddr during flood */
 	case 'n':
 		options |= F_NUMERIC;
 		break;

^ permalink raw reply

* bnx2 fails to compile on parisc because of missing get_dma_ops()
From: James Bottomley @ 2010-06-17  1:13 UTC (permalink / raw)
  To: netdev, linux-parisc, linux-kernel, FUJITA Tomonori; +Cc: Michael Chan

I'm not quite sure whose fault this one is.

However, this code in bnx2.c:

		if (!get_dma_ops(&pdev->dev)->sync_single_for_cpu) {
			next_rx_buf =
				&rxr->rx_buf_ring[
					RX_RING_IDX(NEXT_RX_BD(sw_cons))];
			prefetch(next_rx_buf->desc);
		}

Looks remarkably fragile: what exactly is it trying to do?

The commit that causes the problem:

commit a33fa66bcf365ffe5b79d1ae1d3582cc261ae56e
Author: Michael Chan <mchan@broadcom.com>
Date:   Thu May 6 08:58:13 2010 +0000

    bnx2: Add prefetches to rx path.

Looks fairly innocuous by the description.

Should parisc have a get_dma_ops()?  We don't need one because our dma
ops are per platform not per bus.

James



^ permalink raw reply

* Re: [PATCH net-next-2.6] be2net: enable ipv6 tso support
From: David Miller @ 2010-06-17  1:13 UTC (permalink / raw)
  To: ajitk; +Cc: netdev
In-Reply-To: <20100614145557.GA12552@serverengines.com>

From: Ajit Khaparde <ajitk@serverengines.com>
Date: Mon, 14 Jun 2010 20:26:07 +0530

> Add ipv6 support to the be2net driver.
> 
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>

Applied, thanks.

^ permalink raw reply

* Re: Broken rndis_host with #define DEBUG (by a475f603d23392f386e45cf377b17c30ed3bbb80)
From: David Miller @ 2010-06-17  1:11 UTC (permalink / raw)
  To: david-b; +Cc: jussi.kivilinna, joe, netdev, dbrownell
In-Reply-To: <299618.58880.qm@web180304.mail.gq1.yahoo.com>

From: David Brownell <david-b@pacbell.net>
Date: Sat, 12 Jun 2010 19:49:27 -0700 (PDT)

> --- On Sat, 6/12/10, Joe Perches <joe@perches.com> wrote:
> 
>> > rndis_host oopses with #define DEBUG, in
>> generic_rndis_bind() when  
>> > calling netif_dbg(). Problem is that
>> (netdev)->dev.parent is NULL
> 
>> > (used in netdev_printk) while generic_rndis_bind is
>> called.Thanks.
> 
> Should have been assigned by SET_NETDEV_DEV()
> in usbnet_probe() ... before calling the
> bind() routine
> 
> Maybe just moving that SET_NETDEV_DEV earlier
> would suffice.

Can someone please submit a patch which does this?

Thanks!

^ permalink raw reply

* Re: [PATCH kernel 2.6.35-rc2] pcnet_cs: add new id (TOSHIBA Modem/LAN Card)
From: David Miller @ 2010-06-17  1:11 UTC (permalink / raw)
  To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20100612191728.2d272cc1.ken_kawasaki@spring.nifty.jp>

From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sat, 12 Jun 2010 19:17:28 +0900

> 
> pcnet_cs:
> serial_cs:
>     add new id (TOSHIBA Modem/LAN Card)
> 
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] gianfar: Fix oversized packets handling
From: David Miller @ 2010-06-17  1:09 UTC (permalink / raw)
  To: avorontsov; +Cc: Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100611205103.GA4255@oksana.dev.rtsoft.ru>

From: Anton Vorontsov <avorontsov@mvista.com>
Date: Sat, 12 Jun 2010 00:51:03 +0400

> Issuing the following command on host:
> 
> $ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1
> 
> Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0)
> oops like this:
 ...
> Dumped buffer descriptors showed that eTSEC's length/truncation
> logic sometimes passes oversized packets, i.e. for the above ICMP
> packet the following two buffer descriptors may become ready:
> 
>   status=1400 length=1536
>   status=1800 length=1541
> 
> So, it seems that gianfar actually receives the whole big frame,
> and it tries to place the packet into two BDs. This situation
> confuses the driver, and so the skb_put() sanity check fails.
> 
> This patch fixes the issue by adding an appropriate check, i.e.
> the driver should not try to process frames with buffer
> descriptor's length over rx_buffer_size (i.e. maxfrm and mrblr).
> 
> Note that sometimes eTSEC works correctly, i.e. in the second
> (last) buffer descriptor bits 'truncated' and 'crcerr' are set,
> and so there's no oops. Though I couldn't find any logic when
> it works correctly and when not.
> 
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>

Applied, thanks Anton.

^ permalink raw reply

* Re: udp: Add UFO to NETIF_F_SOFTWARE_GSO
From: David Miller @ 2010-06-17  1:08 UTC (permalink / raw)
  To: herbert; +Cc: netdev
In-Reply-To: <20100615062104.GA4779@gondor.apana.org.au>

From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 15 Jun 2010 16:21:04 +1000

> udp: Add UFO to NETIF_F_SOFTWARE_GSO
> 
> This patch adds UFO to the list of GSO features with a software
> fallback.  This allows UFO to be used even if the hardware does
> not support it.
> 
> In particular, this allows us to test the UFO fallback, as it
> has been reported to not work in some cases.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Applied to net-next-2.6, thanks.

^ permalink raw reply

* Re: [PATCH 2/2] ehea: Fix kernel deadlock in DLPAR-mem processing
From: David Miller @ 2010-06-17  1:05 UTC (permalink / raw)
  To: ossthema; +Cc: netdev, linuxppc-dev, linux-kernel, tklein, adetsch, themann
In-Reply-To: <201006151735.43144.ossthema@de.ibm.com>

From: "Jan-Bernd Themann" <ossthema@de.ibm.com>
Date: Tue, 15 Jun 2010 17:35:42 +0200

> Port reset operations and memory add/remove operations need to 
> be serialized to avoid a kernel deadlock. The deadlock is caused
> by calling the napi_disable() function twice.
> Therefore we have to employ the dlpar_mem_lock in the ehea_reset_port
> function as well
> 
> 
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>

Applied.

^ permalink raw reply

* Re: [PATCH 1/2] ehea: fix delayed packet processing
From: David Miller @ 2010-06-17  1:05 UTC (permalink / raw)
  To: fubar
  Cc: ossthema, netdev, linuxppc-dev, linux-kernel, tklein, adetsch,
	themann
In-Reply-To: <6663.1276620347@death.nxdomain.ibm.com>

From: Jay Vosburgh <fubar@us.ibm.com>
Date: Tue, 15 Jun 2010 09:45:47 -0700

> Jan-Bernd Themann <ossthema@de.ibm.com> wrote:
> 
>>In the eHEA poll function an rmb() is required. Without that some packets
>>on the receive queue are not seen and thus delayed until the next interrupt
>>is handled for the same receive queue.
>>
>>Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
> 
> 	To add a bit of background, this could manifest during a netperf
> TCP_RR or UDP_RR on an otherwise idle network.  TCP would occasionally
> retransmit, but then both the original segment and the retransmission
> would simultaneously appear at the receiver.  For UDP_RR, message sizes
> in excess of the mtu would occasionally "lose" an IP fragment, and
> eventually IP reassembly would time out.
> 
> 	-J
> 
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>

Applied.

^ permalink raw reply

* Re: [PATCH 04/12] phylib: add a way to make PHY time stamps possible.
From: David Miller @ 2010-06-17  1:03 UTC (permalink / raw)
  To: richardcochran
  Cc: netdev, linuxppc-dev, devicetree-discuss, khc, linux-arm-kernel
In-Reply-To: <27c0ad283f025c2bb71e7ceb71be07f969939429.1276615626.git.richard.cochran@omicron.at>

From: Richard Cochran <richardcochran@gmail.com>
Date: Tue, 15 Jun 2010 18:08:20 +0200

> +static inline void skb_tx_timetamp(struct phy_device *phy, struct sk_buff *skb)
> +{
> +	union skb_shared_tx *shtx = skb_tx(skb);
> +
> +	if (shtx->hardware && phy && phy->drv->txtstamp)
> +		phy->drv->txtstamp(phy, skb);
> +
> +	if (shtx->software && !shtx->in_progress)
> +		skb_tstamp_tx(skb, NULL);
> +}
> +
> +static inline void skb_rx_timetamp(struct phy_device *phy, struct sk_buff *skb)
> +{
> +	if (phy && phy->drv->rxtstamp)
> +		phy->drv->rxtstamp(phy, skb);
> +}

Since, as you say, this can provide a way to deal with the sw TX
timestamping sequencing problem we have right now, I'd rather
you implement this from the inside out instead of from the
outside in.

By this I mean you should provide these inline helpers by default
then we can begin to put them into the drivers.

You could also split the SW tstamp handling into a seperate inline
function, which drivers call immediately once they know they will
actually give the packet to the hardware for sending.

^ permalink raw reply

* Re: [PATCH net-next 0/9] cxgb4 update
From: David Miller @ 2010-06-17  0:48 UTC (permalink / raw)
  To: dm; +Cc: netdev
In-Reply-To: <20100616.174527.35032483.davem@davemloft.net>

From: David Miller <davem@davemloft.net>
Date: Wed, 16 Jun 2010 17:45:27 -0700 (PDT)

> From: Dimitris Michailidis <dm@chelsio.com>
> Date: Wed, 16 Jun 2010 15:01:07 -0700
> 
>> 
>> Here's a series of 9 patches for the cxgb4 driver.  The changes include
>> support for larger flash memories, addition of EEH, an update to latest
>> fw api, and assorted few liners.  All patches are for net-next.
> 
> All applied, thanks.

Actually, I'm reverting, this breaks the infiniband driver build:

drivers/infiniband/hw/cxgb4/qp.c: In function 'post_terminate':
drivers/infiniband/hw/cxgb4/qp.c:882:18: error: 'FW_RI_INIT_WR' undeclared (first use in this function)
drivers/infiniband/hw/cxgb4/qp.c:882:18: note: each undeclared identifier is reported only once for each function it appears in
drivers/infiniband/hw/cxgb4/qp.c: In function 'rdma_fini':
drivers/infiniband/hw/cxgb4/qp.c:971:18: error: 'FW_RI_INIT_WR' undeclared (first use in this function)
drivers/infiniband/hw/cxgb4/qp.c: In function 'rdma_init':
drivers/infiniband/hw/cxgb4/qp.c:1045:18: error: 'FW_RI_INIT_WR' undeclared (first use in this function)
make[3]: *** [drivers/infiniband/hw/cxgb4/qp.o] Error 1

^ permalink raw reply

* Re: [PATCH net-next 0/9] cxgb4 update
From: David Miller @ 2010-06-17  0:45 UTC (permalink / raw)
  To: dm; +Cc: netdev
In-Reply-To: <1276725676-31514-1-git-send-email-dm@chelsio.com>

From: Dimitris Michailidis <dm@chelsio.com>
Date: Wed, 16 Jun 2010 15:01:07 -0700

> 
> Here's a series of 9 patches for the cxgb4 driver.  The changes include
> support for larger flash memories, addition of EEH, an update to latest
> fw api, and assorted few liners.  All patches are for net-next.

All applied, thanks.

^ permalink raw reply

* [net-next-2.6 PATCH] net: consolidate netif_needs_gso() checks
From: Jeff Kirsher @ 2010-06-17  0:18 UTC (permalink / raw)
  To: davem; +Cc: netdev, gospo, bphilips, John Fastabend, Herbert Xu, Jeff Kirsher

From: John Fastabend <john.r.fastabend@intel.com>

netif_needs_gso() is checked twice in the TX path once,
before submitting the skb to the qdisc and once after
it is dequeued from the qdisc just before calling
ndo_hard_start().  This opens a window for a user to
change the gso/tso or tx checksum settings that can
cause netif_needs_gso to be true in one check and false
in the other.

Specifically, changing TX checksum setting may cause
the warning in skb_gso_segment() to be triggered if
the checksum is calculated earlier.

This consolidates the netif_needs_gso() calls so that
the stack only checks if gso is needed in
dev_hard_start_xmit().

Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 net/core/dev.c |   68 ++++++++++++++++++++++++++------------------------------
 1 files changed, 32 insertions(+), 36 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 5902426..7f390b5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1895,6 +1895,22 @@ static inline void skb_orphan_try(struct sk_buff *skb)
 		skb_orphan(skb);
 }
 
+/*
+ * Returns true if either:
+ *	1. skb has frag_list and the device doesn't support FRAGLIST, or
+ *	2. skb is fragmented and the device does not support SG, or if
+ *	   at least one of fragments is in highmem and device does not
+ *	   support DMA from it.
+ */
+static inline int skb_needs_linearize(struct sk_buff *skb,
+				      struct net_device *dev)
+{
+	return skb_is_nonlinear(skb) &&
+	       ((skb_has_frags(skb) && !(dev->features & NETIF_F_FRAGLIST)) ||
+	        (skb_shinfo(skb)->nr_frags && (!(dev->features & NETIF_F_SG) ||
+					      illegal_highdma(dev, skb))));
+}
+
 int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
 			struct netdev_queue *txq)
 {
@@ -1919,6 +1935,22 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
 				goto out_kfree_skb;
 			if (skb->next)
 				goto gso;
+		} else {
+			if (skb_needs_linearize(skb, dev) &&
+			    __skb_linearize(skb))
+				goto out_kfree_skb;
+
+			/* If packet is not checksummed and device does not
+			 * support checksumming for this protocol, complete
+			 * checksumming here.
+			 */
+			if (skb->ip_summed == CHECKSUM_PARTIAL) {
+				skb_set_transport_header(skb, skb->csum_start -
+					      skb_headroom(skb));
+				if (!dev_can_checksum(dev, skb) &&
+				     skb_checksum_help(skb))
+					goto out_kfree_skb;
+			}
 		}
 
 		rc = ops->ndo_start_xmit(skb, dev);
@@ -2089,22 +2121,6 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
 	return rc;
 }
 
-/*
- * Returns true if either:
- *	1. skb has frag_list and the device doesn't support FRAGLIST, or
- *	2. skb is fragmented and the device does not support SG, or if
- *	   at least one of fragments is in highmem and device does not
- *	   support DMA from it.
- */
-static inline int skb_needs_linearize(struct sk_buff *skb,
-				      struct net_device *dev)
-{
-	return skb_is_nonlinear(skb) &&
-	       ((skb_has_frags(skb) && !(dev->features & NETIF_F_FRAGLIST)) ||
-	        (skb_shinfo(skb)->nr_frags && (!(dev->features & NETIF_F_SG) ||
-					      illegal_highdma(dev, skb))));
-}
-
 /**
  *	dev_queue_xmit - transmit a buffer
  *	@skb: buffer to transmit
@@ -2137,25 +2153,6 @@ int dev_queue_xmit(struct sk_buff *skb)
 	struct Qdisc *q;
 	int rc = -ENOMEM;
 
-	/* GSO will handle the following emulations directly. */
-	if (netif_needs_gso(dev, skb))
-		goto gso;
-
-	/* Convert a paged skb to linear, if required */
-	if (skb_needs_linearize(skb, dev) && __skb_linearize(skb))
-		goto out_kfree_skb;
-
-	/* If packet is not checksummed and device does not support
-	 * checksumming for this protocol, complete checksumming here.
-	 */
-	if (skb->ip_summed == CHECKSUM_PARTIAL) {
-		skb_set_transport_header(skb, skb->csum_start -
-					      skb_headroom(skb));
-		if (!dev_can_checksum(dev, skb) && skb_checksum_help(skb))
-			goto out_kfree_skb;
-	}
-
-gso:
 	/* Disable soft irqs for various locks below. Also
 	 * stops preemption for RCU.
 	 */
@@ -2214,7 +2211,6 @@ gso:
 	rc = -ENETDOWN;
 	rcu_read_unlock_bh();
 
-out_kfree_skb:
 	kfree_skb(skb);
 	return rc;
 out:


^ permalink raw reply related

* Re: [PATCH net-2.6] ixgbe: fix panic when shutting down system with WoL enabled
From: Jeff Kirsher @ 2010-06-16 23:54 UTC (permalink / raw)
  To: Andy Gospodarek; +Cc: netdev
In-Reply-To: <20100616200102.GP7497@gospo.rdu.redhat.com>

On Wed, Jun 16, 2010 at 13:01, Andy Gospodarek <andy@greyhouse.net> wrote:
>
> This patch added to 2.6.34:
>
>        commit 5f6c01819979afbfec7e0b15fe52371b8eed87e8
>        Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
>        Date:   Wed Apr 14 16:04:23 2010 -0700
>
>            ixgbe: fix bug with vlan strip in promsic mode
>
> among other things added a function called ixgbe_vlan_filter_enable.
> This new function wants to access and set some rx_ring parameters, but
> adapter->rx_ring has already been freed.  This simply moves the free
> until after the access and makes __ixgbe_shutdown look more like
> ixgbe_remove.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> ---
>  drivers/net/ixgbe/ixgbe_main.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
> index ce30c62..e237748 100644
> --- a/drivers/net/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ixgbe/ixgbe_main.c
> @@ -5195,7 +5195,6 @@ static int __ixgbe_shutdown(struct pci_dev *pdev, bool *enable_wake)
>                ixgbe_free_all_tx_resources(adapter);
>                ixgbe_free_all_rx_resources(adapter);
>        }
> -       ixgbe_clear_interrupt_scheme(adapter);
>
>  #ifdef CONFIG_PM
>        retval = pci_save_state(pdev);
> @@ -5230,6 +5229,8 @@ static int __ixgbe_shutdown(struct pci_dev *pdev, bool *enable_wake)
>
>        *enable_wake = !!wufc;
>
> +       ixgbe_clear_interrupt_scheme(adapter);
> +
>        ixgbe_release_hw_control(adapter);
>
>        pci_disable_device(pdev);
> --
> 1.6.2.5
>

Thanks Andy, I have added the patch to my queue.

-- 
Cheers,
Jeff

^ permalink raw reply

* Re: [net-next-2.6 PATCH 6/8] e1000e: enable support for EEE on 82579
From: Ben Hutchings @ 2010-06-16 23:52 UTC (permalink / raw)
  To: Jeff Kirsher; +Cc: davem, netdev, gospo, bphilips, Bruce Allan
In-Reply-To: <20100616232747.4834.46491.stgit@localhost.localdomain>

On Wed, 2010-06-16 at 16:27 -0700, Jeff Kirsher wrote:
> From: Bruce Allan <bruce.w.allan@intel.com>
> 
> This patch enables IEEE802.3az (a.k.a. Energy Efficient Ethernet) on the
> new 82579 LOMs.  An optional module parameter is provided to disable the
> feature if desired.
[...]

IEEE802.3az has not been finalised and I heard that some significant
changes are still required relative to the latest draft.  Given that,
any current implementation may not be interoperable with PHYs that
implement the final standard and it doesn't seem like a great idea to
enable it by default.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


^ permalink raw reply

* Re: [PATCH 0/8] Support unix domain sockets across namespaces
From: Eric W. Biederman @ 2010-06-16 23:32 UTC (permalink / raw)
  To: David Miller; +Cc: serue, containers, daniel.lezcano, netdev, xemul
In-Reply-To: <20100616.161706.229750834.davem@davemloft.net>

David Miller <davem@davemloft.net> writes:

> From: David Miller <davem@davemloft.net>
> Date: Wed, 16 Jun 2010 15:15:36 -0700 (PDT)
>
>> From: ebiederm@xmission.com (Eric W. Biederman)
>> Date: Sun, 13 Jun 2010 06:25:32 -0700
>> 
>>> This patchset takes a addressing all of the issues that crop up with
>>> unix domain sockets when the senders and receivers are in separate
>>> namespaces.
>>> 
>>> Without this patchset we can report the wrong pid and uid
>>> values in our unix domain credentials.
>>> 
>>> As a finally this patchset removes the now unnecessary restriction
>>> that we only allow unix domain sockets between processes in the
>>> same network namespace.
>> 
>> Looks good, all applied to net-next-2.6, thanks Eric.
>
> I had to add a module export of cred_to_ucread to fix the allmodconfig
> build since AF_UNIX makes a reference to it.

Doh!  Thank you for catching that.

My apologies for overlooking the allmodconfig case.

Eric


^ permalink raw reply

* [net-next-2.6 PATCH 8/8] e1000e: update driver version number
From: Jeff Kirsher @ 2010-06-16 23:28 UTC (permalink / raw)
  To: davem; +Cc: netdev, gospo, bphilips, Bruce Allan, Jeff Kirsher
In-Reply-To: <20100616232523.4834.84849.stgit@localhost.localdomain>

From: Bruce Allan <bruce.w.allan@intel.com>

Also separate out an _EXTRAVERSION similar to the core kernel.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 drivers/net/e1000e/netdev.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 77747c7..8faf224 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -52,7 +52,9 @@
 
 #include "e1000.h"
 
-#define DRV_VERSION "1.0.2-k4"
+#define DRV_EXTRAVERSION "-k2"
+
+#define DRV_VERSION "1.2.7" DRV_EXTRAVERSION
 char e1000e_driver_name[] = "e1000e";
 const char e1000e_driver_version[] = DRV_VERSION;
 


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox