* Re: [PATCH 3.2-rc7] skge: restore rx multicast filter on resume and after config changes
From: David Miller @ 2011-12-31 4:33 UTC (permalink / raw)
To: florz; +Cc: netdev, shemminger
In-Reply-To: <20111231033009.GE2698@florz.florz.dyndns.org>
From: Florian Zumbiehl <florz@florz.de>
Date: Sat, 31 Dec 2011 04:30:09 +0100
> Restore skge hardware registers for multicast filtering to their
> appropriate values after system resume and after hardware restarts
> that are done when changing certain settings.
>
> Signed-off-by: Florian Zumbiehl <florz@florz.de>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next V2 00/21] net/mlx4: SRIOV support
From: Roland Dreier @ 2011-12-31 5:57 UTC (permalink / raw)
To: Yinghai Lu
Cc: Or Gerlitz, Yevgeny Petrilin, David Miller,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Liran Liss,
jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org
In-Reply-To: <CAE9FiQW2ZB3VUrg9z-=UVp=s3w1LQhY81hRUjfMXwW3d1dNaig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Dec 30, 2011 at 2:23 PM, Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> hotplug removal is broken...
Is this a new regression with these patches?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: [GIT PULL net-next] IPVS
From: Simon Horman @ 2011-12-31 9:06 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Patrick McHardy, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Julian Anastasov
In-Reply-To: <20111230112419.GB12015@1984>
On Fri, Dec 30, 2011 at 12:24:19PM +0100, Pablo Neira Ayuso wrote:
> Hi Simon,
>
> On Fri, Dec 30, 2011 at 02:19:01PM +0900, Simon Horman wrote:
> > Hi Pablo,
> >
> > please consider pulling
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next
> > master
>
> Since this is a fix, I can try to pass this for 3.2-rc7 to davem. I
> read Linus will release 3.2 by new year, so we can still try to see if
> we can get it in time.
>
> Let me know what you prefer.
Hi Pablo,
please try for 3.2-rc7 if possible.
^ permalink raw reply
* Re: e1000e interface hang on 82574L
From: Chris Boot @ 2011-12-31 9:31 UTC (permalink / raw)
To: netdev, lkml, e1000-devel
In-Reply-To: <4EFA4024.5000909@bootc.net>
On 27 Dec 2011, at 22:01, Chris Boot wrote:
> Hi folks,
>
> Another networking issue I've run into, this time with e1000e (Intel Corporation 82574L Gigabit). My new VM cluster appears to drop a NIC - the port stops responding within Linux and shows the link as being down with ethtool. My ISP says 'Ports running Half Duplex or reduced speed' on the port.
>
> When the port stops working I see this in dmesg:
>
> [35481.659629] ------------[ cut here ]------------
> [35481.667837] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xe9/0x148()
> [35481.676370] Hardware name: X9SCL/X9SCM
> [35481.684793] NETDEV WATCHDOG: eth2 (e1000e): transmit queue 0 timed out
> [35481.684795] Modules linked in: hmac sha256_generic dlm configfs ebtable_nat ebtables acpi_cpufreq mperf cpufreq_stats cpufreq_conservative cpufreq_userspace cpufreq_powersave microcode xt_NOTRACK ip_set_hash_net act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_connlimit xt_realm xt_addrtype ip_set_hash_ip iptable_raw xt_comment xt_recent ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp ip6_queue nf_nat_amanda xt_set ip_set nf_conntrack_tftp nf_conntrack_sip nf_conntrack_sane nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre n
f_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp ts_kmp nf_conntrack_amanda xt_TPROXY xt_NFLOG nfnetlink_log nf_tproxy_core xt_time xt_TCPMSS xt_tcpmss xt_sctp xt_policy xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_connmark xt_CLASSIFY xt_AUDIT ip6t_LOG ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip6table_raw ipt_LOG xt_tcpudp ip6table_mangle xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables ip6table_filter ip6_tables x_tables bridge stp bonding w83627ehf hwmon_vid coretemp sha1_ssse3 sha1_generic crc32c_intel aesni_intel cryptd
aes_x86_64 aes_generic ipmi_poweroff ipmi_devintf ipmi_si ipmi_msghandler vhost_net macvtap macvlan tun drbd lru_cache cn loop kvm_intel kvm snd_pcm snd_timer snd iTCO_wdt soundcore psmouse snd_page_alloc i2c_i801 i2c_core cdc_acm iTCO_vendor_support joydev evdev serio_raw processor button pcspkr thermal_sys ext4 mbcache jbd2 crc16 dm_mod raid1 md_mod sd_mod crc_t10dif usb_storage uas usbhid hid ahci libahci libata igb ehci_hcd scsi_mod usbcore e1000e dca usb_common [last unloaded: scsi_wait_scan]
> [35481.685740] Pid: 0, comm: swapper/4 Not tainted 3.2.0-rc6+ #4
> [35481.685744] Call Trace:
> [35481.685746] <IRQ> [<ffffffff810467ed>] ? warn_slowpath_common+0x78/0x8c
> [35481.685849] [<ffffffff81046899>] ? warn_slowpath_fmt+0x45/0x4a
> [35481.685875] [<ffffffff810aeaa0>] ? perf_event_task_tick+0x166/0x1ab
> [35481.686018] [<ffffffff81294219>] ? netif_tx_lock+0x40/0x72
> [35481.686090] [<ffffffff8129437a>] ? dev_watchdog+0xe9/0x148
> [35481.686136] [<ffffffff81051e58>] ? run_timer_softirq+0x19a/0x261
> [35481.686176] [<ffffffff81294291>] ? netif_tx_unlock+0x46/0x46
> [35481.686215] [<ffffffff810659bb>] ? timekeeping_get_ns+0xd/0x2a
> [35481.686286] [<ffffffff8104bdd4>] ? __do_softirq+0xb9/0x177
> [35481.686365] [<ffffffff81341d6c>] ? call_softirq+0x1c/0x30
> [35481.686530] [<ffffffff8100f841>] ? do_softirq+0x3c/0x7b
> [35481.686580] [<ffffffff8104c03c>] ? irq_exit+0x3c/0x9a
> [35481.686742] [<ffffffff81023e58>] ? smp_apic_timer_interrupt+0x74/0x82
> [35481.686820] [<ffffffff813405de>] ? apic_timer_interrupt+0x6e/0x80
> [35481.686826] <EOI> [<ffffffff811ddf49>] ? intel_idle+0xea/0x119
> [35481.686991] [<ffffffff811ddf28>] ? intel_idle+0xc9/0x119
> [35481.687051] [<ffffffff8125dce3>] ? cpuidle_idle_call+0xec/0x179
> [35481.687089] [<ffffffff8100d255>] ? cpu_idle+0xa1/0xe8
> [35481.687143] [<ffffffff810706ee>] ? arch_local_irq_restore+0x2/0x8
> [35481.687189] [<ffffffff8132d191>] ? start_secondary+0x1d5/0x1db
> [35481.687234] ---[ end trace 01e9907674757948 ]---
> [35481.687817] e1000e 0000:05:00.0: eth2: Reset adapter
>
> To try to regain connectivity I bring down the bond and the interface (eth2), then unload e1000e. Upon loading the module again:
>
> [36021.888962] e1000e: Intel(R) PRO/1000 Network Driver - 1.5.1-k
> [36021.900258] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
> [36021.911446] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [36021.923204] e1000e 0000:00:19.0: setting latency timer to 64
> [36021.923372] e1000e 0000:00:19.0: irq 45 for MSI/MSI-X
> [36022.202737] e1000e 0000:00:19.0: eth2: (PCI Express:2.5GT/s:Width x1) 00:25:90:56:ac:75
> [36022.214480] e1000e 0000:00:19.0: eth3: Intel(R) PRO/1000 Network Connection
> [36022.227506] e1000e 0000:00:19.0: eth3: MAC: 10, PHY: 11, PBA No: FFFFFF-0FF
> [36022.239789] e1000e 0000:05:00.0: Disabling ASPM L0s
> [36022.239805] e1000e 0000:05:00.0: enabling device (0000 -> 0002)
> [36022.239829] e1000e 0000:05:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [36022.239921] e1000e 0000:05:00.0: setting latency timer to 64
> [36022.240963] e1000e 0000:05:00.0: irq 64 for MSI/MSI-X
> [36022.240995] e1000e 0000:05:00.0: irq 65 for MSI/MSI-X
> [36022.241028] e1000e 0000:05:00.0: irq 66 for MSI/MSI-X
> [36022.241596] e1000e 0000:05:00.0: PCI INT A disabled
> [36022.241606] e1000e: probe of 0000:05:00.0 failed with error -2
> [36022.304706] udevd[3634]: renamed network interface eth2 to eth3
>
> I then don't get an eth2 interface. Only a reboot brings the interface back. This has happened twice so far on this server in the past week, both times using v3.2-rc7-3-g4962516.
>
> lspci -vnn shows:
>
> 05:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
> Subsystem: Super Micro Computer Inc Device [15d9:0000]
> Flags: bus master, fast devsel, latency 0, IRQ 16
> Memory at fbd00000 (32-bit, non-prefetchable) [size=128K]
> I/O ports at e000 [size=32]
> Memory at fbd20000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [c8] Power Management version 2
> Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [e0] Express Endpoint, MSI 00
> Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Device Serial Number 00-25-90-ff-ff-56-ac-74
> Kernel driver in use: e1000e
I've just had this happen on my other (identical) server with a nearly identical trace. Is there anything I can do do avoid this at all or at least help narrow down the problem?
Cheers,
Chris
--
Chris Boot
bootc@bootc.net
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] can: cc770: add legacy ISA bus driver for the CC770 and AN82527
From: Wolfgang Zarre @ 2011-12-31 9:39 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Oliver Hartkopp, linux-can-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <4EF32E84.1080006-PyqsHJVlJN8AvxtiuMwx3w@public.gmane.org>
Hello Wolfgang,
> Hello Wolfgang,
>> Hi Wolfgang,
>>
>> On 12/21/2011 07:32 PM, Wolfgang Zarre wrote:
>>> Hello Wolfgang,
>> ...
>>
>>
>> Again, please check if you have netif_start_queue() at the end of the
>> open function.
>>
>
> As said I'm using eec921ac28fde243456078a557768808d93d94a3
>
> However, I'll try further to investigate that issue due the fact having it
> running with my lincan without problems and therefore it should be possible
> to find the problem.
>
I found the problem which was then at the end quite simple to understand why it
get stuck due the fact not receiving an interrupt for TX and due that no
reactivation of the queue.
I think that maybe also the hacks in the TX functions are obsolete with the
fix assuming that the repeated interrupts just happen by indirect access.
Here my fix which worked for me:
--------------------------------------------------------------------------------------------------------
diff --git a/drivers/net/can/cc770/cc770.c b/drivers/net/can/cc770/cc770.c
index 2d12f89..dad6707 100644
--- a/drivers/net/can/cc770/cc770.c
+++ b/drivers/net/can/cc770/cc770.c
@@ -460,15 +460,6 @@ static netdev_tx_t cc770_start_xmit(struct sk_buff *skb, struct net_device *dev)
stats->tx_bytes += dlc;
-
- /*
- * HM: We had some cases of repeated IRQs so make sure the
- * INT is acknowledged I know it's already further up, but
- * doing again fixed the issue
- */
- cc770_write_reg(priv, msgobj[mo].ctrl0,
- MSGVAL_UNC | TXIE_UNC | RXIE_UNC | INTPND_RES);
-
return NETDEV_TX_OK;
}
@@ -689,12 +680,6 @@ static void cc770_tx_interrupt(struct net_device *dev, unsigned int o)
/* Nothing more to send, switch off interrupts */
cc770_write_reg(priv, msgobj[mo].ctrl0,
MSGVAL_RES | TXIE_RES | RXIE_RES | INTPND_RES);
- /*
- * We had some cases of repeated IRQ so make sure the
- * INT is acknowledged
- */
- cc770_write_reg(priv, msgobj[mo].ctrl0,
- MSGVAL_UNC | TXIE_UNC | RXIE_UNC | INTPND_RES);
stats->tx_packets++;
can_get_echo_skb(dev, 0);
diff --git a/drivers/net/can/cc770/cc770_isa.c b/drivers/net/can/cc770/cc770_isa.c
index 4be5fe2..48fc128 100644
--- a/drivers/net/can/cc770/cc770_isa.c
+++ b/drivers/net/can/cc770/cc770_isa.c
@@ -148,8 +148,7 @@ static void cc770_isa_port_write_reg_indirect(const struct cc770_priv *priv,
{
unsigned long base = (unsigned long)priv->reg_base;
- outb(reg, base);
- outb(val, base + 1);
+ outw( reg + ( val << 8), base);
}
static int __devinit cc770_isa_probe(struct platform_device *pdev)
---------------------------------------------------------------------------------------------
Please let me know if this is OK for You, maybe You can do some tests as well.
Would continue then with further tests regarding error conditions, however
I realised another small issue with dropped packages at reception.
As soon as You read the first time from the socket and then You stop reading
the packages are not counted as 'dropped' any more which is IMHO not correct
because as soon as You stop reading they should be counted as dropped again.
>> Wolfgang.
>
> Wolfgang
Wolfgang
^ permalink raw reply related
* [PATCH 1/2] 8139cp/8139too: do not read into reserved registers
From: Jason Wang @ 2011-12-31 9:44 UTC (permalink / raw)
To: netdev, davem, linux-kernel; +Cc: akong
delay_eeprom() use long read for Cfg9346 register(offset 0x50) which may read
into the area of reserved register(offset 0x53). Use byte read instead.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/ethernet/realtek/8139cp.c | 2 +-
drivers/net/ethernet/realtek/8139too.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 87cff10..886e6be 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -1589,7 +1589,7 @@ static int cp_set_mac_address(struct net_device *dev, void *p)
No extra delay is needed with 33Mhz PCI, but 66Mhz may change this.
*/
-#define eeprom_delay() readl(ee_addr)
+#define eeprom_delay() readb(ee_addr)
/* The EEPROM commands include the alway-set leading bit. */
#define EE_EXTEND_CMD (4)
diff --git a/drivers/net/ethernet/realtek/8139too.c b/drivers/net/ethernet/realtek/8139too.c
index d9c7227..a8779be 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -1122,7 +1122,7 @@ static void __devexit rtl8139_remove_one (struct pci_dev *pdev)
No extra delay is needed with 33Mhz PCI, but 66Mhz may change this.
*/
-#define eeprom_delay() (void)RTL_R32(Cfg9346)
+#define eeprom_delay() (void)RTL_R8(Cfg9346)
/* The EEPROM commands include the alway-set leading bit. */
#define EE_WRITE_CMD (5)
^ permalink raw reply related
* [PATCH 2/2] 8139cp: properly config rx mode after resuming
From: Jason Wang @ 2011-12-31 9:44 UTC (permalink / raw)
To: netdev, davem, linux-kernel; +Cc: akong
In-Reply-To: <20111231094433.5433.67602.stgit@dhcp-8-146.nay.redhat.com>
Rx mode should be reset after resming, so unconditionally updating rx
mode rather than conditionally updating based on the value we
remembered, otherwise unexpected value may be used by the nic after
resuming.
btw. I find and test this when debugging guest hibernation in qemu, as
I did not have a 8139cp card in hand, this patch is untested in a
physical 8139cp card, plase review it carefully.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/ethernet/realtek/8139cp.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 886e6be..cc6b391 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -859,7 +859,6 @@ static void __cp_set_rx_mode (struct net_device *dev)
struct cp_private *cp = netdev_priv(dev);
u32 mc_filter[2]; /* Multicast hash filter */
int rx_mode;
- u32 tmp;
/* Note: do not reorder, GCC is clever about common statements. */
if (dev->flags & IFF_PROMISC) {
@@ -886,11 +885,9 @@ static void __cp_set_rx_mode (struct net_device *dev)
}
/* We can safely update without stopping the chip. */
- tmp = cp_rx_config | rx_mode;
- if (cp->rx_config != tmp) {
- cpw32_f (RxConfig, tmp);
- cp->rx_config = tmp;
- }
+ cp->rx_config = cp_rx_config | rx_mode;
+ cpw32_f(RxConfig, cp->rx_config);
+
cpw32_f (MAR0 + 0, mc_filter[0]);
cpw32_f (MAR0 + 4, mc_filter[1]);
}
^ permalink raw reply related
* Re: BCM43224 hanging [3.2.0-rc5]
From: Nico Schottelius @ 2011-12-31 11:48 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Nico Schottelius, LKML, netdev, b43-dev, Greg KH
In-Reply-To: <4EF32E4B.7050307@broadcom.com>
Hey Arend,
Arend van Spriel [Thu, Dec 22, 2011 at 02:19:07PM +0100]:
> On 12/22/2011 11:24 AM, Nico Schottelius wrote:
> > Update:
> >
> > - dmesg with hanging logs
> > - The hang problem seems to happen ONLY with a specific access point: c8:6c:87:a9:df:a9
> > -> this is a zyxel P-2802HWL-I1, running at channel 13, with WPA2-PSK.
> > -> If you need more information, just let me know
> > - Using wlan with the Samsung S2 as access point seems to work fine
>
> Is the Samsung AP also on channel 13? If not, could you try it?
No it's not and I cannot change it. But I changed the other AP
from 13 to channel 3 and now the hang issue is gone. So this is
definitely related to the specific frequence.
Hope this is enough information to get it fixed evetually :-)
Cheers,
Nico
--
PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0
^ permalink raw reply
* Re: [PATCH 1/1] via-rhine: Fix hanging with high CPU load on low-end broads.
From: Francois Romieu @ 2011-12-31 12:17 UTC (permalink / raw)
To: Bjarke Istrup Pedersen
Cc: David Miller, shemminger, bhutchings, linux-kernel, netdev, rl
In-Reply-To: <CACPM=kWn41S85eLgj4G+c6cN0WBgqF=6MigSwa9QBOxD1Uh64A@mail.gmail.com>
Bjarke Istrup Pedersen <gurligebis@gentoo.org> :
[...]
> Also tried connect a machine to one of the ports, and copying a large
> file across (something that before could make it lock up within 15
> secords) - also worked without any problems - CPU usage around 15%
> (mostly "top" using that), so thats not bad at all.
>
> Is there any other testcases that I should try out?
Same thing + random ethtool link management commands.
Same thing + random cable unplug/plug.
Same thing + pktgen facing the lan interface.
Everything at the same time.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] r8169: Enable suspend when device is idle from boot.
From: Francois Romieu @ 2011-12-31 12:17 UTC (permalink / raw)
To: David Miller; +Cc: tbroch, nic_swsd, netdev, Hayes Wang
In-Reply-To: <20111230.172211.188260740088628815.davem@davemloft.net>
David Miller <davem@davemloft.net> :
[...]
> Francois, what would you like me to do with this patch?
I have not tested it yet. I have no objection if a fix must go in now.
There is a slot for some sanity testing this evening.
The description of the patch implies that the initial power management
state is not right. I would be more inclined to set it correctly when
the device goes up instead of checking repeatedly for a loss of sync
through rtl8169_runtime_idle. Todd, any comment ?
--
Ueimor
^ permalink raw reply
* Re: [GIT PULL net-next] IPVS
From: Pablo Neira Ayuso @ 2011-12-31 15:08 UTC (permalink / raw)
To: Simon Horman
Cc: Patrick McHardy, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Julian Anastasov
In-Reply-To: <20111231090603.GA30937@verge.net.au>
On Sat, Dec 31, 2011 at 06:06:25PM +0900, Simon Horman wrote:
> On Fri, Dec 30, 2011 at 12:24:19PM +0100, Pablo Neira Ayuso wrote:
> > Hi Simon,
> >
> > On Fri, Dec 30, 2011 at 02:19:01PM +0900, Simon Horman wrote:
> > > Hi Pablo,
> > >
> > > please consider pulling
> > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next
> > > master
> >
> > Since this is a fix, I can try to pass this for 3.2-rc7 to davem. I
> > read Linus will release 3.2 by new year, so we can still try to see if
> > we can get it in time.
> >
> > Let me know what you prefer.
>
> Hi Pablo,
>
> please try for 3.2-rc7 if possible.
OK, let's try!
^ permalink raw reply
* Re: [PATCH] ipvs: try also real server with port 0 in backup server
From: Pablo Neira Ayuso @ 2011-12-31 15:08 UTC (permalink / raw)
To: Simon Horman
Cc: Patrick McHardy, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Julian Anastasov
In-Reply-To: <1325222342-20240-2-git-send-email-horms@verge.net.au>
On Fri, Dec 30, 2011 at 02:19:02PM +0900, Simon Horman wrote:
> From: Julian Anastasov <ja@ssi.bg>
>
> We should not forget to try for real server with port 0
> in the backup server when processing the sync message. We should
> do it in all cases because the backup server can use different
> forwarding method.
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
> Signed-off-by: Simon Horman <horms@verge.net.au>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] netfilter: ctnetlink: fix timeout calculation
From: Pablo Neira Ayuso @ 2011-12-31 15:58 UTC (permalink / raw)
To: Xi Wang; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <1325259617-22034-1-git-send-email-xi.wang@gmail.com>
On Fri, Dec 30, 2011 at 10:40:17AM -0500, Xi Wang wrote:
> The sanity check (timeout < 0) never works; the dividend is unsigned
> and so is the division, which should have been a signed division.
>
> long timeout = (ct->timeout.expires - jiffies) / HZ;
> if (timeout < 0)
> timeout = 0;
>
> This patch converts the time values to signed for the division.
>
> Signed-off-by: Xi Wang <xi.wang@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] bonding: fix error handling if slave is busy
From: Nicolas de Pesloüan @ 2011-12-31 16:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Jay Vosburgh, Andy Gospodarek, netdev
In-Reply-To: <20111230144023.371be015@nehalam.linuxnetplumber.net>
Le 30/12/2011 23:40, Stephen Hemminger a écrit :
> The bonding device can cause kernel panic in the enslave error handling.
>
> If slave device already has a receive handler registered, then the
> error unwind does not clear the new entry out of the slave list.
> This ends up leaving a reference to freed memory in the bond
> device slave linked list.
>
> The following is a simple example:
> # modprobe dummy
> # ip li add dummy0-1 link dummy0 type macvlan
> # modprobe bonding
> # echo +dummy0>/sys/class/net/bond0/bonding/slaves
> # ip -s li show dev bond0
>
> This returns with -EBUSY, but the bonding device has bogus entry in
> the slave list, and will panic on next operation that gets statistics
> from bond0.
>
> The fix is to detach the slave (which removes it from the list)
> in the unwind path.
>
>
> Signed-off-by: Stephen Hemminger<shemminger@vyatta.com>
>
> ---
> Patch is against net-next but should be applied to net (3.2), and
> stable (3.1 and 3.0).
>
> --- a/drivers/net/bonding/bond_main.c 2011-12-30 14:20:03.171823181 -0800
> +++ b/drivers/net/bonding/bond_main.c 2011-12-30 14:20:20.232020474 -0800
> @@ -1853,6 +1853,9 @@ err_dest_symlinks:
> bond_destroy_slave_symlinks(bond_dev, slave_dev);
>
> err_close:
> + write_lock_bh(&bond->lock);
> + bond_detach_slave(bond, new_slave);
> + write_unlock_bh(&bond->lock);
> dev_close(slave_dev);
>
> err_unset_master:
NAK.
There are three 'goto err_close' before the call to bond_attach_slave. For those three goto, your
path will call bond_detach_slave without a previous call to bond_attach_slave.
This would at least decrement bond->slave_cnt, without having incremented it before.
Do I miss something ?
Nicolas.
^ permalink raw reply
* [PATCH 0/2] more Netfilter fixes for 3.2-rc7
From: pablo @ 2011-12-31 16:22 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
From: Pablo Neira Ayuso <pablo@netfilter.org>
Hi Dave,
The following patches are a couple of late fixes for Netfilter,
one for IPVS and another for ctnetlink.
You can pull them from:
git://1984.lsi.us.es/net nf
Julian Anastasov (1):
ipvs: try also real server with port 0 in backup server
Xi Wang (1):
netfilter: ctnetlink: fix timeout calculation
include/net/ip_vs.h | 2 +-
net/netfilter/ipvs/ip_vs_conn.c | 2 +-
net/netfilter/ipvs/ip_vs_ctl.c | 10 ++++++++--
net/netfilter/ipvs/ip_vs_sync.c | 2 +-
net/netfilter/nf_conntrack_netlink.c | 4 ++--
5 files changed, 13 insertions(+), 7 deletions(-)
--
1.7.7.3
^ permalink raw reply
* [PATCH 1/2] ipvs: try also real server with port 0 in backup server
From: pablo @ 2011-12-31 16:22 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1325348567-4251-1-git-send-email-pablo@netfilter.org>
From: Julian Anastasov <ja@ssi.bg>
We should not forget to try for real server with port 0
in the backup server when processing the sync message. We should
do it in all cases because the backup server can use different
forwarding method.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/net/ip_vs.h | 2 +-
net/netfilter/ipvs/ip_vs_conn.c | 2 +-
net/netfilter/ipvs/ip_vs_ctl.c | 10 ++++++++--
net/netfilter/ipvs/ip_vs_sync.c | 2 +-
4 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 873d5be..e5a7b9a 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -1207,7 +1207,7 @@ extern void ip_vs_control_cleanup(void);
extern struct ip_vs_dest *
ip_vs_find_dest(struct net *net, int af, const union nf_inet_addr *daddr,
__be16 dport, const union nf_inet_addr *vaddr, __be16 vport,
- __u16 protocol, __u32 fwmark);
+ __u16 protocol, __u32 fwmark, __u32 flags);
extern struct ip_vs_dest *ip_vs_try_bind_dest(struct ip_vs_conn *cp);
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index 12571fb..29fa5ba 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -616,7 +616,7 @@ struct ip_vs_dest *ip_vs_try_bind_dest(struct ip_vs_conn *cp)
if ((cp) && (!cp->dest)) {
dest = ip_vs_find_dest(ip_vs_conn_net(cp), cp->af, &cp->daddr,
cp->dport, &cp->vaddr, cp->vport,
- cp->protocol, cp->fwmark);
+ cp->protocol, cp->fwmark, cp->flags);
ip_vs_bind_dest(cp, dest);
return dest;
} else
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 008bf97..e1a66cf 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -619,15 +619,21 @@ struct ip_vs_dest *ip_vs_find_dest(struct net *net, int af,
const union nf_inet_addr *daddr,
__be16 dport,
const union nf_inet_addr *vaddr,
- __be16 vport, __u16 protocol, __u32 fwmark)
+ __be16 vport, __u16 protocol, __u32 fwmark,
+ __u32 flags)
{
struct ip_vs_dest *dest;
struct ip_vs_service *svc;
+ __be16 port = dport;
svc = ip_vs_service_get(net, af, fwmark, protocol, vaddr, vport);
if (!svc)
return NULL;
- dest = ip_vs_lookup_dest(svc, daddr, dport);
+ if (fwmark && (flags & IP_VS_CONN_F_FWD_MASK) != IP_VS_CONN_F_MASQ)
+ port = 0;
+ dest = ip_vs_lookup_dest(svc, daddr, port);
+ if (!dest)
+ dest = ip_vs_lookup_dest(svc, daddr, port ^ dport);
if (dest)
atomic_inc(&dest->refcnt);
ip_vs_service_put(svc);
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index 3cdd479..2b6678c0 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -740,7 +740,7 @@ static void ip_vs_proc_conn(struct net *net, struct ip_vs_conn_param *param,
* but still handled.
*/
dest = ip_vs_find_dest(net, type, daddr, dport, param->vaddr,
- param->vport, protocol, fwmark);
+ param->vport, protocol, fwmark, flags);
/* Set the approprite ativity flag */
if (protocol == IPPROTO_TCP) {
--
1.7.7.3
^ permalink raw reply related
* [PATCH 2/2] netfilter: ctnetlink: fix timeout calculation
From: pablo @ 2011-12-31 16:22 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1325348567-4251-1-git-send-email-pablo@netfilter.org>
From: Xi Wang <xi.wang@gmail.com>
The sanity check (timeout < 0) never works; the dividend is unsigned
and so is the division, which should have been a signed division.
long timeout = (ct->timeout.expires - jiffies) / HZ;
if (timeout < 0)
timeout = 0;
This patch converts the time values to signed for the division.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_netlink.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index b697777..257e772 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -135,7 +135,7 @@ nla_put_failure:
static inline int
ctnetlink_dump_timeout(struct sk_buff *skb, const struct nf_conn *ct)
{
- long timeout = (ct->timeout.expires - jiffies) / HZ;
+ long timeout = ((long)ct->timeout.expires - (long)jiffies) / HZ;
if (timeout < 0)
timeout = 0;
@@ -1641,7 +1641,7 @@ ctnetlink_exp_dump_expect(struct sk_buff *skb,
const struct nf_conntrack_expect *exp)
{
struct nf_conn *master = exp->master;
- long timeout = (exp->timeout.expires - jiffies) / HZ;
+ long timeout = ((long)exp->timeout.expires - (long)jiffies) / HZ;
struct nf_conn_help *help;
if (timeout < 0)
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH 0/2] more Netfilter fixes for 3.2-rc7
From: David Miller @ 2011-12-31 17:46 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1325348567-4251-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Sat, 31 Dec 2011 17:22:45 +0100
> The following patches are a couple of late fixes for Netfilter,
> one for IPVS and another for ctnetlink.
>
> You can pull them from:
>
> git://1984.lsi.us.es/net nf
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] r8169: Enable suspend when device is idle from boot.
From: David Miller @ 2011-12-31 17:46 UTC (permalink / raw)
To: romieu; +Cc: tbroch, nic_swsd, netdev, hayeswang
In-Reply-To: <20111231121704.GA9842@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Sat, 31 Dec 2011 13:17:04 +0100
> David Miller <davem@davemloft.net> :
> [...]
>> Francois, what would you like me to do with this patch?
>
> I have not tested it yet. I have no objection if a fix must go in now.
There is no rush with this, I just was seeking your opinion :-)
^ permalink raw reply
* Re: [PATCH net-next V2 00/21] net/mlx4: SRIOV support
From: Yinghai Lu @ 2011-12-31 18:37 UTC (permalink / raw)
To: Roland Dreier
Cc: Or Gerlitz, Yevgeny Petrilin, David Miller,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Liran Liss,
jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org
In-Reply-To: <CAL1RGDWa+8gv8WZrCtQBpzAQUkD982ONODE7qRjUs_Gn2m4DKA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Dec 30, 2011 at 9:57 PM, Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org> wrote:
> On Fri, Dec 30, 2011 at 2:23 PM, Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
>> hotplug removal is broken...
>
> Is this a new regression with these patches?
>
yes.
after reverting those patches, removal work well without problem.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: [PATCH RFC] IPv6: Avoid taking write lock for /proc/net/ipv6_route
From: Josh Hunt @ 2011-12-31 19:49 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <20111230.170905.1348056803377924696.davem@davemloft.net>
On Fri, Dec 30, 2011 at 4:09 PM, David Miller <davem@davemloft.net> wrote:
> From: Josh Hunt <joshhunt00@gmail.com>
> Date: Wed, 28 Dec 2011 17:23:07 -0600
>
>> lock_stat shows taking the write lock is causing the slowdown. Using
>> this info I decided to write a version of fib6_clean_all() which
>> replaces write_lock_bh(&table->tb6_lock) with
>> read_lock_bh(&table->tb6_lock). With this new function I see the same
>> results as with my rtnetlink iperf test. I guess my question is what
>> am I missing? Is there a reason you need to take the write lock when
>> reading the route table to display to proc?
>
> You're not missing anything, it's just an oversight or laziness. :-)
>
> I've applied your patch thanks.
>
> Longer term we should make the ipv6 tree traversals RCU safe just
> like net/ipv4/fib_trie.c is. Then we can do away with even the
> read locks for read-only traversals.
>
Thanks David. Are you aware if anyone has started the work to make
IPv6 traversals RCU safe?
--
Josh
^ permalink raw reply
* Re: SFQ on HFSC leaf does not seem to work
From: John A. Sullivan III @ 2011-12-31 22:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1324654013.10184.597.camel@denise.theartistscloset.com>
On Fri, 2011-12-23 at 10:26 -0500, John A. Sullivan III wrote:
> <snip>>
> > > tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match
> > > tcp src 443 0x00ff flowid 1:10
> >
> > why "src 443 0x00ff" ? It should be "src 443 0xffff"
> That's what I tried at first but nothing matched the filter. I assumed
> it was because it objected to a value in the dst field so I masked it
> off and it worked.
> >
> > > tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match
> > > tcp dst 822 0xff00 flowid 1:30
> >
> > same here : "dst 822 0xffff"
> Same as above. No filter matches when using that mask.
> >
<snip>
Oops! Must have not matched for some other reason - this is a clear
binary brain cramp! This now appears to be working:
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 handle 6: u32 divisor 1
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff link 6: offset at 0 mask 0x0f00 shift 6 plus 0
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp dst 822 0xffff at nexthdr+2 flowid 1:30
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp src 822 0xffff at nexthdr+0 flowid 1:30
# Send packets <64 bytes (u16 0 0xffc0 at 2) with only the ACK flag set (match u8 16 0xff at nexthdr+13) to the low latency queue
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match u16 0 0xffc0 at 2 match u8 16 0xff at nexthdr+13 flowid 1:30
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp src 443 0xffff at nexthdr+0 flowid 1:10
Thanks - John
^ permalink raw reply
* iproute2: proper detection of libxtables position and flags
From: Jan Engelhardt @ 2011-12-31 22:17 UTC (permalink / raw)
To: shemminger; +Cc: Linux Networking Developer Mailing List
From: Jan Engelhardt <jengelh@medozas.de>
Date: 2011-09-24 23:37:34.405739159 +0200
Upstream: not sent yet
Any tests involving iptables _MUST_ utilize pkg-config to find the
proper locations of the installation.
---
configure | 2 +-
tc/Makefile | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
Index: iproute2-2.6.39/configure
===================================================================
--- iproute2-2.6.39.orig/configure
+++ iproute2-2.6.39/configure
@@ -49,7 +49,7 @@ int main(int argc, char **argv)
EOF
-if gcc -I$INCLUDE $IPTC -o /tmp/ipttest /tmp/ipttest.c $IPTL -ldl -lxtables >/dev/null 2>&1
+if gcc -I$INCLUDE $IPTC -o /tmp/ipttest /tmp/ipttest.c $IPTL $(pkg-config xtables --cflags --libs) -ldl >/dev/null 2>&1
then
echo "TC_CONFIG_XT:=y" >>Config
echo "using xtables"
Index: iproute2-2.6.39/tc/Makefile
===================================================================
--- iproute2-2.6.39.orig/tc/Makefile
+++ iproute2-2.6.39/tc/Makefile
@@ -124,10 +124,10 @@ q_atm.so: q_atm.c
$(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o q_atm.so q_atm.c -latm
m_xt.so: m_xt.c
- $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt.so m_xt.c -lxtables
+ $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt.so m_xt.c $$(pkg-config xtables --cflags --libs)
m_xt_old.so: m_xt_old.c
- $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt_old.so m_xt_old.c -lxtables
+ $(CC) $(CFLAGS) $(LDFLAGS) -shared -fpic -o m_xt_old.so m_xt_old.c $$(pkg-config xtables --cflags --libs)
%.yacc.c: %.y
$(YACC) $(YACCFLAGS) -o $@ $<
^ permalink raw reply
* iproute2: fix calling up the xt action
From: Jan Engelhardt @ 2011-12-31 22:18 UTC (permalink / raw)
To: shemminger; +Cc: Linux Networking Developer Mailing List
In-Reply-To: <alpine.LNX.2.01.1112312317220.24158@frira.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: 2011-06-01 00:52:07+0200
Upsteam: has not been sent yet
Requesting the xt action never succeeded because it registered
using the wrong name.
---
tc/m_xt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: iproute2-2.6.37/tc/m_xt.c
===================================================================
--- iproute2-2.6.37.orig/tc/m_xt.c
+++ iproute2-2.6.37/tc/m_xt.c
@@ -343,8 +343,8 @@ print_ipt(struct action_util *au,FILE *
return 0;
}
-struct action_util ipt_action_util = {
- .id = "ipt",
+struct action_util xt_action_util = {
+ .id = "xt",
.parse_aopt = parse_ipt,
.print_aopt = print_ipt,
};
^ permalink raw reply
* Re: [PATCH 1/2] 8139cp/8139too: do not read into reserved registers
From: Ben Hutchings @ 2011-12-31 22:20 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, davem, linux-kernel, akong
In-Reply-To: <20111231094433.5433.67602.stgit@dhcp-8-146.nay.redhat.com>
On Sat, 2011-12-31 at 17:44 +0800, Jason Wang wrote:
> delay_eeprom() use long read for Cfg9346 register(offset 0x50) which may read
> into the area of reserved register(offset 0x53). Use byte read instead.
[...]
If they've been working like this for so long (from the start of git
history), maybe they're best left alone.
Ben.
--
Ben Hutchings, Staff 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
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