* 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
* 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 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 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 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: 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] 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: [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: 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 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
* 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] 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
* 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 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: 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] 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: 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
* [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: 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
* 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: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Mike Frysinger @ 2010-06-17 4:00 UTC (permalink / raw)
To: Michael Chan
Cc: James Bottomley, netdev@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
FUJITA Tomonori
In-Reply-To: <C27F8246C663564A84BB7AB3439772421B79CBCA1C@IRVEXCHCCR01.corp.ad.broadcom.com>
On Wed, Jun 16, 2010 at 11:53 PM, Michael Chan wrote:
> Mike Frysinger wrote:
>> > 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.
the grep is showing only the arches that define get_dma_ops (and so
the new code works). you'd have to invert the list to see the ones
which do not define get_dma_ops(), and the inverted list is larger.
that was merely my point.
-mike
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Paul Mundt @ 2010-06-17 4:03 UTC (permalink / raw)
To: Michael Chan
Cc: 'Mike Frysinger', James Bottomley, netdev@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
FUJITA Tomonori
In-Reply-To: <C27F8246C663564A84BB7AB3439772421B79CBCA1C@IRVEXCHCCR01.corp.ad.broadcom.com>
On Wed, Jun 16, 2010 at 08:53:57PM -0700, Michael Chan wrote:
> 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.
>
Except that's not a valid assertion, there are platforms that implement
it for sanity checks yet still have consistent DMA. You are making
inherently non-portable assumptions for a PCI driver, which is a good
example of why drivers should never be side-stepping the API in the first
place. If you want to have a micro-optimization for the consistent DMA
case, you can check dma_is_consistent(), which is part of the API and
will be variable on certain platform configurations (ie, some may be
consistent with PCI but not on other busses, etc.)
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: Michael Chan @ 2010-06-17 4:10 UTC (permalink / raw)
To: 'Paul Mundt'
Cc: 'Mike Frysinger', James Bottomley, netdev@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
FUJITA Tomonori
In-Reply-To: <20100617040356.GA8105@linux-sh.org>
Paul Mundt wrote:
> On Wed, Jun 16, 2010 at 08:53:57PM -0700, Michael Chan wrote:
> > 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.
> >
> Except that's not a valid assertion, there are platforms that
> implement
> it for sanity checks yet still have consistent DMA. You are making
> inherently non-portable assumptions for a PCI driver, which is a good
> example of why drivers should never be side-stepping the API
> in the first
> place. If you want to have a micro-optimization for the consistent DMA
> case, you can check dma_is_consistent(), which is part of the API and
> will be variable on certain platform configurations (ie, some may be
> consistent with PCI but not on other busses, etc.)
>
>
Thanks for the tip. I didn't know about the dma_is_consistent() API.
I'll use this to fix it then.
^ permalink raw reply
* Re: bnx2 fails to compile on parisc because of missing get_dma_ops()
From: James Bottomley @ 2010-06-17 4:20 UTC (permalink / raw)
To: Michael Chan
Cc: 'Mike Frysinger', netdev@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
FUJITA Tomonori
In-Reply-To: <C27F8246C663564A84BB7AB3439772421B79CBCA1C@IRVEXCHCCR01.corp.ad.broadcom.com>
On Wed, 2010-06-16 at 20:53 -0700, Michael Chan wrote:
> 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.
That's not entirely a correct statement. Many architectures make a DMA
area coherent by turning off the CPU cache over it. In that case,
prefetching makes absolutely no sense (although it usually works but is
a nop).
> > > 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.
Parisc begs to differ.
Plus you're making assumptions about the contents of the ops structure
which is an internal architecture object ... that's bound to run into
portability problems even if we make it compile on all platform.
> I think I'll send in a patch to remove that part of the code
> from bnx2.c for now.
I think that's the best solution.
James
^ permalink raw reply
* RE: mpd client timeouts (bisected) 2.6.35-rc3
From: Shi, Alex @ 2010-06-17 5:16 UTC (permalink / raw)
To: Fastabend, John R, David Miller, markus@trippelsdorf.de
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
yanmin_zhang@linux.intel.com, Chen, Tim C
In-Reply-To: <4C15414E.5090201@intel.com>
It fixed the aim7/specjbb2005 issues!
Tested-by: Alex Shi <alex.shi@intel.com>
Regards!
Alex
>
>Needed to set the wcard bit in copy_skb_header otherwise it will not be cleared
>when called from skb_clone. Which then hits the loopback device gets pushed
>into the rx path and is eventually dropped. The following patch fixes this.
>Hopefully, this is easy and fast enough for you Dave.
>
>
>[PATCH] net: fix deliver_no_wcard regression on loopback device
>
>deliver_no_wcard is not being set in skb_copy_header.
>In the skb_cloned case it is not being cleared and
>may cause the skb to be dropped when the loopback device
>pushes it back up the stack.
>
>Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>---
>
> net/core/skbuff.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
>diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>index 9f07e74..bcf2fa3 100644
>--- a/net/core/skbuff.c
>+++ b/net/core/skbuff.c
>@@ -532,6 +532,7 @@ static void __copy_skb_header(struct sk_buff *new, const
>struct sk_buff *old)
> new->ip_summed = old->ip_summed;
> skb_copy_queue_mapping(new, old);
> new->priority = old->priority;
>+ new->deliver_no_wcard = old->deliver_no_wcard;
> #if defined(CONFIG_IP_VS) || defined(CONFIG_IP_VS_MODULE)
> new->ipvs_property = old->ipvs_property;
> #endif
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox