* [net-next,v4 09/12] bna: MBOX IRQ Flag Check after Locking
From: Rasesh Mody @ 2011-08-23 17:56 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody, Gurunatha Karaje
In-Reply-To: <1314122168-14314-1-git-send-email-rmody@brocade.com>
Change details:
- Check the BNAD_RF_MBOX_IRQ_DISABLED flag after acquiring the bna_lock.
Signed-off-by: Gurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/ethernet/brocade/bna/bnad.c | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index cf4e09c..ccc2cad 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -582,10 +582,11 @@ bnad_msix_mbox_handler(int irq, void *data)
unsigned long flags;
struct bnad *bnad = (struct bnad *)data;
- if (unlikely(test_bit(BNAD_RF_MBOX_IRQ_DISABLED, &bnad->run_flags)))
- return IRQ_HANDLED;
-
spin_lock_irqsave(&bnad->bna_lock, flags);
+ if (unlikely(test_bit(BNAD_RF_MBOX_IRQ_DISABLED, &bnad->run_flags))) {
+ spin_unlock_irqrestore(&bnad->bna_lock, flags);
+ return IRQ_HANDLED;
+ }
bna_intr_status_get(&bnad->bna, intr_status);
@@ -608,15 +609,18 @@ bnad_isr(int irq, void *data)
struct bnad_rx_ctrl *rx_ctrl;
struct bna_tcb *tcb = NULL;
- if (unlikely(test_bit(BNAD_RF_MBOX_IRQ_DISABLED, &bnad->run_flags)))
+ spin_lock_irqsave(&bnad->bna_lock, flags);
+ if (unlikely(test_bit(BNAD_RF_MBOX_IRQ_DISABLED, &bnad->run_flags))) {
+ spin_unlock_irqrestore(&bnad->bna_lock, flags);
return IRQ_NONE;
+ }
bna_intr_status_get(&bnad->bna, intr_status);
- if (unlikely(!intr_status))
+ if (unlikely(!intr_status)) {
+ spin_unlock_irqrestore(&bnad->bna_lock, flags);
return IRQ_NONE;
-
- spin_lock_irqsave(&bnad->bna_lock, flags);
+ }
if (BNA_IS_MBOX_ERR_INTR(&bnad->bna, intr_status))
bna_mbox_handler(&bnad->bna, intr_status);
--
1.7.1
^ permalink raw reply related
* [net-next,v4 08/12] bna: Async Mode Tx Rx Init Fix
From: Rasesh Mody @ 2011-08-23 17:56 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody, Gurunatha Karaje
In-Reply-To: <1314122168-14314-1-git-send-email-rmody@brocade.com>
Change details:
- Async mode of Tx/Rx queue initialization in BNAD from a task queue context
runs into non-unique taskq allocation issues. Get rid of Tx/Rx
initialization from task q context
- In the attach function, wait for IOC enable, then do Tx/Rx queue
initialization. Default BNA attributes are used when IOC enable from attach
fails and values are set to:
1 TxQ, 1 RxQ, 1 Unicast MAC, 1 RIT entry
Signed-off-by: Gurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/ethernet/brocade/bna/bna_enet.c | 29 ++++++++++++++++++-----
drivers/net/ethernet/brocade/bna/bna_hw_defs.h | 4 +++
drivers/net/ethernet/brocade/bna/bna_types.h | 1 +
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bna_enet.c b/drivers/net/ethernet/brocade/bna/bna_enet.c
index 68a275d..26f5c5a 100644
--- a/drivers/net/ethernet/brocade/bna/bna_enet.c
+++ b/drivers/net/ethernet/brocade/bna/bna_enet.c
@@ -167,13 +167,14 @@ bna_bfi_attr_get_rsp(struct bna_ioceth *ioceth,
* Store only if not set earlier, since BNAD can override the HW
* attributes
*/
- if (!ioceth->attr.num_txq)
+ if (!ioceth->attr.fw_query_complete) {
ioceth->attr.num_txq = ntohl(rsp->max_cfg);
- if (!ioceth->attr.num_rxp)
ioceth->attr.num_rxp = ntohl(rsp->max_cfg);
- ioceth->attr.num_ucmac = ntohl(rsp->max_ucmac);
- ioceth->attr.num_mcmac = BFI_ENET_MAX_MCAM;
- ioceth->attr.max_rit_size = ntohl(rsp->rit_size);
+ ioceth->attr.num_ucmac = ntohl(rsp->max_ucmac);
+ ioceth->attr.num_mcmac = BFI_ENET_MAX_MCAM;
+ ioceth->attr.max_rit_size = ntohl(rsp->rit_size);
+ ioceth->attr.fw_query_complete = true;
+ }
bfa_fsm_send_event(ioceth, IOCETH_E_ENET_ATTR_RESP);
}
@@ -1693,6 +1694,16 @@ static struct bfa_ioc_cbfn bna_ioceth_cbfn = {
bna_cb_ioceth_reset
};
+static void bna_attr_init(struct bna_ioceth *ioceth)
+{
+ ioceth->attr.num_txq = BFI_ENET_DEF_TXQ;
+ ioceth->attr.num_rxp = BFI_ENET_DEF_RXP;
+ ioceth->attr.num_ucmac = BFI_ENET_DEF_UCAM;
+ ioceth->attr.num_mcmac = BFI_ENET_MAX_MCAM;
+ ioceth->attr.max_rit_size = BFI_ENET_DEF_RITSZ;
+ ioceth->attr.fw_query_complete = false;
+}
+
static void
bna_ioceth_init(struct bna_ioceth *ioceth, struct bna *bna,
struct bna_res_info *res_info)
@@ -1738,6 +1749,8 @@ bna_ioceth_init(struct bna_ioceth *ioceth, struct bna *bna,
ioceth->stop_cbfn = NULL;
ioceth->stop_cbarg = NULL;
+ bna_attr_init(ioceth);
+
bfa_fsm_set_state(ioceth, bna_ioceth_sm_stopped);
}
@@ -2036,7 +2049,8 @@ bna_uninit(struct bna *bna)
int
bna_num_txq_set(struct bna *bna, int num_txq)
{
- if (num_txq > 0 && (num_txq <= bna->ioceth.attr.num_txq)) {
+ if (bna->ioceth.attr.fw_query_complete &&
+ (num_txq <= bna->ioceth.attr.num_txq)) {
bna->ioceth.attr.num_txq = num_txq;
return BNA_CB_SUCCESS;
}
@@ -2047,7 +2061,8 @@ bna_num_txq_set(struct bna *bna, int num_txq)
int
bna_num_rxp_set(struct bna *bna, int num_rxp)
{
- if (num_rxp > 0 && (num_rxp <= bna->ioceth.attr.num_rxp)) {
+ if (bna->ioceth.attr.fw_query_complete &&
+ (num_rxp <= bna->ioceth.attr.num_rxp)) {
bna->ioceth.attr.num_rxp = num_rxp;
return BNA_CB_SUCCESS;
}
diff --git a/drivers/net/ethernet/brocade/bna/bna_hw_defs.h b/drivers/net/ethernet/brocade/bna/bna_hw_defs.h
index 7ecdca5..dde8a46 100644
--- a/drivers/net/ethernet/brocade/bna/bna_hw_defs.h
+++ b/drivers/net/ethernet/brocade/bna/bna_hw_defs.h
@@ -30,6 +30,10 @@
* SW imposed limits
*
*/
+#define BFI_ENET_DEF_TXQ 1
+#define BFI_ENET_DEF_RXP 1
+#define BFI_ENET_DEF_UCAM 1
+#define BFI_ENET_DEF_RITSZ 1
#define BFI_ENET_MAX_MCAM 256
diff --git a/drivers/net/ethernet/brocade/bna/bna_types.h b/drivers/net/ethernet/brocade/bna/bna_types.h
index 59417b1..242d799 100644
--- a/drivers/net/ethernet/brocade/bna/bna_types.h
+++ b/drivers/net/ethernet/brocade/bna/bna_types.h
@@ -323,6 +323,7 @@ struct bna_qpt {
};
struct bna_attr {
+ bool fw_query_complete;
int num_txq;
int num_rxp;
int num_ucmac;
--
1.7.1
^ permalink raw reply related
* [net-next,v4 11/12] bna: SKB PCI UNMAP Fix
From: Rasesh Mody @ 2011-08-23 17:56 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody, Gurunatha Karaje
In-Reply-To: <1314122168-14314-1-git-send-email-rmody@brocade.com>
Change details:
- Found a leak in sk_buff unmapping of PCI dma addresses where boundary
conditions are not properly handled in freeing all Tx buffers. Freeing
of all Tx buffers is done considering sk_buffs data and fragments can
be mapped at the boundary.
Signed-off-by: Gurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/ethernet/brocade/bna/bnad.c | 39 ++++++++-----------------------
1 files changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index 16fa435..07570d3 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -133,39 +133,20 @@ bnad_free_all_txbufs(struct bnad *bnad,
struct bnad_unmap_q *unmap_q = tcb->unmap_q;
struct bnad_skb_unmap *unmap_array;
struct sk_buff *skb = NULL;
- int i;
+ int q;
unmap_array = unmap_q->unmap_array;
- unmap_cons = 0;
- while (unmap_cons < unmap_q->q_depth) {
- skb = unmap_array[unmap_cons].skb;
- if (!skb) {
- unmap_cons++;
+ for (q = 0; q < unmap_q->q_depth; q++) {
+ skb = unmap_array[q].skb;
+ if (!skb)
continue;
- }
- unmap_array[unmap_cons].skb = NULL;
-
- dma_unmap_single(&bnad->pcidev->dev,
- dma_unmap_addr(&unmap_array[unmap_cons],
- dma_addr), skb_headlen(skb),
- DMA_TO_DEVICE);
- dma_unmap_addr_set(&unmap_array[unmap_cons], dma_addr, 0);
- if (++unmap_cons >= unmap_q->q_depth)
- break;
+ unmap_cons = q;
+ BNAD_PCI_UNMAP_SKB(&bnad->pcidev->dev, unmap_array, unmap_cons,
+ unmap_q->q_depth, skb,
+ skb_shinfo(skb)->nr_frags);
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
- dma_unmap_page(&bnad->pcidev->dev,
- dma_unmap_addr(&unmap_array[unmap_cons],
- dma_addr),
- skb_shinfo(skb)->frags[i].size,
- DMA_TO_DEVICE);
- dma_unmap_addr_set(&unmap_array[unmap_cons], dma_addr,
- 0);
- if (++unmap_cons >= unmap_q->q_depth)
- break;
- }
dev_kfree_skb_any(skb);
}
}
--
1.7.1
^ permalink raw reply related
* [net-next,v4 10/12] bna: Queue Depth and SKB Unmap Array Fix
From: Rasesh Mody @ 2011-08-23 17:56 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody, Gurunatha Karaje
In-Reply-To: <1314122168-14314-1-git-send-email-rmody@brocade.com>
Change details:
- sk_buff unmap_array grows greater than 65536 (x2) with Tx ring of 65536.
The index used for accessing it is incorrectly declared as u16. It quickly
wraps around and accesses null sk_buff ptr. So using u32 to handle
unmap_array.
- Reducing TXQ depth and safe(max) acking of Tx events to 32768 (same as Rx)
Signed-off-by: Gurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/ethernet/brocade/bna/bnad.c | 4 ++--
drivers/net/ethernet/brocade/bna/bnad.h | 4 ++++
drivers/net/ethernet/brocade/bna/bnad_ethtool.c | 8 ++++----
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index ccc2cad..16fa435 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -182,8 +182,8 @@ static u32
bnad_free_txbufs(struct bnad *bnad,
struct bna_tcb *tcb)
{
- u32 sent_packets = 0, sent_bytes = 0;
- u16 wis, unmap_cons, updated_hw_cons;
+ u32 unmap_cons, sent_packets = 0, sent_bytes = 0;
+ u16 wis, updated_hw_cons;
struct bnad_unmap_q *unmap_q = tcb->unmap_q;
struct bnad_skb_unmap *unmap_array;
struct sk_buff *skb;
diff --git a/drivers/net/ethernet/brocade/bna/bnad.h b/drivers/net/ethernet/brocade/bna/bnad.h
index b31b893..41c984c 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.h
+++ b/drivers/net/ethernet/brocade/bna/bnad.h
@@ -86,6 +86,10 @@ struct bnad_rx_ctrl {
#define BNAD_MAX_Q_DEPTH 0x10000
#define BNAD_MIN_Q_DEPTH 0x200
+#define BNAD_MAX_RXQ_DEPTH (BNAD_MAX_Q_DEPTH / bnad_rxqs_per_cq)
+/* keeping MAX TX and RX Q depth equal */
+#define BNAD_MAX_TXQ_DEPTH BNAD_MAX_RXQ_DEPTH
+
#define BNAD_JUMBO_MTU 9000
#define BNAD_NETIF_WAKE_THRESHOLD 8
diff --git a/drivers/net/ethernet/brocade/bna/bnad_ethtool.c b/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
index 1199f01..e85fb2b 100644
--- a/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
+++ b/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
@@ -407,10 +407,10 @@ bnad_get_ringparam(struct net_device *netdev,
{
struct bnad *bnad = netdev_priv(netdev);
- ringparam->rx_max_pending = BNAD_MAX_Q_DEPTH / bnad_rxqs_per_cq;
+ ringparam->rx_max_pending = BNAD_MAX_RXQ_DEPTH;
ringparam->rx_mini_max_pending = 0;
ringparam->rx_jumbo_max_pending = 0;
- ringparam->tx_max_pending = BNAD_MAX_Q_DEPTH;
+ ringparam->tx_max_pending = BNAD_MAX_TXQ_DEPTH;
ringparam->rx_pending = bnad->rxq_depth;
ringparam->rx_mini_max_pending = 0;
@@ -434,13 +434,13 @@ bnad_set_ringparam(struct net_device *netdev,
}
if (ringparam->rx_pending < BNAD_MIN_Q_DEPTH ||
- ringparam->rx_pending > BNAD_MAX_Q_DEPTH / bnad_rxqs_per_cq ||
+ ringparam->rx_pending > BNAD_MAX_RXQ_DEPTH ||
!BNA_POWER_OF_2(ringparam->rx_pending)) {
mutex_unlock(&bnad->conf_mutex);
return -EINVAL;
}
if (ringparam->tx_pending < BNAD_MIN_Q_DEPTH ||
- ringparam->tx_pending > BNAD_MAX_Q_DEPTH ||
+ ringparam->tx_pending > BNAD_MAX_TXQ_DEPTH ||
!BNA_POWER_OF_2(ringparam->tx_pending)) {
mutex_unlock(&bnad->conf_mutex);
return -EINVAL;
--
1.7.1
^ permalink raw reply related
* [net-next,v4 12/12] bna: Driver Version changed to 3.0.2.1
From: Rasesh Mody @ 2011-08-23 17:56 UTC (permalink / raw)
To: davem, netdev; +Cc: adapter_linux_open_src_team, Rasesh Mody, Gurunatha Karaje
In-Reply-To: <1314122168-14314-1-git-send-email-rmody@brocade.com>
Signed-off-by: Gurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: Rasesh Mody <rmody@brocade.com>
---
drivers/net/ethernet/brocade/bna/bnad.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.h b/drivers/net/ethernet/brocade/bna/bnad.h
index 41c984c..7bdde74 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.h
+++ b/drivers/net/ethernet/brocade/bna/bnad.h
@@ -71,7 +71,7 @@ struct bnad_rx_ctrl {
#define BNAD_NAME "bna"
#define BNAD_NAME_LEN 64
-#define BNAD_VERSION "3.0.2.0"
+#define BNAD_VERSION "3.0.2.1"
#define BNAD_MAILBOX_MSIX_INDEX 0
#define BNAD_MAILBOX_MSIX_VECTORS 1
--
1.7.1
^ permalink raw reply related
* RE: [net-next 04/12] bna: TX Path and RX Path Changes
From: Rasesh Mody @ 2011-08-23 18:06 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Adapter Linux Open SRC Team,
Gurunatha Karaje
In-Reply-To: <20110822.164541.1084485895386350206.davem@davemloft.net>
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Monday, August 22, 2011 4:46 PM
>
>From: Rasesh Mody <rmody@brocade.com>
>Date: Mon, 22 Aug 2011 15:41:01 -0700
>
>> + if (unlikely(skb_is_gso(skb) > netdev->mtu)) {
>
>skb_is_gso() is mean to be a boolean test, it happens to return
>the value of ->gso_size as it's implementation but that's not
>a good reason for you to abuse this interface in this way.
>
>If we every fix skb_is_gso() to return a true 'bool' your driver
>will break.
>
>Access ->gso_size directly if that's what you're interested in,
>that way it's future proof and won't break in the future.
Hi Dave,
We've addressed this by accessing ->gso_size directly and resubmitted
the patch-set.
Thanks for the suggestion,
--Rasesh
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the tree
From: Niklaus Giger @ 2011-08-23 18:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Josh Boyer,
Tony Breeds
In-Reply-To: <20110822115118.e5d97beb22befc4ba9396e9d@canb.auug.org.au>
> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in
> arch/powerpc/configs/40x/hcu4_defconfig between commit 9fcd768d0cc8
> ("powerpc/40x: Remove obsolete HCU4 board") from the 4xx tree and commit
> 3b3bceef26f8 ("net: fix IBM EMAC driver after rename") from the net tree.
>
> The former commit removes the file, so I just did that.
Thanks!
Best regards
^ permalink raw reply
* Re: [PATCH 1/4] net: convert core to skb paged frag APIs
From: Michał Mirosław @ 2011-08-23 18:34 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev, David S. Miller, Eric Dumazet, Michał Mirosław
In-Reply-To: <1314092701-4347-1-git-send-email-ian.campbell@citrix.com>
2011/8/23 Ian Campbell <ian.campbell@citrix.com>:
> + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
> + skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
This is a rather common construct, so it might be worth it to
introduce something like for_each_skb_frag().
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH 2/3] drivers/staging/rtl8192e: Don't pass huge struct by value
From: Greg KH @ 2011-08-23 19:08 UTC (permalink / raw)
To: Larry Finger
Cc: Jesper Juhl, Greg Kroah-Hartman, devel, linux-kernel,
Mike McCormack, Lucas De Marchi, Stefan Weil, Andrea Merello,
netdev
In-Reply-To: <4E45B684.6080300@lwfinger.net>
On Fri, Aug 12, 2011 at 06:25:56PM -0500, Larry Finger wrote:
> On 08/12/2011 06:04 PM, Jesper Juhl wrote:
> >From: Jesper Juhl<jj@chaosbits.net>
> >Date: Sat, 13 Aug 2011 00:52:32 +0200
> >
> >struct ieee80211_network is fairly large (more than half a kilobyte),
> >so let's pass a pointer instead of passing the entire structure by
> >value when ieee80211_is_54g() and ieee80211_is_shortslot() need to
> >look at a few members.
> >Also remove parentheses around the values being returned from those
> >two functions - 'return' is not a function.
> >
> >Signed-off-by: Jesper Juhl<jj@chaosbits.net>
> >---
> > drivers/staging/rtl8192e/ieee80211/ieee80211.h | 4 ++--
> > .../staging/rtl8192e/ieee80211/ieee80211_softmac.c | 14 +++++++-------
> > 2 files changed, 9 insertions(+), 9 deletions(-)
>
> This patch is a good one; however, in Greg's pile of unmerged
> patches is a completely different driver for the RTL8192E. The new
> driver has the advantage of being organized much more like the
> drivers in rtlwifi. That will make it easier to convert to mac80211
> and move to mainline.
>
> I also have a lot of unsubmitted patches to clean up the code in the
> new driver. At the moment, it is clear of 'checkpatch -f' errors,
> and most warnings. In addition, many of the sparse warnings are
> fixed. Once Greg merges the patches already submitted, I will send
> the others.
Ick, I give up.
Larry, can you resend me _all_ pending rtl8192e patches that you have
sent me that I should apply, in the order they should be applied in, as
I'm totally lost here and have now flushed all of the rtl8192e patches
that were in my inboxes out so I can start with a clean slate.
Sorry about this, the different versions of patches floating around
didn't help anything :(
greg k-h
^ permalink raw reply
* Re: [PATCH 2/3] drivers/staging/rtl8192e: Don't pass huge struct by value
From: Larry Finger @ 2011-08-23 19:22 UTC (permalink / raw)
To: Greg KH
Cc: Jesper Juhl, Greg Kroah-Hartman, devel, linux-kernel,
Mike McCormack, Lucas De Marchi, Stefan Weil, Andrea Merello,
netdev
In-Reply-To: <20110823190834.GC17796@kroah.com>
On 08/23/2011 02:08 PM, Greg KH wrote:
>> the others.
>
> Ick, I give up.
>
> Larry, can you resend me _all_ pending rtl8192e patches that you have
> sent me that I should apply, in the order they should be applied in, as
> I'm totally lost here and have now flushed all of the rtl8192e patches
> that were in my inboxes out so I can start with a clean slate.
>
> Sorry about this, the different versions of patches floating around
> didn't help anything :(
I understand. I will resend.
Larry
^ permalink raw reply
* TCP - RST flag
From: Daniel Baluta @ 2011-08-23 20:31 UTC (permalink / raw)
To: netdev, kernelnewbies
[-- Attachment #1: Type: text/plain, Size: 2574 bytes --]
Hello,
Please help me understanding the behavior of the following
TCP conversation.
You can find bellow a snippet of the (FTP) conversation captured both
on client (C) and server (S).
[client]$ tcpdump -n -r client-6-conv.cap
[P1] 49.045690 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
197:220, ack 81, win 757, length 23
[P2] 49.046600 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
win 738, length 0
[P3] 49.047462 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq
81:87, ack 220, win 738, length 6
[P5] 49.048757 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq
242, ack 87, win 757, length 0
[P6] 49.048794 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
win 738, options [nop,nop,sack 1 {242:243}], length 0
[P4] 49.048801 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
220:242, ack 87, win 757, length 22
[P7] 49.048833 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243,
win 715, length 0
[P8] 49.049566 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87,
ack 243, win 715, length 0
[P9] 49.050889 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq
1672731590, win 0, length 0
[server]$ tcpdump -n -r server-6-conv.cap
[P1] 49.059740 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
197:220, ack 81, win 757, length 23
[P2] 49.061394 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
win 738, length 0
[P3] 49.061760 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq
81:87, ack 220, win 738, length 6
[P4] 49.062794 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
220:242, ack 87, win 757, length 22
[P5] 49.062843 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq
242, ack 87, win 757, length 0
[P6] 49.063808 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
win 738, options [nop,nop,sack 1 {242:243}], length 0
[P7] 49.063823 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243,
win 715, length 0
[P8] 49.064271 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87,
ack 243, win 715, length 0
[P9] 49.064481 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq
1672731590, win 0, length 0
What happens is that servers sends packets P4 and P5, but client
receives P5 before P4.
Since SACK is enabled, client will send a SACK (P6) ack-ing P5.
Then client sees P4, and will send an ack (P7) for P4, then sends P8
with FIN flag set.
What I don't understand, is why server responds with RST (P9) instead of ACK?
This is was obtained on 2.6.32.43. I have also attached full capture files.
I am reading TCP's RFC and kernel code, but so far I haven't reached
a conclusion.
thanks,
Daniel.
[-- Attachment #2: server-6-conv.cap --]
[-- Type: application/octet-stream, Size: 2209 bytes --]
[-- Attachment #3: client-6-conv.cap --]
[-- Type: application/octet-stream, Size: 2197 bytes --]
^ permalink raw reply
* Re: [Bugme-new] [Bug 40732] New: atl2 NIC claims NO CARRIER after suspend/resume; rmmod + insmod fixes problem
From: Andrew Morton @ 2011-08-23 20:43 UTC (permalink / raw)
To: netdev, Jay Cliburn, Chris Snook, Jie Yang; +Cc: bugme-daemon, dkg
In-Reply-To: <bug-40732-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 8 Aug 2011 18:10:08 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=40732
>
> URL: http://bugs.debian.org/614622
> Summary: atl2 NIC claims NO CARRIER after suspend/resume; rmmod
> + insmod fixes problem
> Product: Drivers
> Version: 2.5
> Kernel Version: 3.0
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: dkg@fifthhorseman.net
> Regression: No
>
>
> As reported in more detail at http://bugs.debian.org/614622, i have an atl2 NIC
> (03:00.0 Ethernet controller: Atheros Communications L2 Fast Ethernet (rev a0))
> which sometimes reports NO CARRIER after i suspend/resume.
>
> This has been the case since 2.6.37 and it persists with 3.0 as well. I'm
> using debian's 686 kernels.
>
^ permalink raw reply
* [PATCH] carl9170: Fix mismatch in carl9170_op_set_key mutex lock-unlock
From: Alexey Khoroshilov @ 2011-08-23 20:44 UTC (permalink / raw)
To: Christian Lamparter
Cc: Alexey Khoroshilov, John W. Linville,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ldv-project-ufN2psIa012HXe+LvDLADg
If is_main_vif(ar, vif) reports that we have to fall back
to software encryption, we goto err_softw; before locking ar->mutex.
As a result, we have unprotected call to carl9170_set_operating_mode
and unmatched mutex_unlock.
The patch fix the issue by adding mutex_lock before goto.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov-ufN2psIa012HXe+LvDLADg@public.gmane.org>
---
drivers/net/wireless/ath/carl9170/main.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
index 0122930..0474e663 100644
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -1066,8 +1066,10 @@ static int carl9170_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
* the high througput speed in 802.11n networks.
*/
- if (!is_main_vif(ar, vif))
+ if (!is_main_vif(ar, vif)) {
+ mutex_lock(&ar->mutex);
goto err_softw;
+ }
/*
* While the hardware supports *catch-all* key, for offloading
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [net-next 03/10] ixgbe: Drop the TX work limit and instead just leave it to budget
From: Alexander Duyck @ 2011-08-23 20:52 UTC (permalink / raw)
To: Alexander Duyck
Cc: David Miller, bhutchings, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <CAKgT0UeUCyNRbfvkGKdyi17K6T-fSHukMGYwyJu2xOmAiBDZNA@mail.gmail.com>
On 08/22/2011 09:04 PM, Alexander Duyck wrote:
> On Mon, Aug 22, 2011 at 4:40 PM, David Miller<davem@davemloft.net> wrote:
>> From: Alexander Duyck<alexander.h.duyck@intel.com>
>> Date: Mon, 22 Aug 2011 15:57:51 -0700
>>> The problem seemed to be present as long as I allowed the TX budget to
>>> be a multiple of the RX budget. The easiest way to keep things
>>> balanced and avoid allowing the TX from one CPU to overwhelm the RX on
>>> another was just to keep the budgets equal.
>> You're executing 10 or 20 cpu cycles after every 64 TX reclaims,
>> that's the only effect of these changes. That's not even long enough
>> for a cache line to transfer between two cpus.
> It sounds like I may not have been seeing this due to the type of
> workload I was focusing on. I'll try generating some data with pktgen
> and netperf tomorrow to see how this holds up under small packet
> transmit only traffic since those are the cases most likely to get
> into the state you mention.
>
> Also I would appreciate it if you had any suggestions on other
> workloads I might need to focus on in order to determine the impact of
> this change.
>
> Thanks,
>
> Alex
I found a reason to rewrite this. Basically this modification has a
negative impact in the case of multiple ports on a single CPU all
routing to the same port on the same CPU. It ends up making it so that
the transmit throughput is only (total CPU packets per second)/(number
of ports receiving on cpu). So on a system that can receive at 1.4Mpps
on a single core we end up seeing only a little over 350Kpps of transmit
when 4 ports are all receiving packets on the system.
I'll look at rewriting this. I'll probably leave the work limit
controlling things but lower it to a more reasonable value such as 1/2
to 1/4 of the ring size.
Thanks,
Alex
^ permalink raw reply
* Re: TCP - RST flag
From: Eric Dumazet @ 2011-08-23 20:55 UTC (permalink / raw)
To: Daniel Baluta; +Cc: netdev, kernelnewbies
In-Reply-To: <CAEnQRZAchYf-3-t7RRogfb0WogzY9ZF8rzMdtOeS1Vdvx7N4og@mail.gmail.com>
Le mardi 23 août 2011 à 23:31 +0300, Daniel Baluta a écrit :
> Hello,
>
> Please help me understanding the behavior of the following
> TCP conversation.
>
> You can find bellow a snippet of the (FTP) conversation captured both
> on client (C) and server (S).
>
> [client]$ tcpdump -n -r client-6-conv.cap
> [P1] 49.045690 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
> 197:220, ack 81, win 757, length 23
> [P2] 49.046600 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
> win 738, length 0
> [P3] 49.047462 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq
> 81:87, ack 220, win 738, length 6
> [P5] 49.048757 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq
> 242, ack 87, win 757, length 0
> [P6] 49.048794 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
> win 738, options [nop,nop,sack 1 {242:243}], length 0
> [P4] 49.048801 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
> 220:242, ack 87, win 757, length 22
> [P7] 49.048833 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243,
> win 715, length 0
> [P8] 49.049566 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87,
> ack 243, win 715, length 0
> [P9] 49.050889 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq
> 1672731590, win 0, length 0
>
> [server]$ tcpdump -n -r server-6-conv.cap
> [P1] 49.059740 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
> 197:220, ack 81, win 757, length 23
> [P2] 49.061394 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
> win 738, length 0
> [P3] 49.061760 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq
> 81:87, ack 220, win 738, length 6
> [P4] 49.062794 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
> 220:242, ack 87, win 757, length 22
> [P5] 49.062843 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq
> 242, ack 87, win 757, length 0
> [P6] 49.063808 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
> win 738, options [nop,nop,sack 1 {242:243}], length 0
> [P7] 49.063823 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243,
> win 715, length 0
> [P8] 49.064271 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87,
> ack 243, win 715, length 0
> [P9] 49.064481 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq
> 1672731590, win 0, length 0
>
> What happens is that servers sends packets P4 and P5, but client
> receives P5 before P4.
> Since SACK is enabled, client will send a SACK (P6) ack-ing P5.
>
> Then client sees P4, and will send an ack (P7) for P4, then sends P8
> with FIN flag set.
> What I don't understand, is why server responds with RST (P9) instead of ACK?
>
> This is was obtained on 2.6.32.43. I have also attached full capture files.
>
> I am reading TCP's RFC and kernel code, but so far I haven't reached
> a conclusion.
TCP in RFC 1122 section 4.2.2.13:
"A host MAY implement a "half-duplex" TCP close sequence, so that an
application that has called CLOSE cannot continue to read data from the
connection. If such a host issues a CLOSE call while received data is
still pending in TCP, or if new data is received after CLOSE is called,
its TCP SHOULD send a RST to show that data was lost."
This is why some apps first call shutdown(), then drain receive queue,
then close()
^ permalink raw reply
* Re: [Bugme-new] [Bug 40572] New: Intel Gigabit Ethernet 82576 50% packet loss after reboot
From: Andrew Morton @ 2011-08-23 21:30 UTC (permalink / raw)
To: netdev, e1000-devel; +Cc: vojcik, bugme-daemon
In-Reply-To: <bug-40572-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Fri, 5 Aug 2011 07:07:05 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=40572
>
> Summary: Intel Gigabit Ethernet 82576 50% packet loss after
> reboot
> Product: Drivers
> Version: 2.5
> Kernel Version: 3.0
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: blocking
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: vojcik@gmail.com
> Regression: No
I'll change this to "yes".
>
> Hi,
>
> I have strange problem with Intel dualport Gigabit ehternet card.
> Problem appears after 3rd - 5th reboot.
>
> If you ping or make any network traffic you get 50% packet loss. No error
> messages in logs.
> When you make reboot all is ok in next few reboots.
>
> We have eliminated network problems like switches, cables etc. It's software
> related.
>
> It looks like in kernel 2.6.37 we have the same problem but in 2.6.28.6
> everything looks fine.
>
> I attach some files for additional information
>
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: TCP - RST flag
From: Daniel Baluta @ 2011-08-23 21:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, kernelnewbies
In-Reply-To: <1314132932.4478.0.camel@edumazet-laptop>
On Tue, Aug 23, 2011 at 11:55 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 23 août 2011 à 23:31 +0300, Daniel Baluta a écrit :
>> Hello,
>>
>> Please help me understanding the behavior of the following
>> TCP conversation.
>>
>> You can find bellow a snippet of the (FTP) conversation captured both
>> on client (C) and server (S).
>>
>> [client]$ tcpdump -n -r client-6-conv.cap
>> [P1] 49.045690 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
>> 197:220, ack 81, win 757, length 23
>> [P2] 49.046600 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
>> win 738, length 0
>> [P3] 49.047462 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq
>> 81:87, ack 220, win 738, length 6
>> [P5] 49.048757 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq
>> 242, ack 87, win 757, length 0
>> [P6] 49.048794 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
>> win 738, options [nop,nop,sack 1 {242:243}], length 0
>> [P4] 49.048801 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
>> 220:242, ack 87, win 757, length 22
>> [P7] 49.048833 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243,
>> win 715, length 0
>> [P8] 49.049566 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87,
>> ack 243, win 715, length 0
>> [P9] 49.050889 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq
>> 1672731590, win 0, length 0
>>
>> [server]$ tcpdump -n -r server-6-conv.cap
>> [P1] 49.059740 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
>> 197:220, ack 81, win 757, length 23
>> [P2] 49.061394 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
>> win 738, length 0
>> [P3] 49.061760 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [P.], seq
>> 81:87, ack 220, win 738, length 6
>> [P4] 49.062794 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [P.], seq
>> 220:242, ack 87, win 757, length 22
>> [P5] 49.062843 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [F.], seq
>> 242, ack 87, win 757, length 0
>> [P6] 49.063808 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 220,
>> win 738, options [nop,nop,sack 1 {242:243}], length 0
>> [P7] 49.063823 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [.], ack 243,
>> win 715, length 0
>> [P8] 49.064271 IP 10.10.0.20.58277 > 10.10.0.1.21: Flags [F.], seq 87,
>> ack 243, win 715, length 0
>> [P9] 49.064481 IP 10.10.0.1.21 > 10.10.0.20.58277: Flags [R], seq
>> 1672731590, win 0, length 0
>>
>> What happens is that servers sends packets P4 and P5, but client
>> receives P5 before P4.
>> Since SACK is enabled, client will send a SACK (P6) ack-ing P5.
>>
>> Then client sees P4, and will send an ack (P7) for P4, then sends P8
>> with FIN flag set.
>> What I don't understand, is why server responds with RST (P9) instead of ACK?
>>
>> This is was obtained on 2.6.32.43. I have also attached full capture files.
>>
>> I am reading TCP's RFC and kernel code, but so far I haven't reached
>> a conclusion.
>
> TCP in RFC 1122 section 4.2.2.13:
>
> "A host MAY implement a "half-duplex" TCP close sequence, so that an
> application that has called CLOSE cannot continue to read data from the
> connection. If such a host issues a CLOSE call while received data is
> still pending in TCP, or if new data is received after CLOSE is called,
> its TCP SHOULD send a RST to show that data was lost."
So, this means that server's CLOSE operation is issued while received
data is still pending? I will analyze ftp's server code, but this is strange
since P4 [221 Have a nice day!\r\n] it is generated as a response for
P3 [QUIT\r\n]. So P4 must have been fully received.
Also, looking at the capture no data is received from the client after
server calls CLOSE (P5) (there are only ACKs and FIN - P6, P7, P8).
> This is why some apps first call shutdown(), then drain receive queue,
> then close()
This makes sense :).
thanks Eric.
Daniel.
^ permalink raw reply
* Re: TCP - RST flag
From: Eric Dumazet @ 2011-08-23 21:50 UTC (permalink / raw)
To: Daniel Baluta; +Cc: netdev, kernelnewbies
In-Reply-To: <CAEnQRZChkX0K_qWf-Gmu8YeAyxoOb7DTPvvbnA5YxSHEMj_J=g@mail.gmail.com>
Le mercredi 24 août 2011 à 00:32 +0300, Daniel Baluta a écrit :
> On Tue, Aug 23, 2011 at 11:55 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > TCP in RFC 1122 section 4.2.2.13:
> >
> > "A host MAY implement a "half-duplex" TCP close sequence, so that an
> > application that has called CLOSE cannot continue to read data from the
> > connection. If such a host issues a CLOSE call while received data is
> > still pending in TCP, or if new data is received after CLOSE is called,
> > its TCP SHOULD send a RST to show that data was lost."
>
> So, this means that server's CLOSE operation is issued while received
> data is still pending? I will analyze ftp's server code, but this is strange
> since P4 [221 Have a nice day!\r\n] it is generated as a response for
> P3 [QUIT\r\n]. So P4 must have been fully received.
>
tcpdump only shows TCP stack did receive the frame, not that it was
_read_ by application.
Only strace could eventually say if the input queue was really drained
before the close().
Maybe server decided to close the connexion before reading the QUIT
command from client.
> Also, looking at the capture no data is received from the client after
> server calls CLOSE (P5) (there are only ACKs and FIN - P6, P7, P8).
That doesnt matter.
If data was received (and ACKnowledged by TCP stack) _before_ close(fd),
but not yet read by application, TCP must send an RST to be RFC
compliant.
^ permalink raw reply
* Re: [PATCH] carl9170: Fix mismatch in carl9170_op_set_key mutex lock-unlock
From: Christian Lamparter @ 2011-08-23 21:56 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: John W. Linville, linux-wireless, netdev, linux-kernel,
ldv-project
In-Reply-To: <1314132272-7357-1-git-send-email-khoroshilov@ispras.ru>
On Tuesday, August 23, 2011 10:44:32 PM Alexey Khoroshilov wrote:
> If is_main_vif(ar, vif) reports that we have to fall back
> to software encryption, we goto err_softw; before locking ar->mutex.
> As a result, we have unprotected call to carl9170_set_operating_mode
> and unmatched mutex_unlock.
>
> The patch fix the issue by adding mutex_lock before goto.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: <stable@kernel.org>
Acked-By: Christian Lamparter <chunkeey@googlemail.com>
^ permalink raw reply
* Re: TCP - RST flag
From: Daniel Baluta @ 2011-08-23 22:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, kernelnewbies
In-Reply-To: <1314136220.4478.6.camel@edumazet-laptop>
On Wed, Aug 24, 2011 at 12:50 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 24 août 2011 à 00:32 +0300, Daniel Baluta a écrit :
>> On Tue, Aug 23, 2011 at 11:55 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> > TCP in RFC 1122 section 4.2.2.13:
>> >
>> > "A host MAY implement a "half-duplex" TCP close sequence, so that an
>> > application that has called CLOSE cannot continue to read data from the
>> > connection. If such a host issues a CLOSE call while received data is
>> > still pending in TCP, or if new data is received after CLOSE is called,
>> > its TCP SHOULD send a RST to show that data was lost."
>>
>> So, this means that server's CLOSE operation is issued while received
>> data is still pending? I will analyze ftp's server code, but this is strange
>> since P4 [221 Have a nice day!\r\n] it is generated as a response for
>> P3 [QUIT\r\n]. So P4 must have been fully received.
>>
>
> tcpdump only shows TCP stack did receive the frame, not that it was
> _read_ by application.
>
> Only strace could eventually say if the input queue was really drained
> before the close().
> Maybe server decided to close the connexion before reading the QUIT
> command from client.
>
>> Also, looking at the capture no data is received from the client after
>> server calls CLOSE (P5) (there are only ACKs and FIN - P6, P7, P8).
>
> That doesnt matter.
>
> If data was received (and ACKnowledged by TCP stack) _before_ close(fd),
> but not yet read by application, TCP must send an RST to be RFC
> compliant.
I see. Thanks a lot for your explanations. I will further use strace
to see what's going on.
Daniel.
^ permalink raw reply
* [PATCH] MAINTANERS: update Qualcomm Atheros addresses
From: Luis R. Rodriguez @ 2011-08-23 22:07 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
yangjie-A+ZNKFmMK5xy9aJCnZT0Uw, Luis R. Rodriguez,
stable-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
jouni-A+ZNKFmMK5xy9aJCnZT0Uw, vthiagar-A+ZNKFmMK5xy9aJCnZT0Uw,
senthilb-A+ZNKFmMK5xy9aJCnZT0Uw
From: Luis R. Rodriguez <mcgrof-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
Qualcomm ate up Atheros, all of the old e-mail addresses
no longer work and e-mails sent to it will bounce. Update
the addresses to the new shiny Qualcomm Atheros (QCA) ones.
Cc: stable-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: jouni-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org
Cc: yangjie-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org
Cc: vthiagar-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org
Cc: senthilb-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org
Signed-off-by: Luis R. Rodriguez <mcgrof-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
---
John, I've left out ath6kl as you removed that so I take it
the respective MAINTAINERS entry was deleted as well (although
I do not see this on wireless-testing.git)
I've thrown in one Ethernet driver maintainers update as well
for QCA, so hope its OK this goes through you. Given that the
e-mail addresses no longer work Cc'ing stable as well.
MAINTAINERS | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 069ee3b..a286bc8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1230,7 +1230,7 @@ F: Documentation/aoe/
F: drivers/block/aoe/
ATHEROS ATH GENERIC UTILITIES
-M: "Luis R. Rodriguez" <lrodriguez-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
+M: "Luis R. Rodriguez" <mcgrof-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
L: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
S: Supported
F: drivers/net/wireless/ath/*
@@ -1238,7 +1238,7 @@ F: drivers/net/wireless/ath/*
ATHEROS ATH5K WIRELESS DRIVER
M: Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
M: Nick Kossifidis <mickflemm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
-M: "Luis R. Rodriguez" <lrodriguez-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
+M: "Luis R. Rodriguez" <mcgrof-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
M: Bob Copeland <me-aXfl/3sk2vNUbtYUoyoikg@public.gmane.org>
L: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
L: ath5k-devel-xDcbHBWguxEUs3QNXV6qNA@public.gmane.org
@@ -1247,10 +1247,10 @@ S: Maintained
F: drivers/net/wireless/ath/ath5k/
ATHEROS ATH9K WIRELESS DRIVER
-M: "Luis R. Rodriguez" <lrodriguez-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
-M: Jouni Malinen <jmalinen-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
-M: Vasanthakumar Thiagarajan <vasanth-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
-M: Senthil Balasubramanian <senthilkumar-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
+M: "Luis R. Rodriguez" <mcgrof-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
+M: Jouni Malinen <jouni-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
+M: Vasanthakumar Thiagarajan <vthiagar-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
+M: Senthil Balasubramanian <senthilb-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
L: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
L: ath9k-devel-xDcbHBWguxHbcTqmT+pZeQ@public.gmane.org
W: http://wireless.kernel.org/en/users/Drivers/ath9k
@@ -1278,7 +1278,7 @@ F: drivers/input/misc/ati_remote2.c
ATLX ETHERNET DRIVERS
M: Jay Cliburn <jcliburn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
M: Chris Snook <chris.snook-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
-M: Jie Yang <jie.yang-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
+M: Jie Yang <yangjie-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
L: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
W: http://sourceforge.net/projects/atl1
W: http://atl1.sourceforge.net
--
1.7.4.15.g7811d
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [net-next 0/9][pull request] Complete drivers/net/ move
From: David Miller @ 2011-08-23 22:41 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <1314089149-27205-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 23 Aug 2011 01:45:40 -0700
> The following series moves the FDDI, PPP, HIPPI, PLIP, SLIP and the cleanup
> of the drivers/net/ Kconfig & Makefile's. This series in addition moves
> the 2 remaining drivers in drivers/net/pcmcia/ into their respective
> directories (arcnet & tokenring). The last remaining change is to
> make the all the "new" Kconfig options introduced by the Ethernet
> drivers move to yes, so that current defconfig's will compile the expected
> drivers.
>
> The following are changes since commit ca1ba7caa68520864e4b9227e67f3bbc6fed373b:
> Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next
> and are available in the git repository at:
> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/next-organize master
I pulled this, but because you changed FDDI and these other newly
moved subsystems from a "config FOO" into a "menuconfig FOO", it now
prompts for those too during the first oldconfig.
As a result, I'm pretty sure people are going to lose drivers from
their build for exactly for the same reasons as the ethernet driver
issue you're trying to address in patch #9.
^ permalink raw reply
* Re: [net-next 00/10][pull request] Intel Wired LAN Driver Update
From: David Miller @ 2011-08-23 22:45 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <1313911761-11709-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sun, 21 Aug 2011 00:29:11 -0700
> The following series contains updates to ixgbe.
>
> The following are changes since commit ca1ba7caa68520864e4b9227e67f3bbc6fed373b:
> Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next
> and are available in the git repository at:
> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next master
Alexander says he is going to respin patch #3, so I'm dropping this and
waiting for the next submission.
^ permalink raw reply
* Re: [net-next 0/9][pull request] Complete drivers/net/ move
From: David Miller @ 2011-08-23 23:12 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo
In-Reply-To: <20110823.154157.105644491350157006.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 23 Aug 2011 15:41:57 -0700 (PDT)
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Tue, 23 Aug 2011 01:45:40 -0700
>
>> The following series moves the FDDI, PPP, HIPPI, PLIP, SLIP and the cleanup
>> of the drivers/net/ Kconfig & Makefile's. This series in addition moves
>> the 2 remaining drivers in drivers/net/pcmcia/ into their respective
>> directories (arcnet & tokenring). The last remaining change is to
>> make the all the "new" Kconfig options introduced by the Ethernet
>> drivers move to yes, so that current defconfig's will compile the expected
>> drivers.
>>
>> The following are changes since commit ca1ba7caa68520864e4b9227e67f3bbc6fed373b:
>> Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next
>> and are available in the git repository at:
>> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/next-organize master
>
> I pulled this, but because you changed FDDI and these other newly
> moved subsystems from a "config FOO" into a "menuconfig FOO", it now
> prompts for those too during the first oldconfig.
I had to unpull, this breaks the build, see the skfddi errors below.
Also, you can't change "config" into "menuconfig", it makes things
that were previously buildable modular no longer able to be.
include/config/auto.conf:2204:warning: symbol value 'm' invalid for FDDI
include/config/auto.conf:3764:warning: symbol value 'm' invalid for ARCNET
include/config/auto.conf:4044:warning: symbol value 'm' invalid for TR
include/config/auto.conf:4700:warning: symbol value 'm' invalid for PPP
drivers/block/drbd/drbd_main.c: In function ‘drbd_buildtag’:
drivers/block/drbd/drbd_main.c:4187:19: warning: the comparison will always evaluate as ‘true’ for the address of ‘__this_module’ will never be NULL [-Waddress]
drivers/infiniband/hw/mlx4/qp.c: In function ‘build_mlx_header’:
drivers/infiniband/hw/mlx4/qp.c:1387:30: warning: ‘vlan’ may be used uninitialized in this function [-Wuninitialized]
net/dccp/probe.c: In function ‘dccpprobe_init’:
net/dccp/probe.c:166:2: warning: the omitted middle operand in ?: will always be ‘true’, suggest explicit middle operand [-Wparentheses]
drivers/isdn/hardware/mISDN/hfcpci.c: In function ‘hfcpci_softirq’:
drivers/isdn/hardware/mISDN/hfcpci.c:2319:2: warning: ignoring return value of ‘driver_for_each_device’, declared with attribute warn_unused_result [-Wunused-result]
drivers/net/ethernet/amd/nmclan_cs.c: In function ‘nmclan_config’:
drivers/net/ethernet/amd/nmclan_cs.c:628:3: warning: ‘pcmcia_request_exclusive_irq’ is deprecated (declared at include/pcmcia/ds.h:201) [-Wdeprecated-declarations]
In file included from drivers/net/fddi/skfp/skfddi.c:97:0:
drivers/net/fddi/skfp/h/smc.h:41:24: fatal error: h/osdef1st.h: No such file or directory
compilation terminated.
make[4]: *** [drivers/net/fddi/skfp/skfddi.o] Error 1
make[3]: *** [drivers/net/fddi/skfp] Error 2
make[2]: *** [drivers/net/fddi] Error 2
make[2]: *** Waiting for unfinished jobs....
drivers/net/ethernet/broadcom/cnic.c: In function ‘cnic_cm_open’:
drivers/net/ethernet/broadcom/cnic.c:4084:2: warning: the comparison will always evaluate as ‘true’ for the address of ‘cm_ulp_ops’ will never be NULL [-Waddress]
drivers/net/ethernet/i825xx/znet.c: In function ‘hardware_init’:
drivers/net/ethernet/i825xx/znet.c:864:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/net/ethernet/i825xx/znet.c:871:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
net/netfilter/nf_conntrack_proto.c: In function ‘nf_conntrack_l3proto_unregister’:
net/netfilter/nf_conntrack_proto.c:210:2: warning: the comparison will always evaluate as ‘true’ for the address of ‘nf_conntrack_l3proto_generic’ will never be NULL [-Waddress]
net/netfilter/nf_conntrack_proto.c: In function ‘nf_conntrack_l4proto_unregister’:
net/netfilter/nf_conntrack_proto.c:345:2: warning: the comparison will always evaluate as ‘true’ for the address of ‘nf_conntrack_l4proto_generic’ will never be NULL [-Waddress]
net/netfilter/nf_conntrack_proto.c: In function ‘nf_conntrack_proto_init’:
net/netfilter/nf_conntrack_proto.c:370:3: warning: the comparison will always evaluate as ‘true’ for the address of ‘nf_conntrack_l3proto_generic’ will never be NULL [-Waddress]
net/sched/sch_generic.c: In function ‘dev_graft_qdisc’:
net/sched/sch_generic.c:678:2: warning: the comparison will always evaluate as ‘true’ for the address of ‘noop_qdisc’ will never be NULL [-Waddress]
drivers/staging/bcm/CmHost.c: In function ‘StoreCmControlResponseMessage’:
drivers/staging/bcm/CmHost.c:1716:39: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/staging/bcm/CmHost.c:1752:37: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/staging/bcm/CmHost.c:1763:35: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
drivers/staging/bcm/led_control.c: In function ‘LEDControlThread’:
drivers/staging/bcm/led_control.c:789:4: warning: case value ‘255’ not in enumerated type ‘LedEventInfo_t’ [-Wswitch]
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs....
drivers/staging/cxt1e1/functions.c: In function ‘VMETRO_TRACE’:
drivers/staging/cxt1e1/functions.c:275:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
drivers/staging/rtl8192e/ieee80211/ieee80211_module.c: In function ‘store_debug_level’:
drivers/staging/rtl8192e/ieee80211/ieee80211_module.c:253:22: warning: comparison of distinct pointer types lacks a cast [enabled by default]
In file included from drivers/staging/wlan-ng/prism2usb.c:5:0:
drivers/staging/wlan-ng/prism2fw.c: In function ‘writeimage.constprop.0’:
drivers/staging/wlan-ng/prism2fw.c:1115:1: warning: the frame size of 4272 bytes is larger than 2048 bytes [-Wframe-larger-than=]
make: *** [drivers] Error 2
^ permalink raw reply
* Re: [net-next,v4 04/12] bna: TX Path and RX Path Changes
From: David Miller @ 2011-08-23 23:22 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team, gkaraje
In-Reply-To: <1314122168-14314-5-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Tue, 23 Aug 2011 10:56:00 -0700
> + BNA_QE_INDX_ADD(_index, 1, _depth); \
> + for (j = 0; j < (_frag); j++) { \
> + prefetch(&(_array)[(_index) + 1]); \
> + dma_unmap_page(_pdev, dma_unmap_addr(&(_array)[_index], \
This prefetch is excessive and a waste of cpu cycles.
You're going to prefetch a full 64-byte (or even 128-byte) cache line
for every 16-byte blob (at best) you iterate over. This means you'll
prefetch the same cache line, needlessly, over and over again.
This is a really terrible patch series, and I'm frankly exhausted from
reviewing it. I don't want to see another revision of this series for
at least one week. Read it over carefully, meanwhile.
There is very little thought, and way too much arbitrary tinkering
going on in this driver.
^ 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