* [PATCH] b44.c box lockup fix (netconsole): ratelimit NAPI poll error message
From: Andreas Mohr @ 2009-11-25 21:35 UTC (permalink / raw)
To: davem; +Cc: zambrano, dave, mb, netdev, linux-kernel
Hello all,
my OpenWrt MIPSEL ASUS WL-500gP v2 kept locking up during driver
debugging with kobject debugging turned on (when debugging non-working
drivers such as USB, ftdi_sio and usb_audio).
Turns out that it's not very helpful to have a netconsole-deployed
network driver's interrupt handler message spew noise permanently
(see comment in patch).
See
http://bugzilla.kernel.org/show_bug.cgi?id=14691
for background information.
Tested on 2.6.30.9 and working (now normal debug messages manage
to come through, too, yet box still locked up, simply due to excessive
_normal_ log messages such as kobject logging, but that's _expected_
and user-correctable).
checkpatch.pl'd, applies cleanly to -rc8.
Likely -stable candidate material.
r8169 (and perhaps other netconsole-capable drivers?)
might need such a correction, too, if the
if (likely(napi_schedule_prep(&tp->napi)))
__napi_schedule(&tp->napi);
else if (netif_msg_intr(tp)) {
printk(KERN_INFO "%s: interrupt %04x in poll\n",
dev->name, status);
}
is similarly problematic.
BTW: this patch here is to be seen separate from the r8169 interrupt handler
rework as discussed at "r8169: avoid losing MSI interrupts", since even with a
"working" interrupt handler (i.e. one that closes the "new interrupt" race window,
which the one in b44 currently probably doesn't) such error messages
have a fatal feedback loop in the case of netconsole deployment.
Thanks,
Signed-off-by: Andreas Mohr <andi@lisas.de>
--- linux-2.6.30.9/drivers/net/b44.c.orig 2009-11-25 20:49:48.000000000 +0100
+++ linux-2.6.30.9/drivers/net/b44.c 2009-11-25 21:26:34.000000000 +0100
@@ -913,8 +913,18 @@
__b44_disable_ints(bp);
__napi_schedule(&bp->napi);
} else {
- printk(KERN_ERR PFX "%s: Error, poll already scheduled\n",
- dev->name);
+ /* netconsole fix!!:
+ * without ratelimiting, this message would:
+ * immediately find its way out to b44 netconsole ->
+ * new IRQ -> re-encounter failed napi_schedule_prep()
+ * -> error message -> ad nauseam -> box LOCKUP.
+ * See thread "r8169: avoid losing MSI interrupts"
+ * for further inspiration. */
+ if (printk_ratelimit())
+ printk(KERN_ERR PFX
+ "%s: Error, poll already scheduled; "
+ "istat 0x%x, imask 0x%x\n",
+ dev->name, istat, imask);
}
irq_ack:
^ permalink raw reply
* Re: [Bugme-new] [Bug 14691] New: Complete NAPI IRQ lockup in b44 driver: code fundamentally incompatible with netconsole requirements
From: Andrew Morton @ 2009-11-25 21:16 UTC (permalink / raw)
To: Gary Zambrano; +Cc: bugzilla-daemon, bugme-daemon, netdev, andi
In-Reply-To: <bug-14691-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 25 Nov 2009 20:15:33 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14691
>
> Summary: Complete NAPI IRQ lockup in b44 driver: code
> fundamentally incompatible with netconsole
> requirements
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.32-rc8
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: blocking
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: andi@lisas.de
> Regression: No
>
>
> Hi,
>
> severity "blocking" (== "Blocks development and/or testing work"): it's my
> primary window to the world on this router - netconsole - and crashes multiple
> times when loading various drivers, thus for me there's no productive
> proceeding possible, plus there have been multiple reports on this issue since
> at least 2004.
>
> The kernel version I'm testing it on is 2.6.30.9 (OpenWrt MIPSEL, on ASUS
> WL-500gP v2), but since b44 interrupt handler is unchanged I assume it's still
> unfixed.
>
> Frequently when doing some medium activity such as loading modules such as
> ftdi_sio, usb_audio etc. (especially with kobject debugging enabled), the
> network LED starts blinking like crazy and when re-listening to netconsole
> output, there's simply a flood of
> %s: Error, poll already scheduled
> and the box is DEAD (again! *curse*).
>
> Productive debugging of multiple USB and ftdi_sio issues is simply impossible
> with this kind of problem remaining.
>
> See also:
> "RE:hostname freeze" (2004!!):
> http://lists.linuxcoding.com/rhl/2004/msg51048.html
>
> "b44 driver suspend/resume (was Re: [ACPI] Re: Re: various problems with Acer
> TM654, suspend, ACAD, radeon)":
> http://osdir.com/ml/network.general/2004-08/msg00208.html
>
> "acpi and b44: irq disabled, b44: Error, poll already scheduled" (2004!!):
> http://lkml.indiana.edu/hypermail/linux/kernel/0408.3/0078.html
>
> And a very related fix and long discussion is at:
> "[PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts":
> http://kerneltrap.org/mailarchive/linux-netdev/2009/5/23/5791863
>
> I'm very uncertain whether the interrupt handler method of simply screaming
> this error message on every interrupt without doing any actual remedies is a
> good idea.
> HAH! Now I've got it: the fact that we're on netconsole means that this error
> message gets sent _immediately_ (out to the netconsole device!!), thus this
> very network transmission encounters an IRQ handler at a time where the
> previous scheduled NAPI processing had no chance yet of being done, thus
> napi_schedule_prep() FAIL, thus error message again, thus... ad nauseam!
> Or, IOW, now I'm _certain_ that it is _NOT_ a good idea to scream this message
> on every IRQ without doing anything about it.
>
>
> I want to report this issue now to make sure it can get the attention it
> deserves, but for now I'll try to come up with a bandaid locally (simply
> silencing the error message) in order to be able to debug the other driver
> issues mentioned above.
>
> Thanks!
^ permalink raw reply
* Re: [Bugme-new] [Bug 14685] New: 2.6.30 -> 2.6.31: very high number of RX dropped in bnx2
From: Andrew Morton @ 2009-11-25 20:47 UTC (permalink / raw)
To: Michael Chan, netdev; +Cc: bugzilla-daemon, bugme-daemon, olel
In-Reply-To: <bug-14685-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 25 Nov 2009 00:16:00 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14685
>
> Summary: 2.6.30 -> 2.6.31: very high number of RX dropped in
> bnx2
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.31.6
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: olel@ans.pl
> Regression: Yes
>
>
> After upgradig my kernel from 2.6.30 to 2.6.31 I'm observing very high number
> of dropped packets on BCM5708(Dell PowerEdge 1950)/BCM5716(Dell PowerEdge R410)
> NICs.
>
> # uptime ; ifconfig eth0|grep "RX p"; ethtool -S eth0|grep disc
> 01:07:31 up 6 min, 1 user, load average: 0.00, 0.07, 0.04
> RX packets:2234 errors:0 dropped:527 overruns:0 frame:0
> rx_discards: 0
> rx_fw_discards: 527
>
> Everything seems to work just fine so I suspect that the driver/firmware is
> counting something wrong.
>
^ permalink raw reply
* Re: Diagnostic Monitoring Interface Monitoring (DOM) PATCH 0/5 for net-next-2.6
From: Joe Perches @ 2009-11-25 20:38 UTC (permalink / raw)
To: robert; +Cc: Jeff Kirsher, David Miller, netdev
In-Reply-To: <19213.23008.292298.804077@gargle.gargle.HOWL>
On Wed, 2009-11-25 at 17:22 +0100, robert@herjulf.net wrote:
> Jeff Kirsher writes:
> > FYI- This patch series is riddled with trailing whitespace, when I
> > imported that patches into my tree, I cleaned up all the whitespace
> > errors. After some internal testing and review,
> > I can re-post the entire series which has been cleaned up.
> Please do.
Here's another attempt as a complete patch.
Differences from Robert's original:
Whitespace cleanups
Changed presumed coding error from:
if (type & DOM_TYPE_DOM & DOM_TYPE_ADDR_CHNGE) {
to:
if (type & DOM_TYPE_ADDR_CHNGE) {
Added read_phy_diag_u32 function
Refactored multiple sequential register reads to
for loop over struct array with register read
Functional difference from my original patch:
Fixed ARRAY_SIZE(basic) misuse
Reduces code size:
was:
$ size drivers/net/igb/igb_ethtool.o drivers/net/ixgbe/ixgbe_ethtool.o
text data bss dec hex filename
26466 1544 8584 36594 8ef2 drivers/net/igb/igb_ethtool.o
31726 2980 9128 43834 ab3a drivers/net/ixgbe/ixgbe_ethtool.o
is:
$ size drivers/net/igb/igb_ethtool.o drivers/net/ixgbe/ixgbe_ethtool.o
text data bss dec hex filename
24642 1544 8008 34194 8592 drivers/net/igb/igb_ethtool.o
29922 2980 8560 41462 a1f6 drivers/net/ixgbe/ixgbe_ethtool.o
Signed-off-by: Joe Perches <joe@perches.com>
Documentation/networking/dom.txt | 41 ++++++++
drivers/net/igb/igb_ethtool.c | 191 +++++++++++++++++++++++++++++++++++++
drivers/net/ixgbe/ixgbe_ethtool.c | 171 +++++++++++++++++++++++++++++++++-
include/linux/ethtool.h | 49 ++++++++++
include/net/dom.h | 109 +++++++++++++++++++++
net/core/ethtool.c | 18 ++++
6 files changed, 578 insertions(+), 1 deletions(-)
diff --git a/Documentation/networking/dom.txt b/Documentation/networking/dom.txt
new file mode 100644
index 0000000..4bf24de
--- /dev/null
+++ b/Documentation/networking/dom.txt
@@ -0,0 +1,41 @@
+Diagnostic Monitoring Interface Monitoring also called DOM is a specification
+for optical transceivers to allow link and other diagnostics related to the
+transceiver's to standardized and communicated. For communication the I2C
+bus is used. The SFF specifications is available at ftp://ftp.seagate.com/
+Specification is generic and should work for many types of optical modules
+as GBIC, SFP, SFp+, XFP etc
+
+In short DOM spec adds a memory page where the diagnostics's is kept (address
+0xA2 bytes 66 to 105) but there are lot's of option's and variants. For example
+alarm and warnings are optional. See example below.
+
+Not all SFP's (SFP is for GIGE) have DOM support normally long range supports
+DOM. And of course your board and driver needs this support too.
+For SFP+ (10G) DOM is mandatory.
+
+Linux kernel support is via ethertool.
+
+include/net/dom.h # Basic definitions
+net/core/ethtool.c # adds ethtool_phy_diag()
+include/linux/ethtool.h # adds ETHTOOL_GPHYDIAG
+
+And drivers hooks exists currently in igb and ixgbe driver
+
+Usage example: ethtool -D eth5
+
+Ext-Calbr: Avr RX-Power: Alarm & Warn: RX_LOS: Wavelength: 1310 nm
+Alarms, warnings in beginning of line, Ie. AH = Alarm High, WL == Warn Low etc
+ Temp: 35.9 C Thresh: Lo: -12.0/-8.0 Hi: 103.0/110.0 C
+ Vcc: 3.33 V Thresh: Lo: 3.0/3.0 Hi: 3.7/4.0 V
+ Tx-Bias: 13.4 mA Thresh: Lo: 2.0/4.0 Hi: 70.0/84.0 mA
+ALWL TX-pwr: -5.9 dBm ( 0.26 mW) Thresh: Lo: -4.0/-2.0 Hi: 7.0/8.2 dBm
+AHWH RX-pwr: -5.0 dBm ( 0.31 mW) Thresh: Lo: -35.2/-28.0 Hi: -8.2/-6.0 dBm
+
+
+First line shows the options supported by the module. As we see this module
+supports Alarms and warnings as a consequence thresholds are printed. As example
+RX-pwr: -35.2 < no_alarm < -6.0 dBm and -28.0 < no_warning < -8.2 dBm. (dBm yields
+1 mW == 0 dBm)
+
+In the example above we see both warnings for both TX-pwr (low) and RX-Pwr high.
+The Rx side would need some attenuation.
diff --git a/drivers/net/igb/igb_ethtool.c b/drivers/net/igb/igb_ethtool.c
index ac9d527..63a297d 100644
--- a/drivers/net/igb/igb_ethtool.c
+++ b/drivers/net/igb/igb_ethtool.c
@@ -34,6 +34,7 @@
#include <linux/interrupt.h>
#include <linux/if_ether.h>
#include <linux/ethtool.h>
+#include <net/dom.h>
#include <linux/sched.h>
#include "igb.h"
@@ -2063,6 +2064,195 @@ static void igb_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
}
}
+static s32 read_phy_diag(struct e1000_hw *hw, u8 page, u8 offset, u16 *data)
+{
+ u32 i, i2ccmd = 0;
+
+ if (offset > E1000_MAX_SGMII_PHY_REG_ADDR) {
+ hw_dbg("DOM Register Address %u is out of range\n", offset);
+ return -E1000_ERR_PARAM;
+ }
+
+ /*
+ * Set up Op-code, Phy Address, and register address in the I2CCMD
+ * register. The MAC will take care of interfacing with the
+ * PHY to retrieve the desired data.
+ */
+
+ i2ccmd = (E1000_I2CCMD_OPCODE_READ) |
+ (page << E1000_I2CCMD_PHY_ADDR_SHIFT) |
+ (offset << E1000_I2CCMD_REG_ADDR_SHIFT);
+
+ wr32(E1000_I2CCMD, i2ccmd);
+
+ /* Poll the ready bit to see if the I2C read completed */
+ for (i = 0; i < E1000_I2CCMD_PHY_TIMEOUT; i++) {
+ udelay(50);
+ i2ccmd = rd32(E1000_I2CCMD);
+ //printk("DATA i2ccmd=0x%x\n", i2ccmd);
+ if (i2ccmd & E1000_I2CCMD_READY)
+ break;
+ }
+ if (!(i2ccmd & E1000_I2CCMD_READY)) {
+ hw_dbg("I2CCMD Read did not complete\n");
+ return -E1000_ERR_PHY;
+ }
+ if (i2ccmd & E1000_I2CCMD_ERROR) {
+ hw_dbg("I2CCMD Error bit set\n");
+ return -E1000_ERR_PHY;
+ }
+
+ /* Need to byte-swap the 16-bit value. */
+ *data = ((i2ccmd >> 8) & 0x00FF) | ((i2ccmd << 8) & 0xFF00);
+ return 0;
+}
+
+static s32 read_phy_diag_u32(struct e1000_hw *hw, u8 page, u8 offset, u32 *data)
+{
+ u16 p1;
+ u16 p2;
+ s32 res;
+
+ res = read_phy_diag(hw, page, offset, &p1);
+ if (res)
+ goto out;
+
+ res = read_phy_diag(hw, page, offset + 2, &p2);
+ if (res)
+ goto out;
+
+ *data = ((u32)p1) << 16 | p2;
+
+out:
+ return res;
+}
+
+struct reg_offset {
+ int reg;
+ size_t offset;
+};
+
+#define REG_OFFSET(a, b) \
+ { .reg = a, .offset = offsetof(struct ethtool_phy_diag, b) }
+
+int igb_get_phy_diag(struct net_device *netdev, struct ethtool_phy_diag *pd)
+{
+ struct igb_adapter *adapter = netdev_priv(netdev);
+ struct e1000_hw *hw = &adapter->hw;
+ int res;
+ u8 type, eo;
+ int i;
+
+ static const struct reg_offset basic[] = {
+ REG_OFFSET(DOM_A2_TEMP, temp),
+ REG_OFFSET(DOM_A2_TEMP_SLOPE, temp_slope),
+ REG_OFFSET(DOM_A2_TEMP_OFFSET, temp_offset),
+ REG_OFFSET(DOM_A2_VCC, vcc),
+ REG_OFFSET(DOM_A2_VCC_SLOPE, vcc_slope),
+ REG_OFFSET(DOM_A2_VCC_OFFSET, vcc_offset),
+ REG_OFFSET(DOM_A2_TX_BIAS, tx_bias),
+ REG_OFFSET(DOM_A2_TX_I_SLOPE, tx_bias_slope),
+ REG_OFFSET(DOM_A2_TX_I_OFFSET, tx_bias_offset),
+ REG_OFFSET(DOM_A2_TX_PWR, tx_pwr),
+ REG_OFFSET(DOM_A2_TX_PWR_SLOPE, tx_pwr_slope),
+ REG_OFFSET(DOM_A2_TX_PWR_OFFSET, tx_pwr_offset),
+ REG_OFFSET(DOM_A2_RX_PWR, rx_pwr),
+ };
+
+ static const struct reg_offset power[] = {
+ REG_OFFSET(DOM_A2_RX_PWR_0, rx_pwr_cal[0]),
+ REG_OFFSET(DOM_A2_RX_PWR_1, rx_pwr_cal[1]),
+ REG_OFFSET(DOM_A2_RX_PWR_2, rx_pwr_cal[2]),
+ REG_OFFSET(DOM_A2_RX_PWR_3, rx_pwr_cal[3]),
+ REG_OFFSET(DOM_A2_RX_PWR_4, rx_pwr_cal[4]),
+ };
+
+ static const struct reg_offset aw[] = {
+ REG_OFFSET(DOM_A2_TEMP_AHT, temp_aht),
+ REG_OFFSET(DOM_A2_TEMP_ALT, temp_alt),
+ REG_OFFSET(DOM_A2_TEMP_WHT, temp_wht),
+ REG_OFFSET(DOM_A2_TEMP_WLT, temp_wlt),
+ REG_OFFSET(DOM_A2_VCC_AHT, vcc_aht),
+ REG_OFFSET(DOM_A2_VCC_ALT, vcc_alt),
+ REG_OFFSET(DOM_A2_VCC_WHT, vcc_wht),
+ REG_OFFSET(DOM_A2_VCC_WLT, vcc_wlt),
+ REG_OFFSET(DOM_A2_TX_BIAS_AHT, tx_bias_aht),
+ REG_OFFSET(DOM_A2_TX_BIAS_ALT, tx_bias_alt),
+ REG_OFFSET(DOM_A2_TX_BIAS_WHT, tx_bias_wht),
+ REG_OFFSET(DOM_A2_TX_BIAS_WLT, tx_bias_wlt),
+ REG_OFFSET(DOM_A2_TX_PWR_AHT, tx_pwr_aht),
+ REG_OFFSET(DOM_A2_TX_PWR_ALT, tx_pwr_alt),
+ REG_OFFSET(DOM_A2_TX_PWR_WHT, tx_pwr_wht),
+ REG_OFFSET(DOM_A2_TX_PWR_WLT, tx_pwr_wlt),
+ REG_OFFSET(DOM_A2_RX_PWR_AHT, rx_pwr_aht),
+ REG_OFFSET(DOM_A2_RX_PWR_ALT, rx_pwr_alt),
+ REG_OFFSET(DOM_A2_RX_PWR_WHT, rx_pwr_wht),
+ REG_OFFSET(DOM_A2_RX_PWR_WLT, rx_pwr_wlt),
+ };
+
+ res = read_phy_diag(hw, 0x0, DOM_A0_DOM_TYPE, &pd->type);
+ if (res)
+ goto out;
+
+ type = pd->type >> 8;
+
+ if ((~type & DOM_TYPE_DOM) || (type & DOM_TYPE_LEGAGY_DOM))
+ goto out;
+
+ if (type & DOM_TYPE_ADDR_CHNGE) {
+ hw_dbg("DOM module not supported (Address change)\n");
+ goto out;
+ }
+
+ eo = pd->type & 0xFF;
+
+ res = read_phy_diag(hw, 0x0, DOM_A0_WAVELENGTH, &pd->wavelength);
+ if (res)
+ goto out;
+
+ /* If supported. Read alarms and Warnings first*/
+ if (eo & DOM_EO_AW) {
+ res = read_phy_diag(hw, 0x1, DOM_A2_ALARM, &pd->alarm);
+ if (res)
+ goto out;
+ res = read_phy_diag(hw, 0x1, DOM_A2_WARNING, &pd->warning);
+ if (res)
+ goto out;
+ }
+
+ /* Basic diag */
+
+ for (i = 0; i < ARRAY_SIZE(basic); i++) {
+ res = read_phy_diag(hw, 0x1, basic[i].reg,
+ (u16 *)((char *)pd + basic[i].offset));
+ if (res)
+ goto out;
+ }
+
+ /* Power */
+
+ for (i = 0; i < ARRAY_SIZE(power); i++) {
+ res = read_phy_diag_u32(hw, 0x1, power[i].reg,
+ (u32 *)((char *)pd + power[i].offset));
+ if (res)
+ goto out;
+ }
+
+ /* Thresholds for Alarms and Warnings */
+
+ if (eo & DOM_EO_AW) {
+ for (i = 0; i < ARRAY_SIZE(aw); i++) {
+ res = read_phy_diag(hw, 0x1, aw[i].reg,
+ (u16 *)((char *)pd + aw[i].offset));
+ if (res)
+ goto out;
+ }
+ }
+
+out:
+ return res;
+}
+
static const struct ethtool_ops igb_ethtool_ops = {
.get_settings = igb_get_settings,
.set_settings = igb_set_settings,
@@ -2097,6 +2287,7 @@ static const struct ethtool_ops igb_ethtool_ops = {
.get_ethtool_stats = igb_get_ethtool_stats,
.get_coalesce = igb_get_coalesce,
.set_coalesce = igb_set_coalesce,
+ .get_phy_diag = igb_get_phy_diag,
};
void igb_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index 84ab4db..8435cd7 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -34,9 +34,11 @@
#include <linux/ethtool.h>
#include <linux/vmalloc.h>
#include <linux/uaccess.h>
+#include <net/dom.h>
#include "ixgbe.h"
-
+#include "ixgbe_phy.h"
+#include "ixgbe_common.h"
#define IXGBE_ALL_RAR_ENTRIES 16
@@ -2106,6 +2108,172 @@ static int ixgbe_set_flags(struct net_device *netdev, u32 data)
}
+static s32 read_phy_diag(struct ixgbe_hw *hw, u8 page, u8 offset, u16 *data)
+{
+ s32 status;
+ u8 hi, lo;
+
+ status = ixgbe_read_i2c_byte_generic(hw, page, offset, &hi);
+ if (status)
+ goto out;
+
+ status = ixgbe_read_i2c_byte_generic(hw, page, offset, &lo);
+ if (status)
+ goto out;
+
+ *data = (((u16)hi) << 8) | lo;
+
+out:
+ return status;
+}
+
+static s32 read_phy_diag_u32(struct ixgbe_hw *hw, u8 page, u8 offset, u32 *data)
+{
+ u16 p1;
+ u16 p2;
+ s32 res;
+
+ res = read_phy_diag(hw, page, offset, &p1);
+ if (res)
+ goto out;
+
+ res = read_phy_diag(hw, page, offset + 2, &p2);
+ if (res)
+ goto out;
+
+ *data = ((u32)p1) << 16 | p2;
+
+out:
+ return res;
+}
+
+struct reg_offset {
+ int reg;
+ size_t offset;
+};
+
+#define REG_OFFSET(a, b) \
+ { .reg = a, .offset = offsetof(struct ethtool_phy_diag, b) }
+
+int ixgb_get_phy_diag(struct net_device *netdev, struct ethtool_phy_diag *pd)
+{
+ struct ixgbe_adapter *adapter = netdev_priv(netdev);
+ struct ixgbe_hw *hw = &adapter->hw;
+ int res;
+ u8 type, eo;
+ int i;
+
+ static const struct reg_offset basic[] = {
+ REG_OFFSET(DOM_A2_TEMP, temp),
+ REG_OFFSET(DOM_A2_TEMP_SLOPE, temp_slope),
+ REG_OFFSET(DOM_A2_TEMP_OFFSET, temp_offset),
+ REG_OFFSET(DOM_A2_VCC, vcc),
+ REG_OFFSET(DOM_A2_VCC_SLOPE, vcc_slope),
+ REG_OFFSET(DOM_A2_VCC_OFFSET, vcc_offset),
+ REG_OFFSET(DOM_A2_TX_BIAS, tx_bias),
+ REG_OFFSET(DOM_A2_TX_I_SLOPE, tx_bias_slope),
+ REG_OFFSET(DOM_A2_TX_I_OFFSET, tx_bias_offset),
+ REG_OFFSET(DOM_A2_TX_PWR, tx_pwr),
+ REG_OFFSET(DOM_A2_TX_PWR_SLOPE, tx_pwr_slope),
+ REG_OFFSET(DOM_A2_TX_PWR_OFFSET, tx_pwr_offset),
+ REG_OFFSET(DOM_A2_RX_PWR, rx_pwr),
+ };
+
+ static const struct reg_offset power[] = {
+ REG_OFFSET(DOM_A2_RX_PWR_0, rx_pwr_cal[0]),
+ REG_OFFSET(DOM_A2_RX_PWR_1, rx_pwr_cal[1]),
+ REG_OFFSET(DOM_A2_RX_PWR_2, rx_pwr_cal[2]),
+ REG_OFFSET(DOM_A2_RX_PWR_3, rx_pwr_cal[3]),
+ REG_OFFSET(DOM_A2_RX_PWR_4, rx_pwr_cal[4]),
+ };
+
+ static const struct reg_offset aw[] = {
+ REG_OFFSET(DOM_A2_TEMP_AHT, temp_aht),
+ REG_OFFSET(DOM_A2_TEMP_ALT, temp_alt),
+ REG_OFFSET(DOM_A2_TEMP_WHT, temp_wht),
+ REG_OFFSET(DOM_A2_TEMP_WLT, temp_wlt),
+ REG_OFFSET(DOM_A2_VCC_AHT, vcc_aht),
+ REG_OFFSET(DOM_A2_VCC_ALT, vcc_alt),
+ REG_OFFSET(DOM_A2_VCC_WHT, vcc_wht),
+ REG_OFFSET(DOM_A2_VCC_WLT, vcc_wlt),
+ REG_OFFSET(DOM_A2_TX_BIAS_AHT, tx_bias_aht),
+ REG_OFFSET(DOM_A2_TX_BIAS_ALT, tx_bias_alt),
+ REG_OFFSET(DOM_A2_TX_BIAS_WHT, tx_bias_wht),
+ REG_OFFSET(DOM_A2_TX_BIAS_WLT, tx_bias_wlt),
+ REG_OFFSET(DOM_A2_TX_PWR_AHT, tx_pwr_aht),
+ REG_OFFSET(DOM_A2_TX_PWR_ALT, tx_pwr_alt),
+ REG_OFFSET(DOM_A2_TX_PWR_WHT, tx_pwr_wht),
+ REG_OFFSET(DOM_A2_TX_PWR_WLT, tx_pwr_wlt),
+ REG_OFFSET(DOM_A2_RX_PWR_AHT, rx_pwr_aht),
+ REG_OFFSET(DOM_A2_RX_PWR_ALT, rx_pwr_alt),
+ REG_OFFSET(DOM_A2_RX_PWR_WHT, rx_pwr_wht),
+ REG_OFFSET(DOM_A2_RX_PWR_WLT, rx_pwr_wlt),
+ };
+
+ res = read_phy_diag(hw, 0x0, DOM_A0_DOM_TYPE, &pd->type);
+ if (res)
+ goto out;
+
+ type = pd->type >> 8;
+
+ if ((~type & DOM_TYPE_DOM) || (type & DOM_TYPE_LEGAGY_DOM))
+ goto out;
+
+ if (type & DOM_TYPE_ADDR_CHNGE) {
+ hw_dbg(hw, "DOM module not supported (Address change)\n");
+ goto out;
+ }
+
+ eo = pd->type & 0xFF;
+
+ res = read_phy_diag(hw, 0x0, DOM_A0_WAVELENGTH, &pd->wavelength);
+ if (res)
+ goto out;
+
+ /* If supported. Read alarms and Warnings first*/
+ if (eo & DOM_EO_AW) {
+ res = read_phy_diag(hw, 0x1, DOM_A2_ALARM, &pd->alarm);
+ if (res)
+ goto out;
+
+ res = read_phy_diag(hw, 0x1, DOM_A2_WARNING, &pd->warning);
+ if (res)
+ goto out;
+ }
+
+ /* Basic diag */
+
+ for (i = 0; i < ARRAY_SIZE(basic); i++) {
+ res = read_phy_diag(hw, 0x1, basic[i].reg,
+ (u16 *)((char *)pd + basic[i].offset));
+ if (res)
+ goto out;
+ }
+
+ /* Power */
+
+ for (i = 0; i < ARRAY_SIZE(power); i++) {
+ res = read_phy_diag_u32(hw, 0x1, power[i].reg,
+ (u32 *)((char *)pd + power[i].offset));
+ if (res)
+ goto out;
+ }
+
+ /* Thresholds for Alarms and Warnings */
+
+ if (eo & DOM_EO_AW) {
+ for (i = 0; i < ARRAY_SIZE(aw); i++) {
+ res = read_phy_diag(hw, 0x1, aw[i].reg,
+ (u16 *)((char *)pd + aw[i].offset));
+ if (res)
+ goto out;
+ }
+ }
+
+out:
+ return res;
+}
+
static const struct ethtool_ops ixgbe_ethtool_ops = {
.get_settings = ixgbe_get_settings,
.set_settings = ixgbe_set_settings,
@@ -2141,6 +2309,7 @@ static const struct ethtool_ops ixgbe_ethtool_ops = {
.set_coalesce = ixgbe_set_coalesce,
.get_flags = ethtool_op_get_flags,
.set_flags = ixgbe_set_flags,
+ .get_phy_diag = ixgb_get_phy_diag,
};
void ixgbe_set_ethtool_ops(struct net_device *netdev)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index edd03b7..4e45a94 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -272,6 +272,53 @@ struct ethtool_stats {
__u64 data[0];
};
+/* Diagmostic Monitoring Interface Data -- DOM */
+struct ethtool_phy_diag {
+ __u32 cmd;
+ /* A0 page */
+ __u16 type;
+ __u16 wavelength;
+ /* A2 page */
+ __u16 alarm;
+ __u16 warning;
+ __s16 temp;
+ __u16 temp_slope;
+ __s16 temp_offset;
+ __u16 vcc;
+ __u16 vcc_slope;
+ __s16 vcc_offset;
+ __u16 tx_bias;
+ __u16 tx_bias_slope;
+ __s16 tx_bias_offset;
+ __u16 tx_pwr;
+ __u16 tx_pwr_slope;
+ __s16 tx_pwr_offset;
+ __u16 rx_pwr;
+ __u32 rx_pwr_cal[5];
+
+ /* Thresholds */
+ __s16 temp_alt;
+ __s16 temp_aht;
+ __s16 temp_wlt;
+ __s16 temp_wht;
+ __u16 vcc_alt;
+ __u16 vcc_aht;
+ __u16 vcc_wlt;
+ __u16 vcc_wht;
+ __u16 tx_bias_alt;
+ __u16 tx_bias_aht;
+ __u16 tx_bias_wlt;
+ __u16 tx_bias_wht;
+ __u16 tx_pwr_alt;
+ __u16 tx_pwr_aht;
+ __u16 tx_pwr_wlt;
+ __u16 tx_pwr_wht;
+ __u16 rx_pwr_alt;
+ __u16 rx_pwr_aht;
+ __u16 rx_pwr_wlt;
+ __u16 rx_pwr_wht;
+};
+
struct ethtool_perm_addr {
__u32 cmd; /* ETHTOOL_GPERMADDR */
__u32 size;
@@ -499,6 +546,7 @@ struct ethtool_ops {
int (*set_rxnfc)(struct net_device *, struct ethtool_rxnfc *);
int (*flash_device)(struct net_device *, struct ethtool_flash *);
int (*reset)(struct net_device *, u32 *);
+ int (*get_phy_diag)(struct net_device *, struct ethtool_phy_diag *);
};
#endif /* __KERNEL__ */
@@ -557,6 +605,7 @@ struct ethtool_ops {
#define ETHTOOL_SRXCLSRLINS 0x00000032 /* Insert RX classification rule */
#define ETHTOOL_FLASHDEV 0x00000033 /* Flash firmware to device */
#define ETHTOOL_RESET 0x00000034 /* Reset hardware */
+#define ETHTOOL_GPHYDIAG 0x00000035 /* Get PHY diagnostics */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/include/net/dom.h b/include/net/dom.h
new file mode 100644
index 0000000..61540c3
--- /dev/null
+++ b/include/net/dom.h
@@ -0,0 +1,109 @@
+#ifndef _LINUX_DOM_H
+#define _LINUX_DOM_H
+
+/*
+ Diagnostic Monitoring Interface for Optical Tranceivers
+ SFF-8472 v. 10.4 (Jan 2009)
+ ftp://ftp.seagate.com/sff/SFF-8472.PDF
+
+ Licensce GPL. Copyright Robert Olsson robert@herjulf.net
+*/
+
+#define DOM_A0_IDENTIFIER 0
+#define DOM_A0_WAVELENGTH 60
+#define DOM_A0_CC_BASE 63
+#define DOM_A0_DOM_TYPE 92
+
+/* DOM_TYPE codings in DOM_A0_DOM_TYPE */
+#define DOM_TYPE_LEGAGY_DOM (1<<7)
+#define DOM_TYPE_DOM (1<<6) /* Has DOM support */
+#define DOM_TYPE_INT_CAL (1<<5) /* Internally calibrated */
+#define DOM_TYPE_EXT_CAL (1<<4) /* Externally calibrated */
+#define DOM_TYPE_RX_PWR (1<<3) /* Received Power OMA=0, 1=average */
+#define DOM_TYPE_ADDR_CHNGE (1<<2) /* Address change required */
+
+#define DOM_A0_EO 93 /* Enhanced options */
+#define DOM_EO_AW (1<<7) /* Alarm & Warnings */
+#define DOM_EO_TX_DISABLE (1<<6)
+#define DOM_EO_TX_FAULT (1<<5)
+#define DOM_EO_RX_LOS (1<<4)
+#define DOM_EO_RATE_SELECT_MON (1<<3)
+#define DOM_EO_APP_SELECT (1<<2)
+#define DOM_EO_RATE_SELECT (1<<1)
+
+#define DOM_A0_CC_EXT 95
+
+#define DOM_A2_TEMP_AHT 0 /* Temp alarm high threshold */
+#define DOM_A2_TEMP_ALT 2
+#define DOM_A2_TEMP_WHT 4 /* Temp warning high threshold */
+#define DOM_A2_TEMP_WLT 6
+
+#define DOM_A2_VCC_AHT 8 /* VCC alarm high threshold */
+#define DOM_A2_VCC_ALT 10
+#define DOM_A2_VCC_WHT 12 /* VCC warning high threshold */
+#define DOM_A2_VCC_WLT 14
+
+#define DOM_A2_TX_BIAS_AHT 16 /* TX_BIAS alarm high threshold */
+#define DOM_A2_TX_BIAS_ALT 18
+#define DOM_A2_TX_BIAS_WHT 20 /* TX_BIAS warning high threshold */
+#define DOM_A2_TX_BIAS_WLT 22
+
+#define DOM_A2_TX_PWR_AHT 24 /* TX_PWR alarm high threshold */
+#define DOM_A2_TX_PWR_ALT 26
+#define DOM_A2_TX_PWR_WHT 28 /* TX_PWR warning high threshold */
+#define DOM_A2_TX_PWR_WLT 30
+
+#define DOM_A2_RX_PWR_AHT 32 /* RX_PWR alarm high threshold */
+#define DOM_A2_RX_PWR_ALT 34
+#define DOM_A2_RX_PWR_WHT 36 /* RX_PWR warning high threshold */
+#define DOM_A2_RX_PWR_WLT 38
+
+#define DOM_A2_RX_PWR_4 56 /* 4 bytes Calibration constants*/
+#define DOM_A2_RX_PWR_3 60 /* 4 bytes */
+#define DOM_A2_RX_PWR_2 64 /* 4 bytes */
+#define DOM_A2_RX_PWR_1 68 /* 4 bytes */
+#define DOM_A2_RX_PWR_0 72 /* 4 bytes */
+
+#define DOM_A2_TX_I_SLOPE 76 /* 2 bytes */
+#define DOM_A2_TX_I_OFFSET 78 /* 2 bytes */
+#define DOM_A2_TX_PWR_SLOPE 80 /* 2 bytes */
+#define DOM_A2_TX_PWR_OFFSET 82 /* 2 bytes */
+#define DOM_A2_TEMP_SLOPE 84 /* 2 bytes */
+#define DOM_A2_TEMP_OFFSET 86 /* 2 bytes */
+#define DOM_A2_VCC_SLOPE 88 /* 2 bytes */
+#define DOM_A2_VCC_OFFSET 90 /* 2 bytes */
+
+#define DOM_A2_CC_DMI 95
+#define DOM_A2_TEMP 96 /* 2 bytes */
+#define DOM_A2_VCC 98 /* 2 bytes */
+#define DOM_A2_TX_BIAS 100 /* 2 bytes */
+#define DOM_A2_TX_PWR 102 /* 2 bytes */
+#define DOM_A2_RX_PWR 104 /* 2 bytes */
+
+#define DOM_A2_ALARM 112 /* 2 bytes */
+#define DOM_TYPE_TEMP_AH (1<<7) /* Temp alarm high */
+#define DOM_TYPE_TEMP_AL (1<<6) /* low */
+#define DOM_TYPE_VCC_AH (1<<5)
+#define DOM_TYPE_VCC_AL (1<<4)
+#define DOM_TYPE_TX_BIAS_AH (1<<3)
+#define DOM_TYPE_TX_BIAS_AL (1<<2)
+#define DOM_TYPE_TX_PWR_AH (1<<1)
+#define DOM_TYPE_TX_PWR_AL (1<<0)
+/* Next byte 113 */
+#define DOM_TYPE_RX_PWR_AH (1<<7)
+#define DOM_TYPE_RX_PWR_AL (1<<6)
+
+#define DOM_A2_WARNING 116 /* 2 bytes */
+#define DOM_TYPE_TEMP_WH (1<<7) /* Temp warning high */
+#define DOM_TYPE_TEMP_WL (1<<6) /* low */
+#define DOM_TYPE_VCC_WH (1<<5)
+#define DOM_TYPE_VCC_WL (1<<4)
+#define DOM_TYPE_TX_BIAS_WH (1<<3)
+#define DOM_TYPE_TX_BIAS_WL (1<<2)
+#define DOM_TYPE_TX_PWR_WH (1<<1)
+#define DOM_TYPE_TX_PWR_WL (1<<0)
+/* Next byte 117 */
+#define DOM_TYPE_RX_PWR_WH (1<<7)
+#define DOM_TYPE_RX_PWR_WL (1<<6)
+
+#endif /* _LINUX_DOM_H */
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index d8aee58..756434a 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -893,6 +893,21 @@ static int ethtool_flash_device(struct net_device *dev, char __user *useraddr)
return dev->ethtool_ops->flash_device(dev, &efl);
}
+static int ethtool_phy_diag(struct net_device *dev, void __user *useraddr)
+{
+ struct ethtool_phy_diag pd;
+
+ if (!dev->ethtool_ops->get_phy_diag)
+ return -EOPNOTSUPP;
+
+ dev->ethtool_ops->get_phy_diag(dev, &pd); /* FIXME */
+
+ if (copy_to_user(useraddr, &pd, sizeof(pd)))
+ return -EFAULT;
+
+ return 0;
+}
+
/* The main entry point in this file. Called from net/core/dev.c */
int dev_ethtool(struct net *net, struct ifreq *ifr)
@@ -1112,6 +1127,9 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_RESET:
rc = ethtool_reset(dev, useraddr);
break;
+ case ETHTOOL_GPHYDIAG:
+ rc = ethtool_phy_diag(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
^ permalink raw reply related
* Re: [PATCH v2 0/7] via-velocity performance fixes
From: David Miller @ 2009-11-25 20:18 UTC (permalink / raw)
To: simon.kagstrom; +Cc: netdev, davej, shemminger, romieu
In-Reply-To: <20091125083943.2ec05b70@marrow.netinsight.se>
From: Simon Kagstrom <simon.kagstrom@netinsight.net>
Date: Wed, 25 Nov 2009 08:39:43 +0100
> On Tue, 24 Nov 2009 12:13:39 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> Simon I'm still waiting for you to fix the transmit function return
>> value problems I pointed out in patch #5.
>>
>> Please get to this so I can apply your patches.
>
> Sorry, I missed that comment. I only subscribed to netdev after having
> sent out the patches, so I didn't get that reply. I've looked it up now
> (and I'm subscribed now!), so I'll send out a new version.
Your email address was the To: field in the reply, there is no reason
you should not have received the email, here are the email headers:
--------------------
Subject: Re: [PATCH v2 5/7] via-velocity: Re-enable transmit scatter-gather support
From: David Miller <davem@davemloft.net>
To: simon.kagstrom@netinsight.net
Cc: netdev@vger.kernel.org, davej@redhat.com, shemminger@vyatta.com,
romieu@fr.zoreil.com
Date: Mon, 23 Nov 2009 10:52:21 -0800 (PST)
X-Mailer: Mew version 6.2.51 on Emacs 22.1 / Mule 5.0 (SAKAKI)
--------------------
So being subscribed to netdev has nothing to do with it, you simply
didn't get a direct email I sent to you for one reason or another.
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Jarek Poplawski @ 2009-11-25 19:11 UTC (permalink / raw)
To: Caleb Cushing
Cc: e1000-devel, netdev, Frans Pop, Jesse Brandeburg, linux-kernel,
Andi Kleen, Jeff Kirsher
In-Reply-To: <81bfc67a0911250606k1ec76354n217da9ca20b3517c@mail.gmail.com>
On Wed, Nov 25, 2009 at 09:06:30AM -0500, Caleb Cushing wrote:
> > Anyway, since there are problems with
> > getting stats from the router we still can't compare them, or check
> > for the dropped stats. (Btw, could you check for /proc/net/softnet_stat
> > yet?)
>
> router? good kernel? bad kernel?
router.
>
> > So, it might be the kernel problem you reported, but there is not
> > enough data to prove it. Then my proposal is to try to repeat this
> > problem in more "testing friendly" conditions - preferably against
> > some other, more up-to-date linux box, if possible?
>
> yeah 2.6.31.6 works on my laptop fine I'll just have to see about
> getting a direct connection to it. probably do that after I bring the
> other NIC back from home, on thanksgiving.
This other NIC is a really good idea, so let's wait and see.
Happy Thanksgiving!
Jarek P.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* vlan: support "loose binding" to the underlying network device
From: Patrick McHardy @ 2009-11-25 17:54 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 3496 bytes --]
commit 3cf29fff45d8671adf234c17e59681aab222a81d
Author: Patrick McHardy <kaber@trash.net>
Date: Wed Nov 25 16:28:27 2009 +0100
vlan: support "loose binding" to the underlying network device
Currently the UP/DOWN state of VLANs is synchronized to the state of the
underlying device, meaning all VLANs are set down once the underlying
device is set down. This causes all routes to the VLAN devices to vanish.
Add a flag to specify a "loose binding" mode, in which only the operstate
is transfered, but the VLAN device state is independant.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 153f6b9..3d870fd 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -339,6 +339,7 @@ enum vlan_ioctl_cmds {
enum vlan_flags {
VLAN_FLAG_REORDER_HDR = 0x1,
VLAN_FLAG_GVRP = 0x2,
+ VLAN_FLAG_LOOSE_BINDING = 0x4,
};
enum vlan_name_types {
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 1483243..225aa2f 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -431,6 +431,7 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
struct vlan_group *grp;
int i, flgs;
struct net_device *vlandev;
+ struct vlan_dev_info *vlan;
LIST_HEAD(list);
if (is_vlan_dev(dev))
@@ -507,7 +508,9 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
if (!(flgs & IFF_UP))
continue;
- dev_change_flags(vlandev, flgs & ~IFF_UP);
+ vlan = vlan_dev_info(vlandev);
+ if (!(vlan->flags & VLAN_FLAG_LOOSE_BINDING))
+ dev_change_flags(vlandev, flgs & ~IFF_UP);
vlan_transfer_operstate(dev, vlandev);
}
break;
@@ -523,7 +526,9 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
if (flgs & IFF_UP)
continue;
- dev_change_flags(vlandev, flgs | IFF_UP);
+ vlan = vlan_dev_info(vlandev);
+ if (!(vlan->flags & VLAN_FLAG_LOOSE_BINDING))
+ dev_change_flags(vlandev, flgs | IFF_UP);
vlan_transfer_operstate(dev, vlandev);
}
break;
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index de0dc6b..b788978 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -431,7 +431,8 @@ 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))
+ if (mask & ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP |
+ VLAN_FLAG_LOOSE_BINDING))
return -EINVAL;
vlan->flags = (old_flags & ~mask) | (flags & mask);
@@ -456,7 +457,8 @@ static int vlan_dev_open(struct net_device *dev)
struct net_device *real_dev = vlan->real_dev;
int err;
- if (!(real_dev->flags & IFF_UP))
+ if (!(real_dev->flags & IFF_UP) &&
+ !(vlan->flags & VLAN_FLAG_LOOSE_BINDING))
return -ENETDOWN;
if (compare_ether_addr(dev->dev_addr, real_dev->dev_addr)) {
diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
index 3c9cf6a..ddc1057 100644
--- a/net/8021q/vlan_netlink.c
+++ b/net/8021q/vlan_netlink.c
@@ -60,7 +60,8 @@ 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_REORDER_HDR | VLAN_FLAG_GVRP |
+ VLAN_FLAG_LOOSE_BINDING))
return -EINVAL;
}
^ permalink raw reply related
* Re: [RFC PATCH 00/10] Remove skb_dma_map/unmap calls
From: Alexander Duyck @ 2009-11-25 17:25 UTC (permalink / raw)
To: Ajit Khaparde
Cc: mcarlson@broadcom.com, mchan@broadcom.com,
sathyap@serverengines.com, subbus@serverengines.com,
davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <20091125113050.GA19837@serverengines.com>
Ajit Khaparde wrote:
> On 24/11/09 17:20 -0800, Alexander Duyck wrote:
>> This patch series removes the skb_dma_map and skb_dma_unmap function calls.
>> The reason for this change is because the use of skb_dma_map/unmap can lead
>> to serious issues when HW IOMMU is enabled. This is because each mapping
>> of the skb with a HW IOMMU enabled results in a new set of DMA mappings.
>> This in turn leads to issues when skbs are cloned for uses such as
>> bridging or pktgen because each transmitting device will update the skb
>> shared info structure resulting in some mappings being overwritten, and others
>> being freed multiple times.
>
> If this is the case can the members related to the dma mapping stuff
> (skb_shinfo(skb)->dma_maps) be moved out of this shared info structure and
> we retain this "good" abstraction provided by this skb_dma_map/unmap api?
I had submitted a patch on November 5th that tried to move the maps out
of the shared info structure and into the sk_buff itself. That was
rejected and it was suggested to go back to what was there before since
not enough drivers were using the skb_dma_map/unmap calls to justify
increasing the size of an sk_buff.
The biggest issue is that you end up needing to retain a copy of the DMA
mapping output each time it is called and so the easiest place to retain
the information is within the transmit buffer driver specific data
structure.
>> I am looking for input specifically on the tg3, be2net, and bnx2 driver
>> patches as I am not very familiar with them and I am not certain if
>> additional changes are required.
>
>> be2net: remove use of skb_dma_map/unmap
>>
>> drivers/net/benet/be_main.c | 37 ++++++---
>
> We have pulled the be2net specific patch for testing and review.
> We will send an update once done with it.
>
> -Ajit
Thanks for taking a look at this.
Alex
^ permalink raw reply
* Re: dmfe/tulip device id overlap
From: Grant Grundler @ 2009-11-25 17:24 UTC (permalink / raw)
To: Brandon Philips
Cc: Tobias Ringstrom, Kyle McMartin, davem, netdev, Grant Grundler
In-Reply-To: <20091125044944.GL14043@jenkins.home.ifup.org>
On Tue, Nov 24, 2009 at 8:49 PM, Brandon Philips <brandon@ifup.org> wrote:
> Adding Tobias and Grant under (hopefully) working email addresses.
>
> Can you please submit patches to update MAINTAINERS with your
> preferred email?
grundler@parisc-linux.org is my preferred email for tulip driver
issues. Is that bouncing? :(
> On 20:36 Tue 24 Nov 2009, Brandon Philips wrote:
>> Hello All-
>>
>> dmfe and tulip have an overlap of device IDs and it has been discussed
>> before without resolution[1][2].
>>
>> The device ID in particular is:
>>
>> { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>> { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>>
>> Users of Fedora[3] and openSUSE[4] are feeling pain from this but
>> Ubuntu users are avoiding the issue do to the patch below.
>>
>> This patch comes almost directly from the discussion on the
>> linux-sparc thread[2]. So, can we merge that patch? Or can one of the
>> maintainers come up with a less hacky solution (e.g. fix tulip)?
I'm totally ok with "clipping" the DMFE ids so tulip and dmfe drivers
have no overlap. I just can't test it since I don't have those cards.
It sounds like people know which driver works on sparc.
>>
>> Cheers,
>>
>> Brandon
>>
>> [1] http://www.mail-archive.com/debian-sparc@lists.debian.org/msg21647.html
>> [2] http://marc.info/?l=linux-sparc&m=123698905214250&w=2
>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=277731
>> [4] https://bugzilla.novell.com/show_bug.cgi?id=537016
>>
>> From: Ben Collins <bcollins@ubuntu.com>
>> Date: Wed, 18 Jul 2007 17:48:25 +0000 (-0400)
>> Subject: UBUNTU: SAUCE: tulip: Let dmfe handle davicom on non-sparc
>> X-Git-Tag: Ubuntu-2.6.31-10.31~680
>> X-Git-Url: http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-karmic.git;a=commitdiff_plain;h=886595ab493b5c5fcf23b55b3ebf46bfe219a5d0
>>
>> UBUNTU: SAUCE: tulip: Let dmfe handle davicom on non-sparc
>>
>> Signed-off-by: Ben Collins <ben.collins@canonical.com>
I'm ok with this patch except the mention of Ubuntu in the comment is
superfluous. All the distro's will share this problem. I trust davem
to rewrite the comment and plase add my:
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
cheers,
grant
>> ---
>>
>> diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
>> index 4cf9a65..b75f65c 100644
>> --- a/drivers/net/tulip/tulip_core.c
>> +++ b/drivers/net/tulip/tulip_core.c
>> @@ -228,8 +228,12 @@ static struct pci_device_id tulip_pci_tbl[] = {
>> { 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
>> { 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
>> { 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
>> + /* Ubuntu: On non-sparc, this seems to be handled better by the
>> + * dmfe driver. */
>> +#ifdef __sparc__
>> { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>> { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>> +#endif
>> { 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
>> { 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
>> { 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
>
^ permalink raw reply
* Re: Diagnostic Monitoring Interface Monitoring (DOM) PATCH 0/5 for net-next-2.6
From: robert @ 2009-11-25 16:21 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: Robert Olsson, David Miller, netdev
In-Reply-To: <9929d2390911250018o777405ddk257605e7d0b16d17@mail.gmail.com>
Jeff Kirsher writes:
> Robert, to help get more eyes on this I have added it to my tree for
> internal testing and review.
Fine. The igb patch was tested with a 4-port 82576 board from Interface
Masters but they forgot to mount the pull-up resistors for the I2C-bus
on my prototype which took some weeks to debug. Anyway there are working
boards now.
About the the Intel brand 82599 board with fixed SFP's. I don't see any DOM
support from them. It could be idea check if my reading from I2c is correct.
Seems I'll have a SFP+ with DOM support soon.
Cheers
--ro
^ permalink raw reply
* Re: Diagnostic Monitoring Interface Monitoring (DOM) PATCH 0/5 for net-next-2.6
From: robert @ 2009-11-25 16:22 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: Robert Olsson, David Miller, netdev
In-Reply-To: <9929d2390911250119h3e67fb50u2e9d8d3825b0496d@mail.gmail.com>
Jeff Kirsher writes:
> FYI- This patch series is riddled with trailing whitespace, when I
> imported that patches into my tree, I cleaned up all the whitespace
> errors. After some internal testing and review,
> I can re-post the entire series which has been cleaned up.
Please do.
Cheers
--ro
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-25 16:47 UTC (permalink / raw)
To: Jarek Poplawski
Cc: e1000-devel, netdev, Frans Pop, Jesse Brandeburg, linux-kernel,
Andi Kleen, Jeff Kirsher
In-Reply-To: <81bfc67a0911250606k1ec76354n217da9ca20b3517c@mail.gmail.com>
> yeah 2.6.31.6 works on my laptop fine I'll just have to see about
> getting a direct connection to it. probably do that after I bring the
> other NIC back from home, on thanksgiving.
meh scratch that sorta.. screen mounting brackets/joint on laptop
broke... I'm thinking of scrapping it for a netbook. but replacing may
take a few weeks.
--
Caleb Cushing
http://xenoterracide.blogspot.com
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: TCP sockets stalling - help! (long)
From: Asdo @ 2009-11-25 16:38 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: e1000-devel, Netdev
In-Reply-To: <4B0D4EFC.4050302@shiftmail.org>
Asdo wrote:
> Asdo wrote:
>> Ilpo Järvinen wrote:
>>
>>> ...I'd next try strace the sftp server to see what it was doing
>>> during the stall.
>>>
>> Thanks for your help Ilpo
>>
>> Isn't the strace equivalent to the stack trace I obtained via cat
>> /proc/pid/stack reported previously? That was at the time of the stall
>>
>> I'm thinking the strace would slow down sftp-server very deeply...
>>
>
> I found out that if I attach the strace I can see at least the last
> function call.
> The SFTP it's hanged right now so I did that:
>
> root@mystorage:/root# strace -p 11475
> Process 11475 attached - interrupt to quit
> select(5, [3], [], NULL, NULL
>
> (stuck here forever... doesn't move)
> (it's strange the first option of select is 5, shouldn't it be 4 from
> man select? A bug of strace maybe?)
>
> root@mystorage:/root# cat /proc/11475/stack
> [<ffffffff8112e644>] poll_schedule_timeout+0x34/0x50
> [<ffffffff8112ef4f>] do_select+0x58f/0x6b0
> [<ffffffff8112f8b5>] core_sys_select+0x185/0x2b0
> [<ffffffff8112fc32>] sys_select+0x42/0x110
> [<ffffffff8101225b>] tracesys+0xd9/0xde
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> And this is from cat /proc/net/tcp 2: 0F12A8C0:0016 2512A8C0:0FBD 01
> 00000000:00000000 02:00009144 00000000 0 0 5326251 2
> ffff88085408ce00 26 4 1 9 4
>
> The select refers to open files so here they are:
>
>
> root@mystorage:/proc/11475/fd# ll
> total 0
> lr-x------ 1 ccosentino wetlab 64 2009-11-25 14:43 0 -> pipe:[5326309]
> l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 1 -> pipe:[5326310]
> l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 2 -> pipe:[5326311]
> lr-x------ 1 ccosentino wetlab 64 2009-11-25 14:43 3 -> pipe:[5326309]
> l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 4 -> pipe:[5326310]
> l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 5 ->
> /path/to/file_being_saved.filepart
>
> I tried to send SIGSTOP and then SIGCONT to see if I could make it
> make a loop and then reenter into the select. I'm not sure it really
> did that, what do you think? This is the strace:
> root@mystorage:/root# strace -p 11475 2>&1 | tee sftpstrace.dmp
> Process 11475 attached - interrupt to quit
> select(5, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be
> restarted)
> --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
> --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
> select(5, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be
> restarted)
> --- SIGCONT (Continued) @ 0 (0) ---
> select(5, [3], [], NULL, NULL
>
> (hanged again here)
>
>
> Do you think this info is enough or I really have to strace it since
> the beginning?
> If it is a race condition it might not happen if the sftp-server is
> deeply slowed down by the strace.
> If I had a way to make it continue right now we could get the rest of
> the strace... But it's not so easy, I tried starting a Samba transfer
> but it did not unlock the SFTP this time. SIGSTOP + SIGCONT also
> didn't work.
>
> BTW people using the Storage also experienced data loss while pushing
> files in it: appartently data disappeared from the middle of a file
> they were saving to the Storage.
> To me looks like another hint that application-level data which has
> been received via network by TCP stack is trapped there and not being
> pushed to the application.
> Or the data might even be trapped into the anonymous sockets between
> sshd and sftp-server.
>
> Thanks for your help
I thought that it would be more meaningful to try the cat stack, the
strace and the SIGSTOP SIGCONT tricks on the sshd which actually holds
the TCP socket, instead of the sftp-server. Here they are, on the sshd:
root@mystorage:/root# strace -p 11449 2>&1 | tee -a sshd1strace1.dmp
Process 11449 attached - interrupt to quit
read(5, 0x7fff4e956220, 4) = ? ERESTARTSYS (To be restarted)
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
read(5, 0x7fff4e956220, 4) = ? ERESTARTSYS (To be restarted)
--- SIGCONT (Continued) @ 0 (0) ---
read(5,
(hanged again here after the SIGSTOP + SIGCONT, unfortunately)
root@mystorage:/root# cat /proc/11449/stack
[<ffffffff814b428a>] unix_stream_data_wait+0xaa/0x110
[<ffffffff814b50cd>] unix_stream_recvmsg+0x36d/0x570
[<ffffffff81426399>] sock_aio_read+0x149/0x150
[<ffffffff8111e232>] do_sync_read+0xf2/0x130
[<ffffffff8111e8e1>] vfs_read+0x181/0x1a0
[<ffffffff8111edec>] sys_read+0x4c/0x80
[<ffffffff8101225b>] tracesys+0xd9/0xde
[<ffffffffffffffff>] 0xffffffffffffffff
root@mystorage:/proc/11449/fd# ll
total 0
lrwx------ 1 root root 64 2009-11-25 14:43 0 -> /dev/null
lrwx------ 1 root root 64 2009-11-25 14:43 1 -> /dev/null
lrwx------ 1 root root 64 2009-11-25 14:43 2 -> /dev/null
lrwx------ 1 root root 64 2009-11-25 14:43 3 -> socket:[5326251]
lrwx------ 1 root root 64 2009-11-25 14:43 5 -> socket:[5326303]
I would like to try to attach a program of mine (a python interactive)
to "socket:[5326303]" and try to read data from there to see if
something comes out of the TCP stack, but I don't know where to find the
socket:[5326303] on the filesystem. Is it mapped to a file anywhere in
Linux?
Thank you
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* [PATCH] smsc9420: prevent BUG() if ethtool is called with interface down
From: Steve Glendinning @ 2009-11-25 16:21 UTC (permalink / raw)
To: netdev; +Cc: Steve Glendinning
This patch fixes a null pointer dereference BUG() if ethtool is used on
an smsc9420 interface while it is down, because the phy_dev is only
allocated while the interface is up.
Please also consider for -stable.
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
---
drivers/net/smsc9420.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smsc9420.c b/drivers/net/smsc9420.c
index 92e2bbe..12f0f5d 100644
--- a/drivers/net/smsc9420.c
+++ b/drivers/net/smsc9420.c
@@ -252,6 +252,9 @@ static int smsc9420_ethtool_get_settings(struct net_device *dev,
{
struct smsc9420_pdata *pd = netdev_priv(dev);
+ if (!pd->phy_dev)
+ return -ENODEV;
+
cmd->maxtxpkt = 1;
cmd->maxrxpkt = 1;
return phy_ethtool_gset(pd->phy_dev, cmd);
@@ -262,6 +265,9 @@ static int smsc9420_ethtool_set_settings(struct net_device *dev,
{
struct smsc9420_pdata *pd = netdev_priv(dev);
+ if (!pd->phy_dev)
+ return -ENODEV;
+
return phy_ethtool_sset(pd->phy_dev, cmd);
}
@@ -290,6 +296,10 @@ static void smsc9420_ethtool_set_msglevel(struct net_device *netdev, u32 data)
static int smsc9420_ethtool_nway_reset(struct net_device *netdev)
{
struct smsc9420_pdata *pd = netdev_priv(netdev);
+
+ if (!pd->phy_dev)
+ return -ENODEV;
+
return phy_start_aneg(pd->phy_dev);
}
@@ -312,6 +322,10 @@ smsc9420_ethtool_getregs(struct net_device *dev, struct ethtool_regs *regs,
for (i = 0; i < 0x100; i += (sizeof(u32)))
data[j++] = smsc9420_reg_read(pd, i);
+ // cannot read phy registers if the net device is down
+ if (!phy_dev)
+ return;
+
for (i = 0; i <= 31; i++)
data[j++] = smsc9420_mii_read(phy_dev->bus, phy_dev->addr, i);
}
--
1.6.2.5
^ permalink raw reply related
* Re: [patch]USB autosuspend for cdc-ether
From: Oliver Neukum @ 2009-11-25 16:21 UTC (permalink / raw)
To: Steve.Glendinning-sdUf+H5yV5I
Cc: David S. Miller, David Brownell, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, Torgny Johansson
In-Reply-To: <OF4FE9C59B.DA63AAE2-ON80257679.0046C1C2-80257679.004A1287-sdUf+H5yV5I@public.gmane.org>
Am Mittwoch, 25. November 2009 14:29:00 schrieb Steve.Glendinning-sdUf+H5yV5I@public.gmane.org:
> Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org> wrote on 25/11/2009 08:39:33:
> > Hi,
> >
> > this version should fix what you mentioned.
>
> Thanks, it does.
>
> checkpatch.pl still shows 31 errors though, mostly trailing whitespace,
> and the patch doesn't cleanly apply to net-next-2.6. Two hunks fail to
> apply in cdc_ether.c.
Here we go again. The script complains still a bt but that's necessary
to keep a uniform style. Happy with this version?
Against net-next-2.6.
Regards
Oliver
--
commit ab6d67f2f64f087c15c9899447cc297f7fd2e7b2
Author: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Date: Wed Nov 25 16:45:58 2009 +0100
usbnet & cdc-ether: autosuspend for online devices
using remote wakeup and delayed transmission to allow
online device to go into usb autosuspend
minimal alternate support for devices that don't support
remote wakeup
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 71e65fc..b9493ef 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -411,6 +411,12 @@ static int cdc_bind(struct usbnet *dev, struct usb_interface *intf)
return 0;
}
+static int cdc_manage_power(struct usbnet *dev, int on)
+{
+ dev->intf->needs_remote_wakeup = on;
+ return 0;
+}
+
static const struct driver_info cdc_info = {
.description = "CDC Ethernet Device",
.flags = FLAG_ETHER,
@@ -418,6 +424,7 @@ static const struct driver_info cdc_info = {
.bind = cdc_bind,
.unbind = usbnet_cdc_unbind,
.status = cdc_status,
+ .manage_power = cdc_manage_power,
};
static const struct driver_info mbm_info = {
@@ -578,6 +585,7 @@ static struct usb_driver cdc_driver = {
.disconnect = usbnet_disconnect,
.suspend = usbnet_suspend,
.resume = usbnet_resume,
+ .supports_autosuspend = 1,
};
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 378da8c..83cdd46 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -353,7 +353,8 @@ static void rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
if (netif_running (dev->net)
&& netif_device_present (dev->net)
- && !test_bit (EVENT_RX_HALT, &dev->flags)) {
+ && !test_bit (EVENT_RX_HALT, &dev->flags)
+ && !test_bit (EVENT_DEV_ASLEEP, &dev->flags)) {
switch (retval = usb_submit_urb (urb, GFP_ATOMIC)) {
case -EPIPE:
usbnet_defer_kevent (dev, EVENT_RX_HALT);
@@ -611,15 +612,39 @@ EXPORT_SYMBOL_GPL(usbnet_unlink_rx_urbs);
/*-------------------------------------------------------------------------*/
// precondition: never called in_interrupt
+static void usbnet_terminate_urbs(struct usbnet *dev)
+{
+ DECLARE_WAIT_QUEUE_HEAD_ONSTACK(unlink_wakeup);
+ DECLARE_WAITQUEUE(wait, current);
+ int temp;
+
+ /* ensure there are no more active urbs */
+ add_wait_queue(&unlink_wakeup, &wait);
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ dev->wait = &unlink_wakeup;
+ temp = unlink_urbs(dev, &dev->txq) +
+ unlink_urbs(dev, &dev->rxq);
+
+ /* maybe wait for deletions to finish. */
+ while (!skb_queue_empty(&dev->rxq)
+ && !skb_queue_empty(&dev->txq)
+ && !skb_queue_empty(&dev->done)) {
+ schedule_timeout(UNLINK_TIMEOUT_MS);
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ if (netif_msg_ifdown(dev))
+ devdbg(dev, "waited for %d urb completions",
+ temp);
+ }
+ set_current_state(TASK_RUNNING);
+ dev->wait = NULL;
+ remove_wait_queue(&unlink_wakeup, &wait);
+}
int usbnet_stop (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
struct driver_info *info = dev->driver_info;
- int temp;
int retval;
- DECLARE_WAIT_QUEUE_HEAD_ONSTACK (unlink_wakeup);
- DECLARE_WAITQUEUE (wait, current);
netif_stop_queue (net);
@@ -641,25 +666,8 @@ int usbnet_stop (struct net_device *net)
info->description);
}
- if (!(info->flags & FLAG_AVOID_UNLINK_URBS)) {
- /* ensure there are no more active urbs */
- add_wait_queue(&unlink_wakeup, &wait);
- dev->wait = &unlink_wakeup;
- temp = unlink_urbs(dev, &dev->txq) +
- unlink_urbs(dev, &dev->rxq);
-
- /* maybe wait for deletions to finish. */
- while (!skb_queue_empty(&dev->rxq)
- && !skb_queue_empty(&dev->txq)
- && !skb_queue_empty(&dev->done)) {
- msleep(UNLINK_TIMEOUT_MS);
- if (netif_msg_ifdown(dev))
- devdbg(dev, "waited for %d urb completions",
- temp);
- }
- dev->wait = NULL;
- remove_wait_queue(&unlink_wakeup, &wait);
- }
+ if (!(info->flags & FLAG_AVOID_UNLINK_URBS))
+ usbnet_terminate_urbs(dev);
usb_kill_urb(dev->interrupt);
@@ -672,7 +680,10 @@ int usbnet_stop (struct net_device *net)
dev->flags = 0;
del_timer_sync (&dev->delay);
tasklet_kill (&dev->bh);
- usb_autopm_put_interface(dev->intf);
+ if (info->manage_power)
+ info->manage_power(dev, 0);
+ else
+ usb_autopm_put_interface(dev->intf);
return 0;
}
@@ -753,6 +764,12 @@ int usbnet_open (struct net_device *net)
// delay posting reads until we're fully open
tasklet_schedule (&dev->bh);
+ if (info->manage_power) {
+ retval = info->manage_power(dev, 1);
+ if (retval < 0)
+ goto done;
+ usb_autopm_put_interface(dev->intf);
+ }
return retval;
done:
usb_autopm_put_interface(dev->intf);
@@ -881,11 +898,16 @@ kevent (struct work_struct *work)
/* usb_clear_halt() needs a thread context */
if (test_bit (EVENT_TX_HALT, &dev->flags)) {
unlink_urbs (dev, &dev->txq);
+ status = usb_autopm_get_interface(dev->intf);
+ if (status < 0)
+ goto fail_pipe;
status = usb_clear_halt (dev->udev, dev->out);
+ usb_autopm_put_interface(dev->intf);
if (status < 0
&& status != -EPIPE
&& status != -ESHUTDOWN) {
if (netif_msg_tx_err (dev))
+fail_pipe:
deverr (dev, "can't clear tx halt, status %d",
status);
} else {
@@ -896,11 +918,16 @@ kevent (struct work_struct *work)
}
if (test_bit (EVENT_RX_HALT, &dev->flags)) {
unlink_urbs (dev, &dev->rxq);
+ status = usb_autopm_get_interface(dev->intf);
+ if (status < 0)
+ goto fail_halt;
status = usb_clear_halt (dev->udev, dev->in);
+ usb_autopm_put_interface(dev->intf);
if (status < 0
&& status != -EPIPE
&& status != -ESHUTDOWN) {
if (netif_msg_rx_err (dev))
+fail_halt:
deverr (dev, "can't clear rx halt, status %d",
status);
} else {
@@ -919,7 +946,12 @@ kevent (struct work_struct *work)
clear_bit (EVENT_RX_MEMORY, &dev->flags);
if (urb != NULL) {
clear_bit (EVENT_RX_MEMORY, &dev->flags);
+ status = usb_autopm_get_interface(dev->intf);
+ if (status < 0)
+ goto fail_lowmem;
rx_submit (dev, urb, GFP_KERNEL);
+ usb_autopm_put_interface(dev->intf);
+fail_lowmem:
tasklet_schedule (&dev->bh);
}
}
@@ -929,11 +961,18 @@ kevent (struct work_struct *work)
int retval = 0;
clear_bit (EVENT_LINK_RESET, &dev->flags);
+ status = usb_autopm_get_interface(dev->intf);
+ if (status < 0)
+ goto skip_reset;
if(info->link_reset && (retval = info->link_reset(dev)) < 0) {
+ usb_autopm_put_interface(dev->intf);
+skip_reset:
devinfo(dev, "link reset failed (%d) usbnet usb-%s-%s, %s",
retval,
dev->udev->bus->bus_name, dev->udev->devpath,
info->description);
+ } else {
+ usb_autopm_put_interface(dev->intf);
}
}
@@ -971,6 +1010,7 @@ static void tx_complete (struct urb *urb)
case -EPROTO:
case -ETIME:
case -EILSEQ:
+ usb_mark_last_busy(dev->udev);
if (!timer_pending (&dev->delay)) {
mod_timer (&dev->delay,
jiffies + THROTTLE_JIFFIES);
@@ -987,6 +1027,7 @@ static void tx_complete (struct urb *urb)
}
}
+ usb_autopm_put_interface_async(dev->intf);
urb->dev = NULL;
entry->state = tx_done;
defer_bh(dev, skb, &dev->txq);
@@ -1057,14 +1098,34 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
}
}
- spin_lock_irqsave (&dev->txq.lock, flags);
+ spin_lock_irqsave(&dev->txq.lock, flags);
+ retval = usb_autopm_get_interface_async(dev->intf);
+ if (retval < 0) {
+ spin_unlock_irqrestore(&dev->txq.lock, flags);
+ goto drop;
+ }
+
+#ifdef CONFIG_PM
+ /* if this triggers the device is still a sleep */
+ if (test_bit(EVENT_DEV_ASLEEP, &dev->flags)) {
+ /* transmission will be done in resume */
+ usb_anchor_urb(urb, &dev->deferred);
+ /* no use to process more packets */
+ netif_stop_queue(net);
+ spin_unlock_irqrestore(&dev->txq.lock, flags);
+ devdbg(dev, "Delaying transmission for resumption");
+ goto deferred;
+ }
+#endif
switch ((retval = usb_submit_urb (urb, GFP_ATOMIC))) {
case -EPIPE:
netif_stop_queue (net);
usbnet_defer_kevent (dev, EVENT_TX_HALT);
+ usb_autopm_put_interface_async(dev->intf);
break;
default:
+ usb_autopm_put_interface_async(dev->intf);
if (netif_msg_tx_err (dev))
devdbg (dev, "tx: submit urb err %d", retval);
break;
@@ -1088,6 +1149,7 @@ drop:
devdbg (dev, "> tx, len %d, type 0x%x",
length, skb->protocol);
}
+deferred:
return NETDEV_TX_OK;
}
EXPORT_SYMBOL_GPL(usbnet_start_xmit);
@@ -1263,6 +1325,7 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
dev->bh.func = usbnet_bh;
dev->bh.data = (unsigned long) dev;
INIT_WORK (&dev->kevent, kevent);
+ init_usb_anchor(&dev->deferred);
dev->delay.function = usbnet_bh;
dev->delay.data = (unsigned long) dev;
init_timer (&dev->delay);
@@ -1380,13 +1443,23 @@ int usbnet_suspend (struct usb_interface *intf, pm_message_t message)
struct usbnet *dev = usb_get_intfdata(intf);
if (!dev->suspend_count++) {
+ spin_lock_irq(&dev->txq.lock);
+ /* don't autosuspend while transmitting */
+ if (dev->txq.qlen && (message.event & PM_EVENT_AUTO)) {
+ spin_unlock_irq(&dev->txq.lock);
+ return -EBUSY;
+ } else {
+ set_bit(EVENT_DEV_ASLEEP, &dev->flags);
+ spin_unlock_irq(&dev->txq.lock);
+ }
/*
* accelerate emptying of the rx and queues, to avoid
* having everything error out.
*/
netif_device_detach (dev->net);
- (void) unlink_urbs (dev, &dev->rxq);
- (void) unlink_urbs (dev, &dev->txq);
+ usbnet_terminate_urbs(dev);
+ usb_kill_urb(dev->interrupt);
+
/*
* reattach so runtime management can use and
* wake the device
@@ -1400,10 +1473,34 @@ EXPORT_SYMBOL_GPL(usbnet_suspend);
int usbnet_resume (struct usb_interface *intf)
{
struct usbnet *dev = usb_get_intfdata(intf);
+ struct sk_buff *skb;
+ struct urb *res;
+ int retval;
+
+ if (!--dev->suspend_count) {
+ spin_lock_irq(&dev->txq.lock);
+ while ((res = usb_get_from_anchor(&dev->deferred))) {
+
+ printk(KERN_INFO"%s has delayed data\n", __func__);
+ skb = (struct sk_buff *)res->context;
+ retval = usb_submit_urb(res, GFP_ATOMIC);
+ if (retval < 0) {
+ dev_kfree_skb_any(skb);
+ usb_free_urb(res);
+ usb_autopm_put_interface_async(dev->intf);
+ } else {
+ dev->net->trans_start = jiffies;
+ __skb_queue_tail(&dev->txq, skb);
+ }
+ }
- if (!--dev->suspend_count)
+ smp_mb();
+ clear_bit(EVENT_DEV_ASLEEP, &dev->flags);
+ spin_unlock_irq(&dev->txq.lock);
+ if (!(dev->txq.qlen >= TX_QLEN(dev)))
+ netif_start_queue(dev->net);
tasklet_schedule (&dev->bh);
-
+ }
return 0;
}
EXPORT_SYMBOL_GPL(usbnet_resume);
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 86c31b7..a7b92d6 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -55,6 +55,7 @@ struct usbnet {
struct sk_buff_head done;
struct sk_buff_head rxq_pause;
struct urb *interrupt;
+ struct usb_anchor deferred;
struct tasklet_struct bh;
struct work_struct kevent;
@@ -65,6 +66,8 @@ struct usbnet {
# define EVENT_STS_SPLIT 3
# define EVENT_LINK_RESET 4
# define EVENT_RX_PAUSED 5
+# define EVENT_DEV_WAKING 6
+# define EVENT_DEV_ASLEEP 7
};
static inline struct usb_driver *driver_of(struct usb_interface *intf)
@@ -108,6 +111,9 @@ struct driver_info {
/* see if peer is connected ... can sleep */
int (*check_connect)(struct usbnet *);
+ /* (dis)activate runtime power management */
+ int (*manage_power)(struct usbnet *, int);
+
/* for status polling */
void (*status)(struct usbnet *, struct urb *);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* netfilter hooks for IFB device
From: François Delawarde @ 2009-11-25 15:30 UTC (permalink / raw)
To: netdev
Hi,
I'm interested in adding optional netfilter hooks to the IFB device
(enabled by module param), in order to have full IMQ functionality (to
use CONNMARKs and others) without having to add any iptables or
netfilter target.
I'm aiming for something very simple inspired by this older IMQ
implementation:
http://pupa.da.ru/imq/imq.c
The only thing is, I have no idea what to do in the callback function
once the netfilter hooks are registered.
How can I 'steal' the packet in the hook and make it pass through
ifb_xmit to have it enqueued?
Thanks,
François.
^ permalink raw reply
* Re: TCP sockets stalling - help! (long)
From: Asdo @ 2009-11-25 15:36 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: e1000-devel, Netdev
In-Reply-To: <4B0D2C0E.9050101@shiftmail.org>
[-- Attachment #1.1: Type: text/plain, Size: 3381 bytes --]
Asdo wrote:
> Ilpo Järvinen wrote:
>
>> ...I'd next try strace the sftp server to see what it was doing
>> during the stall.
>>
>>
> Thanks for your help Ilpo
>
> Isn't the strace equivalent to the stack trace I obtained via cat
> /proc/pid/stack reported previously? That was at the time of the stall
>
> I'm thinking the strace would slow down sftp-server very deeply...
>
I found out that if I attach the strace I can see at least the last
function call.
The SFTP it's hanged right now so I did that:
root@mystorage:/root# strace -p 11475
Process 11475 attached - interrupt to quit
select(5, [3], [], NULL, NULL
(stuck here forever... doesn't move)
(it's strange the first option of select is 5, shouldn't it be 4 from
man select? A bug of strace maybe?)
root@mystorage:/root# cat /proc/11475/stack
[<ffffffff8112e644>] poll_schedule_timeout+0x34/0x50
[<ffffffff8112ef4f>] do_select+0x58f/0x6b0
[<ffffffff8112f8b5>] core_sys_select+0x185/0x2b0
[<ffffffff8112fc32>] sys_select+0x42/0x110
[<ffffffff8101225b>] tracesys+0xd9/0xde
[<ffffffffffffffff>] 0xffffffffffffffff
And this is from cat /proc/net/tcp
2: 0F12A8C0:0016 2512A8C0:0FBD 01 00000000:00000000 02:00009144
00000000 0 0 5326251 2 ffff88085408ce00 26 4 1 9 4
The select refers to open files so here they are:
root@mystorage:/proc/11475/fd# ll
total 0
lr-x------ 1 ccosentino wetlab 64 2009-11-25 14:43 0 -> pipe:[5326309]
l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 1 -> pipe:[5326310]
l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 2 -> pipe:[5326311]
lr-x------ 1 ccosentino wetlab 64 2009-11-25 14:43 3 -> pipe:[5326309]
l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 4 -> pipe:[5326310]
l-wx------ 1 ccosentino wetlab 64 2009-11-25 14:43 5 ->
/path/to/file_being_saved.filepart
I tried to send SIGSTOP and then SIGCONT to see if I could make it make
a loop and then reenter into the select. I'm not sure it really did
that, what do you think? This is the strace:
root@mystorage:/root# strace -p 11475 2>&1 | tee sftpstrace.dmp
Process 11475 attached - interrupt to quit
select(5, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
select(5, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted)
--- SIGCONT (Continued) @ 0 (0) ---
select(5, [3], [], NULL, NULL
(hanged again here)
Do you think this info is enough or I really have to strace it since the
beginning?
If it is a race condition it might not happen if the sftp-server is
deeply slowed down by the strace.
If I had a way to make it continue right now we could get the rest of
the strace... But it's not so easy, I tried starting a Samba transfer
but it did not unlock the SFTP this time. SIGSTOP + SIGCONT also didn't
work.
BTW people using the Storage also experienced data loss while pushing
files in it: appartently data disappeared from the middle of a file they
were saving to the Storage.
To me looks like another hint that application-level data which has been
received via network by TCP stack is trapped there and not being pushed
to the application.
Or the data might even be trapped into the anonymous sockets between
sshd and sftp-server.
Thanks for your help
[-- Attachment #2: Type: text/plain, Size: 354 bytes --]
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
^ permalink raw reply
* [PATCH net-next-2.6] pktgen: NUMA aware
From: Eric Dumazet @ 2009-11-25 15:01 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List, Andi Kleen
Now my Nehalem dev machine is truly NUMA, time for new patches :)
David, this applies on last pktgen version (after last patches you added in net-2.6).
Thanks
[PATCH net-next-2.6] pktgen: NUMA aware
pktgen threads are bound to given CPU, we can allocate memory for
these threads in a NUMA aware way.
After a pktgen session on two threads, we can check flows memory was
allocated on right node, instead of a not related one.
# grep pktgen_thread_write /proc/vmallocinfo
0xffffc90007204000-0xffffc90007385000 1576960 pktgen_thread_write+0x3a4/0x6b0 [pktgen] pages=384 vmalloc N0=384
0xffffc90007386000-0xffffc90007507000 1576960 pktgen_thread_write+0x3a4/0x6b0 [pktgen] pages=384 vmalloc N1=384
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/pktgen.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 6e79e96..f4f4c50 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3622,6 +3622,7 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
{
struct pktgen_dev *pkt_dev;
int err;
+ int node = cpu_to_node(t->cpu);
/* We don't allow a device to be on several threads */
@@ -3631,12 +3632,13 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
return -EBUSY;
}
- pkt_dev = kzalloc(sizeof(struct pktgen_dev), GFP_KERNEL);
+ pkt_dev = kzalloc_node(sizeof(struct pktgen_dev), GFP_KERNEL, node);
if (!pkt_dev)
return -ENOMEM;
strcpy(pkt_dev->odevname, ifname);
- pkt_dev->flows = vmalloc(MAX_CFLOWS * sizeof(struct flow_state));
+ pkt_dev->flows = vmalloc_node(MAX_CFLOWS * sizeof(struct flow_state),
+ node);
if (pkt_dev->flows == NULL) {
kfree(pkt_dev);
return -ENOMEM;
@@ -3698,7 +3700,8 @@ static int __init pktgen_create_thread(int cpu)
struct proc_dir_entry *pe;
struct task_struct *p;
- t = kzalloc(sizeof(struct pktgen_thread), GFP_KERNEL);
+ t = kzalloc_node(sizeof(struct pktgen_thread), GFP_KERNEL,
+ cpu_to_node(cpu));
if (!t) {
printk(KERN_ERR "pktgen: ERROR: out of memory, can't "
"create new thread.\n");
^ permalink raw reply related
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-25 14:06 UTC (permalink / raw)
To: Jarek Poplawski
Cc: e1000-devel, netdev, Frans Pop, Jesse Brandeburg, linux-kernel,
Andi Kleen, Jeff Kirsher
In-Reply-To: <20091124111946.GA7883@ff.dom.local>
> Alas it's not all information I asked. E.g. "netstat -s before faulty
> kernel" and "netstat -s after faulty kernel" seem to be the same file:
> netstat_after.slave4.log.gz.
sorry I guess I misunderstood what you wanted? (or maybe I just dorked
it when I created all the files) I upped a netstat -s from a good
kernel shortly after reboot.
> Anyway, since there are problems with
> getting stats from the router we still can't compare them, or check
> for the dropped stats. (Btw, could you check for /proc/net/softnet_stat
> yet?)
router? good kernel? bad kernel?
> So, it might be the kernel problem you reported, but there is not
> enough data to prove it. Then my proposal is to try to repeat this
> problem in more "testing friendly" conditions - preferably against
> some other, more up-to-date linux box, if possible?
yeah 2.6.31.6 works on my laptop fine I'll just have to see about
getting a direct connection to it. probably do that after I bring the
other NIC back from home, on thanksgiving.
--
Caleb Cushing
http://xenoterracide.blogspot.com
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* [PATCH] Frame Relay/DLCI coding style corrections.
From: Rudy Matela @ 2009-11-25 14:01 UTC (permalink / raw)
To: mike.mclagan, netdev; +Cc: trivial, linux-kernel
Frame Relay/DLCI coding style corrections.
Added a space separating some keywords (if/while) from the following
parenthesis to conform to the CodingStyle.
Signed-off-by: Rudy Matela <rudy.matela@gmail.com>
---
diff --git a/drivers/net/wan/dlci.c b/drivers/net/wan/dlci.c
index 15d353f..421d071 100644
--- a/drivers/net/wan/dlci.c
+++ b/drivers/net/wan/dlci.c
@@ -77,7 +77,7 @@ static int dlci_header(struct sk_buff *skb, struct net_device *dev,
dlp = netdev_priv(dev);
hdr.control = FRAD_I_UI;
- switch(type)
+ switch (type)
{
case ETH_P_IP:
hdr.IP_NLPID = FRAD_P_IP;
@@ -130,7 +130,7 @@ static void dlci_receive(struct sk_buff *skb, struct net_device *dev)
dev->stats.rx_errors++;
}
else
- switch(hdr->IP_NLPID)
+ switch (hdr->IP_NLPID)
{
case FRAD_P_PADDING:
if (hdr->NLPID != FRAD_P_SNAP)
@@ -208,7 +208,7 @@ static int dlci_config(struct net_device *dev, struct dlci_conf __user *conf, in
if (!get)
{
- if(copy_from_user(&config, conf, sizeof(struct dlci_conf)))
+ if (copy_from_user(&config, conf, sizeof(struct dlci_conf)))
return -EFAULT;
if (config.flags & ~DLCI_VALID_FLAGS)
return(-EINVAL);
@@ -222,7 +222,7 @@ static int dlci_config(struct net_device *dev, struct dlci_conf __user *conf, in
if (get)
{
- if(copy_to_user(conf, &dlp->config, sizeof(struct dlci_conf)))
+ if (copy_to_user(conf, &dlp->config, sizeof(struct dlci_conf)))
return -EFAULT;
}
@@ -238,7 +238,7 @@ static int dlci_dev_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
dlp = netdev_priv(dev);
- switch(cmd)
+ switch (cmd)
{
case DLCI_GET_SLAVE:
if (!*(short *)(dev->dev_addr))
@@ -417,7 +417,7 @@ static int dlci_ioctl(unsigned int cmd, void __user *arg)
if (!capable(CAP_NET_ADMIN))
return(-EPERM);
- if(copy_from_user(&add, arg, sizeof(struct dlci_add)))
+ if (copy_from_user(&add, arg, sizeof(struct dlci_add)))
return -EFAULT;
switch (cmd)
@@ -426,7 +426,7 @@ static int dlci_ioctl(unsigned int cmd, void __user *arg)
err = dlci_add(&add);
if (!err)
- if(copy_to_user(arg, &add, sizeof(struct dlci_add)))
+ if (copy_to_user(arg, &add, sizeof(struct dlci_add)))
return -EFAULT;
break;
^ permalink raw reply related
* Adding IP(v6) address with scope link creates global address
From: Andreas Henriksson @ 2009-11-25 13:59 UTC (permalink / raw)
To: netdev
Hello!
"Jedasothi" reported problems setting scope with iproute on newly added
ipv6 addresses in:
https://bugs.launchpad.net/ubuntu/+source/iproute/+bug/487745
> To reproduce bug run
> ip addr add '::4/64' scope link dev eth0
>
> This results in a line seen with
> ip addr show eth0
> inet6 ::4/64 scope global tentative
>
> The label "global" is seen instead of "link".
This works for me on ipv4 and seems to be only a problem with ipv6.
I think this is a kernel bug. The scope seems to be passed into the
kernel via netlink as specified on the command line.
Looking at the kernel, inet6_rtm_newaddr [1] calls inet6_addr_add [2]
without passing the ifa_scope struct member and then the scope is
generated from the address within the inet6_addr_add function.
It would be nice if someone could verify this and while at it
also whip up a patch and forward to the right person. ;)
[1]: http://lxr.linux.no/#linux+v2.6.31/net/ipv6/addrconf.c#L3263
[2]: http://lxr.linux.no/#linux+v2.6.31/net/ipv6/addrconf.c#L2081
--
Andreas Henriksson
^ permalink raw reply
* Re: [patch]USB autosuspend for cdc-ether
From: Steve.Glendinning-sdUf+H5yV5I @ 2009-11-25 13:29 UTC (permalink / raw)
To: Oliver Neukum
Cc: David S. Miller, David Brownell, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz, Torgny Johansson
In-Reply-To: <200911250939.33127.oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org> wrote on 25/11/2009 08:39:33:
> Hi,
>
> this version should fix what you mentioned.
Thanks, it does.
checkpatch.pl still shows 31 errors though, mostly trailing whitespace,
and the patch doesn't cleanly apply to net-next-2.6. Two hunks fail to
apply in cdc_ether.c.
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: dmfe/tulip device id overlap
From: Ben Hutchings @ 2009-11-25 13:08 UTC (permalink / raw)
To: Brandon Philips
Cc: netdev, Tobias Ringstrom, Grant Grundler, Kyle McMartin, davem
In-Reply-To: <20091125043603.GK14043@jenkins.home.ifup.org>
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
On Tue, 2009-11-24 at 20:36 -0800, Brandon Philips wrote:
> Hello All-
>
> dmfe and tulip have an overlap of device IDs and it has been discussed
> before without resolution[1][2].
>
> The device ID in particular is:
>
> { 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
> { 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
>
> Users of Fedora[3] and openSUSE[4] are feeling pain from this but
> Ubuntu users are avoiding the issue do to the patch below.
[...]
Also an open bug in Debian (#515533). Thanks for pushing this issue.
Ben.
--
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: TCP sockets stalling - help! (long)
From: Asdo @ 2009-11-25 13:07 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: e1000-devel, Netdev
In-Reply-To: <alpine.DEB.2.00.0911251344520.7024@wel-95.cs.helsinki.fi>
Ilpo Järvinen wrote:
> ...I'd next try strace the sftp server to see what it was doing
> during the stall.
>
Thanks for your help Ilpo
Isn't the strace equivalent to the stack trace I obtained via cat
/proc/pid/stack reported previously? That was at the time of the stall
I'm thinking the strace would slow down sftp-server very deeply...
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
^ permalink raw reply
* Re: [PATCH] xfrm: Add SHA384 and SHA512 HMAC authentication algorithms to XFRM
From: Herbert Xu @ 2009-11-25 12:11 UTC (permalink / raw)
To: Martin Willi; +Cc: linux-crypto, netdev, David S. Miller
In-Reply-To: <1259146719-16359-1-git-send-email-martin@strongswan.org>
On Wed, Nov 25, 2009 at 11:58:39AM +0100, Martin Willi wrote:
> These algorithms use a truncation of 192/256 bits, as specified
> in RFC4868.
>
> Signed-off-by: Martin Willi <martin@strongswan.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
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
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