* [PATCH 2/6] netdev: octeon_mgmt: Fix race condition freeing TX buffers.
From: David Daney @ 2010-05-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, David Daney
In-Reply-To: <1273100593-11043-1-git-send-email-ddaney@caviumnetworks.com>
Under heavy load the TX cleanup tasklet and xmit threads would race
and try to free too many buffers.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
---
drivers/net/octeon/octeon_mgmt.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/octeon/octeon_mgmt.c b/drivers/net/octeon/octeon_mgmt.c
index bbbd737..b975a2f 100644
--- a/drivers/net/octeon/octeon_mgmt.c
+++ b/drivers/net/octeon/octeon_mgmt.c
@@ -189,12 +189,19 @@ static void octeon_mgmt_clean_tx_buffers(struct octeon_mgmt *p)
mix_orcnt.u64 = cvmx_read_csr(CVMX_MIXX_ORCNT(port));
while (mix_orcnt.s.orcnt) {
+ spin_lock_irqsave(&p->tx_list.lock, flags);
+
+ mix_orcnt.u64 = cvmx_read_csr(CVMX_MIXX_ORCNT(port));
+
+ if (mix_orcnt.s.orcnt == 0) {
+ spin_unlock_irqrestore(&p->tx_list.lock, flags);
+ break;
+ }
+
dma_sync_single_for_cpu(p->dev, p->tx_ring_handle,
ring_size_to_bytes(OCTEON_MGMT_TX_RING_SIZE),
DMA_BIDIRECTIONAL);
- spin_lock_irqsave(&p->tx_list.lock, flags);
-
re.d64 = p->tx_ring[p->tx_next_clean];
p->tx_next_clean =
(p->tx_next_clean + 1) % OCTEON_MGMT_TX_RING_SIZE;
--
1.6.6.1
^ permalink raw reply related
* [PATCH 1/6] netdev: octeon_mgmt: Use proper MAC addresses.
From: David Daney @ 2010-05-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, David Daney
In-Reply-To: <1273100593-11043-1-git-send-email-ddaney@caviumnetworks.com>
The original implementation incorrectly uses netdev->dev_addrs.
Use netdev->uc instead. Also use netdev_for_each_uc_addr to iterate
over the addresses. Fix comment.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
---
drivers/net/octeon/octeon_mgmt.c | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/octeon/octeon_mgmt.c b/drivers/net/octeon/octeon_mgmt.c
index 6b1d443..bbbd737 100644
--- a/drivers/net/octeon/octeon_mgmt.c
+++ b/drivers/net/octeon/octeon_mgmt.c
@@ -475,12 +475,11 @@ static void octeon_mgmt_set_rx_filtering(struct net_device *netdev)
unsigned int multicast_mode = 1; /* 1 - Reject all multicast. */
struct octeon_mgmt_cam_state cam_state;
struct netdev_hw_addr *ha;
- struct list_head *pos;
int available_cam_entries;
memset(&cam_state, 0, sizeof(cam_state));
- if ((netdev->flags & IFF_PROMISC) || netdev->dev_addrs.count > 7) {
+ if ((netdev->flags & IFF_PROMISC) || netdev->uc.count > 7) {
cam_mode = 0;
available_cam_entries = 8;
} else {
@@ -488,13 +487,13 @@ static void octeon_mgmt_set_rx_filtering(struct net_device *netdev)
* One CAM entry for the primary address, leaves seven
* for the secondary addresses.
*/
- available_cam_entries = 7 - netdev->dev_addrs.count;
+ available_cam_entries = 7 - netdev->uc.count;
}
if (netdev->flags & IFF_MULTICAST) {
if (cam_mode == 0 || (netdev->flags & IFF_ALLMULTI) ||
netdev_mc_count(netdev) > available_cam_entries)
- multicast_mode = 2; /* 1 - Accept all multicast. */
+ multicast_mode = 2; /* 2 - Accept all multicast. */
else
multicast_mode = 0; /* 0 - Use CAM. */
}
@@ -502,12 +501,8 @@ static void octeon_mgmt_set_rx_filtering(struct net_device *netdev)
if (cam_mode == 1) {
/* Add primary address. */
octeon_mgmt_cam_state_add(&cam_state, netdev->dev_addr);
- list_for_each(pos, &netdev->dev_addrs.list) {
- struct netdev_hw_addr *hw_addr;
- hw_addr = list_entry(pos, struct netdev_hw_addr, list);
- octeon_mgmt_cam_state_add(&cam_state, hw_addr->addr);
- list = list->next;
- }
+ netdev_for_each_uc_addr(ha, netdev)
+ octeon_mgmt_cam_state_add(&cam_state, ha->addr);
}
if (multicast_mode == 0) {
netdev_for_each_mc_addr(ha, netdev)
--
1.6.6.1
^ permalink raw reply related
* [PATCH 0/6] netdev: octeon_mgmt: A few fixes for 2.6.35.
From: David Daney @ 2010-05-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, David Daney
The 1/6 corrects a compile error that seems to have crept
in, as well as correcting the dev_addrs/uc snafu.
2/6 - 5/6 are some other small bug fixes.
6/6 just re-formats the code some.
They are relative to commit 0a12761bcd5646691c5d16dd93df84d1b8849285
in net-next-2.6/master
If OK please apply.
Thanks,
David Daney
David Daney (6):
netdev: octeon_mgmt: Use proper MAC addresses.
netdev: octeon_mgmt: Fix race condition freeing TX buffers.
netdev: octeon_mgmt: Fix race manipulating irq bits.
netdev: octeon_mgmt: Free TX skbufs in a timely manner.
netdev: octeon_mgmt: Try not to drop TX packets when stopping the
queue.
netdev: octeon_mgmt: Remove some gratuitous blank lines.
drivers/net/octeon/octeon_mgmt.c | 57 ++++++++++++++++++-------------------
1 files changed, 28 insertions(+), 29 deletions(-)
^ permalink raw reply
* [PATCH 3/6] netdev: octeon_mgmt: Fix race manipulating irq bits.
From: David Daney @ 2010-05-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, David Daney
In-Reply-To: <1273100593-11043-1-git-send-email-ddaney@caviumnetworks.com>
Don't re-read the interrupt status register, clear the exact bits we
will be testing.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
---
drivers/net/octeon/octeon_mgmt.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/octeon/octeon_mgmt.c b/drivers/net/octeon/octeon_mgmt.c
index b975a2f..633fa89 100644
--- a/drivers/net/octeon/octeon_mgmt.c
+++ b/drivers/net/octeon/octeon_mgmt.c
@@ -598,8 +598,7 @@ static irqreturn_t octeon_mgmt_interrupt(int cpl, void *dev_id)
mixx_isr.u64 = cvmx_read_csr(CVMX_MIXX_ISR(port));
/* Clear any pending interrupts */
- cvmx_write_csr(CVMX_MIXX_ISR(port),
- cvmx_read_csr(CVMX_MIXX_ISR(port)));
+ cvmx_write_csr(CVMX_MIXX_ISR(port), mixx_isr.u64);
cvmx_read_csr(CVMX_MIXX_ISR(port));
if (mixx_isr.s.irthresh) {
--
1.6.6.1
^ permalink raw reply related
* [PATCH 5/6] netdev: octeon_mgmt: Try not to drop TX packets when stopping the queue.
From: David Daney @ 2010-05-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, David Daney
In-Reply-To: <1273100593-11043-1-git-send-email-ddaney@caviumnetworks.com>
Stop the queue when we add the packet that will fill it instead of dropping the packet
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
---
drivers/net/octeon/octeon_mgmt.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/octeon/octeon_mgmt.c b/drivers/net/octeon/octeon_mgmt.c
index 3cf6f62..1fdc7b3 100644
--- a/drivers/net/octeon/octeon_mgmt.c
+++ b/drivers/net/octeon/octeon_mgmt.c
@@ -955,6 +955,7 @@ static int octeon_mgmt_xmit(struct sk_buff *skb, struct net_device *netdev)
int port = p->port;
union mgmt_port_ring_entry re;
unsigned long flags;
+ int rv = NETDEV_TX_BUSY;
re.d64 = 0;
re.s.len = skb->len;
@@ -964,15 +965,18 @@ static int octeon_mgmt_xmit(struct sk_buff *skb, struct net_device *netdev)
spin_lock_irqsave(&p->tx_list.lock, flags);
+ if (unlikely(p->tx_current_fill >= ring_max_fill(OCTEON_MGMT_TX_RING_SIZE) - 1)) {
+ spin_unlock_irqrestore(&p->tx_list.lock, flags);
+ netif_stop_queue(netdev);
+ spin_lock_irqsave(&p->tx_list.lock, flags);
+ }
+
if (unlikely(p->tx_current_fill >=
ring_max_fill(OCTEON_MGMT_TX_RING_SIZE))) {
spin_unlock_irqrestore(&p->tx_list.lock, flags);
-
dma_unmap_single(p->dev, re.s.addr, re.s.len,
DMA_TO_DEVICE);
-
- netif_stop_queue(netdev);
- return NETDEV_TX_BUSY;
+ goto out;
}
__skb_queue_tail(&p->tx_list, skb);
@@ -995,8 +999,10 @@ static int octeon_mgmt_xmit(struct sk_buff *skb, struct net_device *netdev)
cvmx_write_csr(CVMX_MIXX_ORING2(port), 1);
netdev->trans_start = jiffies;
+ rv = NETDEV_TX_OK;
+out:
octeon_mgmt_update_tx_stats(netdev);
- return NETDEV_TX_OK;
+ return rv;
}
#ifdef CONFIG_NET_POLL_CONTROLLER
--
1.6.6.1
^ permalink raw reply related
* [PATCH 6/6] netdev: octeon_mgmt: Remove some gratuitous blank lines.
From: David Daney @ 2010-05-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, David Daney
In-Reply-To: <1273100593-11043-1-git-send-email-ddaney@caviumnetworks.com>
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
---
drivers/net/octeon/octeon_mgmt.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/net/octeon/octeon_mgmt.c b/drivers/net/octeon/octeon_mgmt.c
index 1fdc7b3..3924703 100644
--- a/drivers/net/octeon/octeon_mgmt.c
+++ b/drivers/net/octeon/octeon_mgmt.c
@@ -380,7 +380,6 @@ done:
mix_ircnt.s.ircnt = 1;
cvmx_write_csr(CVMX_MIXX_IRCNT(port), mix_ircnt.u64);
return rc;
-
}
static int octeon_mgmt_receive_packets(struct octeon_mgmt *p, int budget)
@@ -390,7 +389,6 @@ static int octeon_mgmt_receive_packets(struct octeon_mgmt *p, int budget)
union cvmx_mixx_ircnt mix_ircnt;
int rc;
-
mix_ircnt.u64 = cvmx_read_csr(CVMX_MIXX_IRCNT(port));
while (work_done < budget && mix_ircnt.s.ircnt) {
@@ -516,7 +514,6 @@ static void octeon_mgmt_set_rx_filtering(struct net_device *netdev)
octeon_mgmt_cam_state_add(&cam_state, ha->addr);
}
-
spin_lock_irqsave(&p->lock, flags);
/* Disable packet I/O. */
@@ -525,7 +522,6 @@ static void octeon_mgmt_set_rx_filtering(struct net_device *netdev)
agl_gmx_prtx.s.en = 0;
cvmx_write_csr(CVMX_AGL_GMX_PRTX_CFG(port), agl_gmx_prtx.u64);
-
adr_ctl.u64 = 0;
adr_ctl.s.cam_mode = cam_mode;
adr_ctl.s.mcst = multicast_mode;
@@ -928,7 +924,6 @@ static int octeon_mgmt_stop(struct net_device *netdev)
octeon_mgmt_reset_hw(p);
-
free_irq(p->irq, netdev);
/* dma_unmap is a nop on Octeon, so just free everything. */
@@ -945,7 +940,6 @@ static int octeon_mgmt_stop(struct net_device *netdev)
DMA_BIDIRECTIONAL);
kfree(p->tx_ring);
-
return 0;
}
@@ -1112,7 +1106,6 @@ static int __init octeon_mgmt_probe(struct platform_device *pdev)
netdev->netdev_ops = &octeon_mgmt_ops;
netdev->ethtool_ops = &octeon_mgmt_ethtool_ops;
-
/* The mgmt ports get the first N MACs. */
for (i = 0; i < 6; i++)
netdev->dev_addr[i] = octeon_bootinfo->mac_addr_base[i];
--
1.6.6.1
^ permalink raw reply related
* [PATCH 4/6] netdev: octeon_mgmt: Free TX skbufs in a timely manner.
From: David Daney @ 2010-05-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, David Daney
In-Reply-To: <1273100593-11043-1-git-send-email-ddaney@caviumnetworks.com>
We also reduce the high water mark to 1 so skbufs are not stranded for
long periods of time. Since we are cleaning after each packet, no
need to do it in the transmit path.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
---
drivers/net/octeon/octeon_mgmt.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/octeon/octeon_mgmt.c b/drivers/net/octeon/octeon_mgmt.c
index 633fa89..3cf6f62 100644
--- a/drivers/net/octeon/octeon_mgmt.c
+++ b/drivers/net/octeon/octeon_mgmt.c
@@ -832,9 +832,9 @@ static int octeon_mgmt_open(struct net_device *netdev)
mix_irhwm.s.irhwm = 0;
cvmx_write_csr(CVMX_MIXX_IRHWM(port), mix_irhwm.u64);
- /* Interrupt when we have 5 or more packets to clean. */
+ /* Interrupt when we have 1 or more packets to clean. */
mix_orhwm.u64 = 0;
- mix_orhwm.s.orhwm = 5;
+ mix_orhwm.s.orhwm = 1;
cvmx_write_csr(CVMX_MIXX_ORHWM(port), mix_orhwm.u64);
/* Enable receive and transmit interrupts */
@@ -995,7 +995,6 @@ static int octeon_mgmt_xmit(struct sk_buff *skb, struct net_device *netdev)
cvmx_write_csr(CVMX_MIXX_ORING2(port), 1);
netdev->trans_start = jiffies;
- octeon_mgmt_clean_tx_buffers(p);
octeon_mgmt_update_tx_stats(netdev);
return NETDEV_TX_OK;
}
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH]PM QOS refresh against next-20100430
From: Rafael J. Wysocki @ 2010-05-05 23:59 UTC (permalink / raw)
To: mgross
Cc: Kevin Hilman, aili, dwalker, tiwai, bruce.w.allan, davidb, mcgrof,
pavel, linux-pm, lkml, NetDev, Johannes Berg,
ACPI Devel Maling List, Len Brown, John W. Linville
In-Reply-To: <20100504143043.GA27927@linux.intel.com>
On Tuesday 04 May 2010, mark gross wrote:
> On Sat, May 01, 2010 at 01:08:28AM +0200, Rafael J. Wysocki wrote:
> > On Saturday 01 May 2010, mark gross wrote:
> > > On Sat, May 01, 2010 at 12:13:16AM +0200, Rafael J. Wysocki wrote:
> > > > On Friday 30 April 2010, mark gross wrote:
> > > > > The following is a refresh of the PM_QOS implementation, this patch
> > > > > updates some documentation input I got from Randy.
> > > > >
> > > > > This patch changes the string based list management to a handle base
> > > > > implementation to help with the hot path use of pm-qos, it also renames
> > > > > much of the API to use "request" as opposed to "requirement" that was
> > > > > used in the initial implementation. I did this because request more
> > > > > accurately represents what it actually does.
> > > > >
> > > > > Also, I added a string based ABI for users wanting to use a string
> > > > > interface. So if the user writes 0xDDDDDDDD formatted hex it will be
> > > > > accepted by the interface. (someone asked me for it and I don't think
> > > > > it hurts anything.)
> > > > >
> > > > > I really would like to get this refresh taken care of. Its been taking
> > > > > me too long to close this. please review or include it in next.
> > > > >
> > > > > Thanks!
> > > >
> > > > Well, I'd take it to suspend-2.6/linux-next, but first, it touches
> > > > subsystems whose maintainers were not in the Cc list, like the network
> > > > drivers, wireless and ACPI. The changes are trivial, so I hope they don't
> > > > mind.
> > > >
> > > > Second, my tree is based on the Linus' tree rather than linux-next and
> > > > the change in net/mac80211/scan.c doesn't seem to match that. Please tell me
> > > > what I'm supposed to do about that.
> > >
> > > You can waite for monday and I'll send a rebased version to linus' tree.
> > >
> > > I thought linux-next was where folks wanted me to put it.
> > >
> > > I'll email out a new one monday.
> >
> > Great, thanks!
> >
> > Rafael
>
> Sorry I'm late,
>
>
> Signed-off-by: markgross <mgross@linux.intel.com>
Applied to suspend-2.6/linux-next. Please verify the changelog.
Rafael
^ permalink raw reply
* [net-next-2.6 PATCH 1/4] e1000e: save skb counts in TX to avoid cache misses
From: Jeff Kirsher @ 2010-05-06 0:02 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Tom Herbert, Bruce Allan, Jeff Kirsher
From: Tom Herbert <therbert@google.com>
In e1000_tx_map, precompute number of segements and bytecounts which
are derived from fields in skb; these are stored in buffer_info. When
cleaning tx in e1000_clean_tx_irq use the values in the associated
buffer_info for statistics counting, this eliminates cache misses
on skb fields.
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/e1000.h | 2 ++
drivers/net/e1000e/netdev.c | 18 +++++++++---------
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index 906c4da..c0b3db4 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -189,6 +189,8 @@ struct e1000_buffer {
unsigned long time_stamp;
u16 length;
u16 next_to_watch;
+ unsigned int segs;
+ unsigned int bytecount;
u16 mapped_as_page;
};
/* Rx */
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 0a16465..1eb9b59 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1001,14 +1001,8 @@ static bool e1000_clean_tx_irq(struct e1000_adapter *adapter)
cleaned = (i == eop);
if (cleaned) {
- struct sk_buff *skb = buffer_info->skb;
- unsigned int segs, bytecount;
- segs = skb_shinfo(skb)->gso_segs ?: 1;
- /* multiply data chunks by size of headers */
- bytecount = ((segs - 1) * skb_headlen(skb)) +
- skb->len;
- total_tx_packets += segs;
- total_tx_bytes += bytecount;
+ total_tx_packets += buffer_info->segs;
+ total_tx_bytes += buffer_info->bytecount;
}
e1000_put_txbuf(adapter, buffer_info);
@@ -4277,7 +4271,7 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
struct e1000_buffer *buffer_info;
unsigned int len = skb_headlen(skb);
unsigned int offset = 0, size, count = 0, i;
- unsigned int f;
+ unsigned int f, bytecount, segs;
i = tx_ring->next_to_use;
@@ -4337,7 +4331,13 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
}
}
+ segs = skb_shinfo(skb)->gso_segs ?: 1;
+ /* multiply data chunks by size of headers */
+ bytecount = ((segs - 1) * skb_headlen(skb)) + skb->len;
+
tx_ring->buffer_info[i].skb = skb;
+ tx_ring->buffer_info[i].segs = segs;
+ tx_ring->buffer_info[i].bytecount = bytecount;
tx_ring->buffer_info[first].next_to_watch = i;
return count;
^ permalink raw reply related
* [net-next-2.6 PATCH 2/4] e1000e: reduce writes of RX producer ptr
From: Jeff Kirsher @ 2010-05-06 0:02 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Tom Herbert, Bruce Allan, Jeff Kirsher
In-Reply-To: <20100506000221.8042.64794.stgit@localhost.localdomain>
From: Tom Herbert <therbert@google.com>
Reduce number of writes to RX producer pointer. When alloc'ing RX
buffers, only write the RX producer pointer once every
E1000_RX_BUFFER_WRITE (16) buffers created.
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 57 +++++++++++++++++--------------------------
1 files changed, 23 insertions(+), 34 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 1eb9b59..b767dbb 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -548,26 +548,23 @@ map_skb:
rx_desc = E1000_RX_DESC(*rx_ring, i);
rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma);
+ if (unlikely(!(i & (E1000_RX_BUFFER_WRITE - 1)))) {
+ /*
+ * Force memory writes to complete before letting h/w
+ * know there are new descriptors to fetch. (Only
+ * applicable for weak-ordered memory model archs,
+ * such as IA-64).
+ */
+ wmb();
+ writel(i, adapter->hw.hw_addr + rx_ring->tail);
+ }
i++;
if (i == rx_ring->count)
i = 0;
buffer_info = &rx_ring->buffer_info[i];
}
- if (rx_ring->next_to_use != i) {
- rx_ring->next_to_use = i;
- if (i-- == 0)
- i = (rx_ring->count - 1);
-
- /*
- * Force memory writes to complete before letting h/w
- * know there are new descriptors to fetch. (Only
- * applicable for weak-ordered memory model archs,
- * such as IA-64).
- */
- wmb();
- writel(i, adapter->hw.hw_addr + rx_ring->tail);
- }
+ rx_ring->next_to_use = i;
}
/**
@@ -649,6 +646,17 @@ static void e1000_alloc_rx_buffers_ps(struct e1000_adapter *adapter,
rx_desc->read.buffer_addr[0] = cpu_to_le64(buffer_info->dma);
+ if (unlikely(!(i & (E1000_RX_BUFFER_WRITE - 1)))) {
+ /*
+ * Force memory writes to complete before letting h/w
+ * know there are new descriptors to fetch. (Only
+ * applicable for weak-ordered memory model archs,
+ * such as IA-64).
+ */
+ wmb();
+ writel(i<<1, adapter->hw.hw_addr + rx_ring->tail);
+ }
+
i++;
if (i == rx_ring->count)
i = 0;
@@ -656,26 +664,7 @@ static void e1000_alloc_rx_buffers_ps(struct e1000_adapter *adapter,
}
no_buffers:
- if (rx_ring->next_to_use != i) {
- rx_ring->next_to_use = i;
-
- if (!(i--))
- i = (rx_ring->count - 1);
-
- /*
- * Force memory writes to complete before letting h/w
- * know there are new descriptors to fetch. (Only
- * applicable for weak-ordered memory model archs,
- * such as IA-64).
- */
- wmb();
- /*
- * Hardware increments by 16 bytes, but packet split
- * descriptors are 32 bytes...so we increment tail
- * twice as much.
- */
- writel(i<<1, adapter->hw.hw_addr + rx_ring->tail);
- }
+ rx_ring->next_to_use = i;
}
/**
^ permalink raw reply related
* [net-next-2.6 PATCH 3/4] e1000e: Remove unnessary log message
From: Jeff Kirsher @ 2010-05-06 0:03 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Tom Herbert, Bruce Allan, Jeff Kirsher
In-Reply-To: <20100506000221.8042.64794.stgit@localhost.localdomain>
From: Tom Herbert <therbert@google.com>
Remove e_info message printed whenever TSO is enabled or disabled.
This is not very useful and just clutters dmesg.
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/ethtool.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
index c81118a..6ff376c 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -412,7 +412,6 @@ static int e1000_set_tso(struct net_device *netdev, u32 data)
netdev->features &= ~NETIF_F_TSO6;
}
- e_info("TSO is %s\n", data ? "Enabled" : "Disabled");
adapter->flags |= FLAG_TSO_FORCE;
return 0;
}
^ permalink raw reply related
* [net-next-2.6 PATCH 4/4] e1000e: Save irq into netdev structure
From: Jeff Kirsher @ 2010-05-06 0:03 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Tom Herbert, Bruce Allan, Jeff Kirsher
In-Reply-To: <20100506000221.8042.64794.stgit@localhost.localdomain>
From: Tom Herbert <therbert@google.com>
Set net->devirq to pdev->irq. This should be consistent with other
drivers.
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index b767dbb..c5f65a2 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -5456,6 +5456,8 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
SET_NETDEV_DEV(netdev, &pdev->dev);
+ netdev->irq = pdev->irq;
+
pci_set_drvdata(pdev, netdev);
adapter = netdev_priv(netdev);
hw = &adapter->hw;
^ permalink raw reply related
* Re: virtio: put last_used and last_avail index into ring itself.
From: Rusty Russell @ 2010-05-06 0:52 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, s.hetze, Daniel Walker, Eric Dumazet
In-Reply-To: <20100504182236.GA14141@redhat.com>
On Wed, 5 May 2010 03:52:36 am Michael S. Tsirkin wrote:
> > virtio: put last_used and last_avail index into ring itself.
> >
> > Generally, the other end of the virtio ring doesn't need to see where
> > you're up to in consuming the ring. However, to completely understand
> > what's going on from the outside, this information must be exposed.
> > For example, if you want to save and restore a virtio_ring, but you're
> > not the consumer because the kernel is using it directly.
> >
> > Fortunately, we have room to expand: the ring is always a whole number
> > of pages and there's hundreds of bytes of padding after the avail ring
> > and the used ring, whatever the number of descriptors (which must be a
> > power of 2).
> >
> > We add a feature bit so the guest can tell the host that it's writing
> > out the current value there, if it wants to use that.
> >
> > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
> I've been looking at this patch some more (more on why
> later), and I wonder: would it be better to add some
> alignment to the last used index address, so that
> if we later add more stuff at the tail, it all
> fits in a single cache line?
In theory, but not in practice. We don't have many rings, so the
difference between 1 and 2 cache lines is not very much.
> We use a new feature bit anyway, so layout change should not be
> a problem.
>
> Since I raised the question of caches: for used ring,
> the ring is not aligned to 64 bit, so on CPUs with 64 bit
> or larger cache lines, used entries will often cross
> cache line boundaries. Am I right and might it
> have been better to align ring entries to cache line boundaries?
>
> What do you think?
I think everyone is settled on 128 byte cache lines for the forseeable
future, so it's not really an issue.
Cheers,
Rusty.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* kernel panic when using netns+bridges+tc(netem)
From: Martín Ferrari @ 2010-05-06 1:01 UTC (permalink / raw)
To: netdev; +Cc: Mathieu Lacage
Hi there,
While working on my project that uses netns, I found another bug. This
one causes a "Kernel panic - not syncing: Fatal exception in
interrupt", and I can reproduce it in 2.6.33 and 2.6.34-rc5, but not
in 2.6.32. It dies during a call to __free_skb.
I tested this on my x86_64 laptop (2 cores) and on qemu. In qemu it
was not triggered until I asked it to emulate 2 cpus instead of one,
so it is probably a SMP-only issue.
Scenario:
I set up a number of network namespaces, each with two veths to netns
1. In the main namespace I take those veths and bridge them in pairs,
to configure a linear topology; also I configure the netem qdisc to
simulate link delay.
Once the network is set up, I run a client/server program to send UDP
packets from one end of the topology to the other. After a few seconds
of sending packets (not really deterministic) it panics.
Note that I didn't experience this problem when using only 2
namespaces (so, no routing)
below the dumps. These all come from the qemu, as I couldn't use
netconsole in the network at work, but I checked and the backtraces
were essentially the same
First, two panics with 2.6.34, each one with a slightly different backtrace
[ 65.272131] ------------[ cut here ]------------
[ 65.272135] kernel BUG at mm/slub.c:2846!
[ 65.272135] invalid opcode: 0000 [#1] SMP
[ 65.272135] last sysfs file: /sys/devices/virtual/net/lo/operstate
[ 65.272135] CPU 1
[ 65.272135] Modules linked in: sch_netem veth bridge stp netconsole
configfs loop parport_pc parport evdev tpm_tis tpm snd_pcm tpm_bios
snd_timer snd soundcore snd_page_alloc pcspkr psmouse serio_raw
i2c_piix4 button i2c_core processor ext3 jbd mbcache ide_cd_mod cdrom
ide_gd_mod ata_generic ata_piix libata 8139too scsi_mod floppy piix
8139cp mii ide_core thermal thermal_sys [last unloaded: configfs]
[ 65.272135]
[ 65.272135] Pid: 1518, comm: udp-perf Not tainted 2.6.34-rc5 #1 /
[ 65.272135] RIP: 0010:[<ffffffff810e0d6b>] [<ffffffff810e0d6b>]
kfree+0x55/0xc6
[ 65.272135] RSP: 0018:ffff880001a23d90 EFLAGS: 00010246
[ 65.272135] RAX: 0100000000000000 RBX: ffff88007d6bc600 RCX: 0000000000012850
[ 65.272135] RDX: ffff88007d6bc600 RSI: 000000000000000e RDI: ffffea0001b6f610
[ 65.272135] RBP: ffff88007d6ae200 R08: ffff88007d6bc600 R09: ffffffffa0280690
[ 65.272135] R10: 0000000000000002 R11: ffff88007d6bc500 R12: ffffffff8123a77f
[ 65.272135] R13: 000000000000002b R14: ffff88007d39b600 R15: ffff88007d6bc600
[ 65.272135] FS: 00007f637c9dd6f0(0000) GS:ffff880001a20000(0000)
knlGS:0000000000000000
[ 65.272135] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 65.272135] CR2: 00000000009deaa0 CR3: 000000007d82d000 CR4: 00000000000006e0
[ 65.272135] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 65.272135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 65.272135] Process udp-perf (pid: 1518, threadinfo
ffff88007d92a000, task ffff88007e7ff810)
[ 65.272135] Stack:
[ 65.272135] ffff88007d6bc600 ffff88007d6bc600 0000000000000246
ffffffff8123a77f
[ 65.272135] <0> ffff880001a32860 ffffffff81241e01 ffffe8ffff623280
ffffe8ffff83ffc0
[ 65.272135] <0> ffff88007d6bc600 ffffffffa028057d 000000027d4c06c8
ffff88007d4c0600
[ 65.272135] Call Trace:
[ 65.272135] <IRQ>
[ 65.272135] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
[ 65.272135] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
[ 65.272135] [<ffffffffa028057d>] ? veth_xmit+0x6e/0xad [veth]
[ 65.272135] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
[ 65.272135] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
[ 65.272135] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
[ 65.272135] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
[ 65.272135] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
[ 65.272135] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
[ 65.272135] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
[ 65.272135] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
[ 65.272135] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
[ 65.272135] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
[ 65.272135] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
[ 65.272135] <EOI>
[ 65.272135] [<ffffffff8114c1ea>] ? cap_sk_getsecid+0x0/0x1
[ 65.272135] [<ffffffff812a0b0f>] ? __xfrm_lookup+0x2/0xb04
[ 65.272135] [<ffffffff81264b8d>] ? ip_route_output_flow+0x77/0x1cc
[ 65.272135] [<ffffffff812887c6>] ? udp_sendmsg+0x32d/0x5f3
[ 65.272135] [<ffffffff81009400>] ? irq_entries_start+0x3c0/0x400
[ 65.272135] [<ffffffff8128e112>] ? inet_sendmsg+0x53/0x58
[ 65.272135] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
[ 65.272135] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
[ 65.272135] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
[ 65.272135] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 65.272135] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 65.272135] [<ffffffff81185d4b>] ? _copy_from_user+0x1b/0x30
[ 65.272135] [<ffffffff8100765f>] ? __switch_to+0x1b5/0x2a6
[ 65.272135] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
[ 65.272135] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
[ 65.272135] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
[ 65.272135] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
[ 65.272135] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 65.272135] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
[ 65.272135] Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 84
00 00 00 48 89 ef e8 f4 e2 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9
00 c0 75 04 <0f> 0b eb fe 5b 5d 41 5c e9 fb 57 fd ff 48 8b 4c 24 18 4c
8b 47
[ 65.272135] RIP [<ffffffff810e0d6b>] kfree+0x55/0xc6
[ 65.272135] RSP <ffff880001a23d90>
[ 65.385803] ---[ end trace 42d2fb5b94980ab5 ]---
[ 65.386337] Kernel panic - not syncing: Fatal exception in interrupt
[ 65.386943] Pid: 1518, comm: udp-perf Tainted: G D 2.6.34-rc5 #1
[ 65.387557] Call Trace:
[ 65.388011] <IRQ> [<ffffffff812eef9b>] ? panic+0x77/0xf7
[ 65.388729] [<ffffffff81046b88>] ? kmsg_dump+0xa6/0x13e
[ 65.389292] [<ffffffff8100c8c2>] ? oops_end+0xa7/0xb4
[ 65.389871] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
[ 65.390441] [<ffffffff8100a695>] ? do_invalid_op+0x8b/0x95
[ 65.391032] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
[ 65.391587] [<ffffffffa026f301>] ?
br_nf_pre_routing_finish+0x0/0x25e [bridge]
[ 65.392512] [<ffffffffa026f301>] ?
br_nf_pre_routing_finish+0x0/0x25e [bridge]
[ 65.393399] [<ffffffff8100975b>] ? invalid_op+0x1b/0x20
[ 65.393978] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
[ 65.394547] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
[ 65.395091] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
[ 65.395668] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
[ 65.396438] [<ffffffffa028057d>] ? veth_xmit+0x6e/0xad [veth]
[ 65.397026] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
[ 65.397640] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
[ 65.398222] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
[ 65.398788] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
[ 65.399365] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
[ 65.399935] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
[ 65.400560] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
[ 65.401125] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
[ 65.401708] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
[ 65.402267] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
[ 65.402869] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
[ 65.403463] <EOI> [<ffffffff8114c1ea>] ? cap_sk_getsecid+0x0/0x1
[ 65.404210] [<ffffffff812a0b0f>] ? __xfrm_lookup+0x2/0xb04
[ 65.404779] [<ffffffff81264b8d>] ? ip_route_output_flow+0x77/0x1cc
[ 65.405375] [<ffffffff812887c6>] ? udp_sendmsg+0x32d/0x5f3
[ 65.405945] [<ffffffff81009400>] ? irq_entries_start+0x3c0/0x400
[ 65.406534] [<ffffffff8128e112>] ? inet_sendmsg+0x53/0x58
[ 65.407102] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
[ 65.407674] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
[ 65.408296] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
[ 65.408854] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 65.409468] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 65.410084] [<ffffffff81185d4b>] ? _copy_from_user+0x1b/0x30
[ 65.410667] [<ffffffff8100765f>] ? __switch_to+0x1b5/0x2a6
[ 65.510031] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
[ 65.510818] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
[ 65.511608] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
[ 65.512465] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
[ 65.513229] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 65.514040] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
[ 1438.042568] ------------[ cut here ]------------
[ 1438.043170] kernel BUG at mm/slub.c:2846!
[ 1438.043711] invalid opcode: 0000 [#1] SMP
[ 1438.044531] last sysfs file: /sys/devices/virtual/net/lo/operstate
[ 1438.045148] CPU 1
[ 1438.045350] Modules linked in: sch_netem veth bridge stp netconsole
configfs loop parport_pc tpm_tis tpm snd_pcm psmouse parport tpm_bios
snd_timer snd soundcore snd_page_alloc evdev pcspkr serio_raw
i2c_piix4 i2c_core button processor ext3 jbd mbcache ide_cd_mod cdrom
ide_gd_mod ata_generic ata_piix 8139too libata scsi_mod floppy 8139cp
mii thermal thermal_sys piix ide_core [last unloaded: scsi_wait_scan]
[ 1438.046215]
[ 1438.046215] Pid: 1476, comm: udp-perf Not tainted 2.6.34-rc5 #1 /
[ 1438.046215] RIP: 0010:[<ffffffff810e0d6b>] [<ffffffff810e0d6b>]
kfree+0x55/0xc6
[ 1438.046215] RSP: 0018:ffff880001a23d90 EFLAGS: 00010246
[ 1438.046215] RAX: 0100000000000000 RBX: ffff88007d882200 RCX: 0000000000012850
[ 1438.046215] RDX: ffff88007d882200 RSI: 000000000000000e RDI: ffffea0001b972a0
[ 1438.046215] RBP: ffff88007e20c000 R08: ffff88007d882200 R09: ffffffffa026c690
[ 1438.046215] R10: 0000000000000002 R11: ffff88007d882100 R12: ffffffff8123a77f
[ 1438.046215] R13: 0000000000000032 R14: ffff8800378e0700 R15: ffff88007d882200
[ 1438.046215] FS: 00007f1c1d07f6f0(0000) GS:ffff880001a20000(0000)
knlGS:0000000000000000
[ 1438.046215] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1438.046215] CR2: 00007f6ea9e07310 CR3: 0000000037834000 CR4: 00000000000006e0
[ 1438.046215] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1438.046215] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1438.046215] Process udp-perf (pid: 1476, threadinfo
ffff88007db0e000, task ffff8800379a2350)
[ 1438.046215] Stack:
[ 1438.046215] ffff88007d882200 ffff88007d882200 0000000000000246
ffffffff8123a77f
[ 1438.046215] <0> ffff880001a32860 ffffffff81241e01 ffffe8ffffa3f430
ffffe8ffffa3d180
[ 1438.046215] <0> ffff88007d882200 ffffffffa026c57d 0000000201a30500
ffff88007d171200
[ 1438.046215] Call Trace:
[ 1438.046215] <IRQ>
[ 1438.046215] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
[ 1438.046215] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
[ 1438.046215] [<ffffffffa026c57d>] ? veth_xmit+0x6e/0xad [veth]
[ 1438.046215] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
[ 1438.046215] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
[ 1438.046215] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
[ 1438.046215] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
[ 1438.046215] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
[ 1438.046215] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
[ 1438.046215] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
[ 1438.046215] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
[ 1438.046215] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
[ 1438.046215] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
[ 1438.046215] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
[ 1438.046215] <EOI>
[ 1438.046215] [<ffffffff81288499>] ? udp_sendmsg+0x0/0x5f3
[ 1438.046215] [<ffffffff8128850f>] ? udp_sendmsg+0x76/0x5f3
[ 1438.046215] [<ffffffff812889a7>] ? udp_sendmsg+0x50e/0x5f3
[ 1438.046215] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
[ 1438.046215] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
[ 1438.046215] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
[ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 1438.046215] [<ffffffff810e93ed>] ? fget_light+0x0/0xa1
[ 1438.046215] [<ffffffff81185e40>] ? copy_user_generic_string+0x30/0x40
[ 1438.046215] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
[ 1438.046215] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
[ 1438.046215] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
[ 1438.046215] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
[ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 1438.046215] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
[ 1438.046215] Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 84
00 00 00 48 89 ef e8 f4 e2 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9
00 c0 75 04 <0f> 0b eb fe 5b 5d 41 5c e9 fb 57 fd ff 48 8b 4c 24 18 4c
8b 47
[ 1438.046215] RIP [<ffffffff810e0d6b>] kfree+0x55/0xc6
[ 1438.046215] RSP <ffff880001a23d90>
[ 1438.102706] ---[ end trace ab36062dcf233d6a ]---
[ 1438.103251] Kernel panic - not syncing: Fatal exception in interrupt
[ 1438.103912] Pid: 1476, comm: udp-perf Tainted: G D 2.6.34-rc5 #1
[ 1438.104563] Call Trace:
[ 1438.105017] <IRQ> [<ffffffff812eef9b>] ? panic+0x77/0xf7
[ 1438.105718] [<ffffffff81046b88>] ? kmsg_dump+0xa6/0x13e
[ 1438.106293] [<ffffffff8100c8c2>] ? oops_end+0xa7/0xb4
[ 1438.106866] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
[ 1438.107451] [<ffffffff8100a695>] ? do_invalid_op+0x8b/0x95
[ 1438.108036] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
[ 1438.108799] [<ffffffffa025b301>] ?
br_nf_pre_routing_finish+0x0/0x25e [bridge]
[ 1438.109699] [<ffffffffa025b301>] ?
br_nf_pre_routing_finish+0x0/0x25e [bridge]
[ 1438.110604] [<ffffffff8100975b>] ? invalid_op+0x1b/0x20
[ 1438.111172] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
[ 1438.111753] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
[ 1438.112359] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
[ 1438.112952] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
[ 1438.113527] [<ffffffffa026c57d>] ? veth_xmit+0x6e/0xad [veth]
[ 1438.114123] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
[ 1438.114734] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
[ 1438.115334] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
[ 1438.115912] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
[ 1438.116544] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
[ 1438.117128] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
[ 1438.117732] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
[ 1438.118420] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
[ 1438.119066] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
[ 1438.147879] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
[ 1438.148615] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
[ 1438.149294] <EOI> [<ffffffff81288499>] ? udp_sendmsg+0x0/0x5f3
[ 1438.150101] [<ffffffff8128850f>] ? udp_sendmsg+0x76/0x5f3
[ 1438.150681] [<ffffffff812889a7>] ? udp_sendmsg+0x50e/0x5f3
[ 1438.151276] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
[ 1438.151853] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
[ 1438.152508] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
[ 1438.153078] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 1438.153687] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 1438.154295] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 1438.154902] [<ffffffff810e93ed>] ? fget_light+0x0/0xa1
[ 1438.155477] [<ffffffff81185e40>] ? copy_user_generic_string+0x30/0x40
[ 1438.156097] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
[ 1438.156720] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
[ 1438.157376] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
[ 1438.157970] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
[ 1438.158557] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
[ 1438.159153] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
------------
Finally, a panic in 2.6.33. Note that the line in wioch BUG is
triggered is different
[ 102.442815] ------------[ cut here ]------------
[ 102.443433] kernel BUG at
/build/mattems-linux-2.6_2.6.33-1~experimental.4-amd64-ieqSsa/linux-2.6-2.6.33-1~experimental.4/debian/build/source_amd64_none/mm/slub.c:2969!
[ 102.444874] invalid opcode: 0000 [#1] SMP
[ 102.444958] last sysfs file: /sys/devices/virtual/net/lo/operstate
[ 102.444958] CPU 0
[ 102.444958] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.33-2-amd64 #1 /
[ 102.444958] RIP: 0010:[<ffffffff810e1e2c>] [<ffffffff810e1e2c>]
kfree+0x55/0xcb
[ 102.444958] RSP: 0018:ffff880001a03df8 EFLAGS: 00010246
[ 102.444958] RAX: 0100000000000000 RBX: ffff88007e439000 RCX: 0000000000012d70
[ 102.444958] RDX: 000000000000006a RSI: ffffea0001b76a70 RDI: ffffea0000c1a328
[ 102.444958] RBP: ffff880037533c00 R08: ffff88007e21e500 R09: ffffffff8162bbe0
[ 102.444958] R10: 000000037e439e00 R11: ffff88007e439e00 R12: ffffffff81239cf2
[ 102.444958] R13: 000000000000006a R14: ffff88007efb3000 R15: ffff88007e21e500
[ 102.444958] FS: 0000000000000000(0000) GS:ffff880001a00000(0000)
knlGS:0000000000000000
[ 102.444958] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 102.444958] CR2: 00007fc8e25cd0f0 CR3: 000000007d088000 CR4: 00000000000006f0
[ 102.444958] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 102.444958] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 102.444958] Process ksoftirqd/0 (pid: 4, threadinfo
ffff88007fb78000, task ffff88007fb61500)
[ 102.444958] Stack:
[ 102.444958] ffff88007e439000 ffff88007e439000 0000000000000246
ffffffff81239cf2
[ 102.444958] <0> ffff880001a12d80 ffffffff8124125d ffffe8ffff818190
ffffe8ffff815ee0
[ 102.444958] <0> ffff88007e439000 ffffffffa025254b ffff880001a10010
ffff88007ef95200
[ 102.444958] Call Trace:
[ 102.444958] <IRQ>
[ 102.444958] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
[ 102.444958] [<ffffffff8124125d>] ? netif_rx+0xe2/0xee
[ 102.444958] [<ffffffffa025254b>] ? veth_xmit+0x6e/0xad [veth]
[ 102.444958] [<ffffffff8124243a>] ? dev_hard_start_xmit+0x221/0x2dc
[ 102.444958] [<ffffffff81255514>] ? sch_direct_xmit+0x5b/0x15d
[ 102.444958] [<ffffffff812556cf>] ? __qdisc_run+0xb9/0xda
[ 102.444958] [<ffffffff8123fa99>] ? net_tx_action+0xd6/0x149
[ 102.444958] [<ffffffff8104c918>] ? __do_softirq+0xdd/0x1a1
[ 102.444958] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
[ 102.444958] <EOI>
[ 102.444958] [<ffffffff8100b85f>] ? do_softirq+0x3f/0x79
[ 102.444958] [<ffffffff8104c504>] ? run_ksoftirqd+0x6a/0x118
[ 102.444958] [<ffffffff8104c49a>] ? run_ksoftirqd+0x0/0x118
[ 102.444958] [<ffffffff8105ee99>] ? kthread+0x79/0x81
[ 102.444958] [<ffffffff810098e4>] ? kernel_thread_helper+0x4/0x10
[ 102.444958] [<ffffffff8105ee20>] ? kthread+0x0/0x81
[ 102.444958] [<ffffffff810098e0>] ? kernel_thread_helper+0x0/0x10
[ 102.444958] Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 89
00 00 00 48 89 ef e8 f0 e6 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9
00 c0 75 04 <0f> 0b eb fe 5b 5d 41 5c e9 45 5a fd ff 48 8b 4c 24 18 4c
8b 4f
[ 102.444958] RIP [<ffffffff810e1e2c>] kfree+0x55/0xcb
[ 102.444958] RSP <ffff880001a03df8>
[ 102.484000] ---[ end trace b1157390d40df1cb ]---
[ 102.485018] Kernel panic - not syncing: Fatal exception in interrupt
[ 102.485647] Pid: 4, comm: ksoftirqd/0 Tainted: G D 2.6.33-2-amd64 #1
[ 102.486630] Call Trace:
[ 102.487112] <IRQ> [<ffffffff812ec605>] ? panic+0x86/0x14b
[ 102.487870] [<ffffffff8104c799>] ? irq_exit+0x48/0x76
[ 102.488474] [<ffffffff812ee893>] ? ret_from_intr+0x0/0x11
[ 102.489068] [<ffffffff810478c0>] ? kmsg_dump+0xa6/0x13e
[ 102.489661] [<ffffffff8100c89a>] ? oops_end+0xa7/0xb4
[ 102.490245] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
[ 102.490836] [<ffffffff8100a690>] ? do_invalid_op+0x8b/0x95
[ 102.491436] [<ffffffff810e1e2c>] ? kfree+0x55/0xcb
[ 102.492020] [<ffffffffa0244aee>] ?
br_nf_pre_routing_finish+0x284/0x2a6 [bridge]
[ 102.492942] [<ffffffffa024486a>] ?
br_nf_pre_routing_finish+0x0/0x2a6 [bridge]
[ 102.493857] [<ffffffff8125f204>] ? nf_hook_slow+0x62/0xc3
[ 102.523082] [<ffffffffa024486a>] ?
br_nf_pre_routing_finish+0x0/0x2a6 [bridge]
[ 102.524008] [<ffffffff8100975b>] ? invalid_op+0x1b/0x20
[ 102.524631] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
[ 102.525225] [<ffffffff810e1e2c>] ? kfree+0x55/0xcb
[ 102.525795] [<ffffffff810e1e1c>] ? kfree+0x45/0xcb
[ 102.526402] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
[ 102.526992] [<ffffffff8124125d>] ? netif_rx+0xe2/0xee
[ 102.527576] [<ffffffffa025254b>] ? veth_xmit+0x6e/0xad [veth]
[ 102.528199] [<ffffffff8124243a>] ? dev_hard_start_xmit+0x221/0x2dc
[ 102.528821] [<ffffffff81255514>] ? sch_direct_xmit+0x5b/0x15d
[ 102.529429] [<ffffffff812556cf>] ? __qdisc_run+0xb9/0xda
[ 102.530018] [<ffffffff8123fa99>] ? net_tx_action+0xd6/0x149
[ 102.530618] [<ffffffff8104c918>] ? __do_softirq+0xdd/0x1a1
[ 102.531214] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
[ 102.531804] <EOI> [<ffffffff8100b85f>] ? do_softirq+0x3f/0x79
[ 102.532572] [<ffffffff8104c504>] ? run_ksoftirqd+0x6a/0x118
[ 102.533169] [<ffffffff8104c49a>] ? run_ksoftirqd+0x0/0x118
[ 102.533764] [<ffffffff8105ee99>] ? kthread+0x79/0x81
[ 102.534340] [<ffffffff810098e4>] ? kernel_thread_helper+0x4/0x10
[ 102.534954] [<ffffffff8105ee20>] ? kthread+0x0/0x81
[ 102.535526] [<ffffffff810098e0>] ? kernel_thread_helper+0x0/0x10
--
Martín Ferrari
^ permalink raw reply
* [PATCH iproute2] document initcwnd
From: Brian Bloniarz @ 2010-05-06 1:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dormando, netdev, Rick Jones, shemminger
In-Reply-To: <20100505150343.0c09c6ba@nehalam>
Stephen Hemminger wrote:
> On Wed, 05 May 2010 16:56:34 -0400
> Brian Bloniarz <bmb@athenacr.com> wrote:
>
>> dormando wrote:
>>>> This sounds like TCP slow start.
>>>>
>>>> http://en.wikipedia.org/wiki/Slow-start
>>>>
>>>> As far as tunables you might want to play with the initcwnd route
>>>> flag (see "ip route help")
>>> Ah, yes, initcwnd was it. I'm well aware of TCP Congestion control / slow
>>> start / etc. However I couldn't find the damn tunable for it :)
>> Documenting the flag in ip(8) might increase its visibility
>> a little. I don't see it documented in the iproute2 git head,
>> though it shows up on http://linux.die.net/man/8/ip somehow.
>>
>> Stephen, do you know why that is?
>
> No one sent me an official patch to change it?
Mention initcwnd in ip(8). Text taken from doc/ip-cref.tex.
Signed-off-by: Brian Bloniarz <bmb@athenacr.com>
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index a5d2915..777a0a7 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -211,7 +211,9 @@ replace " | " monitor " } "
.B realms
.IR REALM " ] [ "
.B rto_min
-.IR TIME " ]"
+.IR TIME " ] [ "
+.B initcwnd
+.IR NUMBER " ]"
.ti -8
.IR TYPE " := [ "
@@ -1561,6 +1563,13 @@ the clamp for congestion window. It is ignored if the
flag is not used.
.TP
+.BI initcwnd " NUMBER " "(2.5.70+ only)"
+Initial congestion window size for connections to this destination.
+Actual window size is this value multiplied by the MSS
+(``Maximal Segment Size'') for same connection. The default is
+zero, meaning to use the values specified in RFC2414.
+
+.TP
.BI advmss " NUMBER " "(2.3.15+ only)"
the MSS ('Maximal Segment Size') to advertise to these
destinations when establishing TCP connections. If it is not given,
^ permalink raw reply related
* Re: linux kernel's IPV6_MULTICAST_HOPS default is 64; should be 1?
From: Brian Haley @ 2010-05-06 1:50 UTC (permalink / raw)
To: David Miller; +Cc: dlstevens, enh, netdev, netdev-owner
In-Reply-To: <20100505.150008.102542618.davem@davemloft.net>
David Miller wrote:
> From: Brian Haley <brian.haley@hp.com>
> Date: Wed, 05 May 2010 11:36:31 -0400
>
>> I now see that in Elliot's email, but I think it's incorrect. The RFC
>> says that setting it to -1 should get you the kernel default, which is
>> now 1. Without this change, setting it to -1 will get you 64, the
>> old behavior. If the user wants to, they can always just set it to
>> 64 themselves, that's better than assuming when you set it to -1
>> you're going to get 64.
>
> It's not 64, it's whatever the per-route metric is.
Not unless that metric's been set via RTAX_HOPLIMIT (and I believe
this is the unicast hop limit value anyways), and that metric
defaults to -1. Routes added via a Router Advertisement are most
likely going to have a hop limit of 64, but I believe that's only
supposed to apply to unicast.
I *did* search the kernel code and test this before my original reply - it
uses the unicast hop limit from the interface as Elliot originally showed.
~# sysctl net.ipv6.conf.eth2.hop_limit
net.ipv6.conf.eth2.hop_limit = 64
21:04:48.766181 IP6 (hlim 64, next-header UDP (17) payload length: 108)
fe80::21f:29ff:fef0:2f46.48914 > ip6-allrouters.7639: UDP, length 100
~# sysctl net.ipv6.conf.eth2.hop_limit=63
net.ipv6.conf.eth2.hop_limit = 63
21:05:09.670190 IP6 (hlim 63, next-header UDP (17) payload length: 108)
fe80::21f:29ff:fef0:2f46.48914 > ip6-allrouters.7639: UDP, length 100
At this point in time I'll gladly implement a per-interface sysctl
to end this discussion.
-Brian
^ permalink raw reply
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Scott Feldman @ 2010-05-06 2:03 UTC (permalink / raw)
To: Shreyas Bhatewara, Arnd Bergmann, Dmitry Torokhov
Cc: Christoph Hellwig, pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, Pankaj Thakkar
In-Reply-To: <89E2752CFA8EC044846EB8499819134102AF2896F5@EXCH-MBX-4.vmware.com>
On 5/5/10 10:29 AM, "Dmitry Torokhov" <dtor@vmware.com> wrote:
> It would not be a binary blob but software properly released under GPL.
> The current plan is for the shell to enforce GPL requirement on the
> plugin code, similar to what module loaded does for regular kernel
> modules.
On 5/5/10 3:05 PM, "Shreyas Bhatewara" <sbhatewara@vmware.com> wrote:
> The plugin image is not linked against Linux kernel. It is OS agnostic infact
> (Eg. same plugin works for Linux and Windows VMs)
Are there any issues with injecting the GPL-licensed plug-in into the
Windows vmxnet3 NDIS driver?
-scott
^ permalink raw reply
* Re: [v5 Patch 1/3] netpoll: add generic support for bridge and bonding devices
From: Matt Mackall @ 2010-05-06 2:05 UTC (permalink / raw)
To: Amerigo Wang
Cc: linux-kernel, netdev, bridge, Andy Gospodarek, Neil Horman,
Jeff Moyer, Stephen Hemminger, bonding-devel, Jay Vosburgh,
David Miller
In-Reply-To: <20100505081514.5157.83783.sendpatchset@localhost.localdomain>
On Wed, 2010-05-05 at 04:11 -0400, Amerigo Wang wrote:
> V5:
> Fix coding style problems pointed by David.
Aside from my concern about the policy of disabling netpoll on
bridges/bonds with only partial netpoll support, I don't have any
remaining issues with this. But I'll leave it to other folks to ack the
underlying driver bits for this series.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [PATCH iproute2] document initcwnd
From: Stephen Hemminger @ 2010-05-06 2:33 UTC (permalink / raw)
To: Brian Bloniarz; +Cc: dormando, netdev, Rick Jones, shemminger
In-Reply-To: <4BE21D64.4040600@athenacr.com>
On Wed, 05 May 2010 21:37:40 -0400
Brian Bloniarz <bmb@athenacr.com> wrote:
> Stephen Hemminger wrote:
> > On Wed, 05 May 2010 16:56:34 -0400
> > Brian Bloniarz <bmb@athenacr.com> wrote:
> >
> >> dormando wrote:
> >>>> This sounds like TCP slow start.
> >>>>
> >>>> http://en.wikipedia.org/wiki/Slow-start
> >>>>
> >>>> As far as tunables you might want to play with the initcwnd route
> >>>> flag (see "ip route help")
> >>> Ah, yes, initcwnd was it. I'm well aware of TCP Congestion control / slow
> >>> start / etc. However I couldn't find the damn tunable for it :)
> >> Documenting the flag in ip(8) might increase its visibility
> >> a little. I don't see it documented in the iproute2 git head,
> >> though it shows up on http://linux.die.net/man/8/ip somehow.
> >>
> >> Stephen, do you know why that is?
> >
> > No one sent me an official patch to change it?
>
> Mention initcwnd in ip(8). Text taken from doc/ip-cref.tex.
>
> Signed-off-by: Brian Bloniarz <bmb@athenacr.com>
Ok, I will add it with an explicit caution about not doing this on public
networks.
^ permalink raw reply
* [PATCH] bnx2x: Fix check to get RX hash
From: Tom Herbert @ 2010-05-06 3:57 UTC (permalink / raw)
To: davem, netdev
Flag used in check to get rxhash out of the descriptor is incorrect one.
Fix to use the proper features flag.
Signed-off-by: Tom Herbert <therbert@google.com>
---
diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
index f706ed1..2bc35c7 100644
--- a/drivers/net/bnx2x_main.c
+++ b/drivers/net/bnx2x_main.c
@@ -1726,7 +1726,7 @@ reuse_rx:
skb->protocol = eth_type_trans(skb, bp->dev);
- if ((bp->dev->features & ETH_FLAG_RXHASH) &&
+ if ((bp->dev->features & NETIF_F_RXHASH) &&
(cqe_fp_status_flags &
ETH_FAST_PATH_RX_CQE_RSS_HASH_FLG))
skb->rxhash = le32_to_cpu(
^ permalink raw reply related
* linux-next: manual merge of the staging-next tree with the net tree
From: Stephen Rothwell @ 2010-05-06 4:05 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Prashant P. Shah, Jiri Pirko,
David Miller, netdev
Hi Greg,
Today's linux-next merge of the staging-next tree got a conflict in
drivers/staging/arlan/arlan-main.c between commit
22bedad3ce112d5ca1eaf043d4990fa2ed698c87 ("net: convert multicast list to
list_head") from the net tree and commit
dd730b627cf8ff0b9d20df94fd31b6192b188710 ("Staging: arlan: fixed
unnecessary whitespace style issue in arlan-main.c") from the
staging-next tree.
I fixed it up (see below - this is bigger than is would otherwise be
because there is a conflict with another patch that was previously
reported) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/staging/arlan/arlan-main.c
index 8028452,301b979..0000000
--- a/drivers/staging/arlan/arlan-main.c
+++ b/drivers/staging/arlan/arlan-main.c
@@@ -1438,105 -1336,99 +1336,99 @@@ static void arlan_rx_interrupt(struct n
priv->in_time10 = jiffies;
}
DEBUGSHM(1, "arlan rcv pkt rxStatus= %d ", arlan->rxStatus, u_char);
- switch (rxStatus)
+ switch (rxStatus) {
+ case 1:
+ case 2:
+ case 3:
{
- case 1:
- case 2:
- case 3:
- {
- /* Malloc up new buffer. */
- struct sk_buff *skb;
+ /* Malloc up new buffer. */
+ struct sk_buff *skb;
- DEBUGSHM(50, "arlan recv pkt offs=%d\n", arlan->rxOffset, u_short);
- DEBUGSHM(1, "arlan rxFrmType = %d \n", arlan->rxFrmType, u_char);
- DEBUGSHM(1, KERN_INFO "arlan rx scrambled = %d \n", arlan->scrambled, u_char);
+ DEBUGSHM(50, "arlan recv pkt offs=%d\n", arlan->rxOffset, u_short);
+ DEBUGSHM(1, "arlan rxFrmType = %d\n", arlan->rxFrmType, u_char);
+ DEBUGSHM(1, KERN_INFO "arlan rx scrambled = %d\n", arlan->scrambled, u_char);
- /* here we do multicast filtering to avoid slow 8-bit memcopy */
+ /* here we do multicast filtering to avoid slow 8-bit memcopy */
#ifdef ARLAN_MULTICAST
- if (!(dev->flags & IFF_ALLMULTI) &&
- !(dev->flags & IFF_PROMISC) &&
- !netdev_mc_empty(dev))
- {
- char hw_dst_addr[6];
- struct netdev_hw_addr *ha;
- int i;
-
- memcpy_fromio(hw_dst_addr, arlan->ultimateDestAddress, 6);
- if (hw_dst_addr[0] == 0x01)
- {
- if (mdebug)
- if (hw_dst_addr[1] == 0x00)
- printk(KERN_ERR "%s mcast 0x0100 \n", dev->name);
- else if (hw_dst_addr[1] == 0x40)
- printk(KERN_ERR "%s m/bcast 0x0140 \n", dev->name);
- netdev_for_each_mc_entry(ha, dev) {
- if (arlan_debug & ARLAN_DEBUG_HEADER_DUMP)
- printk(KERN_ERR "%s mcl %pM\n",
- dev->name,
- ha->addr);
- for (i = 0; i < 6; i++)
- if (ha->addr[i] != hw_dst_addr[i])
- break;
- if (i == 6)
+ if (!(dev->flags & IFF_ALLMULTI) &&
+ !(dev->flags & IFF_PROMISC) &&
+ !netdev_mc_empty(dev)) {
+ char hw_dst_addr[6];
- struct dev_mc_list *dmi;
++ struct netdev_hw_addr *ha;
+ int i;
+
+ memcpy_fromio(hw_dst_addr, arlan->ultimateDestAddress, 6);
+ if (hw_dst_addr[0] == 0x01) {
+ if (mdebug)
+ if (hw_dst_addr[1] == 0x00)
+ printk(KERN_ERR "%s mcast 0x0100\n", dev->name);
+ else if (hw_dst_addr[1] == 0x40)
+ printk(KERN_ERR "%s m/bcast 0x0140\n", dev->name);
- netdev_for_each_mc_entry(dmi, dev) {
++ netdev_for_each_mc_entry(ha, dev) {
+ if (arlan_debug & ARLAN_DEBUG_HEADER_DUMP)
+ printk(KERN_ERR "%s mcl %pM\n",
- dev->name, dmi->dmi_addr);
++ dev->name, ha->addr);
+ for (i = 0; i < 6; i++)
- if (dmi->dmi_addr[i] != hw_dst_addr[i])
++ if (ha->addr[i] != hw_dst_addr[i])
break;
- }
- /* we reach here if multicast filtering is on and packet
- * is multicast and not for receive */
- goto end_of_interrupt;
+ if (i == 6)
+ break;
}
+ /* we reach here if multicast filtering is on and packet */
+ /* is multicast and not for receive */
+ goto end_of_interrupt;
}
- #endif // ARLAN_MULTICAST
- /* multicast filtering ends here */
- pkt_len += ARLAN_FAKE_HDR_LEN;
-
- skb = dev_alloc_skb(pkt_len + 4);
- if (skb == NULL)
- {
- printk(KERN_ERR "%s: Memory squeeze, dropping packet.\n", dev->name);
- dev->stats.rx_dropped++;
- break;
- }
- skb_reserve(skb, 2);
- skbtmp = skb_put(skb, pkt_len);
+ }
+ #endif /* ARLAN_MULTICAST */
+ /* multicast filtering ends here */
+ pkt_len += ARLAN_FAKE_HDR_LEN;
+
+ skb = dev_alloc_skb(pkt_len + 4);
+ if (skb == NULL) {
+ printk(KERN_ERR "%s: Memory squeeze, dropping packet.\n", dev->name);
+ dev->stats.rx_dropped++;
+ break;
+ }
+ skb_reserve(skb, 2);
+ skbtmp = skb_put(skb, pkt_len);
- memcpy_fromio(skbtmp + ARLAN_FAKE_HDR_LEN, ((char __iomem *) arlan) + rxOffset, pkt_len - ARLAN_FAKE_HDR_LEN);
- memcpy_fromio(skbtmp, arlan->ultimateDestAddress, 6);
- memcpy_fromio(skbtmp + 6, arlan->rxSrc, 6);
- WRITESHMB(arlan->rxStatus, 0x00);
- arlan_command(dev, ARLAN_COMMAND_RX);
+ memcpy_fromio(skbtmp + ARLAN_FAKE_HDR_LEN, ((char __iomem *) arlan) + rxOffset, pkt_len - ARLAN_FAKE_HDR_LEN);
+ memcpy_fromio(skbtmp, arlan->ultimateDestAddress, 6);
+ memcpy_fromio(skbtmp + 6, arlan->rxSrc, 6);
+ WRITESHMB(arlan->rxStatus, 0x00);
+ arlan_command(dev, ARLAN_COMMAND_RX);
- IFDEBUG(ARLAN_DEBUG_HEADER_DUMP)
- {
- char immedDestAddress[6];
- char immedSrcAddress[6];
- memcpy_fromio(immedDestAddress, arlan->immedDestAddress, 6);
- memcpy_fromio(immedSrcAddress, arlan->immedSrcAddress, 6);
-
- printk(KERN_WARNING "%s t %pM f %pM imd %pM ims %pM\n",
- dev->name, skbtmp,
- &skbtmp[6],
- immedDestAddress,
- immedSrcAddress);
- }
- skb->protocol = eth_type_trans(skb, dev);
- IFDEBUG(ARLAN_DEBUG_HEADER_DUMP)
- if (skb->protocol != 0x608 && skb->protocol != 0x8)
- {
- for (i = 0; i <= 22; i++)
- printk("%02x:", (u_char) skbtmp[i + 12]);
- printk(KERN_ERR "\n");
- printk(KERN_WARNING "arlan kernel pkt type trans %x \n", skb->protocol);
- }
- netif_rx(skb);
- dev->stats.rx_packets++;
- dev->stats.rx_bytes += pkt_len;
+ IFDEBUG(ARLAN_DEBUG_HEADER_DUMP)
+ {
+ char immedDestAddress[6];
+ char immedSrcAddress[6];
+ memcpy_fromio(immedDestAddress, arlan->immedDestAddress, 6);
+ memcpy_fromio(immedSrcAddress, arlan->immedSrcAddress, 6);
+
+ printk(KERN_WARNING "%s t %pM f %pM imd %pM ims %pM\n",
+ dev->name, skbtmp,
+ &skbtmp[6],
+ immedDestAddress,
+ immedSrcAddress);
}
+ skb->protocol = eth_type_trans(skb, dev);
+ IFDEBUG(ARLAN_DEBUG_HEADER_DUMP)
+ if (skb->protocol != 0x608 && skb->protocol != 0x8) {
+ for (i = 0; i <= 22; i++)
+ printk("%02x:", (u_char) skbtmp[i + 12]);
+ printk(KERN_ERR "\n");
+ printk(KERN_WARNING "arlan kernel pkt type trans %x\n", skb->protocol);
+ }
+ netif_rx(skb);
+ dev->stats.rx_packets++;
+ dev->stats.rx_bytes += pkt_len;
+ }
+ break;
+
+ default:
+ printk(KERN_ERR "arlan intr: received unknown status\n");
+ dev->stats.rx_crc_errors++;
break;
-
- default:
- printk(KERN_ERR "arlan intr: received unknown status\n");
- dev->stats.rx_crc_errors++;
- break;
}
ARLAN_DEBUG_EXIT("arlan_rx_interrupt");
}
^ permalink raw reply
* [PATCH] forcedeth: Account for consumed budget in napi poll
From: Tom Herbert @ 2010-05-06 4:15 UTC (permalink / raw)
To: netdev, davem
Repeated calls to nv_rx_process in napi poll routine do not take
portion of budget that has been consumed in previous calls. Fix by
subtracting the number of packets processed.
Signed-off-by: Tom Herbert <therbert@google.com>
---
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index f9e1dd4..e282d0a 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -3564,14 +3564,15 @@ static int nv_napi_poll(struct napi_struct *napi, int budget)
tx_work += nv_tx_done(dev, np->tx_ring_size);
spin_unlock_irqrestore(&np->lock, flags);
- rx_count = nv_rx_process(dev, budget);
+ rx_count = nv_rx_process(dev, budget - rx_work);
retcode = nv_alloc_rx(dev);
} else {
spin_lock_irqsave(&np->lock, flags);
tx_work += nv_tx_done_optimized(dev, np->tx_ring_size);
spin_unlock_irqrestore(&np->lock, flags);
- rx_count = nv_rx_process_optimized(dev, budget);
+ rx_count = nv_rx_process_optimized(dev,
+ budget - rx_work);
retcode = nv_alloc_rx_optimized(dev);
}
} while (retcode == 0 &&
^ permalink raw reply related
* Re: linux-next: manual merge of the staging-next tree with the net tree
From: Greg KH @ 2010-05-06 4:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Prashant P. Shah, Jiri Pirko,
David Miller, netdev
In-Reply-To: <20100506140543.d6f3841f.sfr@canb.auug.org.au>
On Thu, May 06, 2010 at 02:05:43PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging-next tree got a conflict in
> drivers/staging/arlan/arlan-main.c between commit
> 22bedad3ce112d5ca1eaf043d4990fa2ed698c87 ("net: convert multicast list to
> list_head") from the net tree and commit
> dd730b627cf8ff0b9d20df94fd31b6192b188710 ("Staging: arlan: fixed
> unnecessary whitespace style issue in arlan-main.c") from the
> staging-next tree.
>
> I fixed it up (see below - this is bigger than is would otherwise be
> because there is a conflict with another patch that was previously
> reported) and can carry the fix as necessary.
Thanks for doing this. Hm, the arlan driver is scheduled to be deleted
in .35, so it would make things easier if I just do it now to keep these
kinds of merge issues from happening. I'll queue that up tomorrow.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the staging-next tree with the net tree
From: Stephen Rothwell @ 2010-05-06 4:21 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Prashant P. Shah, Jiri Pirko,
David Miller, netdev
In-Reply-To: <20100506042048.GA25425@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 456 bytes --]
Hi Greg,
On Wed, 5 May 2010 21:20:48 -0700 Greg KH <greg@kroah.com> wrote:
>
> Thanks for doing this. Hm, the arlan driver is scheduled to be deleted
> in .35, so it would make things easier if I just do it now to keep these
> kinds of merge issues from happening. I'll queue that up tomorrow.
Ah, yes, that would be easier. Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [net-next-2.6 V5 PATCH 0/3] Add port-profile netlink support
From: Scott Feldman @ 2010-05-06 4:42 UTC (permalink / raw)
To: davem; +Cc: netdev, chrisw, arnd
(Resending to fix a bug found in testing get_vf_port_profile).
The following series adds port-profile netlink support and adds an
implementation to Cisco's enic netdev driver:
1/3: Adds port-profile netlink RTM_SETLINK/RTM_GETLINK support, and
adds matching netdev ops net_{set|get}_vf_port_profile.
2/3: Adds enic support for net_{set|get}_vf_port_profile for enic
dynamic devices.
3/3: (please don't apply this 3rd patch) Enables SR-IOV support for
enic to illustrate support for port-profile netlink using SR-IOV-
compliant devices.
The SETLINK/GETLINK support follows the model for other IFLA_VF_* msgs used
for SR-IOV devices where the receipent of the netlink msg is the PF, but the
target is the VF.
The intent of this patch set is to cover both definitions of port-profile
as defined by Cisco's enic use and as defined by VSI discover protocol (VDP),
used in VEPA implemenations. While both definitions are based on pre-
standards, the concept of a port-profile to be applied to an external switch
port on behalf of a virtual machine interface is common, as well as many
of the fields defining the protocols.
Signed-off-by: Scott Feldman <scofeldm@cisco.com>
Signed-off-by: Roopa Prabhu<roprabhu@cisco.com>
^ 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