* Re: [PATCH] vlan: allow creating vlan when real device is not up
From: Patrick McHardy @ 2009-07-31 12:16 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20090730.131710.208062164.davem@davemloft.net>
David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 30 Jul 2009 11:23:21 -0700
>
>> There is no reason for the arbitrary restriction that device must be
>> up to create a vlan. This patch was added to Vyatta kernel to resolve startup
>> ordering issues where vlan's are created but real device was disabled.
>>
>> Note: the vlan already correctly inherits the operstate from real device; so
>> if vlan is created and real device is marked down, the vlan is marked
>> down.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Looks fine, added to net-next-2.6
>
> We can revert if Patrick or someone else finds a potential problem
> with allowing this.
It seems perfectly fine to me, we can get to the same state by
setting the lower device down after creating the VLAN device.
^ permalink raw reply
* [PATCH] sky2: Avoid transmits during sky2_down()
From: Mike McCormack @ 2009-07-31 11:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Hi Stephen,
This patch supersedes my previous patch "sky2: Avoid transmitting
during sky2_restart".
I have reworked the patch to avoid crashes during both sky2_restart()
and sky2_set_ringparam().
Without this patch, the sky2 driver can be crashed by doing:
# pktgen eth1 & (transmit many packets on eth1)
# ethtool -G eth1 tx 510
I am aware you object to storing extra state, but I can't see a way
around this. Without remembering that we're restarting,
netif_wake_queue() is called in the ISR from sky2_tx_complete(), and
netif_tx_lock() is used in sky2_tx_done(). If anybody can see a way
around this, please let me know.
thanks,
Mike
----
During sky2_restart() or sky2_set_ringparam(), the tx queue needs to be
shutdown in sky2_down() to avoid accessing a NULL tx_ring.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
---
drivers/net/sky2.c | 14 +++++++++++++-
drivers/net/sky2.h | 1 +
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 661abd0..1415a83 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -1488,6 +1488,8 @@ static int sky2_up(struct net_device *dev)
sky2_set_vlan_mode(hw, port, sky2->vlgrp != NULL);
#endif
+ sky2->restarting = 0;
+
err = sky2_rx_start(sky2);
if (err)
goto err_out;
@@ -1500,6 +1502,9 @@ static int sky2_up(struct net_device *dev)
sky2_set_multicast(dev);
+ /* wake queue incase we are restarting */
+ netif_wake_queue(dev);
+
if (netif_msg_ifup(sky2))
printk(KERN_INFO PFX "%s: enabling interface\n", dev->name);
return 0;
@@ -1533,6 +1538,8 @@ static inline int tx_dist(unsigned tail, unsigned head)
/* Number of list elements available for next tx */
static inline int tx_avail(const struct sky2_port *sky2)
{
+ if (unlikely(sky2->restarting))
+ return 0;
return sky2->tx_pending - tx_dist(sky2->tx_cons, sky2->tx_prod);
}
@@ -1818,6 +1825,10 @@ static int sky2_down(struct net_device *dev)
if (netif_msg_ifdown(sky2))
printk(KERN_INFO PFX "%s: disabling interface\n", dev->name);
+ /* explicitly shut off tx incase we're restarting */
+ sky2->restarting = 1;
+ netif_tx_disable(dev);
+
/* Force flow control off */
sky2_write8(hw, SK_REG(port, GMAC_CTRL), GMC_PAUSE_OFF);
@@ -2359,7 +2370,7 @@ static inline void sky2_tx_done(struct
net_device *dev, u16 last)
{
struct sky2_port *sky2 = netdev_priv(dev);
- if (netif_running(dev)) {
+ if (likely(netif_running(dev) && !sky2->restarting)) {
netif_tx_lock(dev);
sky2_tx_complete(sky2, last);
netif_tx_unlock(dev);
@@ -4283,6 +4294,7 @@ static __devinit struct net_device
*sky2_init_netdev(struct sky2_hw *hw,
spin_lock_init(&sky2->phy_lock);
sky2->tx_pending = TX_DEF_PENDING;
sky2->rx_pending = RX_DEF_PENDING;
+ sky2->restarting = 0;
hw->dev[port] = dev;
diff --git a/drivers/net/sky2.h b/drivers/net/sky2.h
index b5549c9..4486b06 100644
--- a/drivers/net/sky2.h
+++ b/drivers/net/sky2.h
@@ -2051,6 +2051,7 @@ struct sky2_port {
u8 duplex; /* DUPLEX_HALF, DUPLEX_FULL */
u8 rx_csum;
u8 wol;
+ u8 restarting;
enum flow_control flow_mode;
enum flow_control flow_status;
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] xfrm: select sane defaults for xfrm[4|6] gc_thresh
From: Neil Horman @ 2009-07-31 11:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090730.185316.110755605.davem@davemloft.net>
On Thu, Jul 30, 2009 at 06:53:16PM -0700, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Thu, 30 Jul 2009 21:11:30 -0400
>
> > Ok, version 2. I'm not sure exactly what went wrong, but I definately had it
> > built and running.
>
> As I said in my other email, the original patch does build and it
> probably runs too, it's just the warnings that you definitely didn't
> notice in the build at all.
>
> I've apply this new version, thanks.
>
Ah, that would explain it. Thanks for the update!
Neil
^ permalink raw reply
* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Oliver Hartkopp @ 2009-07-31 11:20 UTC (permalink / raw)
To: Dave Young; +Cc: Alan Cox, Marcel Holtmann, Linux Netdev List, linux-bluetooth
In-Reply-To: <a8e1da0907310310h483cedeeg433947d51345246c@mail.gmail.com>
Dave Young wrote:
> On Fri, Jul 31, 2009 at 5:39 PM, Dave Young<hidave.darkstar@gmail.com> wrote:
>> On Thu, Jul 30, 2009 at 12:05:55PM +0200, Oliver Hartkopp wrote:
>>> Dave Young wrote:
>>>> On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver@hartkopp.net> wrote:
>>>>> Hi Dave,
>>>>>
>>>>> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
>>>>> attached screenshot).
>>>> Weird, the oops occurs between sock init and tty init routines. Could
>>>> you tell your bluez version and your configuration?
>>>>
>>> No problem:
>> Thanks.
>>
>> It's still reasonable, after rfcomm sock layer initialized, userspace do sock ioctl callback but tty layer was not initilized yet at this time.
>>
>> Could you confirm it by applying following debug patch on top of my previous patch? if you get more oops with it then above reason will be right.
>>
>> --- linux-2.6.orig/net/bluetooth/rfcomm/core.c 2009-07-31 17:14:07.000000000 +0800
>> +++ linux-2.6/net/bluetooth/rfcomm/core.c 2009-07-31 17:30:39.000000000 +0800
>> @@ -36,6 +36,7 @@
>> #include <linux/net.h>
>> #include <linux/mutex.h>
>> #include <linux/kthread.h>
>> +#include <linux/nmi.h>
>>
>> #include <net/sock.h>
>> #include <asm/uaccess.h>
>> @@ -2080,7 +2081,7 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
>> /* ---- Initialization ---- */
>> static int __init rfcomm_init(void)
>> {
>> - int ret;
>> + int ret, i;
>>
>> l2cap_load();
>>
>> @@ -2088,6 +2089,12 @@ static int __init rfcomm_init(void)
>> if (ret)
>> goto out_sock;
>>
>> + /* delay 5 seconds to trigger the tty bug */
>> + for (i = 0; i < 50; i++) {
>> + touch_nmi_watchdog();
>> + mdelay(100);
>
> Hi, for this case, msleep is better, you can just replace the above
> two lines with msleep(100)
>
Hi Dave,
applied this patch and replaced mdelay(100) with msleep(100).
I got two crashes and three proper boots.
The crashes look like the formerly posted screenshots.
When it boots properly i can see the delay in the boot process.
Does this help?
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH V3] CAN: Add Flexcan CAN controller driver
From: Sascha Hauer @ 2009-07-31 11:20 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Socketcan-core, Linux Netdev List
In-Reply-To: <4A7200F3.3010608@grandegger.com>
On Thu, Jul 30, 2009 at 10:22:11PM +0200, Wolfgang Grandegger wrote:
> Wolfgang Grandegger wrote:
> > Sascha Hauer wrote:
> [...]
> >> errcnt = readl(®s->errcnt);
> >> rxerr = (errcnt >> 8) & 0xff;
> >> txerr = errcnt & 0xff;
> >> if ((rxerr >= 96 || txerr >= 96) && state == CAN_STATE_ERROR_ACTIVE)
> >> state = CAN_STATE_ERROR_WARNING;
> >
> > Yes, or do not handle the state in the "case 0" above appropriately. The
> > CAN spec only specifies the bus error states error active, error passive
> > and bus off. The warning is somehow optional but available on most CAN
> > controllers. Nevertheless, we should create a message if the ISR
> > realizes a state changes.
>
> FYI, I will be on holiday for the next 1.5 weeks.
Lucky you ;)
I just did some tests with the CAN cable disconnected. It turns out that
I get flooded by interrupts caused by ACK errors. The system is
completely unresponsive then. Unfortunately the ACK error interrupt
can't be disabled seperately, so we have to disable error interrupts
completely once we get an ACK error. I'm thinking about setting up a
timer and poll the error status register then.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Dave Young @ 2009-07-31 10:10 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Alan Cox, Marcel Holtmann, Linux Netdev List,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090731093949.GA4867@darkstar>
On Fri, Jul 31, 2009 at 5:39 PM, Dave Young<hidave.darkstar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Jul 30, 2009 at 12:05:55PM +0200, Oliver Hartkopp wrote:
>> Dave Young wrote:
>> > On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver@hartkopp.net> wrote:
>> >> Hi Dave,
>> >>
>> >> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
>> >> attached screenshot).
>> >
>> > Weird, the oops occurs between sock init and tty init routines. Could
>> > you tell your bluez version and your configuration?
>> >
>>
>> No problem:
>
> Thanks.
>
> It's still reasonable, after rfcomm sock layer initialized, userspace do sock ioctl callback but tty layer was not initilized yet at this time.
>
> Could you confirm it by applying following debug patch on top of my previous patch? if you get more oops with it then above reason will be right.
>
> --- linux-2.6.orig/net/bluetooth/rfcomm/core.c 2009-07-31 17:14:07.000000000 +0800
> +++ linux-2.6/net/bluetooth/rfcomm/core.c 2009-07-31 17:30:39.000000000 +0800
> @@ -36,6 +36,7 @@
> #include <linux/net.h>
> #include <linux/mutex.h>
> #include <linux/kthread.h>
> +#include <linux/nmi.h>
>
> #include <net/sock.h>
> #include <asm/uaccess.h>
> @@ -2080,7 +2081,7 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
> /* ---- Initialization ---- */
> static int __init rfcomm_init(void)
> {
> - int ret;
> + int ret, i;
>
> l2cap_load();
>
> @@ -2088,6 +2089,12 @@ static int __init rfcomm_init(void)
> if (ret)
> goto out_sock;
>
> + /* delay 5 seconds to trigger the tty bug */
> + for (i = 0; i < 50; i++) {
> + touch_nmi_watchdog();
> + mdelay(100);
Hi, for this case, msleep is better, you can just replace the above
two lines with msleep(100)
> + }
> +
> ret = rfcomm_init_ttys();
> if (ret)
> goto out_tty;
>
--
Regards
dave
^ permalink raw reply
* Re: tty_register_device NULL pointer dereference in 2.6.31-rc4
From: Dave Young @ 2009-07-31 9:39 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Alan Cox, Marcel Holtmann, Linux Netdev List,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4A717083.5090101-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
On Thu, Jul 30, 2009 at 12:05:55PM +0200, Oliver Hartkopp wrote:
> Dave Young wrote:
> > On Wed, Jul 29, 2009 at 10:00 PM, Oliver Hartkopp<oliver-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> wrote:
> >> Hi Dave,
> >>
> >> i got it again - even with your patch (that's why it's 2.6.31-rc4-dirty in the
> >> attached screenshot).
> >
> > Weird, the oops occurs between sock init and tty init routines. Could
> > you tell your bluez version and your configuration?
> >
>
> No problem:
Thanks.
It's still reasonable, after rfcomm sock layer initialized, userspace do sock ioctl callback but tty layer was not initilized yet at this time.
Could you confirm it by applying following debug patch on top of my previous patch? if you get more oops with it then above reason will be right.
--- linux-2.6.orig/net/bluetooth/rfcomm/core.c 2009-07-31 17:14:07.000000000 +0800
+++ linux-2.6/net/bluetooth/rfcomm/core.c 2009-07-31 17:30:39.000000000 +0800
@@ -36,6 +36,7 @@
#include <linux/net.h>
#include <linux/mutex.h>
#include <linux/kthread.h>
+#include <linux/nmi.h>
#include <net/sock.h>
#include <asm/uaccess.h>
@@ -2080,7 +2081,7 @@ static CLASS_ATTR(rfcomm_dlc, S_IRUGO, r
/* ---- Initialization ---- */
static int __init rfcomm_init(void)
{
- int ret;
+ int ret, i;
l2cap_load();
@@ -2088,6 +2089,12 @@ static int __init rfcomm_init(void)
if (ret)
goto out_sock;
+ /* delay 5 seconds to trigger the tty bug */
+ for (i = 0; i < 50; i++) {
+ touch_nmi_watchdog();
+ mdelay(100);
+ }
+
ret = rfcomm_init_ttys();
if (ret)
goto out_tty;
^ permalink raw reply
* [PATCH 2/2 net-next-2.6] cxgb3: fix Gen2 pci default settings
From: Divy Le Ray @ 2009-07-31 7:23 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20090731072334.4325.34323.stgit@speedy5>
From: Divy Le Ray <divy@chelsio.com>
Modify control register settings to accommodate the bridge's max read requset
size.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/t3_hw.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index e78d341..526e144 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -3465,7 +3465,7 @@ static void config_pcie(struct adapter *adap)
{201, 321, 258, 450, 834, 1602}
};
- u16 val;
+ u16 val, devid;
unsigned int log2_width, pldsize;
unsigned int fst_trn_rx, fst_trn_tx, acklat, rpllmt;
@@ -3473,6 +3473,17 @@ static void config_pcie(struct adapter *adap)
adap->params.pci.pcie_cap_addr + PCI_EXP_DEVCTL,
&val);
pldsize = (val & PCI_EXP_DEVCTL_PAYLOAD) >> 5;
+
+ pci_read_config_word(adap->pdev, 0x2, &devid);
+ if (devid == 0x37) {
+ pci_write_config_word(adap->pdev,
+ adap->params.pci.pcie_cap_addr +
+ PCI_EXP_DEVCTL,
+ val & ~PCI_EXP_DEVCTL_READRQ &
+ ~PCI_EXP_DEVCTL_PAYLOAD);
+ pldsize = 0;
+ }
+
pci_read_config_word(adap->pdev,
adap->params.pci.pcie_cap_addr + PCI_EXP_LNKCTL,
&val);
^ permalink raw reply related
* [PATCH 1/2 net-next-2.6] cxgb3: fix EDC filename string
From: Divy Le Ray @ 2009-07-31 7:23 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, swise
From: Divy Le Ray <divy@chelsio.com>
Fix a cut'n paste error in the AEL2020 twinax EDC file name
Signed-off-by: Divy Le Ray <divy@chelsio.com>
---
drivers/net/cxgb3/cxgb3_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index ec05149..8b3e76c 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -993,7 +993,7 @@ static int bind_qsets(struct adapter *adap)
#define TPSRAM_NAME "cxgb3/t3%c_psram-%d.%d.%d.bin"
#define AEL2005_OPT_EDC_NAME "cxgb3/ael2005_opt_edc.bin"
#define AEL2005_TWX_EDC_NAME "cxgb3/ael2005_twx_edc.bin"
-#define AEL2020_TWX_EDC_NAME "cxgb3/ael2005_twx_edc.bin"
+#define AEL2020_TWX_EDC_NAME "cxgb3/ael2020_twx_edc.bin"
static inline const char *get_edc_fw_name(int edc_idx)
{
^ permalink raw reply related
* Re: pull request: wireless-next-2.6 2009-07-29
From: David Miller @ 2009-07-31 2:30 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090729205423.GC10056@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 29 Jul 2009 16:54:23 -0400
> Here is another batch of wireless bits intended for 2.6.32... Once
> again, there is no particular theme to the bunch. This does cover the
> usual round of driver updates for iwlwifi, ath9k, and others. There are
> also some mac80211 and cfg80211 updates, including the final piece for
> cfg80211 to supplant wireless extensions -- hooray!
...
> P.S. There is a merge-test branch that contains sample merge conflict
> resolutions. They are mostly simple.
Pulled this in after doing a merge. Will push out after some
build checks.
Thanks!
^ permalink raw reply
* Re: [net-2.6 PATCH 3/3] ixgbe: Fix RSC completion delay causing Rx interrupts to stop
From: David Miller @ 2009-07-31 2:29 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, peter.p.waskiewicz.jr
In-Reply-To: <20090730222559.26121.13496.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 30 Jul 2009 15:26:00 -0700
> When a user disables interrupt throttling with ethtool on 82599 devices,
> the interrupt timer may not be re-enabled if hardware RSC is running. The
> RSC completions in hardware don't complete before the next ITR event tries
> to fire, so the ITR timer never gets re-armed. This patch increases the
> amount of time between interrupts when throttling is disabled (rx-usecs =
> 0) when the hardware RSC deature is enabled.
>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/3] ixgbe: Fix usage of second flags bitmap when using LRO/RSC
From: David Miller @ 2009-07-31 2:29 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, peter.p.waskiewicz.jr, mallikarjuna.chilakala
In-Reply-To: <20090730222528.26121.30521.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 30 Jul 2009 15:25:28 -0700
> A second set of feature flag bits was added, and the hardware RSC engine
> flags were moved there. However, the code itself didn't make the move
> completely to use the new bitmap.
>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Acked-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/3] ixgbe: Fix netpoll to be properly multiqueue aware
From: David Miller @ 2009-07-31 2:28 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, peter.p.waskiewicz.jr
In-Reply-To: <20090730222501.26121.2952.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 30 Jul 2009 15:25:09 -0700
> Our ndo_poll_controller callback is broken for anything but non-multiqueue
> setups. This fixes that issue.
>
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] xfrm: select sane defaults for xfrm[4|6] gc_thresh
From: David Miller @ 2009-07-31 1:53 UTC (permalink / raw)
To: nhorman; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090731011130.GA16769@localhost.localdomain>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 30 Jul 2009 21:11:30 -0400
> Ok, version 2. I'm not sure exactly what went wrong, but I definately had it
> built and running.
As I said in my other email, the original patch does build and it
probably runs too, it's just the warnings that you definitely didn't
notice in the build at all.
I've apply this new version, thanks.
^ permalink raw reply
* Re: [PATCH] xfrm: select sane defaults for xfrm[4|6] gc_thresh
From: David Miller @ 2009-07-31 1:34 UTC (permalink / raw)
To: nhorman; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090731001102.GA6068@localhost.localdomain>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 30 Jul 2009 20:11:02 -0400
> On Thu, Jul 30, 2009 at 02:25:54PM -0700, David Miller wrote:
>> From: David Miller <davem@davemloft.net>
>> Date: Thu, 30 Jul 2009 14:23:45 -0700 (PDT)
>>
>> Actually I had to revert, how the heck did you build test
>> this? :-/
>>
>> In file included from include/net/xfrm.h:21,
>> from net/ipv4/af_inet.c:113:
>> include/net/ip6_fib.h:28:1: warning: "FIB_TABLE_HASHSZ" redefined
>> In file included from net/ipv4/af_inet.c:102:
>> include/net/ip_fib.h:134:1: warning: this is the location of the previous definition
>>
>
> Thats bizzare, I've got it running on a system here at Red Hat if you want to
> take a look, it definatley built for me. Sorry about that, let me figure out
> what went south and I'll repost.
Sorry, bad phrasing on my part. It built, it just spits out those
warnings because ipv4 and ipv6 use the same macro name and it
gets redefined.
^ permalink raw reply
* Re: Bonding ALB sends bogus packets
From: Mark Smith @ 2009-07-31 1:30 UTC (permalink / raw)
To: Rick Jones
Cc: Stephen Hemminger, Jay Vosburgh, Ben Greear, bonding-devel,
netdev
In-Reply-To: <4A72314C.9080007@hp.com>
Hi Rick,
On Thu, 30 Jul 2009 16:48:28 -0700
Rick Jones <rick.jones2@hp.com> wrote:
> Mark Smith wrote:
> >
> > ETH_P_LOOP should probably have been avoided, as "LOOP" or "loopback"
> > is commonly used to refer to the Ethernet Configuration Testing
> > Protocol (google search for "Ethernet Loop protocol").
>
> I wonder how that relates to linkloop:
>
> http://sourceforge.net/projects/linkloop/
>
> http://fr2.rpmfind.net/linux/RPM/opensuse/factory/x86_64/usr_share_doc_packages_linkloop_Tree.html
>
> >
> > I'd suggest not using any form of ARP for this purpose. It'd place an
> > IPv4 requirement on the bonded interface, and various "empty" ARP
> > frames have meaning e.g. duplicate address detection. 802.2 test frames
> > or the original Ethernet V2.0 Configuration Testing Protocol have been
> > used for this bridge table address refresh purpose in the past.
>
> I can never remember if linkloop uses XID or Test frames :(
>
>From memory when I looked into it a year or so ago, linkloop
used 802.2 test frames.
When I decided to have a go at implementing ECTP for the Linux kernel
a couple of years ago, one thing I didn't want to was to duplicate
already existing layer 2 testing functionality in the kernel, which
meant comparing 802.2 test frames capability verses ECTP. 802.2 test
frames only do single hop unicast request/reply testing, obviously
requiring you to already know the test unicast address. ECTP, in
addition, provides broadcast and optionally multicast ECTP capable node
discovery, and the ability test a path of nodes, by providing a list of
unicast addresses to visit i.e. a strict source route. As I've found
IPv4 'broadcast pings' occasionally useful, I thought a layer 2
equivalent, not requiring IPv4 to be functioning, would also be quite
useful.
ECTP could also probably be used over any 802.2 capable network, by
using the SNAP encoding with an OUI of 0x000000 and then a protocol ID
of 0x9000.
(When you start looking into it, it's interesting how many layer 2
keepalive/testing protocols have been developed over the years,
including most recently the Ethernet OAM protocols. What is also
suprising is that the original Ethernet V2.0 Configuration Testing
Protocol tends to be more capable than any of them - they're usually
just single-hop request/reply testing)
Regards,
Mark.
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Herbert Xu @ 2009-07-31 1:30 UTC (permalink / raw)
To: Neil Horman; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090730010639.GB4169@localhost.localdomain>
On Wed, Jul 29, 2009 at 09:06:39PM -0400, Neil Horman wrote:
>
> but nothing in that path takes the xmit_lock. The poll_lock is taken in that
> patch, but thats for recieve_side syncronization, not transmit side. Nothing in
> the tg3 driver (to use your example), that I can see takes the xmit_lock in the
> rx path either, so I'm not really sure where you comming from here.
tg3_poll => tg3_poll_work => tg3_tx => netif_tx_lock
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: netpoll + xmit_lock == deadlock
From: Herbert Xu @ 2009-07-31 1:27 UTC (permalink / raw)
To: Neil Horman; +Cc: Matt Mackall, David S. Miller, netdev, Matt Carlson
In-Reply-To: <20090730010222.GA4169@localhost.localdomain>
On Wed, Jul 29, 2009 at 09:02:22PM -0400, Neil Horman wrote:
>
> Under what conditions do you try to take the xmit_lock from within a drivers
> ->poll routine? Do you have an example?
tg3
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] xfrm: select sane defaults for xfrm[4|6] gc_thresh
From: Neil Horman @ 2009-07-31 1:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090730.142554.103113174.davem@davemloft.net>
On Thu, Jul 30, 2009 at 02:25:54PM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 30 Jul 2009 14:23:45 -0700 (PDT)
>
> > From: Neil Horman <nhorman@tuxdriver.com>
> > Date: Tue, 28 Jul 2009 20:34:33 -0400
> >
> >> Choose saner defaults for xfrm[4|6] gc_thresh values on init
> >
> > Looks great, applied to net-next-2.6
>
> Actually I had to revert, how the heck did you build test
> this? :-/
>
> In file included from include/net/xfrm.h:21,
> from net/ipv4/af_inet.c:113:
> include/net/ip6_fib.h:28:1: warning: "FIB_TABLE_HASHSZ" redefined
> In file included from net/ipv4/af_inet.c:102:
> include/net/ip_fib.h:134:1: warning: this is the location of the previous definition
>
Ok, version 2. I'm not sure exactly what went wrong, but I definately had it
built and running. My best guess is that I did a partial build in a tree, and
the dependency check decided that the ipv4 code didn't need to be rebuilt, and
so I didn't get the error. Anywho, The problem is that the ipv4 code had
FIB_TABLE_HASHSZ defined globally, which was causing namespace clashes with my
changes (which moved the privately ipv6 defined FIB_TABLE_HASHSZ to a global
visibility). I've fixed it by modifying the IPv6 definition and uses to be
FIB6_TABLE_HASHSZ. I just tested it (with a clean build), and it works fine.
Apologies for the noise.
Neil
Choose saner defaults for xfrm[4|6] gc_thresh values on init
Currently, the xfrm[4|6] code has hard-coded initial gc_thresh values (set to
1024). Given that the ipv4 and ipv6 routing caches are sized dynamically at
boot time, the static selections can be non-sensical. This patch dynamically
selects an appropriate gc threshold based on the corresponding main routing
table size, using the assumption that we should in the worst case be able to
handle as many connections as the routing table can.
For ipv4, the maximum route cache size is 16 * the number of hash buckets in the
route cache. Given that xfrm4 starts garbage collection at the gc_thresh and
prevents new allocations at 2 * gc_thresh, we set gc_thresh to half the maximum
route cache size.
For ipv6, its a bit trickier. there is no maximum route cache size, but the
ipv6 dst_ops gc_thresh is statically set to 1024. It seems sane to select a
simmilar gc_thresh for the xfrm6 code that is half the number of hash buckets in
the v6 route cache times 16 (like the v4 code does).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
include/net/ip6_fib.h | 6 ++++++
include/net/xfrm.h | 2 +-
net/ipv4/route.c | 2 +-
net/ipv4/xfrm4_policy.c | 13 ++++++++++++-
net/ipv6/ip6_fib.c | 16 +++++-----------
net/ipv6/xfrm6_policy.c | 15 +++++++++++++++
6 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 7c5c0f7..15b492a 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -22,6 +22,12 @@
#include <net/flow.h>
#include <net/netlink.h>
+#ifdef CONFIG_IPV6_MULTIPLE_TABLES
+#define FIB6_TABLE_HASHSZ 256
+#else
+#define FIB6_TABLE_HASHSZ 1
+#endif
+
struct rt6_info;
struct fib6_config
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 9e3a3f4..223e90a 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1280,7 +1280,7 @@ struct xfrm6_tunnel {
};
extern void xfrm_init(void);
-extern void xfrm4_init(void);
+extern void xfrm4_init(int rt_hash_size);
extern int xfrm_state_init(struct net *net);
extern void xfrm_state_fini(struct net *net);
extern void xfrm4_state_init(void);
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 278f46f..fafbe16 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -3442,7 +3442,7 @@ int __init ip_rt_init(void)
printk(KERN_ERR "Unable to create route proc files\n");
#ifdef CONFIG_XFRM
xfrm_init();
- xfrm4_init();
+ xfrm4_init(ip_rt_max_size);
#endif
rtnl_register(PF_INET, RTM_GETROUTE, inet_rtm_getroute, NULL);
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index 018ac8b..00f7f80 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -290,10 +290,21 @@ static void __exit xfrm4_policy_fini(void)
xfrm_policy_unregister_afinfo(&xfrm4_policy_afinfo);
}
-void __init xfrm4_init(void)
+void __init xfrm4_init(int rt_max_size)
{
xfrm4_state_init();
xfrm4_policy_init();
+ /*
+ * Select a default value for the gc_thresh based on the main route
+ * table hash size. It seems to me the worst case scenario is when
+ * we have ipsec operating in transport mode, in which we create a
+ * dst_entry per socket. The xfrm gc algorithm starts trying to remove
+ * entries at gc_thresh, and prevents new allocations as 2*gc_thresh
+ * so lets set an initial xfrm gc_thresh value at the rt_max_size/2.
+ * That will let us store an ipsec connection per route table entry,
+ * and start cleaning when were 1/2 full
+ */
+ xfrm4_dst_ops.gc_thresh = rt_max_size/2;
sysctl_hdr = register_net_sysctl_table(&init_net, net_ipv4_ctl_path,
xfrm4_policy_table);
}
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 52ee1dc..0e93ca5 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -164,12 +164,6 @@ static __inline__ void rt6_release(struct rt6_info *rt)
dst_free(&rt->u.dst);
}
-#ifdef CONFIG_IPV6_MULTIPLE_TABLES
-#define FIB_TABLE_HASHSZ 256
-#else
-#define FIB_TABLE_HASHSZ 1
-#endif
-
static void fib6_link_table(struct net *net, struct fib6_table *tb)
{
unsigned int h;
@@ -180,7 +174,7 @@ static void fib6_link_table(struct net *net, struct fib6_table *tb)
*/
rwlock_init(&tb->tb6_lock);
- h = tb->tb6_id & (FIB_TABLE_HASHSZ - 1);
+ h = tb->tb6_id & (FIB6_TABLE_HASHSZ - 1);
/*
* No protection necessary, this is the only list mutatation
@@ -231,7 +225,7 @@ struct fib6_table *fib6_get_table(struct net *net, u32 id)
if (id == 0)
id = RT6_TABLE_MAIN;
- h = id & (FIB_TABLE_HASHSZ - 1);
+ h = id & (FIB6_TABLE_HASHSZ - 1);
rcu_read_lock();
head = &net->ipv6.fib_table_hash[h];
hlist_for_each_entry_rcu(tb, node, head, tb6_hlist) {
@@ -382,7 +376,7 @@ static int inet6_dump_fib(struct sk_buff *skb, struct netlink_callback *cb)
arg.net = net;
w->args = &arg;
- for (h = s_h; h < FIB_TABLE_HASHSZ; h++, s_e = 0) {
+ for (h = s_h; h < FIB6_TABLE_HASHSZ; h++, s_e = 0) {
e = 0;
head = &net->ipv6.fib_table_hash[h];
hlist_for_each_entry(tb, node, head, tb6_hlist) {
@@ -1368,7 +1362,7 @@ void fib6_clean_all(struct net *net, int (*func)(struct rt6_info *, void *arg),
unsigned int h;
rcu_read_lock();
- for (h = 0; h < FIB_TABLE_HASHSZ; h++) {
+ for (h = 0; h < FIB6_TABLE_HASHSZ; h++) {
head = &net->ipv6.fib_table_hash[h];
hlist_for_each_entry_rcu(table, node, head, tb6_hlist) {
write_lock_bh(&table->tb6_lock);
@@ -1483,7 +1477,7 @@ static int fib6_net_init(struct net *net)
if (!net->ipv6.rt6_stats)
goto out_timer;
- net->ipv6.fib_table_hash = kcalloc(FIB_TABLE_HASHSZ,
+ net->ipv6.fib_table_hash = kcalloc(FIB6_TABLE_HASHSZ,
sizeof(*net->ipv6.fib_table_hash),
GFP_KERNEL);
if (!net->ipv6.fib_table_hash)
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 4acc308..4df7da6 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -323,6 +323,7 @@ static struct ctl_table_header *sysctl_hdr;
int __init xfrm6_init(void)
{
int ret;
+ unsigned int gc_thresh;
ret = xfrm6_policy_init();
if (ret)
@@ -331,6 +332,20 @@ int __init xfrm6_init(void)
ret = xfrm6_state_init();
if (ret)
goto out_policy;
+ /*
+ * We need a good default value for the xfrm6 gc threshold.
+ * In ipv4 we set it to the route hash table size * 8, which
+ * is half the size of the maximaum route cache for ipv4. It
+ * would be good to do the same thing for v6, except the table is
+ * constructed differently here. Here each table for a net namespace
+ * can have FIB_TABLE_HASHSZ entries, so lets go with the same
+ * computation that we used for ipv4 here. Also, lets keep the initial
+ * gc_thresh to a minimum of 1024, since, the ipv6 route cache defaults
+ * to that as a minimum as well
+ */
+ gc_thresh = FIB6_TABLE_HASHSZ * 8;
+ xfrm6_dst_ops.gc_thresh = (gc_thresh < 1024) ? 1024 : gc_thresh;
+
sysctl_hdr = register_net_sysctl_table(&init_net, net_ipv6_ctl_path,
xfrm6_policy_table);
out:
^ permalink raw reply related
* Re: [PATCH 1/4] [atm] fixed faulty check
From: Nathan Williams @ 2009-07-31 0:22 UTC (permalink / raw)
To: Stoyan Gaydarov; +Cc: linux-kernel, chas, David.Woodhouse, netdev
In-Reply-To: <1248949491-20796-1-git-send-email-sgayda2@uiuc.edu>
Stoyan Gaydarov wrote:
> This patche fixes a spelling error that has resulted from copy and pasting. The location of the error was found using a semantic patch but the semantic patch was not trying to find these errors. After looking things over it seemed logical that this change was needed. Please review it and then include the patch if it is in fact the correct change.
>
> Signed-off-by: Stoyan Gaydarov <sgayda2@uiuc.edu>
> ---
> drivers/atm/solos-pci.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
> index 9359613..307321b 100644
> --- a/drivers/atm/solos-pci.c
> +++ b/drivers/atm/solos-pci.c
> @@ -372,7 +372,7 @@ static int process_status(struct solos_card *card, int port, struct sk_buff *skb
> }
>
> snr = next_string(skb);
> - if (!str)
> + if (!snr)
> return -EIO;
> attn = next_string(skb);
> if (!attn)
Thanks Stoyan. Julia Lawall found this error a few days ago, which has been applied to net-next-2.6.
^ permalink raw reply
* Re: [PATCH] xfrm: select sane defaults for xfrm[4|6] gc_thresh
From: Neil Horman @ 2009-07-31 0:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20090730.142554.103113174.davem@davemloft.net>
On Thu, Jul 30, 2009 at 02:25:54PM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 30 Jul 2009 14:23:45 -0700 (PDT)
>
> > From: Neil Horman <nhorman@tuxdriver.com>
> > Date: Tue, 28 Jul 2009 20:34:33 -0400
> >
> >> Choose saner defaults for xfrm[4|6] gc_thresh values on init
> >
> > Looks great, applied to net-next-2.6
>
> Actually I had to revert, how the heck did you build test
> this? :-/
>
> In file included from include/net/xfrm.h:21,
> from net/ipv4/af_inet.c:113:
> include/net/ip6_fib.h:28:1: warning: "FIB_TABLE_HASHSZ" redefined
> In file included from net/ipv4/af_inet.c:102:
> include/net/ip_fib.h:134:1: warning: this is the location of the previous definition
>
Thats bizzare, I've got it running on a system here at Red Hat if you want to
take a look, it definatley built for me. Sorry about that, let me figure out
what went south and I'll repost.
Neil
^ permalink raw reply
* Re: Bonding ALB sends bogus packets
From: Rick Jones @ 2009-07-30 23:48 UTC (permalink / raw)
To: Mark Smith
Cc: Stephen Hemminger, Jay Vosburgh, Ben Greear, bonding-devel,
netdev
In-Reply-To: <20090731090658.db36b555.lk-netdev@lk-netdev.nosense.org>
Mark Smith wrote:
>
> ETH_P_LOOP should probably have been avoided, as "LOOP" or "loopback"
> is commonly used to refer to the Ethernet Configuration Testing
> Protocol (google search for "Ethernet Loop protocol").
I wonder how that relates to linkloop:
http://sourceforge.net/projects/linkloop/
http://fr2.rpmfind.net/linux/RPM/opensuse/factory/x86_64/usr_share_doc_packages_linkloop_Tree.html
>
> I'd suggest not using any form of ARP for this purpose. It'd place an
> IPv4 requirement on the bonded interface, and various "empty" ARP
> frames have meaning e.g. duplicate address detection. 802.2 test frames
> or the original Ethernet V2.0 Configuration Testing Protocol have been
> used for this bridge table address refresh purpose in the past.
I can never remember if linkloop uses XID or Test frames :(
rick jones
^ permalink raw reply
* Re: Bonding ALB sends bogus packets
From: Mark Smith @ 2009-07-30 23:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jay Vosburgh, Ben Greear, bonding-devel, netdev
In-Reply-To: <20090730133545.77e5a76a@nehalam>
On Thu, 30 Jul 2009 13:35:45 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Thu, 30 Jul 2009 13:28:19 -0700
> Jay Vosburgh <fubar@us.ibm.com> wrote:
>
> > Stephen Hemminger <shemminger@vyatta.com> wrote:
> >
> > >The bonding ALB mode builds packets with type, ETH_P_LOOP.
> > >
> > >Well ETH_P_LOOP is defined as 0x0060 which looks completely bogus.
> > >All Ethernet types less than 1536 are interpreted as 802.2 frames.
> > >The result is that the resulting packet looks like a bogus 802.2
> > >frame to the other host (or switch). I have no idea what the
> > >initial design was or what the purpose of this code is, but it
> > >should either send a real packet or nothing at all.
> >
> > I've looked at that code before, too, although I hadn't noticed
> > that ETH_P_LOOP is under the limit for interpretation as a length
> > instead of a type.
> >
> > I believe the purpose of the code is to update the switch's MAC
> > address table for the port and insure it's correct, since the alb mode
> > can move MAC addresses around amongst the set of slaves.
> >
> > -J
>
> Then it ought to send an ARP or at least a real-looking 802.2 packet.
> Also, if the purpose was to update switch MAC table, why does it need
> to do it so often, rather than only when MAC address is swapped.
Generally to overcome the 300 second address timeout. You can't be sure
that any actual traffic is going to come from that address within the
timeout period. Netflow collectors are a good example of something that
receives traffic but doesn't send any. It's a common problem to have
their MAC address timeout of the upstream switch and then start seeing
the UDP Netflow traffic being flooded to all switch ports. You then
have to set up something like a persistent periodic ping to refresh the
MAC address table.
ETH_P_LOOP should probably have been avoided, as "LOOP" or "loopback"
is commonly used to refer to the Ethernet Configuration Testing
Protocol (google search for "Ethernet Loop protocol").
I'd suggest not using any form of ARP for this purpose. It'd place an
IPv4 requirement on the bonded interface, and various "empty" ARP
frames have meaning e.g. duplicate address detection. 802.2 test frames
or the original Ethernet V2.0 Configuration Testing Protocol have been
used for this bridge table address refresh purpose in the past.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] pcnet32: VLB support fixes
From: Bartlomiej Zolnierkiewicz @ 2009-07-30 22:25 UTC (permalink / raw)
To: Jeff Garzik
Cc: Don Fry, netdev, linux-kernel, Dan Carpenter, corbet, eteo,
Julia Lawall
In-Reply-To: <4A721768.2060102@garzik.org>
On Thursday 30 July 2009 23:58:00 Jeff Garzik wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Thursday 30 July 2009 23:32:19 Jeff Garzik wrote:
> >> Bartlomiej Zolnierkiewicz wrote:
> >>> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> >>> Subject: [PATCH] pcnet32: VLB support fixes
> >>>
> >>> VLB support has been broken since at least 2004-2005 period as some
> >>> changes introduced back then assumed that ->pci_dev is always valid,
> >>> lets try to fix it:
> >>>
> >>> - remove duplicated SET_NETDEV_DEV() call
> >>>
> >>> - call SET_NETDEV_DEV() only for PCI devices
> >>>
> >>> - check for ->pci_dev validity in pcnet32_open()
> >>>
> >>> [ Alternatively we may consider removing VLB support but there would not
> >>> be much gain in it since an extra driver code needed for VLB support is
> >>> minimal and quite simple. ]
> >>>
> >>> This takes care of the following entry from Dan's list:
> >>>
> >>> drivers/net/pcnet32.c +1889 pcnet32_probe1(298) warning: variable derefenced before check 'pdev'
> >>>
> >>> Reported-by: Dan Carpenter <error27@gmail.com>
> >>> Cc: corbet@lwn.net
> >>> Cc: eteo@redhat.com
> >>> Cc: Julia Lawall <julia@diku.dk>
> >>> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> >>> ---
> >>> PS I still keep the original cc: list from the smatch thread -- please let
> >>> me know if you don't want to be spammed.. ;-)
> >>>
> >>> drivers/net/pcnet32.c | 12 +++++++-----
> >>> 1 file changed, 7 insertions(+), 5 deletions(-)
> >> ACK -- the patch is correct AFAICS -- but would it not be better to have
> >> a struct device for the VLB device?
> >
> > Sure, such addition would be needed for sysfs support on VLB devices..
>
>
> >> We have capability to create struct device for isa and eisa, so VLB is
> >> quite doable.
> >>
> >> Jeff, who converted old-ISDN ISA+EISA+PCI drivers to
> >> hotplug model, once upon a time
> >
> > ..and it seems that you've the needed experience! :)
>
> <grin> In my esteemed experience, I point you to the 39-line
> include/linux/isa.h as a starting point for grep... :)
Send patches.
I don't have a time/motivation for enhancing VLB support, not even
mentioning the access to hardware needed to test such changes..
^ permalink raw reply
* [net-2.6 PATCH 3/3] ixgbe: Fix RSC completion delay causing Rx interrupts to stop
From: Jeff Kirsher @ 2009-07-30 22:26 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Peter P Waskiewicz Jr, Jeff Kirsher
In-Reply-To: <20090730222501.26121.2952.stgit@localhost.localdomain>
From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
When a user disables interrupt throttling with ethtool on 82599 devices,
the interrupt timer may not be re-enabled if hardware RSC is running. The
RSC completions in hardware don't complete before the next ITR event tries
to fire, so the ITR timer never gets re-armed. This patch increases the
amount of time between interrupts when throttling is disabled (rx-usecs =
0) when the hardware RSC deature is enabled.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe.h | 2 ++
drivers/net/ixgbe/ixgbe_ethtool.c | 5 ++++-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe.h b/drivers/net/ixgbe/ixgbe.h
index 1b12c7b..e11d83d 100644
--- a/drivers/net/ixgbe/ixgbe.h
+++ b/drivers/net/ixgbe/ixgbe.h
@@ -96,6 +96,8 @@
#define IXGBE_TX_FLAGS_VLAN_PRIO_MASK 0x0000e000
#define IXGBE_TX_FLAGS_VLAN_SHIFT 16
+#define IXGBE_MAX_RSC_INT_RATE 162760
+
/* wrapper around a pointer to a socket buffer,
* so a DMA handle can be stored along with the buffer */
struct ixgbe_tx_buffer {
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index 7ddb50c..79144e9 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -1975,7 +1975,10 @@ static int ixgbe_set_coalesce(struct net_device *netdev,
* any other value means disable eitr, which is best
* served by setting the interrupt rate very high
*/
- adapter->eitr_param = IXGBE_MAX_INT_RATE;
+ if (adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED)
+ adapter->eitr_param = IXGBE_MAX_RSC_INT_RATE;
+ else
+ adapter->eitr_param = IXGBE_MAX_INT_RATE;
adapter->itr_setting = 0;
}
^ permalink raw reply related
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