* [PATCH v3 9/9] usb/atm/ueagle-atm.c: call atm_dev_signal_change() when signal changes.
From: Karl Hiramoto @ 2010-07-07 8:50 UTC (permalink / raw)
To: linux-atm-general, netdev, chas; +Cc: Karl Hiramoto
In-Reply-To: <1278492636-11094-1-git-send-email-karl@hiramoto.org>
Propagate signal changes to upper atm layer.
Signed-off-by: Karl Hiramoto <karl@hiramoto.org>
---
drivers/usb/atm/ueagle-atm.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c
index e213d3f..ebae944 100644
--- a/drivers/usb/atm/ueagle-atm.c
+++ b/drivers/usb/atm/ueagle-atm.c
@@ -575,6 +575,13 @@ MODULE_PARM_DESC(annex,
sc->usbatm->atm_dev->type = val; \
} while (0)
+#define UPDATE_ATM_SIGNAL(val) \
+ do { \
+ if (sc->usbatm->atm_dev) \
+ atm_dev_signal_change(sc->usbatm->atm_dev, val); \
+ } while (0)
+
+
/* Firmware loading */
#define LOAD_INTERNAL 0xA0
#define F8051_USBCS 0x7f92
@@ -1359,7 +1366,7 @@ static int uea_stat_e1(struct uea_softc *sc)
/* always update it as atm layer could not be init when we switch to
* operational state
*/
- UPDATE_ATM_STAT(signal, ATM_PHY_SIG_FOUND);
+ UPDATE_ATM_SIGNAL(ATM_PHY_SIG_FOUND);
/* wake up processes waiting for synchronization */
wake_up(&sc->sync_q);
@@ -1498,7 +1505,7 @@ static int uea_stat_e4(struct uea_softc *sc)
/* always update it as atm layer could not be init when we switch to
* operational state
*/
- UPDATE_ATM_STAT(signal, ATM_PHY_SIG_FOUND);
+ UPDATE_ATM_SIGNAL(ATM_PHY_SIG_FOUND);
/* wake up processes waiting for synchronization */
wake_up(&sc->sync_q);
@@ -1825,7 +1832,7 @@ static int uea_start_reset(struct uea_softc *sc)
* So we will failed to wait Ready CMV.
*/
sc->cmv_ack = 0;
- UPDATE_ATM_STAT(signal, ATM_PHY_SIG_LOST);
+ UPDATE_ATM_SIGNAL(ATM_PHY_SIG_LOST);
/* reset statistics */
memset(&sc->stats, 0, sizeof(struct uea_stats));
--
1.7.1
^ permalink raw reply related
* Re: Missing regression fix in 2.6.34.1
From: David Miller @ 2010-07-07 8:57 UTC (permalink / raw)
To: arno; +Cc: stable, brian.haley, netdev
In-Reply-To: <87lj9nkah1.fsf@small.ssi.corp>
I submitted this fix to Greg last night.
^ permalink raw reply
* [PATCH 2.6.35-rc1] net: vmxnet3 fixes [0/5]
From: Shreyas Bhatewara @ 2010-07-07 9:19 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, pv-drivers
This series of patches provide minor fixes to the vmxnet3 driver. Each
patch updates the driver version number. Let me know your comments /
feedback if any.
->Shreyas
^ permalink raw reply
* [PATCH 2.6.35-rc1] net: vmxnet3 fixes [1/5] Spare skb to avoid starvation
From: Shreyas Bhatewara @ 2010-07-07 9:21 UTC (permalink / raw)
To: netdev; +Cc: pv-drivers
From: Shreyas Bhatewara <sbhatewara@vmware.com>
skb_alloc() failure can cause the recv ring to loose all packet reception.
Avoid this by introducing a spare buffer.
Signed-off-by: Michael Stolarchuk <stolarchuk@vmware.com>
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 989b742..5a50d10 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -541,7 +541,12 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,
NET_IP_ALIGN);
if (unlikely(rbi->skb == NULL)) {
rq->stats.rx_buf_alloc_failure++;
- break;
+ /* starvation prevention */
+ if (vmxnet3_cmd_ring_desc_empty(
+ rq->rx_ring + ring_idx))
+ rbi->skb = rq->spare_skb;
+ else
+ break;
}
rbi->skb->dev = adapter->netdev;
@@ -611,6 +616,29 @@ vmxnet3_append_frag(struct sk_buff *skb, struct Vmxnet3_RxCompDesc *rcd,
}
+/*
+ * Free any pages which were attached to the frags of the spare skb. This can
+ * happen when the spare skb is attached to the rx ring to prevent starvation,
+ * but there was no issue with page allocation.
+ */
+
+static void
+vmxnet3_rx_spare_skb_free_frags(struct vmxnet3_adapter *adapter)
+{
+ struct sk_buff *skb = adapter->rx_queue.spare_skb;
+ int i;
+ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[i];
+ BUG_ON(frag->page != 0);
+ put_page(frag->page);
+ frag->page = 0;
+ frag->size = 0;
+ }
+ skb_shinfo(skb)->nr_frags = 0;
+ skb->data_len = 0;
+}
+
+
static void
vmxnet3_map_pkt(struct sk_buff *skb, struct vmxnet3_tx_ctx *ctx,
struct vmxnet3_tx_queue *tq, struct pci_dev *pdev,
@@ -1060,8 +1088,12 @@ vmxnet3_rx_error(struct vmxnet3_rx_queue *rq, struct Vmxnet3_RxCompDesc *rcd,
* ctx->skb may be NULL if this is the first and the only one
* desc for the pkt
*/
- if (ctx->skb)
- dev_kfree_skb_irq(ctx->skb);
+ if (ctx->skb) {
+ if (ctx->skb == rq->spare_skb)
+ vmxnet3_rx_spare_skb_free_frags(adapter);
+ else
+ dev_kfree_skb_irq(ctx->skb);
+ }
ctx->skb = NULL;
}
@@ -1159,6 +1191,12 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
skb = ctx->skb;
if (rcd->eop) {
+ if (skb == rq->spare_skb) {
+ rq->stats.drop_total++;
+ vmxnet3_rx_spare_skb_free_frags(adapter);
+ ctx->skb = NULL;
+ goto rcd_done;
+ }
skb->len += skb->data_len;
skb->truesize += skb->data_len;
@@ -1244,6 +1282,14 @@ vmxnet3_rq_cleanup(struct vmxnet3_rx_queue *rq,
rq->uncommitted[ring_idx] = 0;
}
+ /* free starvation prevention skb if allocated */
+ if (rq->spare_skb) {
+ vmxnet3_rx_spare_skb_free_frags(adapter);
+ dev_kfree_skb(rq->spare_skb);
+ rq->spare_skb = NULL;
+ }
+
+
rq->comp_ring.gen = VMXNET3_INIT_GEN;
rq->comp_ring.next2proc = 0;
}
@@ -1325,6 +1371,15 @@ vmxnet3_rq_init(struct vmxnet3_rx_queue *rq,
}
vmxnet3_rq_alloc_rx_buf(rq, 1, rq->rx_ring[1].size - 1, adapter);
+ /* allocate ring starvation protection */
+ rq->spare_skb = dev_alloc_skb(PAGE_SIZE);
+ if (rq->spare_skb == NULL) {
+ vmxnet3_rq_cleanup(rq, adapter);
+ return -ENOMEM;
+ }
+
+
+
/* reset the comp ring */
rq->comp_ring.next2proc = 0;
memset(rq->comp_ring.base, 0, rq->comp_ring.size *
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 34f392f..7985ba4 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -68,10 +68,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.0.5.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.0.6.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01000500
+#define VMXNET3_DRIVER_VERSION_NUM 0x01000600
/*
@@ -149,6 +149,13 @@ vmxnet3_cmd_ring_desc_avail(struct vmxnet3_cmd_ring *ring)
ring->next2comp - ring->next2fill - 1;
}
+static inline bool
+vmxnet3_cmd_ring_desc_empty(struct vmxnet3_cmd_ring *ring)
+{
+ return (ring->next2comp == ring->next2fill);
+}
+
+
struct vmxnet3_comp_ring {
union Vmxnet3_GenericDesc *base;
u32 size;
@@ -266,9 +273,10 @@ struct vmxnet3_rx_queue {
u32 qid2; /* rqID in RCD for buffer from 2nd ring */
u32 uncommitted[2]; /* # of buffers allocated since last RXPROD
* update */
- struct vmxnet3_rx_buf_info *buf_info[2];
- struct Vmxnet3_RxQueueCtrl *shared;
+ struct vmxnet3_rx_buf_info *buf_info[2];
+ struct Vmxnet3_RxQueueCtrl *shared;
struct vmxnet3_rq_driver_stats stats;
+ struct sk_buff *spare_skb; /* starvation skb */
} __attribute__((__aligned__(SMP_CACHE_BYTES)));
#define VMXNET3_LINUX_MAX_MSIX_VECT 1
^ permalink raw reply related
* [PATCH 2.6.35-rc1] net: vmxnet3 fixes [2/5] Interrupt control bitmap
From: Shreyas Bhatewara @ 2010-07-07 9:24 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, pv-drivers, ronghua
In-Reply-To: <alpine.LRH.2.00.1007070125440.4652@localhost.localdomain>
A new bit map 'intrCtrl' is introduced in the DriverShared area. The driver
should update VMXNET3_IC_DISABLE_ALL bit before writing IMR.
Signed-off-by: Ronghua Zang <ronghua@vmware.com>
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_defs.h b/drivers/net/vmxnet3/vmxnet3_defs.h
index b4889e6..ca7727b 100644
--- a/drivers/net/vmxnet3/vmxnet3_defs.h
+++ b/drivers/net/vmxnet3/vmxnet3_defs.h
@@ -464,6 +464,9 @@ enum vmxnet3_intr_type {
/* addition 1 for events */
#define VMXNET3_MAX_INTRS 25
+/* value of intrCtrl */
+#define VMXNET3_IC_DISABLE_ALL 0x1 /* bit 0 */
+
struct Vmxnet3_IntrConf {
bool autoMask;
@@ -471,7 +474,8 @@ struct Vmxnet3_IntrConf {
u8 eventIntrIdx;
u8 modLevels[VMXNET3_MAX_INTRS]; /* moderation level for
* each intr */
- __le32 reserved[3];
+ __le32 intrCtrl;
+ __le32 reserved[2];
};
/* one bit per VLAN ID, the size is in the units of u32 */
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 1b2d467..29db294 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -72,6 +72,7 @@ vmxnet3_enable_all_intrs(struct vmxnet3_adapter *adapter)
for (i = 0; i < adapter->intr.num_intrs; i++)
vmxnet3_enable_intr(adapter, i);
+ adapter->shared->devRead.intrConf.intrCtrl &= ~VMXNET3_IC_DISABLE_ALL;
}
@@ -80,6 +81,7 @@ vmxnet3_disable_all_intrs(struct vmxnet3_adapter *adapter)
{
int i;
+ adapter->shared->devRead.intrConf.intrCtrl |= VMXNET3_IC_DISABLE_ALL;
for (i = 0; i < adapter->intr.num_intrs; i++)
vmxnet3_disable_intr(adapter, i);
}
@@ -1880,6 +1882,7 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
devRead->intrConf.modLevels[i] = adapter->intr.mod_levels[i];
devRead->intrConf.eventIntrIdx = adapter->intr.event_intr_idx;
+ devRead->intrConf.intrCtrl |= VMXNET3_IC_DISABLE_ALL;
/* rx filter settings */
devRead->rxFilterConf.rxMode = 0;
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 7985ba4..0ddfe3c 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -68,10 +68,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.0.6.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.0.9.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01000600
+#define VMXNET3_DRIVER_VERSION_NUM 0x01000900
/*
^ permalink raw reply related
* [PATCH 2.6.35-rc1] net: vmxnet3 fixes [3/5] Initialize link state at probe time
From: Shreyas Bhatewara @ 2010-07-07 9:28 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, pv-drivers
In-Reply-To: <alpine.LRH.2.00.1007070125440.4652@localhost.localdomain>
Author: Shreyas Bhatewara <sbhatewara@vmware.com>
Initialize vmxnet3 link state at probe time
This change initializes the state of link at the time when driver is
loaded. The ethtool output for 'link detected' and 'link speed'
is thus valid even before the interface is brought up.
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 29db294..31a838f 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -130,7 +130,7 @@ vmxnet3_tq_stop(struct vmxnet3_tx_queue *tq, struct vmxnet3_adapter *adapter)
* Check the link state. This may start or stop the tx queue.
*/
static void
-vmxnet3_check_link(struct vmxnet3_adapter *adapter)
+vmxnet3_check_link(struct vmxnet3_adapter *adapter, bool affectTxQueue)
{
u32 ret;
@@ -143,14 +143,16 @@ vmxnet3_check_link(struct vmxnet3_adapter *adapter)
if (!netif_carrier_ok(adapter->netdev))
netif_carrier_on(adapter->netdev);
- vmxnet3_tq_start(&adapter->tx_queue, adapter);
+ if (affectTxQueue)
+ vmxnet3_tq_start(&adapter->tx_queue, adapter);
} else {
printk(KERN_INFO "%s: NIC Link is Down\n",
adapter->netdev->name);
if (netif_carrier_ok(adapter->netdev))
netif_carrier_off(adapter->netdev);
- vmxnet3_tq_stop(&adapter->tx_queue, adapter);
+ if (affectTxQueue)
+ vmxnet3_tq_stop(&adapter->tx_queue, adapter);
}
}
@@ -165,7 +167,7 @@ vmxnet3_process_events(struct vmxnet3_adapter *adapter)
/* Check if link state has changed */
if (events & VMXNET3_ECR_LINK)
- vmxnet3_check_link(adapter);
+ vmxnet3_check_link(adapter, true);
/* Check if there is an error on xmit/recv queues */
if (events & (VMXNET3_ECR_TQERR | VMXNET3_ECR_RQERR)) {
@@ -1947,7 +1949,7 @@ vmxnet3_activate_dev(struct vmxnet3_adapter *adapter)
* Check link state when first activating device. It will start the
* tx queue if the link is up.
*/
- vmxnet3_check_link(adapter);
+ vmxnet3_check_link(adapter, true);
napi_enable(&adapter->napi);
vmxnet3_enable_all_intrs(adapter);
@@ -2549,6 +2551,7 @@ vmxnet3_probe_device(struct pci_dev *pdev,
}
set_bit(VMXNET3_STATE_BIT_QUIESCED, &adapter->state);
+ vmxnet3_check_link(adapter, false);
atomic_inc(&devices_found);
return 0;
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 0ddfe3c..5c94afa 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -68,10 +68,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.0.9.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.0.10.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01000900
+#define VMXNET3_DRIVER_VERSION_NUM 0x01000A00
/*
^ permalink raw reply related
* [PATCH 2.6.35-rc1] net: vmxnet3 fixes [4/5] Do not reset when the device is not opened
From: Shreyas Bhatewara @ 2010-07-07 9:31 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, pv-drivers, ronghua, matthieu
In-Reply-To: <alpine.LRH.2.00.1007070202080.5939@localhost.localdomain>
commit bc8b3f0b3978d3c0a201926b2e2bd5c732e0352e
Author: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Tue Jul 6 17:00:48 2010 -0700
No reset when the device is not opened
If a reset is scheduled, and the device goes thru close and open, it
may happen that reset and open may run in parallel.
The reset code now bails out if the device is not opened.
Signed-off-by: Ronghua Zang <ronghua@vmware.com>
Signed-off-by: Matthieu Bucchianeri <matthieu@vmware.com>
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 31a838f..01a5bb7 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2417,8 +2417,9 @@ vmxnet3_reset_work(struct work_struct *data)
if (test_and_set_bit(VMXNET3_STATE_BIT_RESETTING, &adapter->state))
return;
- /* if the device is closed, we must leave it alone */
- if (netif_running(adapter->netdev)) {
+ /* if the device is closed or is being opened, we must leave it alone */
+ if (netif_running(adapter->netdev) &&
+ (adapter->netdev->flags & IFF_UP)) {
printk(KERN_INFO "%s: resetting\n", adapter->netdev->name);
vmxnet3_quiesce_dev(adapter);
vmxnet3_reset_dev(adapter);
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 5c94afa..8e1f704 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -68,10 +68,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.0.10.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.0.11.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01000A00
+#define VMXNET3_DRIVER_VERSION_NUM 0x01000B00
/*
^ permalink raw reply related
* [PATCH 2.6.35-rc1] net: vmxnet3 fixes [5/5] Respect the interrupt type in VM configuration
From: Shreyas Bhatewara @ 2010-07-07 9:34 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, pv-drivers
In-Reply-To: <alpine.LRH.2.00.1007070202080.5939@localhost.localdomain>
Respect the interrupt type set in VM configuration.
When interrupt type is not auto, do not ignore the interrupt type set from
VM configuration.
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 01a5bb7..c6d756f 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2355,9 +2355,13 @@ vmxnet3_alloc_intr_resources(struct vmxnet3_adapter *adapter)
adapter->intr.mask_mode = (cfg >> 2) & 0x3;
if (adapter->intr.type == VMXNET3_IT_AUTO) {
- int err;
+ adapter->intr.type = VMXNET3_IT_MSIX;
+ }
#ifdef CONFIG_PCI_MSI
+ if (adapter->intr.type == VMXNET3_IT_MSIX) {
+ int err;
+
adapter->intr.msix_entries[0].entry = 0;
err = pci_enable_msix(adapter->pdev, adapter->intr.msix_entries,
VMXNET3_LINUX_MAX_MSIX_VECT);
@@ -2366,15 +2370,18 @@ vmxnet3_alloc_intr_resources(struct vmxnet3_adapter *adapter)
adapter->intr.type = VMXNET3_IT_MSIX;
return;
}
-#endif
+ adapter->intr.type = VMXNET3_IT_MSI;
+ }
+ if (adapter->intr.type == VMXNET3_IT_MSI) {
+ int err;
err = pci_enable_msi(adapter->pdev);
if (!err) {
adapter->intr.num_intrs = 1;
- adapter->intr.type = VMXNET3_IT_MSI;
return;
}
}
+#endif /* CONFIG_PCI_MSI */
adapter->intr.type = VMXNET3_IT_INTX;
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 8e1f704..6bab6ff 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -68,10 +68,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.0.11.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.0.12.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01000B00
+#define VMXNET3_DRIVER_VERSION_NUM 0x01000C00
/*
^ permalink raw reply related
* Re: IPVS: Incorrect helper use for SCTP [was: wensong@linux-vs.org, horms@verge.net.au]
From: Simon Horman @ 2010-07-07 12:21 UTC (permalink / raw)
To: xiaoyu Du; +Cc: lvs-devel, linux-kernel, netdev
In-Reply-To: <AANLkTinEKn_UBpjf3k2DZn1euMM6z2UM_yeDPvdEQkav@mail.gmail.com>
[CCed netdev]
Thanks,
that looks correct to me. Have you tested this change?
If so could you provided a Signed-off-by line
as per section 12 of Documentation/SubmittingPatches?
On Wed, Jul 07, 2010 at 05:19:06PM +0800, xiaoyu Du wrote:
> Hi，all
>
> After I compared the sctp with tcp and udp, I thinkt his a bug that
> sctp_dnat_handler Incorrectly invoked ip_vs_app_pkt_out.
> below is the patch.
>
> ---
> net/netfilter/ipvs/ip_vs_proto_sctp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c
> b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> index c9a3f7a..db55759 100644
> --- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
> +++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
> @@ -173,7 +173,7 @@ sctp_dnat_handler(struct sk_buff *skb,
> return 0;
>
> /* Call application helper if needed */
> - if (!ip_vs_app_pkt_out(cp, skb))
> + if (!ip_vs_app_pkt_in(cp, skb))
> return 0;
> }
>
> --
> --
> To unsubscribe from this list: send the line "unsubscribe lvs-devel" 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: QoS weirdness : HTB accuracy
From: Jesper Dangaard Brouer @ 2010-07-07 11:40 UTC (permalink / raw)
To: netdev
In-Reply-To: <067c83163988908ef546d7ff7f560a17@localhost>
Julien Vehent <julien <at> linuxwall.info> writes:
> I observe unused bandwidth on my QoS policy that I cannot explain.
> Conditions are: I have a HTB tree with 8 classes and a total rate of
> 768kbits. I use the ATM option so I assume the real rate to be something
> close to 675kbits (about 88% of the ethernet rate).
>
> The sum of my 8 rates is exactly 768kbits. Some have ceil values up to
> 768kbits.
>
> When class 20 "tcp_acks" starts borrowing, TC reduces the total bandwidth
> down to 595kbits/S (minus 79kbits/s). And I can't explain why....
Fortunately, I can explain why. This is actually the expected/correct
behavior. The "tcp_acks" class only receives small packets, and small
packets have a significantly higher overhead than larger packets.
The simple explanation is that small packets will (almost) always
result in two ATM frames being transmittet, thus resulting in 106
bytes (2x 53 bytes) being used on the link.
> The attached graph "tc_htb_weirdness.png" shows the result: there are
> 'holes' in the sending rate.
This is as explained above the behavior I expected to see. As the
small packets eats/consumes more bandwidth on the physical link, and
your observations are based upon what happens on the Ethernet layer.
--
Best regards
Jesper Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] NET: nl80211, fix lock imbalance and netdev referencing
From: Jiri Slaby @ 2010-07-07 13:02 UTC (permalink / raw)
To: johannes
Cc: jirislaby, linux-kernel, John W. Linville, David S. Miller,
Jouni Malinen, Samuel Ortiz, linux-wireless, netdev
Stanse found that nl80211_set_wiphy imporperly handles a lock and netdev
reference and contains unreachable code. It is because there return statement
isntead of assignment to result variable. Fix that.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jouni Malinen <j@w1.fi>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
---
net/wireless/nl80211.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 85285b4..fbfac58 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -877,7 +877,7 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
int idx, mbm = 0;
if (!rdev->ops->set_tx_power) {
- return -EOPNOTSUPP;
+ result = -EOPNOTSUPP;
goto bad_res;
}
--
1.7.1
^ permalink raw reply related
* Re: QoS weirdness : HTB accuracy
From: Jesper Dangaard Brouer @ 2010-07-07 13:07 UTC (permalink / raw)
To: Andrew Beverley
Cc: Julien Vehent, Philip A. Prindeville, Netdev, netfilter, hawk
In-Reply-To: <1278265807.1506.86.camel@andybev>
On Sun, 4 Jul 2010, Andrew Beverley wrote:
>>> I was, in fact, an error in my ruleset. I had put the 'linklayer atm' at
>>> both the branch and leaf levels, so the overhead was computed twice,
>>> creating those holes in the bandwidth.
>>
>> I am seeing similar behaviour with my setup. Am I making the same
>> mistake? A subset of my rules is as follows:
>>
>> tc qdisc add dev ppp0 root handle 1: htb r2q 1
>>
>> tc class add dev ppp0 parent 1: classid 1:1 htb \
>> rate ${DOWNLINK}kbit ceil ${DOWNLINK}kbit \
>> overhead $overhead linklayer atm <------- Here
>>
>> tc class add dev ppp0 parent 1:1 classid 1:10 htb \
>> rate 612kbit ceil 612kbit prio 0 \
>> overhead $overhead linklayer atm <------- And here
>>
>> tc qdisc add dev ppp0 parent 1:10 handle 4210: \
>> sfq perturb 10 limit 50
>>
>> tc filter add dev ppp0 parent 1:0 protocol ip \
>> prio 10 handle 10 fw flowid 1:10
>
> I removed the overhead option on the first leaf, and the speeds change
> to what I expect. However, the rules above are taken straight from the
> ADSL Optimizer project, which was the source of the original overhead
> patch for tc. So is the ADSL Optimizer project wrong?
After looking at the HTB kernel code I believe that the ADSL Optimizer
project is NOT wrong. You should/must set the linklayer option on both
the root class and leaf (else you would be charging the root/parent node
too little).
It is the expected behavior that small packets cause a significant
reduction in the available bandwidth on the ATM link. Small packets will
(almost) always cause 2 ATM packets (being send) using 106 bytes, thus
eg. sending a 40 bytes TCP ACK packet result in approx 62% overhead.
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: QoS weirdness : HTB accuracy
From: Jussi Kivilinna @ 2010-07-07 15:07 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Andrew Beverley, Julien Vehent, Philip A. Prindeville, Netdev,
netfilter, hawk
In-Reply-To: <Pine.LNX.4.64.1007071457020.6631@ask.diku.dk>
Quoting "Jesper Dangaard Brouer" <hawk@diku.dk>:
>
> On Sun, 4 Jul 2010, Andrew Beverley wrote:
>
>>>> I was, in fact, an error in my ruleset. I had put the 'linklayer atm' at
>>>> both the branch and leaf levels, so the overhead was computed twice,
>>>> creating those holes in the bandwidth.
>>>
>>> I am seeing similar behaviour with my setup. Am I making the same
>>> mistake? A subset of my rules is as follows:
>>>
>>> tc qdisc add dev ppp0 root handle 1: htb r2q 1
>>>
>>> tc class add dev ppp0 parent 1: classid 1:1 htb \
>>> rate ${DOWNLINK}kbit ceil ${DOWNLINK}kbit \
>>> overhead $overhead linklayer atm <------- Here
>>>
>>> tc class add dev ppp0 parent 1:1 classid 1:10 htb \
>>> rate 612kbit ceil 612kbit prio 0 \
>>> overhead $overhead linklayer atm <------- And here
>>>
>>> tc qdisc add dev ppp0 parent 1:10 handle 4210: \
>>> sfq perturb 10 limit 50
>>>
>>> tc filter add dev ppp0 parent 1:0 protocol ip \
>>> prio 10 handle 10 fw flowid 1:10
>>
>> I removed the overhead option on the first leaf, and the speeds change
>> to what I expect. However, the rules above are taken straight from the
>> ADSL Optimizer project, which was the source of the original overhead
>> patch for tc. So is the ADSL Optimizer project wrong?
>
> After looking at the HTB kernel code I believe that the ADSL
> Optimizer project is NOT wrong. You should/must set the linklayer
> option on both the root class and leaf (else you would be charging
> the root/parent node too little).
>
It's been while I looked at the linklayer/size-table code, but if I
remember right overhead is calculated with first linklayer packet sees
in qdisc. So when packet goes to leaf with 'linklayer atm', packet get
packet size with overhead for ATM and root linklayer is not used for
that packet. Because of this you can have leafs with different
overheads (pppoe, ipv6-tunnel, etc, with ) and all get right
overhead... ..
..
...Uh oh...
HTB still has linklayer/overhead of its own, I was talking about the
generic linklayer code that can be used with all qdiscs. Never mind,
sorry.
-Jussi
^ permalink raw reply
* Kernel bug 14839: Trying to use a TUN device for IPv6 traffic, cannot set destination address.
From: Ian Shorter @ 2010-07-07 15:04 UTC (permalink / raw)
To: netdev
Hello,
I reported this kernel bug at the end of 2009. In February 2010 Stephen Hemminger said that the problem was not unique to TUN, and that I should bring it up on the network maintainers mailing list, which I am finally doing. Do I need to provide the problem description again?
Regards
mcisho
^ permalink raw reply
* Re: Kernel bug 14839: Trying to use a TUN device for IPv6 traffic, cannot set destination address.
From: Rémi Denis-Courmont @ 2010-07-07 15:25 UTC (permalink / raw)
To: Ian Shorter; +Cc: netdev
In-Reply-To: <846562.91258.qm@web113913.mail.gq1.yahoo.com>
On Wed, 7 Jul 2010 08:04:33 -0700 (PDT), Ian Shorter <mcisho@yahoo.com>
wrote:
> I reported this kernel bug at the end of 2009. In February 2010 Stephen
> Hemminger said that the problem was not unique to TUN, and that I should
> bring it up on the network maintainers mailing list, which I am finally
> doing. Do I need to provide the problem description again?
I really do not see the point of setting a destination address on a TUN
device. Since a TUN device has no link-layer, the notions of gateway or
destination is rather void of meaning.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* [PATCH linux-2.6.35-rc3] ks8842 driver
From: Choi, David @ 2010-07-07 15:24 UTC (permalink / raw)
To: netdev; +Cc: Choi, David, Li, Charles
To whom it may have concerned,
It seems that there are differences between Micrel ks8842 device and Timberdale FPGA based device with generic bus interface. In order to check the differences, I have sent several times but have not received any response. This patch is to support ks8841/ks8842 device from Micrel.
From: David J. Choi <david.choi@micrel.com>
Body of the explanation:
-support 16bit and 32bit bus width.
-add device reset for ks8842/8841 Micrel device.
-set 100Mbps as a default for Micrel device.
-set MAC address in both MAC/Switch layer with different sequence for Micrel device,
as mentioned in data sheet.
Signed-off-by: David J. Choi <david.choi@micrel.com>
---
--- linux-2.6.35-rc3/drivers/net/ks8842.c.orig 2010-07-01 16:26:50.000000000 -0700
+++ linux-2.6.35-rc3/drivers/net/ks8842.c 2010-07-07 07:41:03.000000000 -0700
@@ -18,6 +18,7 @@
/* Supports:
* The Micrel KS8842 behind the timberdale FPGA
+ * The genuine Micrel KS8841/42 device with ISA 16/32bit bus interface
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -191,6 +192,12 @@ static inline u32 ks8842_read32(struct k
static void ks8842_reset(struct ks8842_adapter *adapter)
{
+#ifdef CONFIG_MICREL_KS884X
+ ks8842_write16(adapter, 3, 1, REG_GRR);
+ msleep(10);
+ iowrite16(0, adapter->hw_addr + REG_GRR);
+
+#else
/* The KS8842 goes haywire when doing softare reset
* a work around in the timberdale IP is implemented to
* do a hardware reset instead
@@ -201,6 +208,7 @@ static void ks8842_reset(struct ks8842_a
iowrite16(32, adapter->hw_addr + REG_SELECT_BANK);
iowrite32(0x1, adapter->hw_addr + REG_TIMB_RST);
msleep(20);
+#endif
}
static void ks8842_update_link_status(struct net_device *netdev,
@@ -269,8 +277,11 @@ static void ks8842_reset_hw(struct ks884
/* restart port auto-negotiation */
ks8842_enable_bits(adapter, 49, 1 << 13, REG_P1CR4);
+
+#ifndef CONFIG_MICREL_KS884X
/* only advertise 10Mbps */
ks8842_clear_bits(adapter, 49, 3 << 2, REG_P1CR4);
+#endif
/* Enable the transmitter */
ks8842_enable_tx(adapter);
@@ -296,6 +307,20 @@ static void ks8842_read_mac_addr(struct
for (i = 0; i < ETH_ALEN; i++)
dest[ETH_ALEN - i - 1] = ks8842_read8(adapter, 2, REG_MARL + i);
+#ifdef CONFIG_MICREL_KS884X
+ /*
+ the sequence of saving mac addr between MAC and Switch is
+ different.
+ */
+
+ mac = ks8842_read16(adapter, 2, REG_MARL);
+ ks8842_write16(adapter, 39, mac, REG_MACAR3);
+ mac = ks8842_read16(adapter, 2, REG_MARM);
+ ks8842_write16(adapter, 39, mac, REG_MACAR2);
+ mac = ks8842_read16(adapter, 2, REG_MARH);
+ ks8842_write16(adapter, 39, mac, REG_MACAR1);
+#else
+
/* make sure the switch port uses the same MAC as the QMU */
mac = ks8842_read16(adapter, 2, REG_MARL);
ks8842_write16(adapter, 39, mac, REG_MACAR1);
@@ -303,6 +328,7 @@ static void ks8842_read_mac_addr(struct
ks8842_write16(adapter, 39, mac, REG_MACAR2);
mac = ks8842_read16(adapter, 2, REG_MARH);
ks8842_write16(adapter, 39, mac, REG_MACAR3);
+#endif
}
static void ks8842_write_mac_addr(struct ks8842_adapter *adapter, u8 *mac)
@@ -313,8 +339,13 @@ static void ks8842_write_mac_addr(struct
spin_lock_irqsave(&adapter->lock, flags);
for (i = 0; i < ETH_ALEN; i++) {
ks8842_write8(adapter, 2, mac[ETH_ALEN - i - 1], REG_MARL + i);
+#ifdef CONFIG_MICREL_KS884X
+ ks8842_write8(adapter, 39, mac[ETH_ALEN - i - 1],
+ REG_MACAR3 + 1 - i);
+#else
ks8842_write8(adapter, 39, mac[ETH_ALEN - i - 1],
REG_MACAR1 + i);
+#endif
}
spin_unlock_irqrestore(&adapter->lock, flags);
}
@@ -328,8 +359,12 @@ static int ks8842_tx_frame(struct sk_buf
{
struct ks8842_adapter *adapter = netdev_priv(netdev);
int len = skb->len;
+#ifdef CONFIG_KS884X_16BIT
+ u16 *ptr16 = (u16 *)skb->data;
+#else
u32 *ptr = (u32 *)skb->data;
u32 ctrl;
+#endif
dev_dbg(&adapter->pdev->dev,
"%s: len %u head %p data %p tail %p end %p\n",
@@ -340,6 +375,18 @@ static int ks8842_tx_frame(struct sk_buf
if (ks8842_tx_fifo_space(adapter) < len + 8)
return NETDEV_TX_BUSY;
+#ifdef CONFIG_KS884X_16BIT
+ ks8842_write16(adapter, 17, 0x8000 | 0x100, REG_QMU_DATA_LO);
+ ks8842_write16(adapter, 17, (u16)len, REG_QMU_DATA_HI);
+ netdev->stats.tx_bytes += len;
+
+ /* copy buffer */
+ while (len > 0) {
+ iowrite16(*ptr16++, adapter->hw_addr + REG_QMU_DATA_LO);
+ iowrite16(*ptr16++, adapter->hw_addr + REG_QMU_DATA_HI);
+ len -= sizeof(u32);
+ }
+#else
/* the control word, enable IRQ, port 1 and the length */
ctrl = 0x8000 | 0x100 | (len << 16);
ks8842_write32(adapter, 17, ctrl, REG_QMU_DATA_LO);
@@ -352,6 +399,7 @@ static int ks8842_tx_frame(struct sk_buf
len -= sizeof(u32);
ptr++;
}
+#endif
/* enqueue packet */
ks8842_write16(adapter, 17, 1, REG_TXQCR);
@@ -364,10 +412,15 @@ static int ks8842_tx_frame(struct sk_buf
static void ks8842_rx_frame(struct net_device *netdev,
struct ks8842_adapter *adapter)
{
+#ifdef CONFIG_KS884X_16BIT
+ u16 status = ks8842_read16(adapter, 17, REG_QMU_DATA_LO);
+ int len = (int)ks8842_read16(adapter, 17, REG_QMU_DATA_HI) & 0xffff;
+#else
u32 status = ks8842_read32(adapter, 17, REG_QMU_DATA_LO);
int len = (status >> 16) & 0x7ff;
status &= 0xffff;
+#endif
dev_dbg(&adapter->pdev->dev, "%s - rx_data: status: %x\n",
__func__, status);
@@ -379,13 +432,28 @@ static void ks8842_rx_frame(struct net_d
dev_dbg(&adapter->pdev->dev, "%s, got package, len: %d\n",
__func__, len);
if (skb) {
+#ifdef CONFIG_KS884X_16BIT
+ u16 *data16;
+#else
u32 *data;
+#endif
netdev->stats.rx_packets++;
netdev->stats.rx_bytes += len;
if (status & RXSR_MULTICAST)
netdev->stats.multicast++;
+#ifdef CONFIG_KS884X_16BIT
+ data16 = (u16 *)skb_put(skb, len);
+ ks8842_select_bank(adapter, 17);
+ while (len > 0) {
+ *data16++ = ioread16(adapter->hw_addr +
+ REG_QMU_DATA_LO);
+ *data16++ = ioread16(adapter->hw_addr +
+ REG_QMU_DATA_HI);
+ len -= sizeof(u32);
+ }
+#else
data = (u32 *)skb_put(skb, len);
ks8842_select_bank(adapter, 17);
@@ -397,6 +465,7 @@ static void ks8842_rx_frame(struct net_d
skb->protocol = eth_type_trans(skb, netdev);
netif_rx(skb);
+#endif
} else
netdev->stats.rx_dropped++;
} else {
--- linux-2.6.35-rc3/drivers/net/Kconfig.orig 2010-07-02 15:52:41.000000000 -0700
+++ linux-2.6.35-rc3/drivers/net/Kconfig 2010-07-07 07:45:47.000000000 -0700
@@ -1748,11 +1748,29 @@ config TLAN
Please email feedback to <torben.mathiasen@compaq.com>.
config KS8842
- tristate "Micrel KSZ8842"
+ tristate "Micrel KSZ8841/42 with generic bus interface"
depends on HAS_IOMEM
help
- This platform driver is for Micrel KSZ8842 / KS8842
- 2-port ethernet switch chip (managed, VLAN, QoS).
+ This platform driver is for KSZ8841(1-port) / KS8842(2-port)
+ ethernet switch chip (managed, VLAN, QoS) from Micrel or
+ Timberdale(FPGA).
+
+if KS8842
+config MICREL_KS884X
+ boolean "KSZ8841/42 device from Micrel"
+ default n
+ help
+ Say Y to use Micrel device. Otherwise Timberdale(FPGA) device is
+ selected.
+
+config KS884X_16BIT
+ boolean "16bit bus width"
+ default y
+ help
+ This option specifies 16bit or 32bit bus interface. Say Y to use
+ 16bit bus. Otherwise 32bit bus is selected.
+
+endif # KS8842
config KS8851
tristate "Micrel KS8851 SPI"
---
^ permalink raw reply
* [PATCH RFC 0/4] ARM/KGDB: Some fixes for SMP machines
From: Anton Vorontsov @ 2010-07-07 17:12 UTC (permalink / raw)
To: kgdb-bugreport
Cc: Russell King, David S. Miller, Jason Wessel, netdev,
linux-arm-kernel
Hi all,
It appears that KGDB can easily hang SMP ARM machines.
Here are few fixes that I come up with.
Before the patches, doing 'b schedule' and then 1-3 'continue'
or 'si' gdb commands would cause the board to lock-up completely.
After the patches, KGDB seems to be bullet proof. Well, at least
with the 'b schedule' testcase, there might be other bugs which
I didn't hit yet. ;-)
Notes:
1. I'm testing with I/D caches disabled. With enabled caches,
ARMv6K still locks-up. I'll test ARMv7 soon, and will try
to debug cache issues on ARMv6K.
2. The patches are against a heavily patched kernel, and so far
I didn't rebase them onto the 'debug core' rework as found
in the very latest mainline kernels. I'll rebase the patches
soon, so for now this is just an RFC.
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH RFC 1/4] ARM: kgdb: Must poll for IPIs during busy-waiting
From: Anton Vorontsov @ 2010-07-07 17:13 UTC (permalink / raw)
To: kgdb-bugreport
Cc: Russell King, David S. Miller, Jason Wessel, netdev,
linux-arm-kernel
In-Reply-To: <20100707171222.GA16448@oksana.dev.rtsoft.ru>
On architectures w/o NMIs (e.g. ARM), ordinary (maskable) IRQs are used
for SMP IPI calls.
Various deadlocks are possible if we not poll for IPIs:
- The master CPU might hang in kgdb_roundup_cpus() because the slave CPU
does not process IPIs;
- DMA cache coherency calls are implemented as IPIs, so the master CPU
might hang in *dma_sync_*() calls that may be issued by the KGDB IO
back-ends.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
arch/arm/kernel/kgdb.c | 8 ++++++++
kernel/kgdb.c | 23 ++++++++++++++++++++++-
2 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index a5b846b..5c61100 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -11,6 +11,7 @@
*/
#include <linux/irq.h>
#include <linux/kgdb.h>
+#include <asm/smp.h>
#include <asm/traps.h>
/* Make a local copy of the registers passed into the handler (bletch) */
@@ -171,6 +172,13 @@ void kgdb_roundup_cpus(unsigned long flags)
local_irq_disable();
}
+#ifdef CONFIG_SMP
+void kgdb_arch_poll_ipi(struct pt_regs *regs)
+{
+ do_IPI(regs);
+}
+#endif
+
/**
* kgdb_arch_init - Perform any architecture specific initalization.
*
diff --git a/kernel/kgdb.c b/kernel/kgdb.c
index 9934aa0..97edb05 100644
--- a/kernel/kgdb.c
+++ b/kernel/kgdb.c
@@ -225,6 +225,25 @@ int __weak kgdb_arch_init(void)
return 0;
}
+/*
+ * On architectures w/o NMIs (e.g. ARM), ordinary (maskable) IRQs are used
+ * for SMP IPI calls.
+ *
+ * Various deadlocks are possible if we not poll for IPIs:
+ *
+ * - The master CPU might hang in kgdb_roundup_cpus() because the slave CPU
+ * does not process IPIs;
+ * - DMA cache coherency calls are implemented as IPIs, so the master CPU
+ * might hang in *dma_sync_*() calls that may be issued by the KGDB IO
+ * back-ends.
+ *
+ * The rule of thumb: always poll for IPIs in busy-waiting loops until
+ * all CPUs are in KGDB (i.e. all cpu_in_kgdb[] are set).
+ */
+void __weak kgdb_arch_poll_ipi(struct pt_regs *regs)
+{
+}
+
int __weak kgdb_skipexception(int exception, struct pt_regs *regs)
{
return 0;
@@ -1389,6 +1408,8 @@ acquirelock:
* master cpu and acquire the kgdb_active lock:
*/
while (1) {
+ kgdb_arch_poll_ipi(regs);
+
if (kgdb_info[cpu].exception_state & DCPU_WANT_MASTER) {
if (atomic_cmpxchg(&kgdb_active, -1, cpu) == cpu)
break;
@@ -1465,7 +1486,7 @@ return_normal:
*/
for_each_online_cpu(i) {
while (!atomic_read(&cpu_in_kgdb[i]))
- cpu_relax();
+ kgdb_arch_poll_ipi(regs);
}
/*
--
1.7.0.5
^ permalink raw reply related
* [PATCH RFC 3/4] net: Implement napi_try_disable()
From: Anton Vorontsov @ 2010-07-07 17:13 UTC (permalink / raw)
To: kgdb-bugreport
Cc: Russell King, David S. Miller, Jason Wessel, netdev,
linux-arm-kernel
In-Reply-To: <20100707171222.GA16448@oksana.dev.rtsoft.ru>
For KGDBoE we'll need to disable NAPI, so that we don't randomly
interrupt secondary CPUs while they process networking stuff.
We need to wait for NAPI to become disabled from an atomic context,
thus we can't use napi_disable() as it calls msleep().
Plus, in KGDB we have to always poll for IPIs during busy-waiting,
which means that we must implement the function in a such way that
we can do some caller specific work during the time we wait for
NAPI disable, so just changing msleep() to mdelay() won't work.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
include/linux/netdevice.h | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 08a1dd8..4fc24eb 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -414,6 +414,27 @@ extern void __napi_complete(struct napi_struct *n);
extern void napi_complete(struct napi_struct *n);
/**
+ * napi_try_disable - try to prevent NAPI from scheduling
+ * @n: napi context
+ *
+ * This call is similar to napi_disable(), except that it doesn't
+ * wait till any outstanding processing completes, but returns
+ * whether napi was successfuly disabled.
+ *
+ * Note that you still must wait till napi is actually disabled,
+ * so the only benefit from using this call is that you can do
+ * some useful work while you wait.
+ */
+static inline int napi_try_disable(struct napi_struct *n)
+{
+ set_bit(NAPI_STATE_DISABLE, &n->state);
+ if (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
+ return 0;
+ clear_bit(NAPI_STATE_DISABLE, &n->state);
+ return 1;
+}
+
+/**
* napi_disable - prevent NAPI from scheduling
* @n: napi context
*
--
1.7.0.5
^ permalink raw reply related
* [PATCH RFC 4/4] kgdb: Quiesce IO back-end before rounding up secondary CPUs
From: Anton Vorontsov @ 2010-07-07 17:13 UTC (permalink / raw)
To: kgdb-bugreport
Cc: Russell King, David S. Miller, Jason Wessel, netdev,
linux-arm-kernel
In-Reply-To: <20100707171222.GA16448@oksana.dev.rtsoft.ru>
KGDB may try to roundup secondary CPUs while they're in the IO
back-end code (e.g. NAPI is polling an eth device), so the
secondary CPU might stop processing IO at a random place, which
may cause the IO back-end to become unusable for KGDB itself.
This patch implements try_quiesce and activate KGDB IO callbacks,
so that we quiesce the IO back-end before rounding up the CPUs.
So far it's only implemented for KGDBoE driver.
Note that we have to quiesce the devices via _try mechanism since
we have to poll for IPIs during the time we wait for the other
CPUs.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/kgdboe.c | 21 +++++++++++++++++++++
include/linux/kgdb.h | 2 ++
kernel/kgdb.c | 6 ++++++
3 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/net/kgdboe.c b/drivers/net/kgdboe.c
index 939797a..b46cc9a 100644
--- a/drivers/net/kgdboe.c
+++ b/drivers/net/kgdboe.c
@@ -270,8 +270,29 @@ static int param_set_kgdboe_var(const char *kmessage, struct kernel_param *kp)
return 0;
}
+static int eth_try_quiesce(void)
+{
+ struct napi_struct *napi;
+
+ list_for_each_entry(napi, &np.dev->napi_list, dev_list) {
+ if (!napi_try_disable(napi))
+ return 0;
+ }
+ return 1;
+}
+
+static void eth_activate(void)
+{
+ struct napi_struct *napi;
+
+ list_for_each_entry(napi, &np.dev->napi_list, dev_list)
+ napi_enable(napi);
+}
+
static struct kgdb_io local_kgdb_io_ops = {
.name = "kgdboe",
+ .try_quiesce = eth_try_quiesce,
+ .activate = eth_activate,
.read_char = eth_get_char,
.write_char = eth_put_char,
.flush = eth_flush_buf,
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index 4c80859..93cd305 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -250,6 +250,8 @@ struct kgdb_arch {
*/
struct kgdb_io {
const char *name;
+ int (*try_quiesce) (void);
+ void (*activate) (void);
int (*read_char) (void);
void (*write_char) (u8);
void (*flush) (void);
diff --git a/kernel/kgdb.c b/kernel/kgdb.c
index 97edb05..e7a2274 100644
--- a/kernel/kgdb.c
+++ b/kernel/kgdb.c
@@ -1475,6 +1475,9 @@ return_normal:
atomic_inc(&passive_cpu_wait[i]);
}
+ while (kgdb_io_ops->try_quiesce && !kgdb_io_ops->try_quiesce())
+ kgdb_arch_poll_ipi(regs);
+
#ifdef CONFIG_SMP
/* Signal the other CPUs to enter kgdb_wait() */
if ((!kgdb_single_step) && kgdb_do_roundup)
@@ -1489,6 +1492,9 @@ return_normal:
kgdb_arch_poll_ipi(regs);
}
+ if (kgdb_io_ops->activate)
+ kgdb_io_ops->activate();
+
/*
* At this point the primary processor is completely
* in the debugger and all secondary CPUs are quiescent
--
1.7.0.5
^ permalink raw reply related
* [PATCH RFC 2/4] ARM: kgdb: Disable preemption before re-enabling interrupts
From: Anton Vorontsov @ 2010-07-07 17:13 UTC (permalink / raw)
To: kgdb-bugreport
Cc: Russell King, David S. Miller, Jason Wessel, netdev,
linux-arm-kernel
In-Reply-To: <20100707171222.GA16448@oksana.dev.rtsoft.ru>
We have to disable preemption before enabling local IRQs because
local_irq_enable() makes it possible for the kernel to reschedule,
so the kernel might hit a breakpoint causing itself to re-enter
KGDB and die.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
arch/arm/kernel/kgdb.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index 5c61100..6ece654 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -167,9 +167,17 @@ static void kgdb_call_nmi_hook(void *ignored)
void kgdb_roundup_cpus(unsigned long flags)
{
+ /*
+ * We have to disable preemption before enabling local
+ * IRQs because local_irq_enable() makes it possible for
+ * the kernel to reschedule, so the kernel might hit a
+ * breakpoint causing itself to re-enter KGDB and die.
+ */
+ preempt_disable();
local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
local_irq_disable();
+ preempt_enable();
}
#ifdef CONFIG_SMP
--
1.7.0.5
^ permalink raw reply related
* [PATCH] vlan: allow TSO setting on vlan interfaces
From: Eric Dumazet @ 2010-07-07 17:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Patrick McHardy
When we need to shape traffic with low speeds, we need to disable tso on
network interface :
ethtool -K eth0.2240 tso off
It seems vlan interfaces miss the set_tso() ethtool method.
Propagating tso changes from lower device is not always wanted, some
vlan want TSO on, other want TSO off.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index c6456cb..d827c2e 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -844,6 +844,7 @@ static const struct ethtool_ops vlan_ethtool_ops = {
.get_link = ethtool_op_get_link,
.get_rx_csum = vlan_ethtool_get_rx_csum,
.get_flags = vlan_ethtool_get_flags,
+ .set_tso = ethtool_op_set_tso,
};
static const struct net_device_ops vlan_netdev_ops = {
^ permalink raw reply related
* Re: [PATCH] vlan: allow TSO setting on vlan interfaces
From: Ben Hutchings @ 2010-07-07 17:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Patrick McHardy
In-Reply-To: <1278522874.5906.9.camel@edumazet-laptop>
On Wed, 2010-07-07 at 19:14 +0200, Eric Dumazet wrote:
> When we need to shape traffic with low speeds, we need to disable tso on
> network interface :
>
> ethtool -K eth0.2240 tso off
>
> It seems vlan interfaces miss the set_tso() ethtool method.
> Propagating tso changes from lower device is not always wanted, some
> vlan want TSO on, other want TSO off.
But it should not be possible to enable TSO if the underlying device
doesn't support it.
Ben.
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
>
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index c6456cb..d827c2e 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -844,6 +844,7 @@ static const struct ethtool_ops vlan_ethtool_ops = {
> .get_link = ethtool_op_get_link,
> .get_rx_csum = vlan_ethtool_get_rx_csum,
> .get_flags = vlan_ethtool_get_flags,
> + .set_tso = ethtool_op_set_tso,
> };
>
> static const struct net_device_ops vlan_netdev_ops = {
>
--
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 2.6.35-rc1] net: vmxnet3 fixes [1/5] Spare skb to avoid starvation
From: Stephen Hemminger @ 2010-07-07 17:46 UTC (permalink / raw)
To: Shreyas Bhatewara; +Cc: netdev, pv-drivers
In-Reply-To: <alpine.LRH.2.00.1007070214400.6105@localhost.localdomain>
On Wed, 7 Jul 2010 02:21:55 -0700 (PDT)
Shreyas Bhatewara <sbhatewara@vmware.com> wrote:
>
>
> From: Shreyas Bhatewara <sbhatewara@vmware.com>
>
> skb_alloc() failure can cause the recv ring to loose all packet reception.
> Avoid this by introducing a spare buffer.
>
> Signed-off-by: Michael Stolarchuk <stolarchuk@vmware.com>
> Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
>
I don't see how this fixes the problem, what happens when
the spare buffer is used up? Better to design a flow control algorithm
that holds off sender if allocation fails, and retry allocation later
(for example with a work queue).
> diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
> index 989b742..5a50d10 100644
...
> /*
> @@ -149,6 +149,13 @@ vmxnet3_cmd_ring_desc_avail(struct vmxnet3_cmd_ring *ring)
> ring->next2comp - ring->next2fill - 1;
> }
>
> +static inline bool
> +vmxnet3_cmd_ring_desc_empty(struct vmxnet3_cmd_ring *ring)
> +{
> + return (ring->next2comp == ring->next2fill);
> +}
const is good practice on functions like this.
^ permalink raw reply
* Re: [PATCH 1/2] Export firmware assigned labels of network devices to sysfs
From: Narendra K @ 2010-07-07 17:48 UTC (permalink / raw)
To: greg
Cc: netdev, linux-hotplug, linux-pci, matt_domsch, jordan_hargrave,
charles_rose, vijay_nijhawan
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE612B27@blrx3m08.blr.amer.dell.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, July 07, 2010 4:52 AM
> To: K, Narendra
> Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org;
> linux-pci@vger.kernel.org; Domsch, Matt; Hargrave, Jordan; Rose,
> Charles; Nijhawan, Vijay
> Subject: Re: [PATCH 1/2] Export firmware assigned labels of network
> devices to sysfs
>
> On Tue, Jul 06, 2010 at 01:52:18PM -0500, Narendra K wrote:
> >
> > 'device_create_file' takes 'struct device_attribute *' as a param
> which
> > we have not used here because 'struct device_attribute' does not have
> .test
> > member which we needed in this patch.
>
> Why do you need it? What is calling that function? What am I missing
> here?
The function 'pci_create_smbiosname_file' below is calling the .test method.
For every pdev the function checks if it has a SMBIOS string associated
with it or not. If there is no string (and instance) associated, then the
attributes 'label' and 'instance' are not created for that pdev.
To check for the existance of the string, the .test method is needed and
it is not available in 'struct device_attribute'. It provides
.show and .store. We need a .show and .test. So we defined
+struct smbios_attribute smbios_attr_label = {
+ .attr = {.name = "label", .mode = 0444, .owner = THIS_MODULE},
+ .show = smbiosname_show,
+ .test = smbios_instance_string_exist,
+};
'smbios_instance_string_exist' checks if the pdev has a 'string' and 'instance'.
+static int
+pci_create_smbiosname_file(struct pci_dev *pdev)
+{
+ if (smbios_attr_label.test && smbios_attr_label.test(&pdev->dev, NULL, NULL)) {
+ if (sysfs_create_file(&pdev->dev.kobj, &smbios_attr_label.attr))
+ return -1;
+ if (sysfs_create_file(&pdev->dev.kobj, &smbios_attr_instance.attr))
+ return -1;
+ return 0;
+ }
+ return -1;
+}
+int pci_create_firmware_label_files(struct pci_dev *pdev)
+{
+ if (!pci_create_smbiosname_file(pdev))
>
> Please always run your patches through scripts/checkpatch.pl and fix up
> the issues it finds before sending it out and having everyone else point
> them out to you :)
>
> Also, a new thread is nice at times for new versions of patches...
Thanks for the feedback. Sorry for missing this.I would address all the issues
and post the patch in a new thread.
With regards,
Narendra K
^ 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