* [PATCH net-2.6 0/4] bnx2x fixes
From: Dmitry Kravkov @ 2011-05-22 20:14 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Eilon Greenstein, Vladislav Zolotarov
Hello Dave,
Please consider applying following fixes to net-2.6.
Thanks,
Dmitry
^ permalink raw reply
* [PATCH net-2.6 4/4] bnx2x: allow device properly initialize after hotplug
From: Dmitry Kravkov @ 2011-05-22 20:11 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller; +Cc: Eilon Greenstein
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 67 ++++++++++++++-------------------------
1 files changed, 24 insertions(+), 43 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 58e30a2..8bfd857 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -7450,51 +7450,35 @@ static inline void bnx2x_mcp_wait_one(struct bnx2x *bp)
msleep(MCP_ONE_TIMEOUT);
}
-static int bnx2x_reset_mcp_comp(struct bnx2x *bp, u32 magic_val)
+/*
+ * initializes bp->common.shmem_base and waits for validity signature to appear
+ */
+static int bnx2x_init_shmem(struct bnx2x *bp)
{
- u32 shmem, cnt, validity_offset, val;
- int rc = 0;
-
- msleep(100);
+ int cnt = 0;
+ u32 val = 0;
- /* Get shmem offset */
- shmem = REG_RD(bp, MISC_REG_SHARED_MEM_ADDR);
- if (shmem == 0) {
- BNX2X_ERR("Shmem 0 return failure\n");
- rc = -ENOTTY;
- goto exit_lbl;
- }
+ do {
+ bp->common.shmem_base = REG_RD(bp, MISC_REG_SHARED_MEM_ADDR);
+ if (bp->common.shmem_base) {
+ val = SHMEM_RD(bp, validity_map[BP_PORT(bp)]);
+ if (val & SHR_MEM_VALIDITY_MB)
+ return 0;
+ }
- validity_offset = offsetof(struct shmem_region, validity_map[0]);
+ bnx2x_mcp_wait_one(bp);
- /* Wait for MCP to come up */
- for (cnt = 0; cnt < (MCP_TIMEOUT / MCP_ONE_TIMEOUT); cnt++) {
- /* TBD: its best to check validity map of last port.
- * currently checks on port 0.
- */
- val = REG_RD(bp, shmem + validity_offset);
- DP(NETIF_MSG_HW, "shmem 0x%x validity map(0x%x)=0x%x\n", shmem,
- shmem + validity_offset, val);
+ } while (cnt++ < (MCP_TIMEOUT / MCP_ONE_TIMEOUT));
- /* check that shared memory is valid. */
- if ((val & (SHR_MEM_VALIDITY_DEV_INFO | SHR_MEM_VALIDITY_MB))
- == (SHR_MEM_VALIDITY_DEV_INFO | SHR_MEM_VALIDITY_MB))
- break;
+ BNX2X_ERR("BAD MCP validity signature\n");
- bnx2x_mcp_wait_one(bp);
- }
-
- DP(NETIF_MSG_HW, "Cnt=%d Shmem validity map 0x%x\n", cnt, val);
+ return -ENODEV;
+}
- /* Check that shared memory is valid. This indicates that MCP is up. */
- if ((val & (SHR_MEM_VALIDITY_DEV_INFO | SHR_MEM_VALIDITY_MB)) !=
- (SHR_MEM_VALIDITY_DEV_INFO | SHR_MEM_VALIDITY_MB)) {
- BNX2X_ERR("Shmem signature not present. MCP is not up !!\n");
- rc = -ENOTTY;
- goto exit_lbl;
- }
+static int bnx2x_reset_mcp_comp(struct bnx2x *bp, u32 magic_val)
+{
+ int rc = bnx2x_init_shmem(bp);
-exit_lbl:
/* Restore the `magic' bit value */
if (!CHIP_IS_E1(bp))
bnx2x_clp_reset_done(bp, magic_val);
@@ -8007,10 +7991,12 @@ static void __devinit bnx2x_get_common_hwinfo(struct bnx2x *bp)
BNX2X_DEV_INFO("flash_size 0x%x (%d)\n",
bp->common.flash_size, bp->common.flash_size);
- bp->common.shmem_base = REG_RD(bp, MISC_REG_SHARED_MEM_ADDR);
+ bnx2x_init_shmem(bp);
+
bp->common.shmem2_base = REG_RD(bp, (BP_PATH(bp) ?
MISC_REG_GENERIC_CR_1 :
MISC_REG_GENERIC_CR_0));
+
bp->link_params.shmem_base = bp->common.shmem_base;
bp->link_params.shmem2_base = bp->common.shmem2_base;
BNX2X_DEV_INFO("shmem offset 0x%x shmem2 offset 0x%x\n",
@@ -8022,11 +8008,6 @@ static void __devinit bnx2x_get_common_hwinfo(struct bnx2x *bp)
return;
}
- val = SHMEM_RD(bp, validity_map[BP_PORT(bp)]);
- if ((val & (SHR_MEM_VALIDITY_DEV_INFO | SHR_MEM_VALIDITY_MB))
- != (SHR_MEM_VALIDITY_DEV_INFO | SHR_MEM_VALIDITY_MB))
- BNX2X_ERR("BAD MCP validity signature\n");
-
bp->common.hw_config = SHMEM_RD(bp, dev_info.shared_hw_config.config);
BNX2X_DEV_INFO("hw_config 0x%08x\n", bp->common.hw_config);
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-2.6 2/4] bnx2x: properly handle CFC DEL in cnic flow
From: Dmitry Kravkov @ 2011-05-22 20:08 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller
Cc: Vladislav Zolotarov, Eilon Greenstein
From: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index a97a4a1..e237bea 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -3669,7 +3669,8 @@ static int bnx2x_cnic_handle_cfc_del(struct bnx2x *bp, u32 cid,
union event_ring_elem *elem)
{
if (!bp->cnic_eth_dev.starting_cid ||
- cid < bp->cnic_eth_dev.starting_cid)
+ (cid < bp->cnic_eth_dev.starting_cid &&
+ cid != bp->cnic_eth_dev.iscsi_l2_cid))
return 1;
DP(BNX2X_MSG_SP, "got delete ramrod for CNIC CID %d\n", cid);
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-2.6 3/4] bnx2x: fix DMAE timeout according to hw specifications
From: Dmitry Kravkov @ 2011-05-22 20:09 UTC (permalink / raw)
To: David Miller, netdev@vger.kernel.org; +Cc: Eilon Greenstein
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 8b27c75..09586e2 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -571,7 +571,7 @@ static int bnx2x_issue_dmae_with_comp(struct bnx2x *bp,
struct dmae_command *dmae)
{
u32 *wb_comp = bnx2x_sp(bp, wb_comp);
- int cnt = CHIP_REV_IS_SLOW(bp) ? (400000) : 40;
+ int cnt = CHIP_REV_IS_SLOW(bp) ? (400000) : 4000;
int rc = 0;
DP(BNX2X_MSG_OFF, "data before [0x%08x 0x%08x 0x%08x 0x%08x]\n",
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-2.6 1/4] bnx2x: call dev_kfree_skb_any instead of dev_kfree_skb
From: Dmitry Kravkov @ 2011-05-22 20:06 UTC (permalink / raw)
To: davem, netdev@vger.kernel.org; +Cc: Vladislav Zolotarov, Eilon Greenstein
From: Vladislav Zolotarov <vladz@broadcom.com>
replace function calls when possible call in both irq/non-irq contexts
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 4 ++--
drivers/net/bnx2x/bnx2x_cmn.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index 16581df..9403049 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -87,7 +87,7 @@ static u16 bnx2x_free_tx_pkt(struct bnx2x *bp, struct bnx2x_fastpath *fp,
/* release skb */
WARN_ON(!skb);
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
tx_buf->first_bd = 0;
tx_buf->skb = NULL;
@@ -419,7 +419,7 @@ static void bnx2x_tpa_stop(struct bnx2x *bp, struct bnx2x_fastpath *fp,
} else {
DP(NETIF_MSG_RX_STATUS, "Failed to allocate new pages"
" - dropping packet!\n");
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
}
diff --git a/drivers/net/bnx2x/bnx2x_cmn.h b/drivers/net/bnx2x/bnx2x_cmn.h
index ef37b98..89eb9ca 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/bnx2x/bnx2x_cmn.h
@@ -838,7 +838,7 @@ static inline int bnx2x_alloc_rx_skb(struct bnx2x *bp,
mapping = dma_map_single(&bp->pdev->dev, skb->data, fp->rx_buf_size,
DMA_FROM_DEVICE);
if (unlikely(dma_mapping_error(&bp->pdev->dev, mapping))) {
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
return -ENOMEM;
}
--
1.7.2.2
^ permalink raw reply related
* [PATCH 3/3] vlan: Simplify the code now that VLAN_FLAG_REORDER_HDR is always set
From: Eric W. Biederman @ 2011-05-22 19:42 UTC (permalink / raw)
To: David Miller
Cc: Jiri Pirko, Nicolas de Pesloüan, Changli Gao, netdev,
shemminger, kaber, fubar, eric.dumazet, andy, Jesse Gross
In-Reply-To: <m14o4mjzh3.fsf_-_@fess.ebiederm.org>
Now that we no longer support clearing VLAN_FLAG_REORDER_HDR remove the
code that was needed to cope with the case when it was cleared.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
net/8021q/vlan_dev.c | 45 +++++----------------------------------------
1 files changed, 5 insertions(+), 40 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 20629fe..2b3ca1e 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -96,63 +96,28 @@ static int vlan_dev_hard_header(struct sk_buff *skb, struct net_device *dev,
const void *daddr, const void *saddr,
unsigned int len)
{
- struct vlan_hdr *vhdr;
- unsigned int vhdrlen = 0;
- u16 vlan_tci = 0;
int rc;
- if (!(vlan_dev_info(dev)->flags & VLAN_FLAG_REORDER_HDR)) {
- vhdr = (struct vlan_hdr *) skb_push(skb, VLAN_HLEN);
-
- vlan_tci = vlan_dev_info(dev)->vlan_id;
- vlan_tci |= vlan_dev_get_egress_qos_mask(dev, skb);
- vhdr->h_vlan_TCI = htons(vlan_tci);
-
- /*
- * Set the protocol type. For a packet of type ETH_P_802_3/2 we
- * put the length in here instead.
- */
- if (type != ETH_P_802_3 && type != ETH_P_802_2)
- vhdr->h_vlan_encapsulated_proto = htons(type);
- else
- vhdr->h_vlan_encapsulated_proto = htons(len);
-
- skb->protocol = htons(ETH_P_8021Q);
- type = ETH_P_8021Q;
- vhdrlen = VLAN_HLEN;
- }
-
/* Before delegating work to the lower layer, enter our MAC-address */
if (saddr == NULL)
saddr = dev->dev_addr;
/* Now make the underlying real hard header */
dev = vlan_dev_info(dev)->real_dev;
- rc = dev_hard_header(skb, dev, type, daddr, saddr, len + vhdrlen);
- if (rc > 0)
- rc += vhdrlen;
+ rc = dev_hard_header(skb, dev, type, daddr, saddr, len);
return rc;
}
static netdev_tx_t vlan_dev_hard_start_xmit(struct sk_buff *skb,
struct net_device *dev)
{
- struct vlan_ethhdr *veth = (struct vlan_ethhdr *)(skb->data);
unsigned int len;
+ u16 vlan_tci;
int ret;
- /* Handle non-VLAN frames if they are sent to us, for example by DHCP.
- *
- * NOTE: THIS ASSUMES DIX ETHERNET, SPECIFICALLY NOT SUPPORTING
- * OTHER THINGS LIKE FDDI/TokenRing/802.3 SNAPs...
- */
- if (veth->h_vlan_proto != htons(ETH_P_8021Q) ||
- vlan_dev_info(dev)->flags & VLAN_FLAG_REORDER_HDR) {
- u16 vlan_tci;
- vlan_tci = vlan_dev_info(dev)->vlan_id;
- vlan_tci |= vlan_dev_get_egress_qos_mask(dev, skb);
- skb = __vlan_hwaccel_put_tag(skb, vlan_tci);
- }
+ vlan_tci = vlan_dev_info(dev)->vlan_id;
+ vlan_tci |= vlan_dev_get_egress_qos_mask(dev, skb);
+ skb = __vlan_hwaccel_put_tag(skb, vlan_tci);
skb_set_dev(skb, vlan_dev_info(dev)->real_dev);
len = skb->len;
--
1.7.5.1.217.g4e3aa
^ permalink raw reply related
* [PATCH 2/3] vlan: Always strip the vlan header in vlan_untag.
From: Eric W. Biederman @ 2011-05-22 19:40 UTC (permalink / raw)
To: David Miller
Cc: Jiri Pirko, Nicolas de Pesloüan, Changli Gao, netdev,
shemminger, kaber, fubar, eric.dumazet, andy, Jesse Gross
In-Reply-To: <m1ei3qjzix.fsf_-_@fess.ebiederm.org>
Calling vlan_dev_info() on a non-vlan device gives completely undefined
results, and is no longer needed now that we no longer support keeping
the vlan tag.
Simplify and correct the code by remove the check for VLAN_FLAG_REORDER_HDR.
Additionally rename vlan_check_reorder_header to just
vlan_reorder_header as there is no check involved now.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
net/8021q/vlan_core.c | 20 +++++++++-----------
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 41495dc..302d8e3 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -89,17 +89,15 @@ gro_result_t vlan_gro_frags(struct napi_struct *napi, struct vlan_group *grp,
}
EXPORT_SYMBOL(vlan_gro_frags);
-static struct sk_buff *vlan_check_reorder_header(struct sk_buff *skb)
+static struct sk_buff *vlan_reorder_header(struct sk_buff *skb)
{
- if (vlan_dev_info(skb->dev)->flags & VLAN_FLAG_REORDER_HDR) {
- if (skb_cow(skb, skb_headroom(skb)) < 0)
- skb = NULL;
- if (skb) {
- /* Lifted from Gleb's VLAN code... */
- memmove(skb->data - ETH_HLEN,
- skb->data - VLAN_ETH_HLEN, 12);
- skb->mac_header += VLAN_HLEN;
- }
+ if (skb_cow(skb, skb_headroom(skb)) < 0)
+ skb = NULL;
+ if (skb) {
+ /* Lifted from Gleb's VLAN code... */
+ memmove(skb->data - ETH_HLEN,
+ skb->data - VLAN_ETH_HLEN, 12);
+ skb->mac_header += VLAN_HLEN;
}
return skb;
}
@@ -161,7 +159,7 @@ struct sk_buff *vlan_untag(struct sk_buff *skb)
skb_pull_rcsum(skb, VLAN_HLEN);
vlan_set_encap_proto(skb, vhdr);
- skb = vlan_check_reorder_header(skb);
+ skb = vlan_reorder_header(skb);
if (unlikely(!skb))
goto err_free;
--
1.7.5.1.217.g4e3aa
^ permalink raw reply related
* [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR
From: Eric W. Biederman @ 2011-05-22 19:39 UTC (permalink / raw)
To: David Miller
Cc: Jiri Pirko, Nicolas de Pesloüan, Changli Gao, netdev,
shemminger, kaber, fubar, eric.dumazet, andy, Jesse Gross
In-Reply-To: <BANLkTi=4JJa-J-p_JbY1PfooT75KfSB4uA@mail.gmail.com>
Simplify the vlan handling code by not supporing clearing of
VLAN_FLAG_REORDER_HDR. Which means we always make the vlan handling
code strip the vlan header from the packets, and always insert the vlan
header when transmitting packets.
Not stripping the vlan header has alwasy been broken in combination with
vlan hardware accelleration. Now that we are making everything look
like accelerated vlan handling not stripping the vlan header is always
broken.
I don't think anyone actually cares so simply stop supporting the broken
case.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
net/8021q/vlan_dev.c | 3 +--
net/8021q/vlan_netlink.c | 4 +---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index f247f5b..20629fe 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -242,8 +242,7 @@ int vlan_dev_change_flags(const struct net_device *dev, u32 flags, u32 mask)
struct vlan_dev_info *vlan = vlan_dev_info(dev);
u32 old_flags = vlan->flags;
- if (mask & ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP |
- VLAN_FLAG_LOOSE_BINDING))
+ if (mask & ~(VLAN_FLAG_GVRP | VLAN_FLAG_LOOSE_BINDING))
return -EINVAL;
vlan->flags = (old_flags & ~mask) | (flags & mask);
diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
index be9a5c1..a638a4c 100644
--- a/net/8021q/vlan_netlink.c
+++ b/net/8021q/vlan_netlink.c
@@ -59,9 +59,7 @@ static int vlan_validate(struct nlattr *tb[], struct nlattr *data[])
}
if (data[IFLA_VLAN_FLAGS]) {
flags = nla_data(data[IFLA_VLAN_FLAGS]);
- if ((flags->flags & flags->mask) &
- ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP |
- VLAN_FLAG_LOOSE_BINDING))
+ if (flags->mask & ~(VLAN_FLAG_GVRP | VLAN_FLAG_LOOSE_BINDING))
return -EINVAL;
}
--
1.7.5.1.217.g4e3aa
^ permalink raw reply related
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Eric W. Biederman @ 2011-05-22 19:33 UTC (permalink / raw)
To: Jesse Gross
Cc: Jiri Pirko, Nicolas de Pesloüan, Changli Gao, David Miller,
netdev, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <m1ei3qlhjw.fsf@fess.ebiederm.org>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Jesse Gross <jesse@nicira.com> writes:
>
>> On Sat, May 21, 2011 at 11:34 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> Jiri Pirko <jpirko@redhat.com> writes:
>>>
>>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>>>
>>>> <snip>
>>>>>
>>>>>And because some setups may still require the skb not to be untagged,
>>>>>may be we need the ability to re-tag the skb in some situations...
>>>>>When a protocol handler or rx_handler is explicitly registered on a
>>>>>net_device which expect to receive tagged skb, we should deliver
>>>>>tagged skb to it... Arguably, this may sound incredible for the
>>>>>general case, but may be required for not-so-special cases like
>>>>>bridge or protocol analyzer.
>>>>
>>>> Wait, what setups/code require the skb not to be untagged? If there's
>>>> such, it should be fixed.
>>>
>>> tcpdump on the non-vlan interface for one.
>>
>> There are some drivers still using the old vlan model that will drop
>> tags or packets when no vlan group is configured but that's a driver
>> problem, not one with networking core or tcpdump.
>
> On receive if we have stripped the vlan header and then we go to deliver
> the interrupt to a pf_packet socket (on a non-vlan interface) before
> or as part of the deliver of the packet to user space we need to
> re-add the vlan header. Additionally the socket filter on a pf_packet
> socket needs to behave as though we have a vlan header.
Hmm. Taking a second look the pf_packet code and with hardware vlan
header removal isn't completely broken. It is possible to receive
packet auxdata and get the information from the vlan header.
It stills seems like a pretty messed up interface to me. Especially
since the socket filter can't get at the information in the stripped
vlan header, but that is another matter entirely.
Eric
^ permalink raw reply
* Re: More prefetch fall-out
From: Eric Dumazet @ 2011-05-22 18:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, Network Development
In-Reply-To: <BANLkTimQAhP17Hg6D84gtCO3nJ_SSsDAeg@mail.gmail.com>
Le dimanche 22 mai 2011 à 11:38 -0700, Linus Torvalds a écrit :
> On Sun, May 22, 2011 at 11:23 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > Taking a look at various skb_queue_walk* call sites, I think prefetches
> > are not a clear win, I would just remove them all from skbuff.h
>
> Hmm.
>
> I did that, and it turns out that we also have:
>
> - *lots* of network drivers that use "prefetch" (without including prefetch.h)
> - net/netlabel/netlabel_addrlist.h doing the same.
>
> and fixing that up is annoying "grunt work".
>
> So for now, I think I'll just do the "add the <linux/prefetch.h> to
> <linux/skbuff.h>" thing, and leave networking alone. That makes
> everything compile ("allyesconfig") even with my "you *have* to
> include <linux/prefetch.h>" test-patch.
>
Or include <linux/prefetch.h> from linux/skbuff.h but remove the
prefetch() calls...
BTW this reminds me Andi Kleen prior patch
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-09/msg03096.html
^ permalink raw reply
* Re: More prefetch fall-out
From: Linus Torvalds @ 2011-05-22 18:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Network Development
In-Reply-To: <1306088626.12435.27.camel@edumazet-laptop>
On Sun, May 22, 2011 at 11:23 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Taking a look at various skb_queue_walk* call sites, I think prefetches
> are not a clear win, I would just remove them all from skbuff.h
Hmm.
I did that, and it turns out that we also have:
- *lots* of network drivers that use "prefetch" (without including prefetch.h)
- net/netlabel/netlabel_addrlist.h doing the same.
and fixing that up is annoying "grunt work".
So for now, I think I'll just do the "add the <linux/prefetch.h> to
<linux/skbuff.h>" thing, and leave networking alone. That makes
everything compile ("allyesconfig") even with my "you *have* to
include <linux/prefetch.h>" test-patch.
Linus
^ permalink raw reply
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Eric W. Biederman @ 2011-05-22 18:24 UTC (permalink / raw)
To: Jesse Gross
Cc: Jiri Pirko, Nicolas de Pesloüan, Changli Gao, David Miller,
netdev, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <BANLkTi=4JJa-J-p_JbY1PfooT75KfSB4uA@mail.gmail.com>
Jesse Gross <jesse@nicira.com> writes:
> On Sat, May 21, 2011 at 11:34 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Jiri Pirko <jpirko@redhat.com> writes:
>>
>>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>>
>>> <snip>
>>>>
>>>>And because some setups may still require the skb not to be untagged,
>>>>may be we need the ability to re-tag the skb in some situations...
>>>>When a protocol handler or rx_handler is explicitly registered on a
>>>>net_device which expect to receive tagged skb, we should deliver
>>>>tagged skb to it... Arguably, this may sound incredible for the
>>>>general case, but may be required for not-so-special cases like
>>>>bridge or protocol analyzer.
>>>
>>> Wait, what setups/code require the skb not to be untagged? If there's
>>> such, it should be fixed.
>>
>> tcpdump on the non-vlan interface for one.
>
> There are some drivers still using the old vlan model that will drop
> tags or packets when no vlan group is configured but that's a driver
> problem, not one with networking core or tcpdump.
On receive if we have stripped the vlan header and then we go to deliver
the interrupt to a pf_packet socket (on a non-vlan interface) before
or as part of the deliver of the packet to user space we need to
re-add the vlan header. Additionally the socket filter on a pf_packet
socket needs to behave as though we have a vlan header.
So no I am not talking about anything that is driver specific. I am
talking about reasonable userspace expectations. Because otherwise
we simply loose the information that a packet was vlan tagged, and
in doing so we break existing userspace applications because of our
bugs.
Eric
^ permalink raw reply
* Re: More prefetch fall-out
From: Eric Dumazet @ 2011-05-22 18:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, Network Development
In-Reply-To: <BANLkTi=YwLaoTVjKguH-uZpZgXduLhiTNg@mail.gmail.com>
Le dimanche 22 mai 2011 à 10:49 -0700, Linus Torvalds a écrit :
> However, one of the breakages is <linux/skbuff.h> that does its own
> list-walking functions ("skb_queue_walk*"), and they do prefetching.
> So now I have the option to either just add <linux/prefetch.h> to that
> file, or remove the prefetches. And you're the one that said that the
> prefetches in the networking code were annoying.
>
> So should the skb queues use prefetching? I have a hard time judging.
> Are those lists usually long? Is the loop usually large enough that
> there is any point to prefetching the next entry?
>
Taking a look at various skb_queue_walk* call sites, I think prefetches
are not a clear win, I would just remove them all from skbuff.h
BTW, the skb_queue_walk_safe(), skb_queue_walk_from_safe(),
skb_queue_reverse_walk_safe, skb_queue_reverse_walk_from_safe() dont
have prefetch() calls.
^ permalink raw reply
* More prefetch fall-out
From: Linus Torvalds @ 2011-05-22 17:49 UTC (permalink / raw)
To: David Miller; +Cc: Network Development
So it turns out that the architectures that don't define their
prefetch() macros in <asm/processor.h> (and instead depend on
linux/prefetch.h to give them the default ones) are currently broken.
Fine, that's really trivial to fix. And, in fact, I'm now testing on
x86 by having x86 put its prefetch infrastructure in <asm/prefetch.h>
and thus making sure that you *have* to include <linux/prefetch.h> to
get it (rather than get it accidentally just because everything ends
up including <asm/processor.h>).
However, one of the breakages is <linux/skbuff.h> that does its own
list-walking functions ("skb_queue_walk*"), and they do prefetching.
So now I have the option to either just add <linux/prefetch.h> to that
file, or remove the prefetches. And you're the one that said that the
prefetches in the networking code were annoying.
So should the skb queues use prefetching? I have a hard time judging.
Are those lists usually long? Is the loop usually large enough that
there is any point to prefetching the next entry?
Linus
^ permalink raw reply
* Block based abstraction in af_packet->Rx::mmap
From: chetan loke @ 2011-05-22 17:46 UTC (permalink / raw)
To: netdev, loke.chetan
Hello,
With the current af_packet->rx::mmap based approach, the element size
in the block needs to be statically configured.
Nothing wrong with the current config/implementation. But since the
traffic profile cannot be known in advance, it would be nice if that
configuration
wasn't static. Normally, one would configure the element-size
to be '2048' so that you can atleast capture the entire 'MTU-size'.
But if the traffic profile varies then we would end up either
i)wasting memory or ii) end up getting a sliced frame.
In other words the packet density will be much much less in the first case.
Also, today we have to spin-wait/poll if a single packet is ready for
consumption(is status == TP_STATUS_USER?).
This does not scale. Rather, poll-waiting on a single block will
definitely help.
Q1)Is anyone working on enhancing the current mmap implementation?
Q2)Do patches exist for such non-static implementation already?
PS: Please CC me on the replies as I am not subscribed on the mailing list.
Regards
Chetan
^ permalink raw reply
* Re: [PATCH] net: ipv4: add IPPROTO_ICMP socket kind
From: Vasiliy Kulikov @ 2011-05-22 17:46 UTC (permalink / raw)
To: Pavel Kankovsky; +Cc: Alexey Dobriyan, netdev, Solar Designer
In-Reply-To: <20110522174412.2F0C.0@paddy.troja.mff.cuni.cz>
On Sun, May 22, 2011 at 18:01 +0200, Pavel Kankovsky wrote:
> On Thu, 14 Apr 2011, Alexey Dobriyan wrote:
>
> > Also, there was big discussion re exposing kernel socket pointers,
> > which this file continue to do.
>
> One late comment:
>
> The code was intented to immitate /proc/net/udp.
>
> As far as I can tell UDP and TCP (having checked udp.c and tcp_ipv[46].c
> in the latest net-next-2.6) do not have any qualms about exposing kernel
> pointers so we are a little bit holier than the pope here. :)
Anyway, ping uses %pK:
seq_printf(f, "%5d: %08X:%04X %08X:%04X"
" %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK d%n",
bucket, src, srcp, dest, destp, sp->sk_state,
sk_wmem_alloc_get(sp),
sk_rmem_alloc_get(sp),
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
atomic_read(&sp->sk_refcnt), sp,
atomic_read(&sp->sk_drops), len);
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Security Warning
From: Webmaster Administrator @ 2011-05-22 17:25 UTC (permalink / raw)
Your mailbox has exceeded the storage limit which is 20GB as set by your
administrator,you are currently running on 20.9GB,you may not be able to
send or receive new mail until you re-validate your mailbox. To
re-validate your mailbox, please click the link below:
http://doiop.com/4rgn5e
If the link above don't work, please copy and paste the link below to your
browser window.
http://doiop.com/4rgn5e
Thanks
System Administrator Team.
^ permalink raw reply
* Re: [PATCH RFC] virtio_net: fix patch: virtio_net: limit xmit polling
From: Michael S. Tsirkin @ 2011-05-22 17:32 UTC (permalink / raw)
To: Rusty Russell
Cc: habanero, Shirley Ma, Krishna Kumar2, kvm, steved, Tom Lendacky,
borntraeger, avi, virtualization, netdev, linux-kernel
In-Reply-To: <8739kb5era.fsf@rustcorp.com.au>
On Thu, May 19, 2011 at 05:00:17PM +0930, Rusty Russell wrote:
> On Thu, 19 May 2011 01:01:25 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > The patch virtio_net: limit xmit polling
> > got the logic reversed: it polled while we had
> > capacity not while ring was empty.
> >
> > Fix it up and clean up a bit by using a for loop.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >
> > OK, turns out that patch was borken. Here's
> > a fix that survived stress test on my box.
> > Pushed on my branch, I'll send a rebased series
> > with Rusty's comments addressed ASAP.
>
> Normally you would have missed the merge window by now, but I'd really
> like this stuff in, so I'm holding it open for this. I want these patches
> in linux-next for at least a few days before I push them.
>
> If you think we're not close enough, please tell me and I'll push
> the rest of the virtio patches to Linus now.
>
> Thanks,
> Rusty.
I think it makes sense to push just the patches you have
applied by now (event index + delayed callback) - the
rest are close but they are guest only patches so very easy to
experiment with out of tree. OTOH if event index misses the
window it makes testing painful as we have to keep patching
both host and guest.
--
MST
^ permalink raw reply
* [PATCH] net: filter: move forward declarations to avoid compile warnings
From: Heiko Carstens @ 2011-05-22 17:08 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, Eric Dumazet
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Get rid of this compile warning:
In file included from arch/s390/kernel/compat_linux.c:37:0:
include/linux/filter.h:139:23: warning: 'struct sk_buff' declared inside parameter list
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
include/linux/filter.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 4609b85..9ee3f9f 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -131,6 +131,10 @@ struct sock_fprog { /* Required for SO_ATTACH_FILTER. */
#define SKF_LL_OFF (-0x200000)
#ifdef __KERNEL__
+
+struct sk_buff;
+struct sock;
+
struct sk_filter
{
atomic_t refcnt;
@@ -146,9 +150,6 @@ static inline unsigned int sk_filter_len(const struct sk_filter *fp)
return fp->len * sizeof(struct sock_filter) + sizeof(*fp);
}
-struct sk_buff;
-struct sock;
-
extern int sk_filter(struct sock *sk, struct sk_buff *skb);
extern unsigned int sk_run_filter(const struct sk_buff *skb,
const struct sock_filter *filter);
^ permalink raw reply related
* [PATCH] net: add missing prefetch.h include
From: Heiko Carstens @ 2011-05-22 16:55 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton, David Miller; +Cc: linux-kernel, netdev
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Fixes build errors on s390 and probably other archs as well:
In file included from net/ipv4/ip_forward.c:32:0:
include/net/udp.h: In function 'udp_csum_outgoing':
include/net/udp.h:141:2: error: implicit declaration of function 'prefetch'
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
include/linux/skbuff.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 79aafbb..8276815 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -28,6 +28,7 @@
#include <net/checksum.h>
#include <linux/rcupdate.h>
#include <linux/dmaengine.h>
+#include <linux/prefetch.h>
#include <linux/hrtimer.h>
/* Don't change this without changing skb_csum_unnecessary! */
^ permalink raw reply related
* Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel
From: Jesse Gross @ 2011-05-22 16:11 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Jiri Pirko, Nicolas de Pesloüan, Changli Gao, David Miller,
netdev, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <m17h9jp7js.fsf@fess.ebiederm.org>
On Sat, May 21, 2011 at 11:34 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Jiri Pirko <jpirko@redhat.com> writes:
>
>> Sun, May 22, 2011 at 04:59:49AM CEST, nicolas.2p.debian@gmail.com wrote:
>>
>> <snip>
>>>
>>>And because some setups may still require the skb not to be untagged,
>>>may be we need the ability to re-tag the skb in some situations...
>>>When a protocol handler or rx_handler is explicitly registered on a
>>>net_device which expect to receive tagged skb, we should deliver
>>>tagged skb to it... Arguably, this may sound incredible for the
>>>general case, but may be required for not-so-special cases like
>>>bridge or protocol analyzer.
>>
>> Wait, what setups/code require the skb not to be untagged? If there's
>> such, it should be fixed.
>
> tcpdump on the non-vlan interface for one.
There are some drivers still using the old vlan model that will drop
tags or packets when no vlan group is configured but that's a driver
problem, not one with networking core or tcpdump.
^ permalink raw reply
* Re: [PATCH] net: ipv4: add IPPROTO_ICMP socket kind
From: Pavel Kankovsky @ 2011-05-22 16:01 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: netdev, Vasiliy Kulikov, Solar Designer
In-Reply-To: <BANLkTinh0cmb0hzpVdm5XemT5NeULeAoHQ@mail.gmail.com>
On Thu, 14 Apr 2011, Alexey Dobriyan wrote:
> Also, there was big discussion re exposing kernel socket pointers,
> which this file continue to do.
One late comment:
The code was intented to immitate /proc/net/udp.
As far as I can tell UDP and TCP (having checked udp.c and tcp_ipv[46].c
in the latest net-next-2.6) do not have any qualms about exposing kernel
pointers so we are a little bit holier than the pope here. :)
--
Pavel Kankovsky aka Peak / Jeremiah 9:21 \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /
^ permalink raw reply
* Patchs for pg3.c and Linux 2.6.x kernel
From: cedric arbogast @ 2011-05-22 15:24 UTC (permalink / raw)
To: netdev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
This is my first contact and mail with this mailing list, to summarize i'm a coder maintening a personnal home server using several GNU tools since the late 90's.
I build IPUTILS-s20101006 in a chroot jail (gcc 4.5.2/libc 2.13/binutils 2.21/make 3.82) with an athlon architecture on ext3 FS. I see the packet's injection module in the Module directory and try a "make modules" which indeed fails. I put an eye on the pg3.c and it seems it has not been ported to
the 2.6.x modules architecture (i'm not a kernel hacker, so it's just my humble opinion).
I make some trivial adaptations to make the code meets the 2.6 module's API requirements. The patched code compile successfully on the platform described above, but i can't now test it's proper functioning, if anyone could give a try (please consider it could (will ?) be harmful for the test
platform as i am not familiar with kernel modules hacking...) :
- --- Makefile.orig 2010-10-06 13:59:20.000000000 +0200
+++ Makefile 2011-05-22 16:56:09.000000000 +0200
@@ -39,17 +39,8 @@
$(CC) $(CFLAGS) -DRDISC_SERVER -o rdisc_srv.o rdisc.c
- -check-kernel:
- -ifeq ($(KERNEL_INCLUDE),)
- - @echo "Please, set correct KERNEL_INCLUDE"; false
- -else
- - @set -e; \
- - if [ ! -r $(KERNEL_INCLUDE)/linux/autoconf.h ]; then \
- - echo "Please, set correct KERNEL_INCLUDE"; false; fi
- -endif
- -
- -modules: check-kernel
- - $(MAKE) KERNEL_INCLUDE=$(KERNEL_INCLUDE) -C Modules
+modules:
+ $(MAKE) -C Modules
man:
$(MAKE) -C doc man
- --- Modules/Makefile.orig 2010-10-06 13:59:20.000000000 +0200
+++ Modules/Makefile 2011-05-22 14:47:48.000000000 +0200
@@ -1,12 +1,10 @@
- -KERNEL_INCLUDE=/usr/src/linux/include
+ifneq ($(KERNELRELEASE),)
+ obj-m := pg3.o
+else
+KDIR := /lib/modules/$(shell uname -r)/build
+PWD := $(shell pwd)
- -CC=gcc
- -CCOPT=-O2 -Wstrict-prototypes -Wall -Werror -fno-strict-aliasing -fno-common
- -CFLAGS=-DMODULE -D__KERNEL__ -I$(KERNEL_INCLUDE) $(CCOPT)
- -
- -
- -all: pg3.o
- -
- -clean:
- - @rm -f *.o
+default:
+ $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
+endif
- --- Modules/pg3.c.orig 2010-10-06 13:59:20.000000000 +0200
+++ Modules/pg3.c 2011-05-22 16:27:57.000000000 +0200
@@ -89,7 +89,7 @@
#include <linux/ptrace.h>
#include <linux/errno.h>
#include <linux/ioport.h>
- -#include <linux/malloc.h>
+#include <linux/slab.h>
#include <linux/interrupt.h>
#include <linux/pci.h>
#include <linux/delay.h>
@@ -110,6 +110,7 @@
#include <linux/proc_fs.h>
#include <linux/if_arp.h>
#include <net/checksum.h>
+#include <linux/version.h>
static char version[] __initdata =
"pg3.c: v1.0 010812: Packet Generator for packet performance testing.\n";
@@ -150,7 +151,7 @@
u32 saddr;
rtnl_lock();
- - odev = __dev_get_by_name(pg_outdev);
+ odev = __dev_get_by_name(&init_net, pg_outdev);
if (!odev) {
sprintf(pg_result, "No such netdevice: \"%s\"", pg_outdev);
goto out_unlock;
@@ -176,7 +177,8 @@
if (in_dev->ifa_list)
saddr = in_dev->ifa_list->ifa_address;
}
- - atomic_inc(&odev->refcnt);
+ //atomic_inc(&odev->refcnt);
+ dev_hold(odev);
rtnl_unlock();
*saddrp = saddr;
@@ -282,7 +284,8 @@
iph->check = 0;
iph->check = ip_fast_csum((void *)iph, iph->ihl);
skb->protocol = __constant_htons(ETH_P_IP);
- - skb->mac.raw = ((u8*)iph) - 14;
+ //skb->mac.raw = ((u8*)iph) - 14;
+ skb_set_mac_header(skb, -14);
skb->dev = odev;
skb->pkt_type = PACKET_HOST;
@@ -363,10 +366,11 @@
do_gettimeofday(&start);
for(;;) {
- - spin_lock_bh(&odev->xmit_lock);
+ //spin_lock_bh(&odev->xmit_lock);
+ netif_tx_lock_bh(odev);
atomic_inc(&skb->users);
if (!netif_queue_stopped(odev)) {
- - if (odev->hard_start_xmit(skb, odev)) {
+ if (odev->netdev_ops->ndo_start_xmit(skb, odev)) {
kfree_skb(skb);
if (net_ratelimit())
printk(KERN_INFO "Hard xmit error\n");
@@ -375,7 +379,8 @@
} else {
kfree_skb(skb);
}
- - spin_unlock_bh(&odev->xmit_lock);
+ //spin_unlock_bh(&odev->xmit_lock);
+ netif_tx_unlock_bh(odev);
if (pg_ipg)
nanospin(pg_ipg);
@@ -402,7 +407,7 @@
break;
}
- - if (netif_queue_stopped(odev) || current->need_resched) {
+ if (netif_queue_stopped(odev) || test_thread_flag(TIF_NEED_RESCHED) /*current->need_resched*/) {
u32 idle_start, idle;
idle_start = get_cycles();
@@ -411,10 +416,10 @@
goto out_intr;
if (!netif_running(odev))
goto out_intr;
- - if (current->need_resched)
+ if (test_thread_flag(TIF_NEED_RESCHED) /*current->need_resched*/)
schedule();
- - else
- - do_softirq();
+ //else
+ // do_softirq();
} while (netif_queue_stopped(odev));
idle = get_cycles() - idle_start;
idle_acc_lo += idle;
@@ -540,7 +545,7 @@
case '\t':
case ' ':
goto done_str;
- - default:
+ default:;
}
done_str:
return i;
@@ -669,12 +674,12 @@
}
if (!strcmp(name, "inject") || !strcmp(name, "start") ) {
- - MOD_INC_USE_COUNT;
+ //MOD_INC_USE_COUNT;
pg_busy = 1;
strcpy(pg_result, "Starting");
pg_inject();
pg_busy = 0;
- - MOD_DEC_USE_COUNT;
+ //MOD_DEC_USE_COUNT;
return count;
}
@@ -723,9 +728,12 @@
#if LINUX_VERSION_CODE > 0x20118
MODULE_AUTHOR("Robert Olsson <robert.olsson@its.uu.se");
MODULE_DESCRIPTION("Packet Generator tool");
- -MODULE_PARM(pg_count, "i");
- -MODULE_PARM(pg_ipg, "i");
- -MODULE_PARM(pg_cpu_speed, "i");
+module_param(pg_count, int, S_IRUGO);
+module_param(pg_ipg, int, S_IRUGO);
+module_param(pg_cpu_speed, int, S_IRUGO);
+//MODULE_PARM(pg_count, "i");
+//MODULE_PARM(pg_ipg, "i");
+//MODULE_PARM(pg_cpu_speed, "i");
#endif
/*
Regards, Cedric.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3ZKqsACgkQUPHT03kXaaar2wCfcxesPlBK/5e/Dy9tfX+csq5M
qIIAn2acDqBbFyKZdVHJEKHLkGxoPKxf
=JShy
-----END PGP SIGNATURE-----
^ permalink raw reply
* is UDP broadcast over wlan broken?
From: Ortwin Glück @ 2011-05-22 14:30 UTC (permalink / raw)
To: netdev, linux-kernel
Hi,
On 2.6.38.6 I can no longer receive UDP broadcasts over wireless interfaces.
This affects CUPS zeroconf (port 631 broadcasts). Other UDP traffic (like DNS
lookups) works fine.
I can see UDP broadcasts originate fine on 192.168.111.11/24 (my router):
# uname -a
Linux gandalf 2.6.38.6 #11 SMP PREEMPT Tue May 10 13:42:44 CEST 2011 x86_64
Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz GenuineIntel GNU/Linux
# tcpdump -np -i wlan0 udp and port 631
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
16:15:21.695230 IP 192.168.111.11.631 > 192.168.111.255.631: UDP, length 151
But these packets are not received on 192.168.111.10/24 (the client):
# uname -a
Linux mithril 2.6.39 #2 SMP PREEMPT Sun May 22 14:22:23 CEST 2011 i686 Intel(R)
Core(TM)2 CPU T7600 @ 2.33GHz GenuineIntel GNU/Linux
# tcpdump -n -i wlan0 udp and port 631
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
I made very sure that nothing is dropped by netfilter on either side.
Both sides use ath9k as their wifi driver.
Ortwin
^ permalink raw reply
* Re: PA-RISC: compile error in include/net/dst.h
From: WANG Cong @ 2011-05-22 14:13 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-parisc, stable, netdev
In-Reply-To: <2612811.b2htuyZy9x@donald.sf-tec.de>
(Cc netdev as well)
On Sun, 22 May 2011 10:15:19 +0200, Rolf Eike Beer wrote:
> from include/net/ipv6.h:16,
> from include/linux/sunrpc/clnt.h:25,
> from include/linux/nfs_fs.h:50,
> from init/do_mounts.c:20:
> include/net/dst.h: In function 'dst_hold': include/net/dst.h:238:2:
> error: size of unnamed array is negative In file included from
> include/linux/nfs_fs.h:59:0,
> from init/do_mounts.c:20:
Seems someone touched struct dst_entry...
> include/linux/mempool.h: In function 'mempool_create_kmalloc_pool':
> include/linux/mempool.h:58:10: warning: cast to pointer from integer of
> different size
>
> This is both in 2.6.38.6 and 2.6.39, but is not in 2.6.38.4 when
> compiling for my C8000.
>
> pioneer src # hppa64-unknown-linux-gnu-gcc --version
> hppa64-unknown-linux-gnu-gcc (Gentoo 4.5.2 p1.1) 4.5.2
>
> Greetings,
>
> Eike
^ 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