* Re: DSCP values in TCP handshake
From: Stephen Hemminger @ 2011-04-18 15:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Joe Buehler, netdev
In-Reply-To: <1303135512.3137.335.camel@edumazet-laptop>
On Mon, 18 Apr 2011 16:05:12 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 18 avril 2011 à 13:48 +0000, Joe Buehler a écrit :
> > What does the LINUX network code put in the DSCP field of TCP SYN-ACK packets
> > that are replies to a SYN connection request? I have a customer sending SYN
> > with 0x2e in the DSCP field but apparently getting DSCP 0x0 in the reply.
>
> The other way (server->client) is depending on application and listener
> only.
>
> If it uses a standard socket, standard bind() + listen(), TOS is 0
If you want to set DSCP in the response, the application needs to apply
set it on the listening socket.
dscp = 0x2e;
setsockopt(s, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp));
^ permalink raw reply
* ixgbe: about ixgbe_clean_rx_irq
From: wangjun @ 2011-04-18 15:51 UTC (permalink / raw)
To: netdev
hi:
I am learning the codes of ixgbe-3.3.8, and i wonder why
the packet is invalid in ixgbe_main.c:1645 ,
and if no RSC nor Packet Split is configured , we receive
larage packet that may span several descriptors and buffers, what
will the code do in this scene.
thanks !
1645 if (ixgbe_close_active_frag_list(skb) && !pkt_is_rsc) {
1646 /* if we got here without RSC the packet is invalid */
1647 dev_kfree_skb_any(skb);
1648 goto next_desc;
1649 }
^ permalink raw reply
* Re: DSCP values in TCP handshake
From: Mikael Abrahamsson @ 2011-04-18 15:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, Joe Buehler, netdev
In-Reply-To: <20110418083827.05dd2d43@nehalam>
On Mon, 18 Apr 2011, Stephen Hemminger wrote:
> If you want to set DSCP in the response, the application needs to apply
> set it on the listening socket.
> dscp = 0x2e;
> setsockopt(s, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp));
<http://tools.ietf.org/html/rfc2873> says this is ok, but I would like
default to be that if incoming SYN has a certain DSCP value, the SYN+ACK
should mirror this value if the application doesn't explicitly set
anything else.
I was under the impression that mirroring was done historically, but this
has changed? Looking at how my apache server is behaving in 2.6.32, it
seems it uses 0x0 for the whole TOS byte by default. I send it 0x20 and it
responds with 0x0. SSH does the same thing.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: Driver build-testing (was: [PATCH] net: dm9000: Fix build)
From: Mark Brown @ 2011-04-18 16:07 UTC (permalink / raw)
To: Micha? Miros?aw; +Cc: netdev
In-Reply-To: <20110418145102.GA2555@rere.qmqm.pl>
On Mon, Apr 18, 2011 at 04:51:02PM +0200, Micha? Miros?aw wrote:
> I wonder if allyesconfig/allmodconfig is supposed to include code that's
> known not to work for a particular architecture.
Well, it's certainly supposed to include things that aren't *useful*
which is more the point here. all*config is clearly building a
configuration which isn't terribly useful for any particular machine.
^ permalink raw reply
* r8169 : always copying the rx buffer to new skb
From: John Lumby @ 2011-04-18 17:08 UTC (permalink / raw)
To: netdev
Summary - current r8169 always memcpy's every received buffer to new skb,
and I'd like to propose that it should not,
which can improve throughput / reduce CPU utilization by
around 10%
In the patch
2010-10-09 Stanislaw Gruszka r8169: allocate with GFP_KERNEL flag
when able to sleep
the code for making a decision
"shall I copy the buffer to new skb or unhook it from ring to pass
up and allocate new"
based on a module param called rx_copybreak, was removed, and instead
we now always allocate naked data buffers (i.e. not wrapped in skb) and
always memcpy each one to a new skb to pass up to netif.
I think (not sure) this was related to a bug
Bug 629158 Network adapter "disappears" after resuming from acpi suspend
although the change from using GFP_ATOMIC to using GFP_KERNEL for
initial allocation
was made (I believe) in
2010-04-30 Eric Dumazet r8169: Fix rtl8169_rx_interrupt()
So I am not entirely certain of the motivation for the removal of
rx_copybreak and the "always memcpy". But I believe it is not
necessary, at least not on all (most?) systems, and have measured 11%
increase in throughput (aggregate Mbits/sec) on a heavy network
benchmark on my own machine, on 2.6.39-rc2 with rps/rfs enabled, by
patching the code back to the 2.6.39 equivalent of rx_copybreak.
oprofile shows the improvement is all or mostly obtained from avoiding
the memcpy'ing. And of course since the memcpy'ing is done in the
driver before the netif/rps gets it, all that memcpy'ing is done on
CPU0 (I think true on any SMP machine with an rtl8169?)
The measurements are :
aggregate (rx+tx) Mbits/sec through the NIC
2.6.39-rc2 unpatched 918
2.6.39-rc2 patched, rx_copybreak=64 1026
packet rates fluctuate around 60K - 70K pkts/sec rx plus 60K - 70K
pkts/sec tx
I would like to propose that :
. switch back to wrapping databuffers in skb's (so we have the
option of copying or unhooking)
. re-introduce rx_copybreak module param so each sysadmin can
control if wished.
That is my main proposal, and I would be interested to hear thoughts
on that.
As a second proposal (which I made before), I'd like to suggest that
the number of rx buffers allocated at open should be configurable by
module param. This is not needed for my other proposal but may help
reduce the possibility of temporary shortage of buffers. There is
really no justification for assuming that 256 buffers is the correct
number for all systems from a netbook to a 32-way server. I ran my
"patched" measurement with num_rx_buffs=128 and there were no alloc
failures logged. I would say that if there is any enthusiasm for the
main avoid_memcpy proposal, then it is worth the extra small effort to
do the num_rx_buffs as well.
My current patch (including configurable num_rx_buffs) -
lines deleted 120
lines added 668
BTW if this proposal is acceptable, I'm willing to do the patch work
but I have only one machine with a r8169 (actually a RTL8168c) to test on.
John Lumby
^ permalink raw reply
* Re: r8169 : always copying the rx buffer to new skb
From: Ben Hutchings @ 2011-04-18 17:27 UTC (permalink / raw)
To: John Lumby; +Cc: netdev
In-Reply-To: <4DAC7001.9060800@hotmail.com>
On Mon, 2011-04-18 at 13:08 -0400, John Lumby wrote:
> Summary - current r8169 always memcpy's every received buffer to new skb,
> and I'd like to propose that it should not,
> which can improve throughput / reduce CPU utilization by
> around 10%
At least some variants of the hardware have a bug in RX DMA scatter that
can be exploited for denial-of-service. The workaround is to allocate
huge RX buffers (16K). Then, to avoid allocation failures later on (and
to save memory) the buffers must be copied rather than passed up the
stack and reallocated.
[...]
> As a second proposal (which I made before), I'd like to suggest that
> the number of rx buffers allocated at open should be configurable by
> module param.
[...]
No, it should implement the ethtool set_ringparam operation.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Suspend/resume - slow resume
From: Francois Romieu @ 2011-04-18 18:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ciprian Docan, netdev, Linux Kernel Mailing List, Len Brown,
Pavel Machek, Rafael, J. Wysocki
In-Reply-To: <BANLkTi=tPc6NmUuTYqbVZduNRNbE=-c34Q@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> :
[lots of silly bugs]
Ok. it should be fixed for wednesday.
[...]
> - unload not on close, but on device unregister (iow not when you do
> "ifconfig eth0 down", but when the "eth0" device really goes away)
Without further action, the firmware(s) will thus be locked in until the
driver is removed.
> But as mentioned, the above is (a) just my gut feel - please discuss -
> and (b) I really think that leaving this to the network driver has
> been shown to continually result in the drivers doing the firmware
> load/unload in all the wrong places.
As long as it can be fixed... If the 60s delay is removed and the firmware
loading emits some messages for programmer barbie, I am more than happy.
If someone can tell me where Realtek's firmware should be sent to as David
W. seems to be busy, it will be perfect.
--
"Lack of vision" Ueimor
^ permalink raw reply
* Re: [PATCH v2] net: r8169: convert to hw_features
From: Francois Romieu @ 2011-04-18 18:08 UTC (permalink / raw)
To: David Dillow; +Cc: netdev, Realtek, davem
In-Reply-To: <1302718764.3167.7.camel@lap75545.ornl.gov>
[...]
> I've attached my ancient patch, if it helps.
Thanks, it works way better now (see below). It is ok for me to use
you s-o-b on it ?
I have given it a try on 8169, 8168b, 8168d, 8102e and the load can
dramatically fall (more at 1000 Mbps than at 100 Mbps).
David (M.), should it go through net-next or be made ready for net-2.6 ?
Subject: [PATCH] r8169: TSO fixes.
- the MSS value is actually contained in a 11 bits wide (0x7ff) field.
The extra bit in the former MSSMask did encompass the TSO command
bit ("LargeSend") as well (0xfff). Oops.
- the Tx descriptor layout is not the same through the whole chipset
family. The 8169 documentation, the 8168c documentation and Realtek's
drivers (8.020.00, 1.019.00, 6.014.00) highlight two layouts:
1. 8169, 8168 up to 8168b (included) and 8101
2. {8102e, 8168c} and beyond
- notwithstanding the "first descriptor" and "last descriptor" bits, the
same Tx descriptor content is enforced when a packet consists of several
descriptors. The chipsets are documented to require it.
Credits go to David Dillow <dave@thedillows.org> for the original patch.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Realtek <nic_swsd@realtek.com>
---
drivers/net/r8169.c | 209 +++++++++++++++++++++++++++++++++------------------
1 files changed, 137 insertions(+), 72 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 058524f..fb03e6f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -134,47 +134,52 @@ enum mac_version {
RTL_GIGA_MAC_VER_33 = 0x21, // 8168E
};
-#define _R(NAME,MAC,MASK) \
- { .name = NAME, .mac_version = MAC, .RxConfigMask = MASK }
+enum rtl_tx_desc_version {
+ RTL_TD_0 = 0,
+ RTL_TD_1 = 1,
+};
+
+#define _R(NAME,MAC,TD) \
+ { .name = NAME, .mac_version = MAC, .txd_version = TD }
static const struct {
const char *name;
u8 mac_version;
- u32 RxConfigMask; /* Clears the bits supported by this chip */
+ enum rtl_tx_desc_version txd_version;
} rtl_chip_info[] = {
- _R("RTL8169", RTL_GIGA_MAC_VER_01, 0xff7e1880), // 8169
- _R("RTL8169s", RTL_GIGA_MAC_VER_02, 0xff7e1880), // 8169S
- _R("RTL8110s", RTL_GIGA_MAC_VER_03, 0xff7e1880), // 8110S
- _R("RTL8169sb/8110sb", RTL_GIGA_MAC_VER_04, 0xff7e1880), // 8169SB
- _R("RTL8169sc/8110sc", RTL_GIGA_MAC_VER_05, 0xff7e1880), // 8110SCd
- _R("RTL8169sc/8110sc", RTL_GIGA_MAC_VER_06, 0xff7e1880), // 8110SCe
- _R("RTL8102e", RTL_GIGA_MAC_VER_07, 0xff7e1880), // PCI-E
- _R("RTL8102e", RTL_GIGA_MAC_VER_08, 0xff7e1880), // PCI-E
- _R("RTL8102e", RTL_GIGA_MAC_VER_09, 0xff7e1880), // PCI-E
- _R("RTL8101e", RTL_GIGA_MAC_VER_10, 0xff7e1880), // PCI-E
- _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_11, 0xff7e1880), // PCI-E
- _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_12, 0xff7e1880), // PCI-E
- _R("RTL8101e", RTL_GIGA_MAC_VER_13, 0xff7e1880), // PCI-E 8139
- _R("RTL8100e", RTL_GIGA_MAC_VER_14, 0xff7e1880), // PCI-E 8139
- _R("RTL8100e", RTL_GIGA_MAC_VER_15, 0xff7e1880), // PCI-E 8139
- _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_17, 0xff7e1880), // PCI-E
- _R("RTL8101e", RTL_GIGA_MAC_VER_16, 0xff7e1880), // PCI-E
- _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_18, 0xff7e1880), // PCI-E
- _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_19, 0xff7e1880), // PCI-E
- _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_20, 0xff7e1880), // PCI-E
- _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_21, 0xff7e1880), // PCI-E
- _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_22, 0xff7e1880), // PCI-E
- _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_23, 0xff7e1880), // PCI-E
- _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_24, 0xff7e1880), // PCI-E
- _R("RTL8168d/8111d", RTL_GIGA_MAC_VER_25, 0xff7e1880), // PCI-E
- _R("RTL8168d/8111d", RTL_GIGA_MAC_VER_26, 0xff7e1880), // PCI-E
- _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_27, 0xff7e1880), // PCI-E
- _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, 0xff7e1880), // PCI-E
- _R("RTL8105e", RTL_GIGA_MAC_VER_29, 0xff7e1880), // PCI-E
- _R("RTL8105e", RTL_GIGA_MAC_VER_30, 0xff7e1880), // PCI-E
- _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_31, 0xff7e1880), // PCI-E
- _R("RTL8168e/8111e", RTL_GIGA_MAC_VER_32, 0xff7e1880), // PCI-E
- _R("RTL8168e/8111e", RTL_GIGA_MAC_VER_33, 0xff7e1880) // PCI-E
+ _R("RTL8169", RTL_GIGA_MAC_VER_01, RTL_TD_0), // 8169
+ _R("RTL8169s", RTL_GIGA_MAC_VER_02, RTL_TD_0), // 8169S
+ _R("RTL8110s", RTL_GIGA_MAC_VER_03, RTL_TD_0), // 8110S
+ _R("RTL8169sb/8110sb", RTL_GIGA_MAC_VER_04, RTL_TD_0), // 8169SB
+ _R("RTL8169sc/8110sc", RTL_GIGA_MAC_VER_05, RTL_TD_0), // 8110SCd
+ _R("RTL8169sc/8110sc", RTL_GIGA_MAC_VER_06, RTL_TD_0), // 8110SCe
+ _R("RTL8102e", RTL_GIGA_MAC_VER_07, RTL_TD_1), // PCI-E
+ _R("RTL8102e", RTL_GIGA_MAC_VER_08, RTL_TD_1), // PCI-E
+ _R("RTL8102e", RTL_GIGA_MAC_VER_09, RTL_TD_1), // PCI-E
+ _R("RTL8101e", RTL_GIGA_MAC_VER_10, RTL_TD_0), // PCI-E
+ _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_11, RTL_TD_0), // PCI-E
+ _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_12, RTL_TD_0), // PCI-E
+ _R("RTL8101e", RTL_GIGA_MAC_VER_13, RTL_TD_0), // PCI-E 8139
+ _R("RTL8100e", RTL_GIGA_MAC_VER_14, RTL_TD_0), // PCI-E 8139
+ _R("RTL8100e", RTL_GIGA_MAC_VER_15, RTL_TD_0), // PCI-E 8139
+ _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_17, RTL_TD_0), // PCI-E
+ _R("RTL8101e", RTL_GIGA_MAC_VER_16, RTL_TD_0), // PCI-E
+ _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_18, RTL_TD_1), // PCI-E
+ _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_19, RTL_TD_1), // PCI-E
+ _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_20, RTL_TD_1), // PCI-E
+ _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_21, RTL_TD_1), // PCI-E
+ _R("RTL8168c/8111c", RTL_GIGA_MAC_VER_22, RTL_TD_1), // PCI-E
+ _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_23, RTL_TD_1), // PCI-E
+ _R("RTL8168cp/8111cp", RTL_GIGA_MAC_VER_24, RTL_TD_1), // PCI-E
+ _R("RTL8168d/8111d", RTL_GIGA_MAC_VER_25, RTL_TD_1), // PCI-E
+ _R("RTL8168d/8111d", RTL_GIGA_MAC_VER_26, RTL_TD_1), // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_27, RTL_TD_1), // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, RTL_TD_1), // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_29, RTL_TD_1), // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_30, RTL_TD_1), // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_31, RTL_TD_1), // PCI-E
+ _R("RTL8168e/8111e", RTL_GIGA_MAC_VER_32, RTL_TD_1), // PCI-E
+ _R("RTL8168e/8111e", RTL_GIGA_MAC_VER_33, RTL_TD_1) // PCI-E
};
#undef _R
@@ -230,6 +235,9 @@ enum rtl_registers {
IntrStatus = 0x3e,
TxConfig = 0x40,
RxConfig = 0x44,
+
+#define RTL_RX_CONFIG_MASK 0xff7e1880u
+
RxMissed = 0x4c,
Cfg9346 = 0x50,
Config0 = 0x51,
@@ -452,21 +460,69 @@ enum rtl_register_content {
CounterDump = 0x8,
};
-enum desc_status_bit {
+enum rtl_desc_bit {
+ /* First doubleword. */
DescOwn = (1 << 31), /* Descriptor is owned by NIC */
RingEnd = (1 << 30), /* End of descriptor ring */
FirstFrag = (1 << 29), /* First segment of a packet */
LastFrag = (1 << 28), /* Final segment of a packet */
+};
+
+/* Generic case. */
+enum rtl_tx_desc_bit {
+ /* First doubleword. */
+ TD_LSO = (1 << 27), /* Large Send Offload */
+#define TD_MSS_MAX 0x07ffu /* MSS value */
- /* Tx private */
- LargeSend = (1 << 27), /* TCP Large Send Offload (TSO) */
- MSSShift = 16, /* MSS value position */
- MSSMask = 0xfff, /* MSS value + LargeSend bit: 12 bits */
- IPCS = (1 << 18), /* Calculate IP checksum */
- UDPCS = (1 << 17), /* Calculate UDP/IP checksum */
- TCPCS = (1 << 16), /* Calculate TCP/IP checksum */
- TxVlanTag = (1 << 17), /* Add VLAN tag */
+ /* Second doubleword. */
+ TxVlanTag = (1 << 17), /* Add VLAN tag */
+};
+
+/* 8169, 8168b and 810x except 8102e. */
+enum rtl_tx_desc_bit_0 {
+ /* First doubleword. */
+#define TD0_MSS_SHIFT 16 /* MSS position (11 bits) */
+ TD0_TCP_CS = (1 << 16), /* Calculate TCP/IP checksum */
+ TD0_UDP_CS = (1 << 17), /* Calculate UDP/IP checksum */
+ TD0_IP_CS = (1 << 18), /* Calculate IP checksum */
+};
+
+/* 8102e, 8168c and beyond. */
+enum rtl_tx_desc_bit_1 {
+ /* Second doubleword. */
+#define TD1_MSS_SHIFT 18 /* MSS position (11 bits) */
+ TD1_IP_CS = (1 << 29), /* Calculate IP checksum */
+ TD1_TCP_CS = (1 << 30), /* Calculate TCP/IP checksum */
+ TD1_UDP_CS = (1 << 31), /* Calculate UDP/IP checksum */
+};
+static const struct rtl_tx_desc_info {
+ struct {
+ u32 udp;
+ u32 tcp;
+ } checksum;
+ u16 mss_shift;
+ u16 opts_offset;
+} tx_desc_info [] = {
+ [RTL_TD_0] = {
+ .checksum = {
+ .udp = TD0_IP_CS | TD0_UDP_CS,
+ .tcp = TD0_IP_CS | TD0_TCP_CS
+ },
+ .mss_shift = TD0_MSS_SHIFT,
+ .opts_offset = 0
+ },
+ [RTL_TD_1] = {
+ .checksum = {
+ .udp = TD1_IP_CS | TD1_UDP_CS,
+ .tcp = TD1_IP_CS | TD1_TCP_CS
+ },
+ .mss_shift = TD1_MSS_SHIFT,
+ .opts_offset = 1
+ }
+};
+
+enum rtl_rx_desc_bit {
/* Rx private */
PID1 = (1 << 18), /* Protocol ID bit 1/2 */
PID0 = (1 << 17), /* Protocol ID bit 2/2 */
@@ -531,8 +587,8 @@ struct rtl8169_private {
struct napi_struct napi;
spinlock_t lock; /* spin lock flag */
u32 msg_enable;
- int chipset;
- int mac_version;
+ u16 txd_version;
+ u16 mac_version;
u32 cur_rx; /* Index into the Rx descriptor buffer of next Rx pkt. */
u32 cur_tx; /* Index into the Tx descriptor buffer of next Rx pkt. */
u32 dirty_rx;
@@ -1288,7 +1344,7 @@ static int rtl8169_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
static u32 rtl8169_fix_features(struct net_device *dev, u32 features)
{
- if (dev->mtu > MSSMask)
+ if (dev->mtu > TD_MSS_MAX)
features &= ~NETIF_F_ALL_TSO;
return features;
@@ -3194,7 +3250,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
struct mii_if_info *mii;
struct net_device *dev;
void __iomem *ioaddr;
- unsigned int i;
+ int chipset, i;
int rc;
if (netif_msg_drv(&debug)) {
@@ -3336,7 +3392,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
"driver bug, MAC version not found in rtl_chip_info\n");
goto err_out_msi_4;
}
- tp->chipset = i;
+ chipset = i;
+ tp->txd_version = rtl_chip_info[chipset].txd_version;
RTL_W8(Cfg9346, Cfg9346_Unlock);
RTL_W8(Config1, RTL_R8(Config1) | PMEnable);
@@ -3413,8 +3470,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, dev);
netif_info(tp, probe, dev, "%s at 0x%lx, %pM, XID %08x IRQ %d\n",
- rtl_chip_info[tp->chipset].name,
- dev->base_addr, dev->dev_addr,
+ rtl_chip_info[chipset].name, dev->base_addr, dev->dev_addr,
(u32)(RTL_R32(TxConfig) & 0x9cf0f8ff), dev->irq);
if ((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
@@ -3572,7 +3628,7 @@ static void rtl_set_rx_tx_config_registers(struct rtl8169_private *tp)
void __iomem *ioaddr = tp->mmio_addr;
u32 cfg = rtl8169_rx_config;
- cfg |= (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset].RxConfigMask);
+ cfg |= (RTL_R32(RxConfig) & RTL_RX_CONFIG_MASK);
RTL_W32(RxConfig, cfg);
/* Set DMA burst size and Interframe Gap Time */
@@ -4564,7 +4620,7 @@ static void rtl8169_tx_timeout(struct net_device *dev)
}
static int rtl8169_xmit_frags(struct rtl8169_private *tp, struct sk_buff *skb,
- u32 opts1)
+ u32 *opts)
{
struct skb_shared_info *info = skb_shinfo(skb);
unsigned int cur_frag, entry;
@@ -4592,9 +4648,11 @@ static int rtl8169_xmit_frags(struct rtl8169_private *tp, struct sk_buff *skb,
}
/* anti gcc 2.95.3 bugware (sic) */
- status = opts1 | len | (RingEnd * !((entry + 1) % NUM_TX_DESC));
+ status = opts[0] | len |
+ (RingEnd * !((entry + 1) % NUM_TX_DESC));
txd->opts1 = cpu_to_le32(status);
+ txd->opts2 = cpu_to_le32(opts[1]);
txd->addr = cpu_to_le64(mapping);
tp->tx_skb[entry].len = len;
@@ -4612,23 +4670,26 @@ err_out:
return -EIO;
}
-static inline u32 rtl8169_tso_csum(struct sk_buff *skb, struct net_device *dev)
+static inline void rtl8169_tso_csum(struct rtl8169_private *tp,
+ struct sk_buff *skb, u32 *opts)
{
+ const struct rtl_tx_desc_info *info = tx_desc_info + tp->txd_version;
u32 mss = skb_shinfo(skb)->gso_size;
+ int offset = info->opts_offset;
- if (mss)
- return LargeSend | ((mss & MSSMask) << MSSShift);
-
- if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ if (mss) {
+ opts[0] |= TD_LSO;
+ opts[offset] |= min(mss, TD_MSS_MAX) << info->mss_shift;
+ } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
const struct iphdr *ip = ip_hdr(skb);
if (ip->protocol == IPPROTO_TCP)
- return IPCS | TCPCS;
+ opts[offset] |= info->checksum.tcp;
else if (ip->protocol == IPPROTO_UDP)
- return IPCS | UDPCS;
- WARN_ON(1); /* we need a WARN() */
+ opts[offset] |= info->checksum.udp;
+ else
+ WARN_ON_ONCE(1);
}
- return 0;
}
static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
@@ -4641,7 +4702,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
struct device *d = &tp->pci_dev->dev;
dma_addr_t mapping;
u32 status, len;
- u32 opts1;
+ u32 opts[2];
int frags;
if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) {
@@ -4662,24 +4723,28 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
tp->tx_skb[entry].len = len;
txd->addr = cpu_to_le64(mapping);
- txd->opts2 = cpu_to_le32(rtl8169_tx_vlan_tag(tp, skb));
- opts1 = DescOwn | rtl8169_tso_csum(skb, dev);
+ opts[1] = cpu_to_le32(rtl8169_tx_vlan_tag(tp, skb));
+ opts[0] = DescOwn;
- frags = rtl8169_xmit_frags(tp, skb, opts1);
+ rtl8169_tso_csum(tp, skb, opts);
+
+ frags = rtl8169_xmit_frags(tp, skb, opts);
if (frags < 0)
goto err_dma_1;
else if (frags)
- opts1 |= FirstFrag;
+ opts[0] |= FirstFrag;
else {
- opts1 |= FirstFrag | LastFrag;
+ opts[0] |= FirstFrag | LastFrag;
tp->tx_skb[entry].skb = skb;
}
+ txd->opts2 = cpu_to_le32(opts[1]);
+
wmb();
/* anti gcc 2.95.3 bugware (sic) */
- status = opts1 | len | (RingEnd * !((entry + 1) % NUM_TX_DESC));
+ status = opts[0] | len | (RingEnd * !((entry + 1) % NUM_TX_DESC));
txd->opts1 = cpu_to_le32(status);
tp->cur_tx += frags + 1;
@@ -5167,7 +5232,7 @@ static void rtl_set_rx_mode(struct net_device *dev)
spin_lock_irqsave(&tp->lock, flags);
tmp = rtl8169_rx_config | rx_mode |
- (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset].RxConfigMask);
+ (RTL_R32(RxConfig) & RTL_RX_CONFIG_MASK);
if (tp->mac_version > RTL_GIGA_MAC_VER_06) {
u32 data = mc_filter[0];
--
1.7.4.2
^ permalink raw reply related
* Re: r8169 : always copying the rx buffer to new skb
From: Francois Romieu @ 2011-04-18 18:21 UTC (permalink / raw)
To: John Lumby; +Cc: netdev, nic_swsd
In-Reply-To: <4DAC7001.9060800@hotmail.com>
John Lumby <johnlumby@hotmail.com> :
> Summary - current r8169 always memcpy's every received buffer to new skb,
> and I'd like to propose that it should not,
> which can improve throughput / reduce CPU utilization by
> around 10%
Disclaimer: I'll read your suggestion more carefully when I am back home.
I am late and I could be off-topic.
> I think (not sure) this was related to a bug
Short answer: it's mostly related to CVE-2009-4537 (see git log).
I may resurrect some alternate fix - i.e. detect corrupted Tx descriptors
and reset before things gets wrong - but it is not easy to prove it right
since it may be necessary to tailor it for each member of the 816x / 810x
family. Some input from Realtek may help though.
--
Ueimor
^ permalink raw reply
* Re: Suspend/resume - slow resume
From: Linus Torvalds @ 2011-04-18 18:49 UTC (permalink / raw)
To: Francois Romieu
Cc: Ciprian Docan, netdev, Linux Kernel Mailing List, Len Brown,
Pavel Machek, Rafael, J. Wysocki, Greg KH
In-Reply-To: <20110418180813.GA18469@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]
On Mon, Apr 18, 2011 at 11:08 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> [...]
>> - unload not on close, but on device unregister (iow not when you do
>> "ifconfig eth0 down", but when the "eth0" device really goes away)
>
> Without further action, the firmware(s) will thus be locked in until the
> driver is removed.
I do agree. It's a downside. Maybe doing it in "close()" is the right
thing, as long as we don't have that crazy "every four timer ticks"
situation with rtl8169_reinit_task.
As mentioned, the only real reason for me to be worried about the
close thing is that I don't have a good feel for what happens at boot
time. Are the setup scripts going to look at the interface lots of
times? On my desktop, I couldn't care less, but I try to keep boot
time in mind.
Maybe in practice there's just a single open at boot-time (for dhcp or
whatever), and I'm just worried for no good reason.
Without having looked at that whole rtl8169_reinit_task thing, I
probably wouldn't even worry about anything else doing something
similar ;)
> As long as it can be fixed... If the 60s delay is removed and the firmware
> loading emits some messages for programmer barbie, I am more than happy.
So the firmware loading timeout used to be ten seconds (which I
already think is excessive), but then commit
2f65168de7d68a5795e945e781d85b313bdc97b9 increased it to 60s because
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174589
The ipw driver sometimes takes a long time to load its firmware.
Whilst the ipw driver should be using the async interface of
the firmware loader to make this a non-issue, this is a minimal fix.
although when I actually look at that bugzilla entry, the _timestamps_
for the failed case do not seem to support this being a timeout.
Very odd.
But the real problem is that we do that timeout even in cases where it
cannot help, ie when people load firmware during early boot or during
suspend. So I think drivers/base/firmware_class.c should be made a bit
smarter.
We have a few cases where call_usermodehelper() fails immediately:
- khelper_wq hasn't been set up yet
- usermodehelper_disabled is set.
and in particular, during suspend/resume, that
"usermodehelper_disabled" flag will be set.
I don't think it is sensible to do a user request for firmware during
that time either, and that 60-second timeout is just silly. It's not
going to help.
Why doesn't the firmware loader class check the error return from the
kobject_uevent()? I'd expect that if that fails, we should just warn
and abort, rather than wait 60 seconds to time out. Greg?
TOTALLY UNTESTED PATCH ATTACHED!
Ciprian - does this get rid of the 60-second wait? Do you get a nice
kernel traceback in your dmesg instead?
> If someone can tell me where Realtek's firmware should be sent to as David
> W. seems to be busy, it will be perfect.
Hmm. Dunno about that.
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 625 bytes --]
drivers/base/firmware_class.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8c798ef7f13f..956dd34e59da 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -549,7 +549,8 @@ static int _request_firmware(const struct firmware **firmware_p,
round_jiffies_up(jiffies +
loading_timeout * HZ));
- kobject_uevent(&fw_priv->dev.kobj, KOBJ_ADD);
+ if (WARN_ON(kobject_uevent(&fw_priv->dev.kobj, KOBJ_ADD)))
+ fw_load_abort(fw_priv);
}
wait_for_completion(&fw_priv->completion);
^ permalink raw reply related
* Re: [PATCH net-next-2.6 3/3] bonding,ipv4,ipv6,vlan: Handle NETDEV_BONDING_FAILOVER like NETDEV_NOTIFY_PEERS
From: Ben Hutchings @ 2011-04-18 19:09 UTC (permalink / raw)
To: Jay Vosburgh
Cc: David Miller, Andy Gospodarek, Patrick McHardy, netdev,
Brian Haley
In-Reply-To: <22334.1302913805@death>
On Fri, 2011-04-15 at 17:30 -0700, Jay Vosburgh wrote:
> Ben Hutchings <bhutchings@solarflare.com> wrote:
>
> >It is undesirable for the bonding driver to be poking into higher
> >level protocols, and notifiers provide a way to avoid that. This does
> >mean removing the ability to configure reptitition of gratuitous ARPs
> >and unsolicited NAs.
>
> In principle I think this is a good thing (getting rid of some
> of those dependencies, duplicated code, etc).
>
> However, the removal of the multiple grat ARP and NAs may be an
> issue for some users. I don't know that we can just remove this (along
> with its API) without going through the feature removal process.
Right.
> As I recall, the multiple gratuitous ARP stuff was added for
> Infiniband, because it is dependent on the grat ARP for a smooth
> failover.
>
> There is also currently logic to check the linkwatch link state
> to wait for the link to go up prior to sending a grat ARP; this is also
> for IB.
Why would we activate a slave without link up? Perhaps if the previous
active slave is removed?
> Brian Haley added the unsolicited NAs; I've added him to the cc
> so perhaps he (or somebody else) can comment on the necessity of keeping
> the ability to send multiple NAs.
[...]
How about restoring the parameters like this:
---
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 18 Apr 2011 19:36:48 +0100
Subject: [PATCH net-next-2.6] ipv4,ipv6,bonding: Restore control over number of peer notifications
For backward compatibility, we should retain the module parameters and
sysfs attributes to control the number of peer notifications
(gratuitous ARPs and unsolicited NAs) sent after bonding failover.
Also, it is possible for failover to take place even though the new
active slave does not have link up, and in that case the peer
notification should be deferred until it does.
Change ipv4 and ipv6 so they do not automatically send peer
notifications on bonding failover. Change the bonding driver to send
separate NETDEV_NOTIFY_PEERS notifications when the link is up, as
many times as requested. Since it does not directly control which
protocols send notifications, make num_grat_arp and num_unsol_na
aliases for a single parameter.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Documentation/networking/bonding.txt | 31 ++++++++----------
drivers/net/bonding/bond_main.c | 59 ++++++++++++++++++++++++++++++++++
drivers/net/bonding/bond_sysfs.c | 26 +++++++++++++++
drivers/net/bonding/bonding.h | 2 +
net/ipv4/devinet.c | 1 -
net/ipv6/ndisc.c | 1 -
6 files changed, 101 insertions(+), 19 deletions(-)
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index e27202b..511b4e5 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -1,7 +1,7 @@
Linux Ethernet Bonding Driver HOWTO
- Latest update: 23 September 2009
+ Latest update: 18 April 2011
Initial release : Thomas Davis <tadavis at lbl.gov>
Corrections, HA extensions : 2000/10/03-15 :
@@ -585,25 +585,22 @@ mode
chosen.
num_grat_arp
-
- Specifies the number of gratuitous ARPs to be issued after a
- failover event. One gratuitous ARP is issued immediately after
- the failover, subsequent ARPs are sent at a rate of one per link
- monitor interval (arp_interval or miimon, whichever is active).
-
- The valid range is 0 - 255; the default value is 1. This option
- affects only the active-backup mode. This option was added for
- bonding version 3.3.0.
-
num_unsol_na
- Specifies the number of unsolicited IPv6 Neighbor Advertisements
- to be issued after a failover event. One unsolicited NA is issued
- immediately after the failover.
+ Specify the number of peer notifications (gratuitous ARPs and
+ unsolicited IPv6 Neighbor Advertisements) to be issued after a
+ failover event. As soon as the link is up on the new slave
+ (possibly immediately) a peer notification is sent on the
+ bonding device and each VLAN sub-device. This is repeated at
+ each link monitor interval (arp_interval or miimon, whichever
+ is active) if the number is greater than 1.
+
+ These notifications are now generated by the ipv4 and ipv6 code
+ and the numbers of repetitions cannot be set independently.
- The valid range is 0 - 255; the default value is 1. This option
- affects only the active-backup mode. This option was added for
- bonding version 3.4.0.
+ The valid range is 0 - 255; the default value is 1. These options
+ affect only the active-backup mode. These options were added for
+ bonding versions 3.3.0 and 3.4.0 respectively.
primary
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5cd4766..c9043db 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -89,6 +89,7 @@
static int max_bonds = BOND_DEFAULT_MAX_BONDS;
static int tx_queues = BOND_DEFAULT_TX_QUEUES;
+static int num_peer_notif = 1;
static int miimon = BOND_LINK_MON_INTERV;
static int updelay;
static int downdelay;
@@ -111,6 +112,10 @@ module_param(max_bonds, int, 0);
MODULE_PARM_DESC(max_bonds, "Max number of bonded devices");
module_param(tx_queues, int, 0);
MODULE_PARM_DESC(tx_queues, "Max number of transmit queues (default = 16)");
+module_param_named(num_grat_arp, num_peer_notif, int, 0644);
+MODULE_PARM_DESC(num_grat_arp, "Number of peer notifications to send on failover event");
+module_param_named(num_unsol_na, num_peer_notif, int, 0644);
+MODULE_PARM_DESC(num_unsol_na, "Number of peer notifications to send on failover event");
module_param(miimon, int, 0);
MODULE_PARM_DESC(miimon, "Link check interval in milliseconds");
module_param(updelay, int, 0);
@@ -1080,6 +1085,21 @@ static struct slave *bond_find_best_slave(struct bonding *bond)
return bestslave;
}
+static bool bond_should_notify_peers(struct bonding *bond)
+{
+ struct slave *slave = bond->curr_active_slave;
+
+ pr_debug("bond_should_notify_peers: bond %s slave %s\n",
+ bond->dev->name, slave ? slave->dev->name : "NULL");
+
+ if (!slave || !bond->send_peer_notif ||
+ test_bit(__LINK_STATE_LINKWATCH_PENDING, &slave->dev->state))
+ return false;
+
+ bond->send_peer_notif--;
+ return true;
+}
+
/**
* change_active_interface - change the active slave into the specified one
* @bond: our bonding struct
@@ -1147,16 +1167,28 @@ void bond_change_active_slave(struct bonding *bond, struct slave *new_active)
bond_set_slave_inactive_flags(old_active);
if (new_active) {
+ bool should_notify_peers = false;
+
bond_set_slave_active_flags(new_active);
if (bond->params.fail_over_mac)
bond_do_fail_over_mac(bond, new_active,
old_active);
+ if (netif_running(bond->dev)) {
+ bond->send_peer_notif =
+ bond->params.num_peer_notif;
+ should_notify_peers =
+ bond_should_notify_peers(bond);
+ }
+
write_unlock_bh(&bond->curr_slave_lock);
read_unlock(&bond->lock);
netdev_bonding_change(bond->dev, NETDEV_BONDING_FAILOVER);
+ if (should_notify_peers)
+ netdev_bonding_change(bond->dev,
+ NETDEV_NOTIFY_PEERS);
read_lock(&bond->lock);
write_lock_bh(&bond->curr_slave_lock);
@@ -2555,6 +2587,7 @@ void bond_mii_monitor(struct work_struct *work)
{
struct bonding *bond = container_of(work, struct bonding,
mii_work.work);
+ bool should_notify_peers = false;
read_lock(&bond->lock);
if (bond->kill_timers)
@@ -2563,6 +2596,8 @@ void bond_mii_monitor(struct work_struct *work)
if (bond->slave_cnt == 0)
goto re_arm;
+ should_notify_peers = bond_should_notify_peers(bond);
+
if (bond_miimon_inspect(bond)) {
read_unlock(&bond->lock);
rtnl_lock();
@@ -2581,6 +2616,12 @@ re_arm:
msecs_to_jiffies(bond->params.miimon));
out:
read_unlock(&bond->lock);
+
+ if (should_notify_peers) {
+ rtnl_lock();
+ netdev_bonding_change(bond->dev, NETDEV_NOTIFY_PEERS);
+ rtnl_unlock();
+ }
}
static __be32 bond_glean_dev_ip(struct net_device *dev)
@@ -3178,6 +3219,7 @@ void bond_activebackup_arp_mon(struct work_struct *work)
{
struct bonding *bond = container_of(work, struct bonding,
arp_work.work);
+ bool should_notify_peers = false;
int delta_in_ticks;
read_lock(&bond->lock);
@@ -3190,6 +3232,8 @@ void bond_activebackup_arp_mon(struct work_struct *work)
if (bond->slave_cnt == 0)
goto re_arm;
+ should_notify_peers = bond_should_notify_peers(bond);
+
if (bond_ab_arp_inspect(bond, delta_in_ticks)) {
read_unlock(&bond->lock);
rtnl_lock();
@@ -3209,6 +3253,12 @@ re_arm:
queue_delayed_work(bond->wq, &bond->arp_work, delta_in_ticks);
out:
read_unlock(&bond->lock);
+
+ if (should_notify_peers) {
+ rtnl_lock();
+ netdev_bonding_change(bond->dev, NETDEV_NOTIFY_PEERS);
+ rtnl_unlock();
+ }
}
/*-------------------------- netdev event handling --------------------------*/
@@ -3568,6 +3618,8 @@ static int bond_close(struct net_device *bond_dev)
write_lock_bh(&bond->lock);
+ bond->send_peer_notif = 0;
+
/* signal timers not to re-arm */
bond->kill_timers = 1;
@@ -4644,6 +4696,12 @@ static int bond_check_params(struct bond_params *params)
use_carrier = 1;
}
+ if (num_peer_notif < 0 || num_peer_notif > 255) {
+ pr_warning("Warning: num_grat_arp/num_unsol_na (%d) not in range 0-255 so it was reset to 1\n",
+ num_peer_notif);
+ num_peer_notif = 1;
+ }
+
/* reset values for 802.3ad */
if (bond_mode == BOND_MODE_8023AD) {
if (!miimon) {
@@ -4833,6 +4891,7 @@ static int bond_check_params(struct bond_params *params)
params->mode = bond_mode;
params->xmit_policy = xmit_hashtype;
params->miimon = miimon;
+ params->num_peer_notif = num_peer_notif;
params->arp_interval = arp_interval;
params->arp_validate = arp_validate_value;
params->updelay = updelay;
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 259ff32..58fb3e9 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -874,6 +874,30 @@ static DEVICE_ATTR(ad_select, S_IRUGO | S_IWUSR,
bonding_show_ad_select, bonding_store_ad_select);
/*
+ * Show and set the number of peer notifications to send after a failover event.
+ */
+static ssize_t bonding_show_num_peer_notif(struct device *d,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct bonding *bond = to_bond(d);
+ return sprintf(buf, "%d\n", bond->params.num_peer_notif);
+}
+
+static ssize_t bonding_store_num_peer_notif(struct device *d,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct bonding *bond = to_bond(d);
+ int err = kstrtou8(buf, 10, &bond->params.num_peer_notif);
+ return err ? err : count;
+}
+static DEVICE_ATTR(num_grat_arp, S_IRUGO | S_IWUSR,
+ bonding_show_num_peer_notif, bonding_store_num_peer_notif);
+static DEVICE_ATTR(num_unsol_na, S_IRUGO | S_IWUSR,
+ bonding_show_num_peer_notif, bonding_store_num_peer_notif);
+
+/*
* Show and set the MII monitor interval. There are two tricky bits
* here. First, if MII monitoring is activated, then we must disable
* ARP monitoring. Second, if the timer isn't running, we must
@@ -1572,6 +1596,8 @@ static struct attribute *per_bond_attrs[] = {
&dev_attr_lacp_rate.attr,
&dev_attr_ad_select.attr,
&dev_attr_xmit_hash_policy.attr,
+ &dev_attr_num_grat_arp.attr,
+ &dev_attr_num_unsol_na.attr,
&dev_attr_miimon.attr,
&dev_attr_primary.attr,
&dev_attr_primary_reselect.attr,
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 77180b1..5bf3b89 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -149,6 +149,7 @@ struct bond_params {
int mode;
int xmit_policy;
int miimon;
+ u8 num_peer_notif;
int arp_interval;
int arp_validate;
int use_carrier;
@@ -229,6 +230,7 @@ struct bonding {
rwlock_t lock;
rwlock_t curr_slave_lock;
s8 kill_timers;
+ u8 send_peer_notif;
s8 setup_by_slave;
s8 igmp_retrans;
#ifdef CONFIG_PROC_FS
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index acf553f..5345b0b 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1203,7 +1203,6 @@ static int inetdev_event(struct notifier_block *this, unsigned long event,
break;
/* fall through */
case NETDEV_NOTIFY_PEERS:
- case NETDEV_BONDING_FAILOVER:
/* Send gratuitous ARP to notify of link change */
inetdev_send_gratuitous_arp(dev, in_dev);
break;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 6f7d491..a51fa74c 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1746,7 +1746,6 @@ static int ndisc_netdev_event(struct notifier_block *this, unsigned long event,
fib6_run_gc(~0UL, net);
break;
case NETDEV_NOTIFY_PEERS:
- case NETDEV_BONDING_FAILOVER:
ndisc_send_unsol_na(dev);
break;
default:
--
1.7.4
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: DSCP values in TCP handshake
From: Mikael Abrahamsson @ 2011-04-18 19:16 UTC (permalink / raw)
To: Joe Buehler; +Cc: Stephen Hemminger, Eric Dumazet, netdev
In-Reply-To: <4DAC8A8A.1010401@cox.net>
On Mon, 18 Apr 2011, Joe Buehler wrote:
> The argument I have seen for not making reflection standard behavior is
> that it is not always appropriate for the application. For example, web
> servers have short requests but large responses so non-identical DSCP
> values might make more sense.
I'm a router guy. I don't understand this reasoning at all.
Anyone care to elaborate?
I'd like reflection be standard and have the application set DSCP if it
needs to.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: DSCP values in TCP handshake
From: Joe Buehler @ 2011-04-18 19:01 UTC (permalink / raw)
To: Mikael Abrahamsson; +Cc: Stephen Hemminger, Eric Dumazet, netdev
In-Reply-To: <alpine.DEB.2.00.1104181750150.14027@uplift.swm.pp.se>
> <http://tools.ietf.org/html/rfc2873> says this is ok, but I would like
> default to be that if incoming SYN has a certain DSCP value, the SYN+ACK
> should mirror this value if the application doesn't explicitly set
> anything else.
>
> I was under the impression that mirroring was done historically, but
> this has changed? Looking at how my apache server is behaving in 2.6.32,
> it seems it uses 0x0 for the whole TOS byte by default. I send it 0x20
> and it responds with 0x0. SSH does the same thing.
In my case I just need the SYN-ACK to reflect the incoming SYN. To get
it I am going to use iptables like so (barring bugs on my part -- still
testing this...):
iptables -t mangle -A PREROUTING -m tcp -p tcp --tcp-flags SYN,RST,ACK
SYN -m dscp --dscp 0 -j CONNMARK --set-mark 0
iptables -t mangle -A POSTROUTING -m tcp -p tcp --tcp-flags SYN,RST,ACK
SYN,ACK -m connmark --mark 0 -j DSCP --set-dscp 0
(repeat for the other 63 values of DSCP...)
The argument I have seen for not making reflection standard behavior is
that it is not always appropriate for the application. For example, web
servers have short requests but large responses so non-identical DSCP
values might make more sense.
Thanks for all the replies.
Joe Buehler
^ permalink raw reply
* Re: Suspend/resume - slow resume
From: Ben Hutchings @ 2011-04-18 19:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: Francois Romieu, Ciprian Docan, netdev, Linux Kernel Mailing List,
Len Brown, Pavel Machek, Rafael, J. Wysocki, Greg KH
In-Reply-To: <BANLkTim_1OgqjCeD1a4Ay2fWJSmPHa_XTQ@mail.gmail.com>
On Mon, 2011-04-18 at 11:49 -0700, Linus Torvalds wrote:
> On Mon, Apr 18, 2011 at 11:08 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> > [...]
> >> - unload not on close, but on device unregister (iow not when you do
> >> "ifconfig eth0 down", but when the "eth0" device really goes away)
> >
> > Without further action, the firmware(s) will thus be locked in until the
> > driver is removed.
>
> I do agree. It's a downside. Maybe doing it in "close()" is the right
> thing, as long as we don't have that crazy "every four timer ticks"
> situation with rtl8169_reinit_task.
>
> As mentioned, the only real reason for me to be worried about the
> close thing is that I don't have a good feel for what happens at boot
> time. Are the setup scripts going to look at the interface lots of
> times? On my desktop, I couldn't care less, but I try to keep boot
> time in mind.
>
> Maybe in practice there's just a single open at boot-time (for dhcp or
> whatever), and I'm just worried for no good reason.
[...]
Well, net devices are weird - they don't have file descriptors, they
just have names and indices which you can specify in an ioctl on any
socket (or netlink message on an appropriate netlink socket). Opening
means starting the device, and I can't think of a configuration tool
that implicitly opens a net device. Normally they get opened by ifup or
network-manager or the local equivalent, and then they stay open until
an explicit action by the administrator.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/2] bna: fix for clean fw re-initialization
From: David Miller @ 2011-04-18 19:28 UTC (permalink / raw)
To: rmody; +Cc: netdev, ddutt
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86A5D7348A7B@HQ1-EXCH01.corp.brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Mon, 18 Apr 2011 12:26:12 -0700
> We were not able to see these patches when we did a git-pull of
> net-next-2.6. We were wondering if the patches are stuck behind
> others and not committed to the tree.
They went into net-2.6 since they are bug fixes and you didn't specify
which tree you wanted them to appear in.
^ permalink raw reply
* Re: Suspend/resume - slow resume
From: Linus Torvalds @ 2011-04-18 19:51 UTC (permalink / raw)
To: Ciprian Docan
Cc: Francois Romieu, netdev, Linux Kernel Mailing List, Len Brown,
Pavel Machek, Rafael, J. Wysocki, Greg KH
In-Reply-To: <Pine.SOC.4.64.1104181519490.1320@er3.rutgers.edu>
On Mon, Apr 18, 2011 at 12:27 PM, Ciprian Docan <docan@eden.rutgers.edu> wrote:
>
> Linus - I applied your patch and attached the diff between output of dmesg
> before and after the patch as resume_timing.diff. This patch alone does not
> seem to fix the issue;
Ok, that just means that the error return from call_usermodehelper()
gets lost somewhere along the way to kobject_uevent(). Or that I
misread the whole thing.
> however, applying Francois's patch in addition to
> yours make the resume smooth.
Well, Francois' patch on its own should already have fixed it for you,
and made the whole issue moot.
Francois' patch is fine and improves on things, I only had a few
arguments with it. The problems I think it had were really about some
rather special cases.
Linus
^ permalink raw reply
* RE: [PATCH 1/2] bna: fix for clean fw re-initialization
From: Rasesh Mody @ 2011-04-18 19:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Debashis Dutt
In-Reply-To: <20110414.133957.226775217.davem@davemloft.net>
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of David Miller
>Sent: Thursday, April 14, 2011 1:40 PM
>To: Rasesh Mody
>Cc: netdev@vger.kernel.org; Debashis Dutt
>Subject: Re: [PATCH 1/2] bna: fix for clean fw re-initialization
>
>From: Rasesh Mody <rmody@brocade.com>
>Date: Thu, 14 Apr 2011 11:05:18 -0700
>
>> During a kernel crash, bna control path state machine and firmware do
>not
>> get a notification and hence are not cleanly shutdown. The registers
>> holding driver/IOC state information are not reset back to valid
>> disabled/parking values. This causes subsequent driver initialization
>> to hang during kdump kernel boot. This patch, during the
>initialization
>> of first PCI function, resets corresponding register when unclean
>shutown
>> is detect by reading chip registers. This will make sure that ioc/fw
>> gets clean re-initialization.
>>
>> Signed-off-by: Debashis Dutt <ddutt@brocade.com>
>> Signed-off-by: Rasesh Mody <rmody@brocade.com>
>
>Applied.
Hello David,
We were not able to see these patches when we did a git-pull of
net-next-2.6. We were wondering if the patches are stuck behind
others and not committed to the tree.
Thanks.
^ permalink raw reply
* Re: Suspend/resume - slow resume
From: Ciprian Docan @ 2011-04-18 19:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Francois Romieu, netdev, Linux Kernel Mailing List, Len Brown,
Pavel Machek, Rafael, J. Wysocki, Greg KH
In-Reply-To: <BANLkTim_1OgqjCeD1a4Ay2fWJSmPHa_XTQ@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 650 bytes --]
> TOTALLY UNTESTED PATCH ATTACHED!
>
> Ciprian - does this get rid of the 60-second wait? Do you get a nice
> kernel traceback in your dmesg instead?
Linus - I applied your patch and attached the diff between output of dmesg
before and after the patch as resume_timing.diff. This patch alone does
not seem to fix the issue; however, applying Francois's patch in addition
to yours make the resume smooth. I have also attached the diff output of
dmesg before and after, with both patched applied as resume2_timing.diff.
Both cases were tested after a fresh reboot. Please let me know if you
need any other information.
Thank you,
--
Ciprian
[-- Attachment #2: Type: TEXT/PLAIN, Size: 12194 bytes --]
1003a1004,1167
> [ 65.618866] wl_ops_bss_info_changed: qos enabled: false (implement)
> [ 65.618883] brcmsmac: wl_ops_bss_info_changed: disassociated
> [ 65.618888] wl_ops_bss_info_changed: use_cts_prot: false (implement)
> [ 65.618892] wl_ops_bss_info_changed: short preamble: false (implement)
> [ 65.618903] wl_ops_bss_info_changed: arp filtering: enabled false, count 1 (implement)
> [ 65.618911] wlan0: deauthenticating from 00:1c:10:9c:3c:98 by local choice (reason=3)
> [ 65.642295] wl_ops_bss_info_changed: BSS idle: true (implement)
> [ 65.642338] cfg80211: All devices are disconnected, going to restore regulatory settings
> [ 65.642346] cfg80211: Restoring regulatory settings
> [ 65.642356] cfg80211: Calling CRDA to update world regulatory domain
> [ 65.642419] wl_ops_bss_info_changed: BSS idle: false (implement)
> [ 65.647025] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647033] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647038] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647043] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647047] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647052] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647056] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647061] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647065] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647070] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647075] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647079] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647084] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647089] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647093] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647098] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647102] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647107] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647111] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647116] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647120] cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width channel with regulatory rule:
> [ 65.647125] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 65.647129] cfg80211: Disabling freq 2467 MHz
> [ 65.647132] cfg80211: Disabling freq 2472 MHz
> [ 65.647135] cfg80211: Disabling freq 2484 MHz
> [ 65.647139] cfg80211: World regulatory domain updated:
> [ 65.647141] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> [ 65.647146] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 65.647151] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ 65.647156] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ 65.647160] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 65.647182] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 65.661205] wl_ops_bss_info_changed: BSS idle: true (implement)
> [ 67.149409] PM: Syncing filesystems ... done.
> [ 67.150612] PM: Preparing system for mem sleep
> [ 67.294102] Freezing user space processes ... (elapsed 0.01 seconds) done.
> [ 67.304765] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> [ 67.315716] PM: Entering mem sleep
> [ 67.315872] Suspending console(s) (use no_console_suspend to debug)
> [ 67.316505] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [ 67.319105] sd 0:0:0:0: [sda] Stopping disk
> [ 67.355568] brcmsmac 0000:03:00.0: PCI INT A disabled
> [ 67.366638] ehci_hcd 0000:00:1d.0: PCI INT A disabled
> [ 67.366650] ehci_hcd 0000:00:1a.0: PCI INT A disabled
> [ 67.455454] HDA Intel 0000:01:00.1: PCI INT B disabled
> [ 67.455488] ACPI handle has no context!
> [ 67.457872] HDA Intel 0000:00:1b.0: PCI INT A disabled
> [ 69.824037] PM: suspend of devices complete after 2514.601 msecs
> [ 69.824247] r8169 0000:02:00.0: PME# enabled
> [ 69.832945] r8169 0000:02:00.0: wake-up capability enabled by ACPI
> [ 69.865924] PM: late suspend of devices complete after 42.000 msecs
> [ 69.866079] ACPI: Preparing to enter system sleep state S3
> [ 69.911889] PM: Saving platform NVS memory
> [ 69.915560] Disabling non-boot CPUs ...
> [ 69.917358] CPU 1 is now offline
> [ 69.929978] CPU 2 is now offline
> [ 69.931819] Broke affinity for irq 9
> [ 69.932857] CPU 3 is now offline
> [ 69.933182] Extended CMOS year: 2000
> [ 69.933377] ACPI: Low-level resume complete
> [ 69.933432] PM: Restoring platform NVS memory
> [ 69.933979] Extended CMOS year: 2000
> [ 69.934000] Enabling non-boot CPUs ...
> [ 69.934120] Booting Node 0 Processor 1 APIC 0x1
> [ 69.934121] smpboot cpu 1: start_ip = 98000
> [ 70.025135] Switched to NOHz mode on CPU #1
> [ 70.026670] CPU1 is up
> [ 70.026831] Booting Node 0 Processor 2 APIC 0x4
> [ 70.026834] smpboot cpu 2: start_ip = 98000
> [ 70.117565] CPU2 is up
> [ 70.117646] Booting Node 0 Processor 3 APIC 0x5
> [ 70.117648] smpboot cpu 3: start_ip = 98000
> [ 70.117845] Switched to NOHz mode on CPU #2
> [ 70.208157] CPU3 is up
> [ 70.209353] Switched to NOHz mode on CPU #3
> [ 70.209710] ACPI: Waking up from system sleep state S3
> [ 70.277137] pcieport 0000:00:01.0: restoring config space at offset 0x7 (was 0x20003030, writing 0x3030)
> [ 70.277142] pcieport 0000:00:01.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100407)
> [ 70.277162] i915 0000:00:02.0: restoring config space at offset 0x1 (was 0x900007, writing 0x900407)
> [ 70.277190] pci 0000:00:16.0: restoring config space at offset 0x1 (was 0x180006, writing 0x100006)
> [ 70.277222] ehci_hcd 0000:00:1a.0: restoring config space at offset 0x1 (was 0x2900006, writing 0x2900002)
> [ 70.277257] HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100006, writing 0x100002)
> [ 70.277286] pcieport 0000:00:1c.0: restoring config space at offset 0x7 (was 0x20002020, writing 0x2020)
> [ 70.277362] ehci_hcd 0000:00:1d.0: restoring config space at offset 0x1 (was 0x2900006, writing 0x2900002)
> [ 70.277384] pci 0000:00:1e.0: restoring config space at offset 0xa (was 0xffffffff, writing 0x0)
> [ 70.277465] ahci 0000:00:1f.2: restoring config space at offset 0x1 (was 0x2b00007, writing 0x2b00407)
> [ 70.277588] HDA Intel 0000:01:00.1: restoring config space at offset 0x1 (was 0x100007, writing 0x100003)
> [ 70.277642] r8169 0000:02:00.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100407)
> [ 70.277728] brcmsmac 0000:03:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
> [ 70.277748] brcmsmac 0000:03:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xc2400004)
> [ 70.277753] brcmsmac 0000:03:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
> [ 70.277759] brcmsmac 0000:03:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100006)
> [ 70.277907] PM: early resume of devices complete after 0.832 msecs
> [ 70.278058] i915 0000:00:02.0: setting latency timer to 64
> [ 70.278063] ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [ 70.278069] ehci_hcd 0000:00:1a.0: setting latency timer to 64
> [ 70.278084] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> [ 70.278091] ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [ 70.278093] HDA Intel 0000:00:1b.0: setting latency timer to 64
> [ 70.278100] ehci_hcd 0000:00:1d.0: setting latency timer to 64
> [ 70.278110] pci 0000:00:1e.0: setting latency timer to 64
> [ 70.278132] ahci 0000:00:1f.2: setting latency timer to 64
> [ 70.278140] HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> [ 70.278145] HDA Intel 0000:01:00.1: setting latency timer to 64
> [ 70.278160] HDA Intel 0000:00:1b.0: irq 46 for MSI/MSI-X
> [ 70.278194] HDA Intel 0000:01:00.1: irq 47 for MSI/MSI-X
> [ 70.278338] sd 0:0:0:0: [sda] Starting disk
> [ 70.278461] brcmsmac 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [ 70.278467] brcmsmac 0000:03:00.0: setting latency timer to 64
> [ 70.286439] r8169 0000:02:00.0: wake-up capability disabled by ACPI
> [ 70.286445] r8169 0000:02:00.0: PME# disabled
> [ 70.508985] usb 1-1.4: reset full speed USB device number 3 using ehci_hcd
> [ 70.583638] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 70.585644] ata5: SATA link down (SStatus 0 SControl 300)
> [ 70.617518] ata2.00: configured for UDMA/100
> [ 70.666598] usb 2-1.3: reset full speed USB device number 3 using ehci_hcd
> [ 70.753366] btusb 2-1.3:1.0: no reset_resume for driver btusb?
> [ 70.753372] btusb 2-1.3:1.1: no reset_resume for driver btusb?
> [ 70.824183] usb 2-1.6: reset high speed USB device number 5 using ehci_hcd
> [ 71.753512] hci_cmd_timer: hci0 command tx timeout
> [ 73.023083] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 73.035133] ata1.00: configured for UDMA/133
> [ 73.642069] PM: resume of devices complete after 3373.220 msecs
> [ 73.642418] PM: Finishing wakeup.
> [ 73.642420] Restarting tasks ... done.
> [ 73.648564] video LNXVIDEO:00: Restoring backlight state
> [ 73.648712] video LNXVIDEO:01: Restoring backlight state
> [ 74.082737] wl_ops_bss_info_changed: use_cts_prot: false (implement)
> [ 74.082742] wl_ops_bss_info_changed: short preamble: false (implement)
> [ 74.082760] wl_ops_config: change monitor mode: false (implement)
> [ 74.082763] wl_ops_config: change power-save mode: false (implement)
> [ 74.084986] wl_ops_bss_info_changed: qos enabled: false (implement)
> [ 74.085682] wl_ops_bss_info_changed: BSS idle: false (implement)
> [ 74.085702] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 74.174940] wl_ops_bss_info_changed: BSS idle: true (implement)
> [ 74.174977] wl_ops_bss_info_changed: BSS idle: false (implement)
> [ 74.264656] wl_ops_bss_info_changed: BSS idle: true (implement)
> [ 74.293752] wl_ops_bss_info_changed: BSS idle: false (implement)
> [ 74.293812] wlan0: deauthenticating from 00:1c:10:9c:3c:98 by local choice (reason=3)
> [ 74.383350] wlan0: authenticate with 00:1c:10:9c:3c:98 (try 1)
> [ 74.398331] wlan0: authenticated
> [ 74.398347] wl_ops_bss_info_changed: BSS idle: true (implement)
> [ 74.398374] wl_ops_bss_info_changed: BSS idle: false (implement)
> [ 74.398381] wlan0: associate with 00:1c:10:9c:3c:98 (try 1)
> [ 74.402842] wlan0: RX AssocResp from 00:1c:10:9c:3c:98 (capab=0x411 status=0 aid=11)
> [ 74.402846] wlan0: associated
> [ 74.403886] wl_ops_bss_info_changed: qos enabled: false (implement)
> [ 74.403891] brcmsmac: wl_ops_bss_info_changed: associated
> [ 74.403898] wl_ops_bss_info_changed: Need to change Basic Rates: 0xf (implement)
> [ 74.403904] wl_ops_bss_info_changed: arp filtering: enabled true, count 0 (implement)
> [ 74.405021] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 74.647583] hci_cmd_timer: hci0 command tx timeout
> [ 74.776522] wl_ops_bss_info_changed: arp filtering: enabled true, count 1 (implement)
[-- Attachment #3: Type: TEXT/PLAIN, Size: 12320 bytes --]
1031a1032,1197
> [ 75.923864] wl_ops_bss_info_changed: qos enabled: false (implement)
> [ 75.923874] brcmsmac: wl_ops_bss_info_changed: disassociated
> [ 75.923877] wl_ops_bss_info_changed: use_cts_prot: false (implement)
> [ 75.923880] wl_ops_bss_info_changed: short preamble: false (implement)
> [ 75.923889] wl_ops_bss_info_changed: arp filtering: enabled false, count 1 (implement)
> [ 75.923895] wlan0: deauthenticating from 00:1c:10:9c:3c:98 by local choice (reason=3)
> [ 75.943322] wl_ops_bss_info_changed: BSS idle: true (implement)
> [ 75.943339] cfg80211: All devices are disconnected, going to restore regulatory settings
> [ 75.943348] cfg80211: Restoring regulatory settings
> [ 75.943357] cfg80211: Calling CRDA to update world regulatory domain
> [ 75.943362] wl_ops_bss_info_changed: BSS idle: false (implement)
> [ 75.948033] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948041] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948046] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948051] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948055] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948060] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948065] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948069] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948074] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948079] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948083] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948088] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948092] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948097] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948101] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948106] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948110] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948115] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948119] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948124] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948149] cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width channel with regulatory rule:
> [ 75.948154] cfg80211: 2402000 KHz - 2472000 KHz @ KHz), (300 mBi, 2700 mBm)
> [ 75.948157] cfg80211: Disabling freq 2467 MHz
> [ 75.948160] cfg80211: Disabling freq 2472 MHz
> [ 75.948163] cfg80211: Disabling freq 2484 MHz
> [ 75.948167] cfg80211: World regulatory domain updated:
> [ 75.948170] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> [ 75.948175] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 75.948180] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ 75.948185] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [ 75.948189] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 75.948194] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [ 75.957206] wl_ops_bss_info_changed: BSS idle: true (implement)
> [ 77.705556] PM: Syncing filesystems ... done.
> [ 77.706722] PM: Preparing system for mem sleep
> [ 77.850189] Freezing user space processes ... (elapsed 0.01 seconds) done.
> [ 77.861052] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
> [ 77.872039] PM: Entering mem sleep
> [ 77.872191] Suspending console(s) (use no_console_suspend to debug)
> [ 77.872837] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [ 77.888620] sd 0:0:0:0: [sda] Stopping disk
> [ 77.912060] brcmsmac 0000:03:00.0: PCI INT A disabled
> [ 77.923064] ehci_hcd 0000:00:1d.0: PCI INT A disabled
> [ 77.923076] ehci_hcd 0000:00:1a.0: PCI INT A disabled
> [ 78.013092] HDA Intel 0000:01:00.1: PCI INT B disabled
> [ 78.013126] ACPI handle has no context!
> [ 78.014369] HDA Intel 0000:00:1b.0: PCI INT A disabled
> [ 80.399749] PM: suspend of devices complete after 2527.459 msecs
> [ 80.399924] r8169 0000:02:00.0: PME# enabled
> [ 80.408697] r8169 0000:02:00.0: wake-up capability enabled by ACPI
> [ 80.441740] PM: late suspend of devices complete after 41.997 msecs
> [ 80.441884] ACPI: Preparing to enter system sleep state S3
> [ 80.487834] PM: Saving platform NVS memory
> [ 80.493177] Disabling non-boot CPUs ...
> [ 80.494806] CPU 1 is now offline
> [ 80.496529] CPU 2 is now offline
> [ 80.504829] Broke affinity for irq 20
> [ 80.505876] CPU 3 is now offline
> [ 80.506220] Extended CMOS year: 2000
> [ 80.506416] ACPI: Low-level resume complete
> [ 80.506471] PM: Restoring platform NVS memory
> [ 80.507040] Extended CMOS year: 2000
> [ 80.507079] Enabling non-boot CPUs ...
> [ 80.507182] Booting Node 0 Processor 1 APIC 0x1
> [ 80.507183] smpboot cpu 1: start_ip = 98000
> [ 80.598507] Switched to NOHz mode on CPU #1
> [ 80.599960] CPU1 is up
> [ 80.600052] Booting Node 0 Processor 2 APIC 0x4
> [ 80.600053] smpboot cpu 2: start_ip = 98000
> [ 80.691078] CPU2 is up
> [ 80.691178] Booting Node 0 Processor 3 APIC 0x5
> [ 80.691180] smpboot cpu 3: start_ip = 98000
> [ 80.691471] Switched to NOHz mode on CPU #2
> [ 80.782157] CPU3 is up
> [ 80.783357] Switched to NOHz mode on CPU #3
> [ 80.783681] ACPI: Waking up from system sleep state S3
> [ 80.851177] pcieport 0000:00:01.0: restoring config space at offset 0x7 (was 0x20003030, writing 0x3030)
> [ 80.851181] pcieport 0000:00:01.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100407)
> [ 80.851201] i915 0000:00:02.0: restoring config space at offset 0x1 (was 0x900007, writing 0x900407)
> [ 80.851229] pci 0000:00:16.0: restoring config space at offset 0x1 (was 0x180006, writing 0x100006)
> [ 80.851262] ehci_hcd 0000:00:1a.0: restoring config space at offset 0x1 (was 0x2900006, writing 0x2900002)
> [ 80.851297] HDA Intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100006, writing 0x100002)
> [ 80.851327] pcieport 0000:00:1c.0: restoring config space at offset 0x7 (was 0x20002020, writing 0x2020)
> [ 80.851402] ehci_hcd 0000:00:1d.0: restoring config space at offset 0x1 (was 0x2900006, writing 0x2900002)
> [ 80.851424] pci 0000:00:1e.0: restoring config space at offset 0xa (was 0xffffffff, writing 0x0)
> [ 80.851504] ahci 0000:00:1f.2: restoring config space at offset 0x1 (was 0x2b00007, writing 0x2b00407)
> [ 80.851627] HDA Intel 0000:01:00.1: restoring config space at offset 0x1 (was 0x100007, writing 0x100003)
> [ 80.851680] r8169 0000:02:00.0: restoring config space at offset 0x1 (was 0x100007, writing 0x100407)
> [ 80.851768] brcmsmac 0000:03:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
> [ 80.851787] brcmsmac 0000:03:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xc2400004)
> [ 80.851792] brcmsmac 0000:03:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
> [ 80.851798] brcmsmac 0000:03:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100006)
> [ 80.851949] PM: early resume of devices complete after 0.833 msecs
> [ 80.852100] i915 0000:00:02.0: setting latency timer to 64
> [ 80.852107] ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [ 80.852113] ehci_hcd 0000:00:1a.0: setting latency timer to 64
> [ 80.852148] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> [ 80.852152] HDA Intel 0000:00:1b.0: setting latency timer to 64
> [ 80.852191] HDA Intel 0000:00:1b.0: irq 46 for MSI/MSI-X
> [ 80.852231] ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [ 80.852236] ehci_hcd 0000:00:1d.0: setting latency timer to 64
> [ 80.852265] pci 0000:00:1e.0: setting latency timer to 64
> [ 80.852277] ahci 0000:00:1f.2: setting latency timer to 64
> [ 80.852326] HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> [ 80.852330] HDA Intel 0000:01:00.1: setting latency timer to 64
> [ 80.852363] HDA Intel 0000:01:00.1: irq 47 for MSI/MSI-X
> [ 80.852480] brcmsmac 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [ 80.852485] brcmsmac 0000:03:00.0: setting latency timer to 64
> [ 80.852598] sd 0:0:0:0: [sda] Starting disk
> [ 80.865473] r8169 0000:02:00.0: wake-up capability disabled by ACPI
> [ 80.865479] r8169 0000:02:00.0: PME# disabled
> [ 81.083607] usb 1-1.4: reset full speed USB device number 3 using ehci_hcd
> [ 81.158479] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 81.160479] ata5: SATA link down (SStatus 0 SControl 300)
> [ 81.192446] ata2.00: configured for UDMA/100
> [ 81.241617] usb 2-1.3: reset full speed USB device number 3 using ehci_hcd
> [ 81.328714] btusb 2-1.3:1.0: no reset_resume for driver btusb?
> [ 81.328719] btusb 2-1.3:1.1: no reset_resume for driver btusb?
> [ 81.399752] usb 2-1.6: reset high speed USB device number 5 using ehci_hcd
> [ 82.329405] hci_cmd_timer: hci0 command tx timeout
> [ 83.604299] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 83.616192] ata1.00: configured for UDMA/133
> [ 141.955556] r8169 0000:02:00.0: eth0: unable to apply firmware patch
> [ 142.557969] PM: resume of devices complete after 61712.246 msecs
> [ 142.558474] PM: Finishing wakeup.
> [ 142.558475] Restarting tasks ... done.
> [ 142.563742] video LNXVIDEO:00: Restoring backlight state
> [ 142.563923] video LNXVIDEO:01: Restoring backlight state
> [ 143.565055] hci_cmd_timer: hci0 command tx timeout
> [ 143.591177] wl_ops_bss_info_changed: use_cts_prot: false (implement)
> [ 143.591183] wl_ops_bss_info_changed: short preamble: false (implement)
> [ 143.591202] wl_ops_config: change monitor mode: false (implement)
> [ 143.591205] wl_ops_config: change power-save mode: false (implement)
> [ 143.593448] wl_ops_bss_info_changed: qos enabled: false (implement)
> [ 143.594031] wl_ops_bss_info_changed: BSS idle: false (implement)
> [ 143.594061] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 143.684097] wl_ops_bss_info_changed: BSS idle: true (implement)
> [ 143.684157] wl_ops_bss_info_changed: BSS idle: false (implement)
> [ 143.774118] wl_ops_bss_info_changed: BSS idle: true (implement)
> [ 143.798174] wl_ops_bss_info_changed: BSS idle: false (implement)
> [ 143.798222] wlan0: deauthenticating from 00:1c:10:9c:3c:98 by local choice (reason=3)
> [ 143.888109] wlan0: authenticate with 00:1c:10:9c:3c:98 (try 1)
> [ 143.911758] wlan0: authenticated
> [ 143.911781] wl_ops_bss_info_changed: BSS idle: true (implement)
> [ 143.911815] wl_ops_bss_info_changed: BSS idle: false (implement)
> [ 143.911821] wlan0: associate with 00:1c:10:9c:3c:98 (try 1)
> [ 143.914372] wlan0: RX AssocResp from 00:1c:10:9c:3c:98 (capab=0x411 status=0 aid=11)
> [ 143.914377] wlan0: associated
> [ 143.915137] wl_ops_bss_info_changed: qos enabled: false (implement)
> [ 143.915141] brcmsmac: wl_ops_bss_info_changed: associated
> [ 143.915147] wl_ops_bss_info_changed: Need to change Basic Rates: 0xf (implement)
> [ 143.915153] wl_ops_bss_info_changed: arp filtering: enabled true, count 0 (implement)
> [ 143.915987] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 143.974405] wl_ops_bss_info_changed: arp filtering: enabled true, count 1 (implement)
> [ 154.004056] wlan0: no IPv6 routers present
^ permalink raw reply
* Re: [PATCH V14 3/4] ptp: Added a clock driver for the IXP46x.
From: Ben Hutchings @ 2011-04-18 20:53 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Alan Cox, Arnd Bergmann,
Christoph Lameter, David Miller, John Stultz, Krzysztof Halasa,
Peter Zijlstra, Rodolfo Giometti, Thomas Gleixner,
Benjamin Herrenschmidt, Mike Frysinger, Paul Mackerras,
Russell King
In-Reply-To: <dbee2487a57fd7f41e4efbbd2ddfb1313b8d71bc.1303107532.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
On Mon, 2011-04-18 at 08:29 +0200, Richard Cochran wrote:
> This patch adds a driver for the hardware time stamping unit found on the
> IXP465. The basic clock operations and an external trigger are implemented.
[...]
> --- a/drivers/net/arm/ixp4xx_eth.c
> +++ b/drivers/net/arm/ixp4xx_eth.c
[...]
> @@ -246,6 +255,169 @@ static int ports_open;
> static struct port *npe_port_tab[MAX_NPES];
> static struct dma_pool *dma_pool;
>
> +static struct sock_filter ptp_filter[] = {
> + PTP_FILTER
> +};
> +
> +static int ixp_ptp_match(struct sk_buff *skb, u16 uid_hi, u32 uid_lo, u16 seq)
> +{
> + unsigned int type;
> + u16 *hi, *id;
> + u8 *lo, *data = skb->data;
> +
> + type = sk_run_filter(skb, ptp_filter);
> +
> + if (PTP_CLASS_V1_IPV4 == type) {
> +
> + id = (u16 *)(data + 42 + 30);
> + hi = (u16 *)(data + 42 + 22);
> + lo = data + 42 + 24;
[...]
PTP_FILTER does not verify that the packet length is sufficient to hold
a complete PTP header, nor does it require that the IPv4 header length
is 5 (i.e. 20 bytes). So you have to check those here rather than using
magic numbers.
I think you also need to use be16_to_cpup() to read 'id' and 'hi', since
the host byte order may vary.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH V14 4/4] ptp: Added a clock driver for the National Semiconductor PHYTER.
From: Ben Hutchings @ 2011-04-18 20:57 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel, linux-api, netdev, devicetree-discuss,
linux-arm-kernel, linuxppc-dev, Alan Cox, Arnd Bergmann,
Christoph Lameter, David Miller, John Stultz, Krzysztof Halasa,
Peter Zijlstra, Rodolfo Giometti, Thomas Gleixner,
Benjamin Herrenschmidt, Mike Frysinger, Paul Mackerras,
Russell King
In-Reply-To: <1728ffb5735c2a04876a69ad55427c4e7b5a1bd7.1303107532.git.richard.cochran@omicron.at>
On Mon, 2011-04-18 at 08:30 +0200, Richard Cochran wrote:
> This patch adds support for the PTP clock found on the DP83640.
> The basic clock operations and one external time stamp have
> been implemented.
[...]
> --- /dev/null
> +++ b/drivers/net/phy/dp83640.c
[...]
> +static int match(struct sk_buff *skb, unsigned int type, struct rxts *rxts)
> +{
> + u16 *seqid;
Should be __be16 *, and similarly for the casts.
> + u8 *msgtype, *data = skb_mac_header(skb);
> +
> + /* check sequenceID, messageType, 12 bit hash of offset 20-29 */
> + /* We assume that the IPv4 header has no options. */
Does the hardware definitely not timestamp received packets with IP
options?
> + switch (type) {
> + case PTP_CLASS_V1_IPV4:
> + msgtype = data + 42 + 32;
> + seqid = (u16 *)(data + 42 + 30);
> + break;
> + case PTP_CLASS_V1_IPV6:
> + msgtype = data + 62 + 32;
> + seqid = (u16 *)(data + 62 + 30);
> + break;
> + case PTP_CLASS_V2_IPV4:
> + msgtype = data + 42 + 0;
> + seqid = (u16 *)(data + 42 + 30);
> + break;
> + case PTP_CLASS_V2_IPV6:
> + msgtype = data + 62 + 0;
> + seqid = (u16 *)(data + 62 + 30);
> + break;
> + case PTP_CLASS_V2_L2:
> + msgtype = data + 14 + 0;
> + seqid = (u16 *)(data + 14 + 30);
> + break;
> + case PTP_CLASS_V2_VLAN:
> + msgtype = data + 18 + 0;
> + seqid = (u16 *)(data + 18 + 30);
> + break;
[...]
Would be better without the magic numbers.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [Bugme-new] [Bug 33332] New: IC Plus Corp IP1000 Family Gigabit Ethernet and OpenSuSE (x86, x86_64)
From: Andrew Morton @ 2011-04-18 21:00 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, gearge, Denis Kirjanov
In-Reply-To: <bug-33332-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Fri, 15 Apr 2011 16:32:20 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=33332
>
> Summary: IC Plus Corp IP1000 Family Gigabit Ethernet and
> OpenSuSE (x86, x86_64)
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.34.7-0.7-desktop
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: gearge@gmail.com
> Regression: No
>
>
> I have an odd problem with my NIC; on both x86 and x86_64 OpenSuSE 11.3 I lose
> network connectivity with my gateway router, if heavy downloading is evolved
> (e.g. downloading a large file over HTTP or any activity - large or small - on
> bittorrent). I have no limitations on my ISP side and the router is working
> fine. I even upgraded to the latest firmware from my wireless router's vendor
> and installed third party firmware, but the problem remains. While I lose
> connectivity on the wired network segment (my PC is directly connected to the
> router), the wireless segment continues to operate. What's even more odd, I
> have no networking issues while watching streaming media - normal or higher
> quality.
>
> Information about my network card:
>
> 06:01.0 Ethernet controller [0200]: Sundance Technology Inc / IC Plus Corp
> IP1000 Family Gigabit Ethernet [13f0:1023] (rev 41)
>
> 1: None 00.0: 10701 Ethernet
> [Created at net.124]
> Unique ID: usDW.ndpeucax6V1
> Parent ID: rBUF.H29BqU8ALB5
> SysFS ID: /class/net/eth0
> SysFS Device Link: /devices/pci0000:00/0000:00:1e.0/0000:06:01.0
> Hardware Class: network interface
> Model: "Ethernet network interface"
> Driver: "Sundance Technology IPG Triple-Speed Ethernet"
> Driver Modules: "ipg"
> Device File: eth0
> HW Address:
> Link detected: yes
> Config Status: cfg=new, avail=yes, need=no, active=unknown
> Attached to: #31 (Ethernet controller)
>
> Please assist in resolving this issue.
>
^ permalink raw reply
* What if?
From: Shannon Lavenia @ 2011-04-18 18:34 UTC (permalink / raw)
To: netdev
Hi,
I hope you had a great weekend. John and I
spent the time playing with our daughter...
hard to believe she's 6 months old already.
Watching her grow made me realize that
time really does go by fast.
It's almost Easter already and a quarter
of the year has just flown by.
Which made me think: Will 2011 be
"just another year", or will it be
EXTRAORDINARY.
This year is turning out fantastic for us and
I sincerely hope it is for you too. We're taking
every step possible towards our goal:
"To help 100 people achieve their financial
and personal goals".
We made a decision a few months ago
to really focus on helping more people
achieve success...to help people
realize the freedom that we enjoy
working for ourselves.
We're doing it with http://www.UprofitPro.com
I mean, let's face it, with all the
fear mongering going on in the news
right now, it's easy for you and I to think
that it's hopeless.
But, it really isn't. Yes, there is a huge
transfer of wealth happening right now.
That doesn't mean you have to lay down
and be on the wrong side of the transfer.
You CAN win and win BIG right now
just by knowing a few key steps to take
that will make a HUGE difference.
We started UprofitPro to give you
access to:
1. Success coaching from 7 figure
earners and our exclusive alliance
of mentors including The Home Business
Diva Robin Firestone, Michael Hamburger -
Executive Vice President of Marketing at
WMI, Neal Peterson - World Renowned
Motivational Speaker and more.
That means you'll get motivated and
inspired whether you want to be or not...
on a daily basis.
Keeping your energy up is key to
success.
2. A very simple, yet powerful, way to
generate an on-going residual income
stream without ever mentioning it to
your friends, family or neighbors.
We actually do most of the marketing
for you...it's that simple.
3. And, if you're already building
a home based business, a way to
generate the highest quality, highest
converting leads known to man.
I know that sounds a bit "hypey", but
it's true. We'll show you how to get the
same quality of leads that top marketers
get and how to make money generating
leads instead of paying for them.
How serious are we about helping people?
John and I usually charge upwards of $500.00
for a 45 minute session of coaching.
Seriously.
But, we're giving you full access to the
UprofitPro coaching and wealth building
system for only $1.00.
You have nothing to lose and everything
to gain.
If, after a week you say "not for me", we'll
give you your buck back and wish you all the
best.
But, we know you won't. Noone has yet. Because
everything we've got in store for you will simply
blow you away.
So, give yourself a great boost today
and a huge step towards running first through
that ribbon at the finish line by joining us
at http://www.uprofitpro.com.
You'll be grateful you did.
With you in success!
Shannon Lavenia
Co-founder, Uprofitpro.com
+1(323) 834-9274
PS: If you have any questions, feel free to
give us ring. You'll get instant access to
all the member resources, training and coaching
videos.
^ permalink raw reply
* Re: unregister_netdevice: waiting for lo to become free. Usage count = 8
From: Julian Anastasov @ 2011-04-18 21:12 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: Simon Horman, netdev, lvs-devel, Eric W. Biederman
In-Reply-To: <201104181243.30613.hans@schillstrom.com>
Hello,
On Mon, 18 Apr 2011, Hans Schillstrom wrote:
> Actually I forgot to tell there is a need for a
> ip_vs_service_cleanup() due to above.
> Do you see any drawbacks with it ?
May be ip_vs_service_cleanup() should call only
ip_vs_flush(), under __ip_vs_mutex.
> /*
> * Delete service by {netns} in the service table.
> */
> static void ip_vs_service_cleanup(struct net *net)
> {
> unsigned hash;
> struct ip_vs_service *svc, *tmp;
>
> EnterFunction(2);
> /* Check for "full" addressed entries */
> for (hash = 0; hash<IP_VS_SVC_TAB_SIZE; hash++) {
> write_lock_bh(&__ip_vs_svc_lock);
> list_for_each_entry_safe(svc, tmp, &ip_vs_svc_table[hash],
> s_list) {
> if (net_eq(svc->net, net)) {
> ip_vs_svc_unhash(svc);
> __ip_vs_del_service(svc);
> }
> }
> list_for_each_entry_safe(svc, tmp, &ip_vs_svc_fwm_table[hash],
> f_list) {
> if (net_eq(svc->net, net)) {
> ip_vs_svc_unhash(svc);
> __ip_vs_del_service(svc);
> }
> }
> write_unlock_bh(&__ip_vs_svc_lock);
> }
> LeaveFunction(2);
> }
>
> Called just after the __ip_vs_control_cleanup_sysctl()
Hm, no. ip_vs_service_cleanup() should be called
by ip_vs_cleanup() before or after nf_unregister_hooks().
The rule is that ip_vs_flush() should be called before
ip_vs_conn_flush() because after ip_vs_flush() no more
connections can be created and even if hooks are still
registered the packets can not create conns in the netns. Then
ip_vs_conn_flush() will remove all existing connections and
ip_vs_control_cleanup() can remove all real servers with
ip_vs_trash_cleanup(). I mean, per-netns calls.
Also, may be all code that was called in old
kernels by ip_vs_cleanup() should be now called by
__ip_vs_cleanup(net), i.e. we can preserve the needed order
of all functions but now also per-netns. For example, for
ip_vs_ctl.c ip_vs_control_init() can remain as global but it
should not register ipvs_control_ops. Then we
can rename __ip_vs_control_init to ip_vs_control_init_net()
and to call it from __ip_vs_init(). I.e. all such files
will have global function and also _init_net and
_cleanup_net. Now there are many register_pernet_subsys()
calls and I'm not sure we preserve the needed order for
cleanup. Are the ->exit methods called in reverse order?
I don't see it in ops_exit_list() and we can not rely
on such registration order. I think, ip_vs_init() should
call global functions as now but __ip_vs_init() and
__ip_vs_cleanup() should call the _net methods in right
order.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
From: Jesse Brandeburg @ 2011-04-18 21:12 UTC (permalink / raw)
To: Wei Gu
Cc: Peter Zijlstra, Eric Dumazet, Alexander Duyck, netdev,
Kirsher, Jeffrey T, Mike Galbraith, Thomas Gleixner
In-Reply-To: <D12839161ADD3A4B8DA63D1A134D084026E4953D6E@ESGSCCMS0001.eapac.ericsson.se>
On Fri, Apr 15, 2011 at 2:14 AM, Wei Gu <wei.gu@ericsson.com> wrote:
> Is there something that I can provide in order to identify the problem?
for power state concerns you may want to try running turbostat
(available in recent kernels, runs also on older kernels) during the
workload in question. Capture the results via something like:
cd /home/jbrandeb/linux-2.6.38.2/tools/power/x86/turbostat
make
for i in `seq 1 10` ; do ./turbostat -v sleep 5 >> turbostat.txt 2>&1 ; done
Jesse
^ permalink raw reply
* Re: [PATCH] net: dm9000: Fix build
From: David Miller @ 2011-04-18 21:19 UTC (permalink / raw)
To: broonie; +Cc: mirq-linux, netdev, patches
In-Reply-To: <1303124677-6168-1-git-send-email-broonie@opensource.wolfsonmicro.com>
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: Mon, 18 Apr 2011 12:04:37 +0100
> Commit c88fcb (net: dm9000: convert to hw_features) broke the build of
> the dm9000 driver since it merged functions which use different names
> for the board info structure used for I/O operations without updating
> all the references to use the same name. Fix that.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Applied, thanks.
^ 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