* [PATCH v4] smc91x: add devicetree support
From: Thomas Chou @ 2011-01-26 5:22 UTC (permalink / raw)
To: Grant Likely, David Miller
Cc: nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110125.194532.71125517.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Signed-off-by: Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
---
v2 specify part numbers in compat as Grant suggested.
v3 more specific part name.
v4 include match table only for OF as David suggested.
drivers/net/smc91x.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c
index 726df61..43654a3 100644
--- a/drivers/net/smc91x.c
+++ b/drivers/net/smc91x.c
@@ -81,6 +81,7 @@ static const char version[] =
#include <linux/ethtool.h>
#include <linux/mii.h>
#include <linux/workqueue.h>
+#include <linux/of.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
@@ -2394,6 +2395,15 @@ static int smc_drv_resume(struct device *dev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id smc91x_match[] = {
+ { .compatible = "smsc,lan91c94", },
+ { .compatible = "smsc,lan91c111", },
+ {},
+}
+MODULE_DEVICE_TABLE(of, smc91x_match);
+#endif
+
static struct dev_pm_ops smc_drv_pm_ops = {
.suspend = smc_drv_suspend,
.resume = smc_drv_resume,
@@ -2406,6 +2416,9 @@ static struct platform_driver smc_driver = {
.name = CARDNAME,
.owner = THIS_MODULE,
.pm = &smc_drv_pm_ops,
+#ifdef CONFIG_OF
+ .of_match_table = smc91x_match,
+#endif
},
};
--
1.7.3.5
^ permalink raw reply related
* Re: [PATCH v4] smc91x: add devicetree support
From: Grant Likely @ 2011-01-26 5:52 UTC (permalink / raw)
To: Thomas Chou
Cc: nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <1296019325-17801-1-git-send-email-thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
On Tue, Jan 25, 2011 at 10:22 PM, Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org> wrote:
> Signed-off-by: Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
> ---
> v2 specify part numbers in compat as Grant suggested.
> v3 more specific part name.
> v4 include match table only for OF as David suggested.
>
> drivers/net/smc91x.c | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
Looks okay to me.
Reviewed-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
>
> diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c
> index 726df61..43654a3 100644
> --- a/drivers/net/smc91x.c
> +++ b/drivers/net/smc91x.c
> @@ -81,6 +81,7 @@ static const char version[] =
> #include <linux/ethtool.h>
> #include <linux/mii.h>
> #include <linux/workqueue.h>
> +#include <linux/of.h>
>
> #include <linux/netdevice.h>
> #include <linux/etherdevice.h>
> @@ -2394,6 +2395,15 @@ static int smc_drv_resume(struct device *dev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id smc91x_match[] = {
> + { .compatible = "smsc,lan91c94", },
> + { .compatible = "smsc,lan91c111", },
> + {},
> +}
> +MODULE_DEVICE_TABLE(of, smc91x_match);
> +#endif
> +
> static struct dev_pm_ops smc_drv_pm_ops = {
> .suspend = smc_drv_suspend,
> .resume = smc_drv_resume,
> @@ -2406,6 +2416,9 @@ static struct platform_driver smc_driver = {
> .name = CARDNAME,
> .owner = THIS_MODULE,
> .pm = &smc_drv_pm_ops,
> +#ifdef CONFIG_OF
> + .of_match_table = smc91x_match,
> +#endif
> },
> };
>
> --
> 1.7.3.5
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH net-next 0/11] tg3: 5719, VLAN, and EEE bugfixes
From: Eric Dumazet @ 2011-01-26 6:14 UTC (permalink / raw)
To: David Miller; +Cc: mcarlson, netdev, andy
In-Reply-To: <20110125.193859.193720518.davem@davemloft.net>
Le mardi 25 janvier 2011 à 19:38 -0800, David Miller a écrit :
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Tue, 25 Jan 2011 17:58:46 -0800
>
> > This patchset implements bugfixes for the 5719, the VLAN code and
> > enhances EEE support.
>
> All applied to net-next-2.6, thanks.
>
> In particular, thanks for taking care of the vlan conversion.
> --
I tested the vlan patch on my machine, and it solves the problem I had
with linux-2.6
I believe this particular patch should be net-2.6 material, not
net-next-2.6
(There is a small rejected hunk)
Thanks !
^ permalink raw reply
* Re: [PATCH net-next 0/11] tg3: 5719, VLAN, and EEE bugfixes
From: David Miller @ 2011-01-26 6:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: mcarlson, netdev, andy
In-Reply-To: <1296022477.2633.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 26 Jan 2011 07:14:37 +0100
> I tested the vlan patch on my machine, and it solves the problem I had
> with linux-2.6
>
> I believe this particular patch should be net-2.6 material, not
> net-next-2.6
Agreed.
> (There is a small rejected hunk)
Matt, if you would send me a net-2.6 backport with your blessing
I'd appreciate it.
^ permalink raw reply
* Re: [PATCH v4] smc91x: add devicetree support
From: David Miller @ 2011-01-26 6:42 UTC (permalink / raw)
To: grant.likely-s3s/WqlpOiPyB63q8FvJNQ
Cc: nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTindbigYzY0zJufpr-D25m_B5Gjqp09ZbcaN-aZ9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Date: Tue, 25 Jan 2011 22:52:36 -0700
> On Tue, Jan 25, 2011 at 10:22 PM, Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org> wrote:
>> Signed-off-by: Thomas Chou <thomas-SDxUXYEhEBiCuPEqFHbRBg@public.gmane.org>
>> ---
>> v2 specify part numbers in compat as Grant suggested.
>> v3 more specific part name.
>> v4 include match table only for OF as David suggested.
>>
>> drivers/net/smc91x.c | 13 +++++++++++++
>> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> Looks okay to me.
>
> Reviewed-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* [PATCH net-2.6] bnx2: Eliminate AER error messages on systems not supporting it
From: Michael Chan @ 2011-01-26 8:14 UTC (permalink / raw)
To: davem; +Cc: leitao, netdev, Michael Chan
In-Reply-To: <1296029691-3591-1-git-send-email-mchan@broadcom.com>
On PPC for example, AER is not supported and we see unnecessary AER
error message without this patch:
bnx2 0003:01:00.1: pci_cleanup_aer_uncorrect_error_status failed 0xfffffffb
Reported-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 17 +++++++++--------
drivers/net/bnx2.h | 1 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 99e7652..62c6079 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -7966,11 +7966,8 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
/* AER (Advanced Error Reporting) hooks */
err = pci_enable_pcie_error_reporting(pdev);
- if (err) {
- dev_err(&pdev->dev, "pci_enable_pcie_error_reporting "
- "failed 0x%x\n", err);
- /* non-fatal, continue */
- }
+ if (!err)
+ bp->flags |= BNX2_FLAG_AER_ENABLED;
} else {
bp->pcix_cap = pci_find_capability(pdev, PCI_CAP_ID_PCIX);
@@ -8233,8 +8230,10 @@ bnx2_init_board(struct pci_dev *pdev, struct net_device *dev)
return 0;
err_out_unmap:
- if (bp->flags & BNX2_FLAG_PCIE)
+ if (bp->flags & BNX2_FLAG_AER_ENABLED) {
pci_disable_pcie_error_reporting(pdev);
+ bp->flags &= ~BNX2_FLAG_AER_ENABLED;
+ }
if (bp->regview) {
iounmap(bp->regview);
@@ -8422,8 +8421,10 @@ bnx2_remove_one(struct pci_dev *pdev)
kfree(bp->temp_stats_blk);
- if (bp->flags & BNX2_FLAG_PCIE)
+ if (bp->flags & BNX2_FLAG_AER_ENABLED) {
pci_disable_pcie_error_reporting(pdev);
+ bp->flags &= ~BNX2_FLAG_AER_ENABLED;
+ }
free_netdev(dev);
@@ -8539,7 +8540,7 @@ static pci_ers_result_t bnx2_io_slot_reset(struct pci_dev *pdev)
}
rtnl_unlock();
- if (!(bp->flags & BNX2_FLAG_PCIE))
+ if (!bp->flags & BNX2_FLAG_AER_ENABLED)
return result;
err = pci_cleanup_aer_uncorrect_error_status(pdev);
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index 5488a2e..f459fb2 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6741,6 +6741,7 @@ struct bnx2 {
#define BNX2_FLAG_JUMBO_BROKEN 0x00000800
#define BNX2_FLAG_CAN_KEEP_VLAN 0x00001000
#define BNX2_FLAG_BROKEN_STATS 0x00002000
+#define BNX2_FLAG_AER_ENABLED 0x00004000
struct bnx2_napi bnx2_napi[BNX2_MAX_MSIX_VEC];
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH net-2.6] cnic: Fix big endian bug
From: Michael Chan @ 2011-01-26 8:14 UTC (permalink / raw)
To: davem; +Cc: leitao, netdev, Michael Chan
The chip's page tables did not set up properly on big endian machines,
causing EEH errors on PPC machines.
Reported-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/cnic.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 263a294..7ff170c 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -699,13 +699,13 @@ static void cnic_free_dma(struct cnic_dev *dev, struct cnic_dma *dma)
static void cnic_setup_page_tbl(struct cnic_dev *dev, struct cnic_dma *dma)
{
int i;
- u32 *page_table = dma->pgtbl;
+ __le32 *page_table = (__le32 *) dma->pgtbl;
for (i = 0; i < dma->num_pages; i++) {
/* Each entry needs to be in big endian format. */
- *page_table = (u32) ((u64) dma->pg_map_arr[i] >> 32);
+ *page_table = cpu_to_le32((u64) dma->pg_map_arr[i] >> 32);
page_table++;
- *page_table = (u32) dma->pg_map_arr[i];
+ *page_table = cpu_to_le32(dma->pg_map_arr[i] & 0xffffffff);
page_table++;
}
}
@@ -713,13 +713,13 @@ static void cnic_setup_page_tbl(struct cnic_dev *dev, struct cnic_dma *dma)
static void cnic_setup_page_tbl_le(struct cnic_dev *dev, struct cnic_dma *dma)
{
int i;
- u32 *page_table = dma->pgtbl;
+ __le32 *page_table = (__le32 *) dma->pgtbl;
for (i = 0; i < dma->num_pages; i++) {
/* Each entry needs to be in little endian format. */
- *page_table = dma->pg_map_arr[i] & 0xffffffff;
+ *page_table = cpu_to_le32(dma->pg_map_arr[i] & 0xffffffff);
page_table++;
- *page_table = (u32) ((u64) dma->pg_map_arr[i] >> 32);
+ *page_table = cpu_to_le32((u64) dma->pg_map_arr[i] >> 32);
page_table++;
}
}
--
1.6.4.GIT
^ permalink raw reply related
* Re: [Bugme-new] [Bug 27212] New: Warning kmemcheck: Caught 64-bit read from uninitialized memory in netlink_broadcast_filtered
From: Eric Dumazet @ 2011-01-26 9:18 UTC (permalink / raw)
To: David Miller
Cc: netdev, bugzilla-daemon, bugme-daemon, casteyde.christian,
Andrew Morton
In-Reply-To: <20110120122549.85863a84.akpm@linux-foundation.org>
Le jeudi 20 janvier 2011 à 12:25 -0800, Andrew Morton a écrit :
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 20 Jan 2011 20:08:32 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > https://bugzilla.kernel.org/show_bug.cgi?id=27212
> >
> > Summary: Warning kmemcheck: Caught 64-bit read from
> > uninitialized memory in netlink_broadcast_filtered
> > Product: Other
> > Version: 2.5
> > Kernel Version: 2.6.38-rc1
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Other
> > AssignedTo: other_other@kernel-bugs.osdl.org
> > ReportedBy: casteyde.christian@free.fr
> > Regression: Yes
> >
> >
> > Athlon 64 X2 3000 in 64bits
> > Slackware64 13.1
> > Kernel compiled with kmemcheck and other debug options
> >
> > At boot I got the following warning:
> >
> > PCI: Using ACPI for IRQ routing
> > PCI: pci_cache_line_size set to 64 bytes
> > pci 0000:00:00.0: address space collision: [mem 0xe0000000-0xefffffff pref]
> > conflicts with GART [mem 0x
> > e0000000-0xefffffff]
> > reserve RAM buffer: 000000000009fc00 - 000000000009ffff
> > reserve RAM buffer: 000000003ffb0000 - 000000003fffffff
> > WARNING: kmemcheck: Caught 64-bit read from uninitialized memory
> > (ffff88003e170eb0)
> > 0000000000000000010000000000000000000000000000000000000000000000
> > i i i i i i i i i i i i u u u u u u u u u u u u u u u u u u u u
> > ^
> >
> > Pid: 1, comm: swapper Not tainted 2.6.38-rc1 #2 K8 Combo-Z/K8 Combo-Z
> > RIP: 0010:[<ffffffff8127ad72>] [<ffffffff8127ad72>] memmove+0x122/0x1a0
> > RSP: 0018:ffff88003e0b3c60 EFLAGS: 00010202
> > RAX: ffff88003e170080 RBX: ffff88003e27b500 RCX: 0000000000000020
> > RDX: 0000000000000018 RSI: ffff88003e170ea0 RDI: ffff88003e1700a0
> > RBP: ffff88003e0b3c60 R08: 0000000000000001 R09: 0000000000000001
> > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001
> > FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: ffff88003e018abc CR3: 0000000001a1c000 CR4: 00000000000006f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
> > [<ffffffff814741c2>] pskb_expand_head+0xc2/0x2a0
> > [<ffffffff81498fa7>] netlink_broadcast_filtered+0xa7/0x4a0
> > [<ffffffff814993b8>] netlink_broadcast+0x18/0x20
> > [<ffffffff8149b884>] genlmsg_mcast+0x144/0x180
> > [<ffffffff8149bc4a>] genl_ctrl_event+0xca/0x450
> > [<ffffffff8149c75d>] genl_register_mc_group+0x10d/0x2a0
> > [<ffffffff81ad9da4>] genl_init+0x6c/0x84
> > [<ffffffff810001de>] do_one_initcall+0x3e/0x170
> > [<ffffffff81aae6ea>] kernel_init+0x197/0x21b
> > [<ffffffff81003254>] kernel_thread_helper+0x4/0x10
> > [<ffffffffffffffff>] 0xffffffffffffffff
> > pnp: PnP ACPI init
> > ACPI: bus type pnp registered
> > pnp 00:00: [bus 00-ff]
> > pnp 00:00: [io 0x0cf8-0x0cff]
> >
> > This is specific to 2.6.38-rc1.
> >
[PATCH] net: add kmemcheck annotation in __alloc_skb()
pskb_expand_head() triggers a kmemcheck warning when copy of
skb_shared_info is done in pskb_expand_head()
This is because destructor_arg field is not necessarily initialized at
this point. Add kmemcheck_annotate_variable() call in __alloc_skb() to
instruct kmemcheck this is a normal situation.
Resolves bugzilla.kernel.org 27212
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=27212
Reported-by: Christian Casteyde <casteyde.christian@free.fr>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Andrew Morton <akpm@linux-foundation.org>
---
net/core/skbuff.c | 1 +
1 files changed, 1 insertion(+)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index d31bb36..1762e97 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -210,6 +210,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
shinfo = skb_shinfo(skb);
memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
atomic_set(&shinfo->dataref, 1);
+ kmemcheck_annotate_variable(shinfo->destructor_arg);
if (fclone) {
struct sk_buff *child = skb + 1;
^ permalink raw reply related
* Re: [PATCH v2 14/16] Intel net drivers: convert to ndo_fix_features
From: Jeff Kirsher @ 2011-01-26 9:47 UTC (permalink / raw)
To: Michał Mirosław; +Cc: davem, netdev, Ben Hutchings
In-Reply-To: <28a1c0f6e1ab9a523ee1e947ca4a013fd5730539.1295734271.git.mirq-linux@rere.qmqm.pl>
2011/1/22 Michał Mirosław <mirq-linux@rere.qmqm.pl>:
> Private rx_csum flags are now duplicate of netdev->features & NETIF_F_RXCSUM.
> Removing this needs deeper surgery.
>
> Since ixgbevf doesn't change hardware state on RX csum enable/disable
> its reset is avoided.
>
> Things noticed:
> - e1000, e1000e and ixgb have RX csum disabled by default
> - HW VLAN acceleration probably can be toggled, but it's left as is
> - the resets on RX csum offload change can probably be avoided
> - there is A LOT of copy-and-pasted code here
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
> drivers/net/e1000/e1000_ethtool.c | 69 ------------------------------------
> drivers/net/e1000/e1000_main.c | 30 +++++++++++++--
> drivers/net/e1000e/ethtool.c | 62 --------------------------------
> drivers/net/e1000e/netdev.c | 30 +++++++++++++--
> drivers/net/igb/igb_ethtool.c | 67 ----------------------------------
> drivers/net/igb/igb_main.c | 33 +++++++++++++----
> drivers/net/igbvf/ethtool.c | 57 -----------------------------
> drivers/net/igbvf/netdev.c | 25 ++++++++++---
> drivers/net/ixgb/ixgb.h | 2 +
> drivers/net/ixgb/ixgb_ethtool.c | 59 +------------------------------
> drivers/net/ixgb/ixgb_main.c | 31 ++++++++++++++--
> drivers/net/ixgbe/ixgbe_ethtool.c | 65 ---------------------------------
> drivers/net/ixgbe/ixgbe_main.c | 31 +++++++++++-----
> drivers/net/ixgbevf/ethtool.c | 46 ------------------------
> drivers/net/ixgbevf/ixgbevf_main.c | 26 +++++++++++---
> 15 files changed, 172 insertions(+), 461 deletions(-)
>
Upon initial reviews of the patch, we found issues with the e1000e
changes so far. We are working to put together a patch to resolve the
issues (and to do the conversion to ndo_fix_features). Based on the
initial work done by Michal, we can take care of the changes necessary
for the Intel Wired Ethernet drivers, and will wait for acceptance of
the net and ethtool changes before pushing the Intel patch. Is that
acceptable?
For e1000e, this patch breaks the ability to manually override the
default behavior of disabling TSO for 10/100, and there is some
additional cleanup that can be done w.r.t. Rx csum flags.
--
Cheers,
Jeff
^ permalink raw reply
* Watches Replica - Explore 5000+ Watches. Save on Watches Replicas!
From: Sunday Royce @ 2011-01-26 10:43 UTC (permalink / raw)
To: netdev
Watches Replica
Explore 5000+ Watches. Save on Watches Replicas!
http://topwatchgin.ru
^ permalink raw reply
* [PATCH] econet: remove compiler warnings
From: Eric Dumazet @ 2011-01-26 10:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev
net/econet/af_econet.c: In function ‘econet_sendmsg’:
net/econet/af_econet.c:494: warning: label ‘error’ defined but not used
net/econet/af_econet.c:268: warning: unused variable ‘sk’
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/econet/af_econet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/econet/af_econet.c b/net/econet/af_econet.c
index 15dcc1a..0c28263 100644
--- a/net/econet/af_econet.c
+++ b/net/econet/af_econet.c
@@ -265,13 +265,13 @@ static void ec_tx_done(struct sk_buff *skb, int result)
static int econet_sendmsg(struct kiocb *iocb, struct socket *sock,
struct msghdr *msg, size_t len)
{
- struct sock *sk = sock->sk;
struct sockaddr_ec *saddr=(struct sockaddr_ec *)msg->msg_name;
struct net_device *dev;
struct ec_addr addr;
int err;
unsigned char port, cb;
#if defined(CONFIG_ECONET_AUNUDP) || defined(CONFIG_ECONET_NATIVE)
+ struct sock *sk = sock->sk;
struct sk_buff *skb;
struct ec_cb *eb;
#endif
@@ -488,10 +488,10 @@ static int econet_sendmsg(struct kiocb *iocb, struct socket *sock,
error_free_buf:
vfree(userbuf);
+error:
#else
err = -EPROTOTYPE;
#endif
- error:
mutex_unlock(&econet_mutex);
return err;
^ permalink raw reply related
* [PATCH] dl2k: nulify fraginfo after unmap
From: Stanislaw Gruszka @ 2011-01-26 10:45 UTC (permalink / raw)
To: netdev
Patch fixes: "DMA-API: device driver tries to free an invalid DMA
memory address" warning reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=639824
Reported-by: Frantisek Hanzlik <franta@hanzlici.cz>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/dl2k.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dl2k.c b/drivers/net/dl2k.c
index e1a8216..c05db60 100644
--- a/drivers/net/dl2k.c
+++ b/drivers/net/dl2k.c
@@ -1753,8 +1753,6 @@ rio_close (struct net_device *dev)
/* Free all the skbuffs in the queue. */
for (i = 0; i < RX_RING_SIZE; i++) {
- np->rx_ring[i].status = 0;
- np->rx_ring[i].fraginfo = 0;
skb = np->rx_skbuff[i];
if (skb) {
pci_unmap_single(np->pdev,
@@ -1763,6 +1761,8 @@ rio_close (struct net_device *dev)
dev_kfree_skb (skb);
np->rx_skbuff[i] = NULL;
}
+ np->rx_ring[i].status = 0;
+ np->rx_ring[i].fraginfo = 0;
}
for (i = 0; i < TX_RING_SIZE; i++) {
skb = np->tx_skbuff[i];
--
1.7.3.4
^ permalink raw reply related
* Re: [patch] kconfig: unify GENERIC_ISA_DMA and ISA_DMA_API
From: Russell King - ARM Linux @ 2011-01-26 11:29 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Ralf Baechle, Kyle McMartin, James Bottomley,
Benjamin Herrenschmidt, Thomas Gleixner, H. Peter Anvin,
Ingo Molnar, David S. Miller, Greg Kroah-Hartman, Randy Dunlap,
x86, linux-arch, netdev, linux-scsi, linux-kernel
In-Reply-To: <alpine.DEB.2.00.1101251706040.9641@chino.kir.corp.google.com>
On Tue, Jan 25, 2011 at 05:06:28PM -0800, David Rientjes wrote:
> CONFIG_GENERIC_ISA_DMA and CONFIG_ISA_DMA_API usually have dependencies
> on one another depending on the architecture and generic kernel code uses
> either to determine whether an ISA-style DMA API is configured.
Wrong.
GENERIC_ISA_DMA enables support for the standard ISA DMA allocator found
in kernel/dma.c
ISA_DMA_API says that a platform supports the ISA DMA interfaces.
An architecture can provide the ISA DMA interfaces, but not use the
standard ISA DMA allocator found in kernel/dma.c. Such as the one in
arch/arm/kernel/dma.c.
So on ARM, we have platforms where ISA_DMA_API=y but GENERIC_ISA_DMA=n.
> This patch unifies both options and consolidates them into a single
> option: CONFIG_GENERIC_ISA_DMA. It is also a prerequisite for a 1% text
> savings for a future x86 patch that allows these options to be disabled
> on that architecture when CONFIG_ZONE_DMA also becomes configurable.
NAK. This is wrong.
^ permalink raw reply
* Re: [RFC 00/20] Proposal for remaining BKL users
From: Arnd Bergmann @ 2011-01-26 11:31 UTC (permalink / raw)
To: Greg KH
Cc: Mauro Carvalho Chehab, Frederic Weisbecker, dri-devel,
Mikulas Patocka, H. Peter Anvin, Ian Kent, linux-cifs,
Nick Bowler, linux-x25, Takahiro Hirofuchi, Ross Cohen,
Arnaldo Carvalho de Melo, Evgeniy Dushistov, Stuart Swales,
Thomas Gleixner, Arjan van de Ven, autofs, Jeff Layton, netdev,
linux-kernel, Palash Bandyopadhyay, linux-fsdevel, Andrew Morton
In-Reply-To: <20110126022223.GB28072@suse.de>
On Wednesday 26 January 2011, Greg KH wrote:
> On Tue, Jan 25, 2011 at 11:17:14PM +0100, Arnd Bergmann wrote:
> > I've gone through all the code in the kernel that
> > uses the big kernel lock and come up with a solution
> > that seems at least half-reasonable for each of them.
> >
> > The decisions are somewhat arbitrary, but here is
> > what I'd suggest we do:
> >
> > * Remove in 2.6.39:
> > i830, autofs3, smbfs
>
> I thought some people really wanted to keep i830. Or was that i810?
> I'll drop autofs3 and smbfs, thanks.
i810 needs to be kept, i830 is obsolete, see the patch changelogs
there. I assume that Dave Airlie will take both patches (i810 BKL
removal and i830 removal) into his 2.6.39 queue.
> > * Work around in an ugly way, but keep alive:
> > * ufs, ipx, i810, cx25721
> >
> > * Fix properly:
> > * usbip, go7007, adfs, x25
>
> Thanks for the usbip and go7007 patches, I'll queue them up.
It would be good if you could also take the cx25721 patch. It's
not the nicest one I've done, but it's a bug fix nonetheless.
Thanks,
Arnd
^ permalink raw reply
* Re: [PATCH 2/2] xen: netfront: Drop GSO SKBs which do not have csum_blank.
From: Ian Campbell @ 2011-01-26 11:56 UTC (permalink / raw)
To: David Miller
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
netdev@vger.kernel.org
In-Reply-To: <20110125.194405.226769333.davem@davemloft.net>
On Wed, 2011-01-26 at 03:44 +0000, David Miller wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Tue, 25 Jan 2011 17:10:00 +0000
>
> > The Linux network stack expects all GSO SKBs to have ip_summed ==
> > CHECKSUM_PARTIAL (which implies that the frame contains a partial
> > checksum) and the Xen network ring protocol similarly expects an SKB
> > which has GSO set to also have NETRX_csum_blank (which also implies a
> > partial checksum). Therefore drop such frames on receive otherwise
> > they will trigger the warning in skb_gso_segment.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> The GSO code does in fact warn in the logs about this situation, but
> it _DOES NOT_ drop the packet. Therefore, either you guys should do
> the same or we should make the generic code drop too.
Ah, yes. I misread the handling of an error from pskb_expand_head() in
skb_gso_segment() and thought it was a more general error return
covering the entire case.
> I think the generic code is doing the right thing, therefore what you
> should probably do is put the checksum of the SKB into the right state
> when you detect this situation (and perhaps bump a ethtool driver
> local statistic which specifically tracks this exact event).
Yes, I think this is a good idea. I'll come up with a patch which does
this.
> Or, even better, you should fix whatever causes this in the first
> place.
Sure, that has already been done but the proper fix is in another guest,
with a secondary robustness fix in netback (similar to this one, so I'll
take your advice from above on board in that context too).
The intention here was to be robust in the face of unfixed guests
sharing the same host or future netback bugs etc.
> Dropping frames ought to be the last option, stuff like this is
> impossible to debug if someone starts wondering why they are getting
> frame drops.
>
> You don't even account for this in a unique statistic somewhere, so
> people can figure out the actual spcific _reason_ for the drop. They
> will just see "rx_error" and scratch their heads.
>
> Anyways, I think dropping is fundamentally wrong, so I'm not applying
> this.
You've convinced me too, thanks for the feedback.
Thanks,
Ian.
^ permalink raw reply
* Re: [RFC 00/20] Proposal for remaining BKL users
From: Mauro Carvalho Chehab @ 2011-01-26 11:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Frederic Weisbecker, dri-devel, Mikulas Patocka, H. Peter Anvin,
Ian Kent, linux-cifs, Nick Bowler, linux-x25, Takahiro Hirofuchi,
Palash Bandyopadhyay, Ross Cohen, Arnaldo Carvalho de Melo,
Evgeniy Dushistov, Stuart Swales, Thomas Gleixner,
Arjan van de Ven, autofs, Jeff Layton, netdev, Greg KH,
linux-kernel, Palash Bandyopadhyay, linux-fsdevel
In-Reply-To: <201101261231.30390.arnd@arndb.de>
Em 26-01-2011 09:31, Arnd Bergmann escreveu:
> On Wednesday 26 January 2011, Greg KH wrote:
>> On Tue, Jan 25, 2011 at 11:17:14PM +0100, Arnd Bergmann wrote:
>>> I've gone through all the code in the kernel that
>>> uses the big kernel lock and come up with a solution
>>> that seems at least half-reasonable for each of them.
>>>
>>> The decisions are somewhat arbitrary, but here is
>>> what I'd suggest we do:
>>>
>>> * Remove in 2.6.39:
>>> i830, autofs3, smbfs
>>
>> I thought some people really wanted to keep i830. Or was that i810?
>> I'll drop autofs3 and smbfs, thanks.
>
> i810 needs to be kept, i830 is obsolete, see the patch changelogs
> there. I assume that Dave Airlie will take both patches (i810 BKL
> removal and i830 removal) into his 2.6.39 queue.
>
>>> * Work around in an ugly way, but keep alive:
>>> * ufs, ipx, i810, cx25721
>>>
>>> * Fix properly:
>>> * usbip, go7007, adfs, x25
>>
>> Thanks for the usbip and go7007 patches, I'll queue them up.
>
> It would be good if you could also take the cx25721 patch. It's
> not the nicest one I've done, but it's a bug fix nonetheless.
I guess you're meaning cx25821, right?
Palash should take a look on it and review. This is a device that allows
12 simultaneous streams, so, I suspect that he'll need to do some
changes at the locking schema, to avoid performance bottlenecks.
Cheers,
Mauro
^ permalink raw reply
* 40k+ outbound connections and bind() problem
From: denys @ 2011-01-26 12:14 UTC (permalink / raw)
To: netdev
I am running server (TCP accelerator), which is initiating more than
40K connections.
Each instance of server bound to separate IP, and each of them handling
around 5-10K connections.
At moments, when i have excessive connect/disconnect events if i try to
establish connection even from IP is not used,
during bind() i am getting errno "Address already in use".
What can be the issue?
Will it help if i increase in kernel hardcoded limit from 64K TCP bind
hash entries to higher values?
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: Daniel Baluta @ 2011-01-26 12:23 UTC (permalink / raw)
To: denys; +Cc: netdev
In-Reply-To: <8cdb2dde69120a8668b31e2050916493@visp.net.lb>
Hi,
On Wed, Jan 26, 2011 at 2:14 PM, <denys@visp.net.lb> wrote:
> I am running server (TCP accelerator), which is initiating more than 40K
> connections.
> Each instance of server bound to separate IP, and each of them handling
> around 5-10K connections.
> At moments, when i have excessive connect/disconnect events if i try to
> establish connection even from IP is not used,
> during bind() i am getting errno "Address already in use".
> What can be the issue?
> Will it help if i increase in kernel hardcoded limit from 64K TCP bind hash
> entries to higher values?
Please provide more information. What kernel version are you using?
Are you binding on a SO_REUSEADDR socket right?
thanks,
Daniel.
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: denys @ 2011-01-26 12:35 UTC (permalink / raw)
To: Daniel Baluta; +Cc: netdev
In-Reply-To: <AANLkTikSvf8bNK2_eHg+cWQJLz-56_88mrf0ttJX3W=0@mail.gmail.com>
On Wed, 26 Jan 2011 14:23:44 +0200, Daniel Baluta wrote:
> Hi,
>
> On Wed, Jan 26, 2011 at 2:14 PM, <denys@visp.net.lb> wrote:
>> I am running server (TCP accelerator), which is initiating more than
>> 40K
>> connections.
>> Each instance of server bound to separate IP, and each of them
>> handling
>> around 5-10K connections.
>> At moments, when i have excessive connect/disconnect events if i try
>> to
>> establish connection even from IP is not used,
>> during bind() i am getting errno "Address already in use".
>> What can be the issue?
>> Will it help if i increase in kernel hardcoded limit from 64K TCP
>> bind hash
>> entries to higher values?
>
> Please provide more information. What kernel version are you using?
> Are you binding on a SO_REUSEADDR socket right?
Latest stable, 2.6.37
No, but trying with it now. At same time i think it is not correct, if
i try to bind to "unused" for any connections IP, and it will return
such error.
It is not listening socket, it is outbound connection
s = socket(...)
memset(&name,0x0,sizeof(name));
name.sin_family=AF_INET;
name.sin_addr.s_addr=s_stx->src_ip;
name.sin_port=0;
bind()
connect()
Now i will try to put between socket and bind
setsockopt(netsocket,SOL_SOCKET,SO_REUSEADDR,(void*)&tmpint,sizeof(tmpint));
But IMHO it is not very correct for outgoing connections.
^ permalink raw reply
* RE: bnx2 cards intermittantly going offline
From: Mills, Tony @ 2011-01-26 12:44 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev@vger.kernel.org
In-Reply-To: <1295373358.8131.4.camel@HP1>
Hi, Thanks for your response.
I have done some further investigation and found that we have had a massive amount of interrupts occurring on our Broadcom cards, i have set the affinity for irq 36 and 48 to run on the first two vcpu's on the box and the java processes to run on the others. I have also replaced the debian bnx2 driver with the latest from the Broadcom website and made the rx ring buffer to 4080, this has stopped a multiplexed server running at 1.6 cycles per second from missing cycles due to interrupts on the interface and allowing much better processing time, and the ring buffer up at 4080 stops the rx_fw_discards i was seeing periodically, (even upping that to 1020 or 2040 did not sort the issue but the maximum setting from the Broadcom driver does.
I am now monitoring the system to see if the card ever becomes unresponsive. But i do have a question.
If i setup the smp_affinity with a mask of cpu 0 and 1 (the first two on the box) for the APIC-fasteoi irq's for the Ethernet devices, it appears that the kernel does not balance and will continue to use the same cpu to do the interrupts even though there is processing power on the other one. Is this a known issue or am i doing something wrong?
Can i add it's on an dell r610 with a 12 core intel Xeon X5680, this shows up as 24 vcpu's.
Best Regards
Tony Mills
-----Original Message-----
From: Michael Chan [mailto:mchan@broadcom.com]
Sent: 18 January 2011 17:56
To: Mills, Tony
Cc: netdev@vger.kernel.org
Subject: Re: bnx2 cards intermittantly going offline
On Tue, 2011-01-18 at 02:54 -0800, Mills, Tony wrote:
> Last night i setup a machine to monitor overnight and at 3:52 this
> morning it became unresponsive.
>
When it becomes unresponsive, please send some packets to the NIC (such
as ping) and monitor statistics with ethtool -S. See if the packets are
being received or discarded. Also, run tcpdump on the machine to see if
the packets are properly received by the stack. Thanks.
--
IMPORTANT NOTICE
The sender does not guarantee that this message, including any attachment, is secure
or virus free. Also, it is confidential and may be privileged or otherwise protected
from disclosure. If you are not the intended recipient, do not disclose or copy it
or its contents. Please telephone or email the sender and delete the message
entirely from your system.
Jagex Limited is a company registered in England & Wales with company number
03982706 and a registered office at St John's Innovation Centre, Cowley Road,
Cambridge, CB4 0WS, UK.
^ permalink raw reply
* Re: [PATCH 14/20] staging/appletalk: remove the BKL
From: Arnd Bergmann @ 2011-01-26 12:57 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, acme, netdev
In-Reply-To: <20110125.142926.246535705.davem@davemloft.net>
On Tuesday 25 January 2011, David Miller wrote:
> If you're moving appletalk to staging because "nobody is motivated
> enough to remove the BKL" and then you actually do the work to remove
> the BKL, I really don't see any point in doing the whole staging
> thing.
>
> We always keep an eye on every protocol that sits under the top-level
> net/. Every socket API change propagates, as does every other
> networking API change that matters for those protocols.
Ok, fair enough. I've removed the "move to staging" patch now from my
series. I'm going to need some help with testing, or at least thoroughly
reviewing the patch, since I am not extremely confident in my own work
there.
Arnd
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: Daniel Baluta @ 2011-01-26 13:00 UTC (permalink / raw)
To: denys; +Cc: netdev
In-Reply-To: <9e62acde19ef75f3f77468cd81ed7ffd@visp.net.lb>
Hi,
> Latest stable, 2.6.37
Please apply this patch [1] and see if it's still happening.
thanks,
Daniel
[1] http://www.spinics.net/lists/netdev/msg152204.html
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: Eric Dumazet @ 2011-01-26 13:17 UTC (permalink / raw)
To: Daniel Baluta; +Cc: denys, netdev
In-Reply-To: <AANLkTinDQ-n3Y2_8PtvdWSxkYV8Kvj8on3iEeHsBSFB-@mail.gmail.com>
Le mercredi 26 janvier 2011 à 15:00 +0200, Daniel Baluta a écrit :
> Hi,
>
> > Latest stable, 2.6.37
>
> Please apply this patch [1] and see if it's still happening.
>
> thanks,
> Daniel
>
> [1] http://www.spinics.net/lists/netdev/msg152204.html
> -
I dont think it'll help ;)
Denys problem is if one source IP address is used, there is an absolute
64K limit to (IP, port) tuple
Only thing you can do is to tune /proc/sys/net/ipv4/ip_local_port_range
to get close to 64K limit
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: denys @ 2011-01-26 13:23 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Daniel Baluta, netdev
In-Reply-To: <1296047834.2899.62.camel@edumazet-laptop>
On Wed, 26 Jan 2011 14:17:14 +0100, Eric Dumazet wrote:
> Le mercredi 26 janvier 2011 à 15:00 +0200, Daniel Baluta a écrit :
>> Hi,
>>
>> > Latest stable, 2.6.37
>>
>> Please apply this patch [1] and see if it's still happening.
>>
>> thanks,
>> Daniel
>>
>> [1] http://www.spinics.net/lists/netdev/msg152204.html
>> -
>
> I dont think it'll help ;)
>
> Denys problem is if one source IP address is used, there is an
> absolute
> 64K limit to (IP, port) tuple
>
> Only thing you can do is to tune
> /proc/sys/net/ipv4/ip_local_port_range
> to get close to 64K limit
No, it is not one ip source.
As i mention before, i am binding each instance to different IP before
connect().
And when i am having issues and such errors, i am trying httping and
binding it to some unused ip, but still getting this error.
^ permalink raw reply
* Re: 40k+ outbound connections and bind() problem
From: Eric Dumazet @ 2011-01-26 13:26 UTC (permalink / raw)
To: denys; +Cc: Daniel Baluta, netdev
In-Reply-To: <398df9351d5c9aec1ba69511d9dc6a70@visp.net.lb>
Le mercredi 26 janvier 2011 à 15:23 +0200, denys@visp.net.lb a écrit :
> On Wed, 26 Jan 2011 14:17:14 +0100, Eric Dumazet wrote:
> > Le mercredi 26 janvier 2011 à 15:00 +0200, Daniel Baluta a écrit :
> >> Hi,
> >>
> >> > Latest stable, 2.6.37
> >>
> >> Please apply this patch [1] and see if it's still happening.
> >>
> >> thanks,
> >> Daniel
> >>
> >> [1] http://www.spinics.net/lists/netdev/msg152204.html
> >> -
> >
> > I dont think it'll help ;)
> >
> > Denys problem is if one source IP address is used, there is an
> > absolute
> > 64K limit to (IP, port) tuple
> >
> > Only thing you can do is to tune
> > /proc/sys/net/ipv4/ip_local_port_range
> > to get close to 64K limit
> No, it is not one ip source.
> As i mention before, i am binding each instance to different IP before
> connect().
> And when i am having issues and such errors, i am trying httping and
> binding it to some unused ip, but still getting this error.
Ah OK, you definitely want to use REUSEADDR then.
^ 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