* [PATCH 08/18] IPVS: Add {sysctl_sync_threshold,period}()
From: Simon Horman @ 2011-03-05 23:45 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Julian Anastasov, Hans Schillstrom, Simon Horman
In-Reply-To: <1299368760-14271-1-git-send-email-horms@verge.net.au>
In preparation for not including sysctl_sync_threshold in
struct netns_ipvs when CONFIG_SYCTL is not defined.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 29 +++++++++++++++++++++++++++++
net/netfilter/ipvs/ip_vs_core.c | 10 +++++-----
net/netfilter/ipvs/ip_vs_ctl.c | 4 ++--
net/netfilter/ipvs/ip_vs_sync.c | 4 ++--
4 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index efd68dc..4975524 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -908,6 +908,35 @@ struct netns_ipvs {
struct net *net; /* Needed by timer routines */
};
+#define DEFAULT_SYNC_THRESHOLD 3
+#define DEFAULT_SYNC_PERIOD 50
+
+#ifdef CONFIG_SYSCTL
+
+static inline int sysctl_sync_threshold(struct netns_ipvs *ipvs)
+{
+ return ipvs->sysctl_sync_threshold[0];
+}
+
+static inline int sysctl_sync_period(struct netns_ipvs *ipvs)
+{
+ return ipvs->sysctl_sync_threshold[1];
+}
+
+#else
+
+static inline int sysctl_sync_threshold(struct netns_ipvs *ipvs)
+{
+ return DEFAULT_SYNC_THRESHOLD;
+}
+
+static inline int sysctl_sync_period(struct netns_ipvs *ipvs)
+{
+ return DEFAULT_SYNC_PERIOD;
+}
+
+#endif
+
/*
* IPVS core functions
* (from ip_vs_core.c)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index c9b8372..6a0053d 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1613,15 +1613,15 @@ ip_vs_in(unsigned int hooknum, struct sk_buff *skb, int af)
*/
if (cp->flags & IP_VS_CONN_F_ONE_PACKET)
- pkts = ipvs->sysctl_sync_threshold[0];
+ pkts = sysctl_sync_threshold(ipvs);
else
pkts = atomic_add_return(1, &cp->in_pkts);
if ((ipvs->sync_state & IP_VS_STATE_MASTER) &&
cp->protocol == IPPROTO_SCTP) {
if ((cp->state == IP_VS_SCTP_S_ESTABLISHED &&
- (pkts % ipvs->sysctl_sync_threshold[1]
- == ipvs->sysctl_sync_threshold[0])) ||
+ (pkts % sysctl_sync_period(ipvs)
+ == sysctl_sync_threshold(ipvs))) ||
(cp->old_state != cp->state &&
((cp->state == IP_VS_SCTP_S_CLOSED) ||
(cp->state == IP_VS_SCTP_S_SHUT_ACK_CLI) ||
@@ -1635,8 +1635,8 @@ ip_vs_in(unsigned int hooknum, struct sk_buff *skb, int af)
else if ((ipvs->sync_state & IP_VS_STATE_MASTER) &&
(((cp->protocol != IPPROTO_TCP ||
cp->state == IP_VS_TCP_S_ESTABLISHED) &&
- (pkts % ipvs->sysctl_sync_threshold[1]
- == ipvs->sysctl_sync_threshold[0])) ||
+ (pkts % sysctl_sync_period(ipvs)
+ == sysctl_sync_threshold(ipvs))) ||
((cp->protocol == IPPROTO_TCP) && (cp->old_state != cp->state) &&
((cp->state == IP_VS_TCP_S_FIN_WAIT) ||
(cp->state == IP_VS_TCP_S_CLOSE) ||
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index fd74527..8cdbf91 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -3569,8 +3569,8 @@ int __net_init __ip_vs_control_init(struct net *net)
tbl[idx++].data = &ipvs->sysctl_cache_bypass;
tbl[idx++].data = &ipvs->sysctl_expire_nodest_conn;
tbl[idx++].data = &ipvs->sysctl_expire_quiescent_template;
- ipvs->sysctl_sync_threshold[0] = 3;
- ipvs->sysctl_sync_threshold[1] = 50;
+ ipvs->sysctl_sync_threshold[0] = DEFAULT_SYNC_THRESHOLD;
+ ipvs->sysctl_sync_threshold[1] = DEFAULT_SYNC_PERIOD;
tbl[idx].data = &ipvs->sysctl_sync_threshold;
tbl[idx++].maxlen = sizeof(ipvs->sysctl_sync_threshold);
tbl[idx++].data = &ipvs->sysctl_nat_icmp_send;
diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index fecf24d..d037763 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -650,7 +650,7 @@ control:
if (cp->flags & IP_VS_CONN_F_TEMPLATE) {
int pkts = atomic_add_return(1, &cp->in_pkts);
- if (pkts % ipvs->sysctl_sync_threshold[1] != 1)
+ if (pkts % sysctl_sync_period(ipvs) != 1)
return;
}
goto sloop;
@@ -795,7 +795,7 @@ static void ip_vs_proc_conn(struct net *net, struct ip_vs_conn_param *param,
if (opt)
memcpy(&cp->in_seq, opt, sizeof(*opt));
- atomic_set(&cp->in_pkts, ipvs->sysctl_sync_threshold[0]);
+ atomic_set(&cp->in_pkts, sysctl_sync_threshold(ipvs));
cp->state = state;
cp->old_state = cp->state;
/*
--
1.7.2.3
^ permalink raw reply related
* [PATCH 06/18] IPVS: Add sysctl_snat_reroute()
From: Simon Horman @ 2011-03-05 23:45 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Julian Anastasov, Hans Schillstrom, Simon Horman
In-Reply-To: <1299368760-14271-1-git-send-email-horms@verge.net.au>
In preparation for not including sysctl_snat_reroute in
struct netns_ipvs when CONFIG_SYCTL is not defined.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_core.c | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 299c7f3..1d8a2a2 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -599,6 +599,20 @@ int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
return NF_DROP;
}
+#ifdef CONFIG_SYSCTL
+
+static int sysctl_snat_reroute(struct sk_buff *skb)
+{
+ struct netns_ipvs *ipvs = net_ipvs(skb_net(skb));
+ return ipvs->sysctl_snat_reroute;
+}
+
+#else
+
+static int sysctl_snat_reroute(struct sk_buff *skb) { return 0; }
+
+#endif
+
__sum16 ip_vs_checksum_complete(struct sk_buff *skb, int offset)
{
return csum_fold(skb_checksum(skb, offset, skb->len - offset, 0));
@@ -633,15 +647,13 @@ static inline int ip_vs_gather_frags_v6(struct sk_buff *skb, u_int32_t user)
static int ip_vs_route_me_harder(int af, struct sk_buff *skb)
{
- struct netns_ipvs *ipvs = net_ipvs(skb_net(skb));
-
#ifdef CONFIG_IP_VS_IPV6
if (af == AF_INET6) {
- if (ipvs->sysctl_snat_reroute && ip6_route_me_harder(skb) != 0)
+ if (sysctl_snat_reroute(skb) && ip6_route_me_harder(skb) != 0)
return 1;
} else
#endif
- if ((ipvs->sysctl_snat_reroute ||
+ if ((sysctl_snat_reroute(skb) ||
skb_rtable(skb)->rt_flags & RTCF_LOCAL) &&
ip_route_me_harder(skb, RTN_LOCAL) != 0)
return 1;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 18/18] IPVS: Conditionally include sysctl members of struct netns_ipvs
From: Simon Horman @ 2011-03-05 23:46 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Julian Anastasov, Hans Schillstrom, Simon Horman
In-Reply-To: <1299368760-14271-1-git-send-email-horms@verge.net.au>
There is now no need to include sysctl members of struct netns_ipvs
unless CONFIG_SYSCTL is defined.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
include/net/ip_vs.h | 21 +++++++++++++--------
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index 7ef0813..9b92190 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -838,6 +838,17 @@ struct netns_ipvs {
struct ip_vs_stats tot_stats; /* Statistics & est. */
int num_services; /* no of virtual services */
+
+ rwlock_t rs_lock; /* real services table */
+ /* semaphore for IPVS sockopts. And, [gs]etsockopt may sleep. */
+ struct lock_class_key ctl_key; /* ctl_mutex debuging */
+ /* Trash for destinations */
+ struct list_head dest_trash;
+ /* Service counters */
+ atomic_t ftpsvc_counter;
+ atomic_t nullsvc_counter;
+
+#ifdef CONFIG_SYSCTL
/* 1/rate drop and drop-entry variables */
struct delayed_work defense_work; /* Work handler */
int drop_rate;
@@ -847,18 +858,12 @@ struct netns_ipvs {
spinlock_t dropentry_lock; /* drop entry handling */
spinlock_t droppacket_lock; /* drop packet handling */
spinlock_t securetcp_lock; /* state and timeout tables */
- rwlock_t rs_lock; /* real services table */
- /* semaphore for IPVS sockopts. And, [gs]etsockopt may sleep. */
- struct lock_class_key ctl_key; /* ctl_mutex debuging */
- /* Trash for destinations */
- struct list_head dest_trash;
- /* Service counters */
- atomic_t ftpsvc_counter;
- atomic_t nullsvc_counter;
/* sys-ctl struct */
struct ctl_table_header *sysctl_hdr;
struct ctl_table *sysctl_tbl;
+#endif
+
/* sysctl variables */
int sysctl_amemthresh;
int sysctl_am_droprate;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 15/18] IPVS: Minimise ip_vs_leave when CONFIG_SYSCTL is undefined
From: Simon Horman @ 2011-03-05 23:45 UTC (permalink / raw)
To: netdev, netfilter-devel, netfilter, lvs-devel
Cc: Julian Anastasov, Hans Schillstrom, Simon Horman
In-Reply-To: <1299368760-14271-1-git-send-email-horms@verge.net.au>
Much of ip_vs_leave() is unnecessary if CONFIG_SYSCTL is undefined.
I tried an approach of breaking the now #ifdef'ed portions out
into a separate function. However this appeared to grow the
compiled code on x86_64 by about 200 bytes in the case where
CONFIG_SYSCTL is defined. So I have gone with the simpler though
less elegant #ifdef'ed solution for now.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_core.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index d418bc6..07accf6 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -499,11 +499,13 @@ ip_vs_schedule(struct ip_vs_service *svc, struct sk_buff *skb,
int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
struct ip_vs_proto_data *pd)
{
- struct net *net;
- struct netns_ipvs *ipvs;
__be16 _ports[2], *pptr;
struct ip_vs_iphdr iph;
+#ifdef CONFIG_SYSCTL
+ struct net *net;
+ struct netns_ipvs *ipvs;
int unicast;
+#endif
ip_vs_fill_iphdr(svc->af, skb_network_header(skb), &iph);
@@ -512,6 +514,8 @@ int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
ip_vs_service_put(svc);
return NF_DROP;
}
+
+#ifdef CONFIG_SYSCTL
net = skb_net(skb);
#ifdef CONFIG_IP_VS_IPV6
@@ -563,6 +567,7 @@ int ip_vs_leave(struct ip_vs_service *svc, struct sk_buff *skb,
ip_vs_conn_put(cp);
return ret;
}
+#endif
/*
* When the virtual ftp service is presented, packets destined
--
1.7.2.3
^ permalink raw reply related
* Re: Mass udp flow reboot linux with RealTek RTL-8169 Gigabit
From: Seblu @ 2011-03-06 0:29 UTC (permalink / raw)
To: Francois Romieu; +Cc: Eric Dumazet, lkml, netdev, Ivan Vecera
In-Reply-To: <20110218093000.GA12106@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 13538 bytes --]
On Fri, Feb 18, 2011 at 10:30 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Seblu <seblu@seblu.net> :
> [...]
>> I've applyed your patch on 2.6.38-rc5. Host have rebooted 2mn after udp start.
>> After this reboot, host is still on after 2 hour under a 1Gbit/s udp flow.
>
> Thanks for testing.
Thanks for debugging! Sorry for the late reply.
I catched the following trace during my previous torture session.
Maybe it can help.
[ 1448.189961] ------------[ cut here ]------------
[ 1448.189968] WARNING: at net/sched/sch_generic.c:256
dev_watchdog+0x104/0x1ad()
[ 1448.189970] Hardware name: H55N-USB3
[ 1448.189971] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
[ 1448.189972] Modules linked in: ext2 it87 hwmon_vid ds1621 i915
drm_kms_helper drm i2c_algo_bit video dm_crypt raid456
async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy
async_tx md_mod option usb_wwan r8169 snd_pcm snd_timer snd soundcore
usbserial uhci_hcd xhci_hcd ehci_hcd usbcore tpm_tis evdev i2c_i801
tpm processor snd_page_alloc mii sata_mv pcspkr serio_raw i2c_core
tpm_bios button thermal_sys nls_base ext4 mbcache jbd2 crc16 dm_mod
btrfs zlib_deflate crc32c libcrc32c sd_mod crc_t10dif ahci libahci
libata scsi_mod
[ 1448.190006] Pid: 0, comm: kworker/0:1 Not tainted 2.6.38-rc5-seblu #2
[ 1448.190007] Call Trace:
[ 1448.190009] <IRQ> [<ffffffff8103a198>] ? warn_slowpath_common+0x78/0x8c
[ 1448.190016] [<ffffffff8103a24b>] ? warn_slowpath_fmt+0x45/0x4a
[ 1448.190018] [<ffffffff8126a718>] ? netif_tx_lock+0x43/0x74
[ 1448.190019] [<ffffffff8126a84d>] ? dev_watchdog+0x104/0x1ad
[ 1448.190023] [<ffffffff8104e80f>] ? __queue_work+0x30c/0x334
[ 1448.190026] [<ffffffff81045ff3>] ? run_timer_softirq+0x1b8/0x27b
[ 1448.190028] [<ffffffff8126a749>] ? dev_watchdog+0x0/0x1ad
[ 1448.190031] [<ffffffff8105a726>] ? ktime_get+0x5f/0xb8
[ 1448.190034] [<ffffffff8103fa09>] ? __do_softirq+0xbd/0x194
[ 1448.190037] [<ffffffff810037cc>] ? call_softirq+0x1c/0x28
[ 1448.190040] [<ffffffff81004bb5>] ? do_softirq+0x31/0x63
[ 1448.190042] [<ffffffff8103f8b1>] ? irq_exit+0x36/0x7b
[ 1448.190045] [<ffffffff8101843c>] ? smp_apic_timer_interrupt+0x87/0x94
[ 1448.190047] [<ffffffff81003293>] ? apic_timer_interrupt+0x13/0x20
[ 1448.190048] <EOI> [<ffffffff81056250>] ? hrtimer_get_next_event+0x8a/0xa2
[ 1448.190056] [<ffffffffa0128d11>] ? acpi_idle_enter_c1+0x7b/0x95 [processor]
[ 1448.190059] [<ffffffffa0128cf1>] ? acpi_idle_enter_c1+0x5b/0x95 [processor]
[ 1448.190063] [<ffffffff8123c097>] ? cpuidle_idle_call+0x119/0x1c6
[ 1448.190065] [<ffffffff81001c9c>] ? cpu_idle+0xa5/0xdb
[ 1448.190068] [<ffffffff812ffd4a>] ? start_secondary+0x1ad/0x1b3
[ 1448.190070] ---[ end trace dd5a8baf361d8b47 ]---
>> I attached a dmesg output before reboot. Do you need anything else?
ok. next informations is about test with patch
r8169-TX-stop-queue-race-fix and r8169-debuginator on 2.6.38-rc7.
> Mostly :
> 1. .config
see attachment
> 2. the size of the udp packets and the mtu
eth0 mtu is 1500
iperf output:
Client connecting to bitume, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 122 KByte (default)
and icmp echo have size of 65500.
> As an option :
> 3. a few seconds of 'vmstat 1' from the host under test
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 3720532 11292 43292 0 0 15 2 2356 4160 0 1 98 1
0 0 0 3720524 11300 43316 0 0 0 20 21459 41637 0 2 97 2
1 0 0 3720420 11300 43316 0 0 0 0 20565 39521 1 1 98 0
0 0 0 3720588 11300 43316 0 0 0 0 21451 41569 0 1 99 0
0 0 0 3720492 11300 43316 0 0 0 0 21492 41441 0 1 98 0
0 0 0 3720564 11300 43316 0 0 0 0 21475 41435 0 2 98 0
1 0 0 3720500 11308 43320 0 0 0 16 21485 41675 1 1 97 1
1 0 0 3720556 11308 43320 0 0 0 0 17940 33773 0 1 99 0
0 0 0 3720588 11308 43320 0 0 0 0 9472 16384 0 1 100 0
0 0 0 3720660 11308 43320 0 0 0 0 8769 15217 1 1 99 0
0 0 0 3720484 11308 43320 0 0 0 0 10137 17766 0 1 99 0
2 0 0 3720524 11316 43324 0 0 0 16 9760 16907 0 1 98 2
0 0 0 3720492 11316 43324 0 0 0 0 9956 17138 0 1 99 0
0 0 0 3720492 11316 43324 0 0 0 0 9927 17220 0 0 99 0
1 0 0 3720524 11316 43324 0 0 0 0 10543 18502
0 0 100 0
1 0 0 3720596 11316 43324 0 0 0 0 9600 16409 0 1 99 0
0 0 0 3720564 11324 43324 0 0 0 60 9953 17339 0 1 98 1
0 0 0 3720460 11324 43324 0 0 0 0 9503 16583 0 0 99 0
0 0 0 3720684 11324 43324 0 0 0 0 9106 15637 0 1 99 0
0 0 0 3720460 11324 43324 0 0 0 0 9800 17019 0 1 99 0
0 0 0 3720492 11324 43324 0 0 0 0 9522 16559 0 0 99 0
0 0 0 3720428 11332 43328 0 0 0 28 9789 17106 0 1 97 2
0 0 0 3720460 11332 43328 0 0 0 0 10157 17717 0 1 99 0
0 0 0 3720564 11332 43328 0 0 0 0 9882 16940 0 0 100 0
0 0 0 3720492 11332 43328 0 0 0 0 9360 15991 0 0 100 0
0 0 0 3720492 11332 43328 0 0 0 0 10096 17436 0 0 99 0
0 0 0 3720556 11340 43328 0 0 0 28 9224 16028 0 1 97 2
0 0 0 3720500 11340 43328 0 0 0 0 9154 15942 0 1 99 0
1 0 0 3720524 11340 43328 0 0 0 0 10309 17781 0 1 99 0
> 4. an 'ethtool -s eth0' from the host under test
# ethtool -S eth0
NIC statistics:
tx_packets: 2598554
rx_packets: 35146015
tx_errors: 0
rx_errors: 0
rx_missed: 27571
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 35145983
broadcast: 24
multicast: 8
tx_aborted: 0
tx_underrun: 0
> 5. /proc/interrupts from the host under test
CPU0 CPU1 CPU2 CPU3
0: 40 1 0 2 IO-APIC-edge timer
1: 1 0 0 1 IO-APIC-edge i8042
8: 0 0 1 0 IO-APIC-edge rtc0
9: 0 0 0 0 IO-APIC-fasteoi acpi
16: 135 135 130 124 IO-APIC-fasteoi
sata_mv, uhci_hcd:usb4
18: 0 0 0 0 IO-APIC-fasteoi
ehci_hcd:usb1, uhci_hcd:usb6, uhci_hcd:usb9
19: 0 0 0 0 IO-APIC-fasteoi
uhci_hcd:usb8
21: 0 0 0 0 IO-APIC-fasteoi
uhci_hcd:usb5
23: 0 0 0 0 IO-APIC-fasteoi
ehci_hcd:usb3, uhci_hcd:usb7
41: 1196 1164 1206 1197 PCI-MSI-edge ahci
42: 0 0 0 1 PCI-MSI-edge xhci_hcd
43: 0 0 0 0 PCI-MSI-edge xhci_hcd
44: 0 0 0 0 PCI-MSI-edge xhci_hcd
45: 0 0 0 0 PCI-MSI-edge xhci_hcd
46: 0 0 0 0 PCI-MSI-edge xhci_hcd
47: 2517359 2517695 2517327 2517689 PCI-MSI-edge eth0
48: 0 0 0 0 PCI-MSI-edge i915
NMI: 64 64 63 61 Non-maskable interrupts
LOC: 189057 173286 183692 172647 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 64 64 63 61 Performance
monitoring interrupts
IWI: 0 0 0 0 IRQ work interrupts
RES: 75 82 102 65 Rescheduling interrupts
CAL: 93 129 107 125 Function call interrupts
TLB: 105 111 238 322 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 5 5 5 5 Machine check polls
ERR: 3
MIS: 0
> 6. lspci -tv
-[0000:00]-+-00.0 Intel Corporation Core Processor DRAM Controller
+-01.0-[01]----00.0 Adaptec Serial ATA II RAID 1430SA
+-02.0 Intel Corporation Core Processor Integrated
Graphics Controller
+-16.0 Intel Corporation 5 Series/3400 Series Chipset HECI
Controller
+-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB
Universal Host Controller
+-1a.1 Intel Corporation 5 Series/3400 Series Chipset USB
Universal Host Controller
+-1a.2 Intel Corporation 5 Series/3400 Series Chipset USB
Universal Host Controller
+-1a.7 Intel Corporation 5 Series/3400 Series Chipset USB2
Enhanced Host Controller
+-1c.0-[02]--
+-1c.3-[03]----00.0 NEC Corporation uPD720200 USB 3.0 Host
Controller
+-1c.5-[04]----00.0 Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller
+-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB
Universal Host Controller
+-1d.1 Intel Corporation 5 Series/3400 Series Chipset USB
Universal Host Controller
+-1d.2 Intel Corporation 5 Series/3400 Series Chipset USB
Universal Host Controller
+-1d.7 Intel Corporation 5 Series/3400 Series Chipset USB2
Enhanced Host Controller
+-1e.0-[05]--
+-1f.0 Intel Corporation 5 Series Chipset LPC Interface Controller
+-1f.2 Intel Corporation 5 Series/3400 Series Chipset 6
port SATA AHCI Controller
\-1f.3 Intel Corporation 5 Series/3400 Series Chipset
SMBus Controller
>
> Can you apply the two attached patches on top of the previous ones and
> give it a try ? The debug should not be too verbose if things are stationary
> enough.
2.6.38-rc7 with your 2 previous patch change the game. No reboot. No
strange message in dmesg.
But somes sended packet are lost from some host. Example:
thunder ~ 1 # ping bitume
PING bitume.spn (192.168.242.4) 56(84) bytes of data.
64 bytes from bitume.spn (192.168.242.4): icmp_req=9 ttl=64 time=1005 ms
64 bytes from bitume.spn (192.168.242.4): icmp_req=10 ttl=64 time=0.538 ms
64 bytes from bitume.spn (192.168.242.4): icmp_req=12 ttl=64 time=0.817 ms
64 bytes from bitume.spn (192.168.242.4): icmp_req=15 ttl=64 time=0.639 ms
64 bytes from bitume.spn (192.168.242.4): icmp_req=20 ttl=64 time=5.32 ms
64 bytes from bitume.spn (192.168.242.4): icmp_req=22 ttl=64 time=0.866 ms
64 bytes from bitume.spn (192.168.242.4): icmp_req=26 ttl=64 time=0.607 ms
bitume ~ 0 # tcpdump -lni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:23:45.713828 IP 192.168.242.5 > 192.168.242.4: ICMP echo request,
id 19486, seq 9, length 64
00:23:46.718479 IP 192.168.242.4 > 192.168.242.5: ICMP echo reply, id
19486, seq 9, length 64
00:23:46.718482 IP 192.168.242.4 > 192.168.242.5: ICMP ip reassembly
time exceeded, length 556
00:23:46.720291 IP 192.168.242.5 > 192.168.242.4: ICMP echo request,
id 19486, seq 10, length 64
00:23:46.720297 IP 192.168.242.4 > 192.168.242.5: ICMP echo reply, id
19486, seq 10, length 64
00:23:48.141013 IP 192.168.242.4 > 192.168.242.5: ICMP ip reassembly
time exceeded, length 556
00:23:48.722329 IP 192.168.242.5 > 192.168.242.4: ICMP echo request,
id 19486, seq 12, length 64
00:23:48.722335 IP 192.168.242.4 > 192.168.242.5: ICMP echo reply, id
19486, seq 12, length 64
00:23:51.741686 IP 192.168.242.5 > 192.168.242.4: ICMP echo request,
id 19486, seq 15, length 64
00:23:51.741692 IP 192.168.242.4 > 192.168.242.5: ICMP echo reply, id
19486, seq 15, length 64
00:23:56.778367 IP 192.168.242.5 > 192.168.242.4: ICMP echo request,
id 19486, seq 20, length 64
00:23:56.778373 IP 192.168.242.4 > 192.168.242.5: ICMP echo reply, id
19486, seq 20, length 64
00:23:57.988239 IP 192.168.242.2 > 192.168.242.4: ICMP ip reassembly
time exceeded, length 556
00:23:57.988243 IP 192.168.242.2 > 192.168.242.4: ICMP ip reassembly
time exceeded, length 556
00:23:57.988327 IP 192.168.242.2 > 192.168.242.4: ICMP ip reassembly
time exceeded, length 556
00:23:58.775425 IP 192.168.242.5 > 192.168.242.4: ICMP echo request,
id 19486, seq 22, length 64
00:23:58.775431 IP 192.168.242.4 > 192.168.242.5: ICMP echo reply, id
19486, seq 22, length 64
^C
17 packets captured
82 packets received by filter
0 packets dropped by kernel
This is maybe normal under stress, card discard packet after all.
> Do you have a serial cable and a second computer at hand by chance (don't
> go for netconsole with the r8169 driver) ?
I've a serial cable and a second computer, but my first computer
doesn't have a com port. Is it then possible?
Do you need more test?
--
Sébastien Luttringer
www.seblu.net
[-- Attachment #2: dmesg.2.6.38-rc7-seblu-patched.xz --]
[-- Type: application/x-xz, Size: 13516 bytes --]
[-- Attachment #3: config-2.6.38-rc7-seblu-patched.xz --]
[-- Type: application/x-xz, Size: 26984 bytes --]
^ permalink raw reply
* [PATCH 1/2] Issue NETDEV_CHANGE notification when bridge changes state
From: Adam Majer @ 2011-03-06 5:18 UTC (permalink / raw)
To: netdev
Cc: Stephen Hemminger, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, bridge, linux-kernel
IPv6 address autoconfiguration relies on an UP interface to processes
traffic normally. A bridge that is UP enters LEARNING state and this
state "eats" any Router Advertising packets sent to the
bridge. Issuing a NETDEV_CHANGE notification on the bridge interface
when it changes state allows autoconfiguration code to retry
querying router information.
Signed-off-by: Adam Majer <adamm@zombino.com>
---
net/bridge/br_if.c | 20 ++++++++++++++++++++
net/bridge/br_private.h | 2 ++
net/bridge/br_stp.c | 2 ++
3 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index d9d1e2b..9604d52 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -25,6 +25,22 @@
#include "br_private.h"
+
+/*
+ * Notifies that the bridge has changed state
+ */
+static void br_port_change_notifier_handler(struct work_struct *work)
+{
+ struct net_bridge *br = container_of(work,
+ struct net_bridge,
+ change_notification_worker);
+
+ rtnl_lock();
+ netdev_state_change(br->dev);
+ rtnl_unlock();
+}
+
+
/*
* Determine initial path cost based on speed.
* using recommendations from 802.1d standard
@@ -163,6 +179,7 @@ static void del_br(struct net_bridge *br, struct list_head *head)
{
struct net_bridge_port *p, *n;
+ flush_work(&br->change_notification_worker);
list_for_each_entry_safe(p, n, &br->port_list, list) {
del_nbp(p);
}
@@ -203,6 +220,9 @@ static struct net_device *new_bridge_dev(struct net *net, const char *name)
memcpy(br->group_addr, br_group_address, ETH_ALEN);
+ INIT_WORK(&br->change_notification_worker,
+ &br_port_change_notifier_handler);
+
br->feature_mask = dev->features;
br->stp_enabled = BR_NO_STP;
br->designated_root = br->bridge_id;
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 4e1b620..7f8ef41 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -179,6 +179,8 @@ struct net_bridge
struct list_head port_list;
struct net_device *dev;
+ struct work_struct change_notification_worker;
+
struct br_cpu_netstats __percpu *stats;
spinlock_t hash_lock;
struct hlist_head hash[BR_HASH_SIZE];
diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
index 57186d8..b5be3e3 100644
--- a/net/bridge/br_stp.c
+++ b/net/bridge/br_stp.c
@@ -296,6 +296,8 @@ void br_topology_change_detection(struct net_bridge *br)
{
int isroot = br_is_root_bridge(br);
+ queue_work(system_long_wq, &br->change_notification_worker);
+
if (br->stp_enabled != BR_KERNEL_STP)
return;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] Retry autoconfiguration on interface after NETDEV_CHANGE notification
From: Adam Majer @ 2011-03-06 5:20 UTC (permalink / raw)
To: netdev
Cc: Stephen Hemminger, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, bridge, linux-kernel
In-Reply-To: <20110306051833.GA3098@mira.lan.galacticasoftware.com>
A bridged interface will timeout trying to receive Router Advert as
these packets are not forwarded when bridge is UP but not in the
FORWARDING state (eg. LEARNING state). Bridge code issues
NETDEV_CHANGE when bridge's internal state is changed. It is then
possible to retry Router Solicitation.
Signed-off-by: Adam Majer <adamm@zombino.com>
---
net/ipv6/addrconf.c | 74 +++++++++++++++++++++++++++++++++-----------------
1 files changed, 49 insertions(+), 25 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index fd6782e..f8018b3 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -152,6 +152,7 @@ static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags);
static void addrconf_dad_timer(unsigned long data);
static void addrconf_dad_completed(struct inet6_ifaddr *ifp);
static void addrconf_dad_run(struct inet6_dev *idev);
+static void addrconf_rs_start(struct inet6_ifaddr *ifp);
static void addrconf_rs_timer(unsigned long data);
static void __ipv6_ifa_notify(int event, struct inet6_ifaddr *ifa);
static void ipv6_ifa_notify(int event, struct inet6_ifaddr *ifa);
@@ -2368,6 +2369,18 @@ static void addrconf_add_linklocal(struct inet6_dev *idev, struct in6_addr *addr
addrconf_prefix_route(&ifp->addr, ifp->prefix_len, idev->dev, 0, 0);
addrconf_dad_start(ifp, 0);
in6_ifa_put(ifp);
+ } else if (PTR_ERR(ifp) == -EEXIST &&
+ list_is_singular(&idev->addr_list)) {
+ /*
+ * first address must be link local, but no router - re-solicit.
+ * This code path is called when bridge exits LEARNING state
+ */
+
+ ifp = list_first_entry(&idev->addr_list,
+ struct inet6_ifaddr,
+ if_list);
+
+ addrconf_rs_start(ifp);
}
}
@@ -2532,8 +2545,11 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
}
if (idev) {
- if (idev->if_flags & IF_READY)
- /* device is already configured. */
+ if (idev->if_flags & IF_READY &&
+ idev->if_flags & IF_RA_RCVD)
+ /* device is already configured and
+ * RA was received.
+ */
break;
idev->if_flags |= IF_READY;
}
@@ -2775,6 +2791,35 @@ static int addrconf_ifdown(struct net_device *dev, int how)
return 0;
}
+static void addrconf_rs_start(struct inet6_ifaddr *ifp)
+{
+ /* If added prefix is link local and forwarding is off,
+ start sending router solicitations.
+ */
+ struct net_device *dev = ifp->idev->dev;
+
+ if ((ifp->idev->cnf.forwarding == 0 ||
+ ifp->idev->cnf.forwarding == 2) &&
+ ifp->idev->cnf.rtr_solicits > 0 &&
+ (dev->flags&IFF_LOOPBACK) == 0 &&
+ (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
+ /*
+ * If a host as already performed a random delay
+ * [...] as part of DAD [...] there is no need
+ * to delay again before sending the first RS
+ */
+ ndisc_send_rs(ifp->idev->dev, &ifp->addr,
+ &in6addr_linklocal_allrouters);
+
+ spin_lock_bh(&ifp->lock);
+ ifp->probes = 1;
+ ifp->idev->if_flags |= IF_RS_SENT;
+ addrconf_mod_timer(ifp, AC_RS,
+ ifp->idev->cnf.rtr_solicit_interval);
+ spin_unlock_bh(&ifp->lock);
+ }
+}
+
static void addrconf_rs_timer(unsigned long data)
{
struct inet6_ifaddr *ifp = (struct inet6_ifaddr *) data;
@@ -2935,36 +2980,15 @@ out:
static void addrconf_dad_completed(struct inet6_ifaddr *ifp)
{
- struct net_device *dev = ifp->idev->dev;
-
/*
* Configure the address for reception. Now it is valid.
*/
ipv6_ifa_notify(RTM_NEWADDR, ifp);
- /* If added prefix is link local and forwarding is off,
- start sending router solicitations.
- */
+ /* start sending router solicitations. */
- if ((ifp->idev->cnf.forwarding == 0 ||
- ifp->idev->cnf.forwarding == 2) &&
- ifp->idev->cnf.rtr_solicits > 0 &&
- (dev->flags&IFF_LOOPBACK) == 0 &&
- (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
- /*
- * If a host as already performed a random delay
- * [...] as part of DAD [...] there is no need
- * to delay again before sending the first RS
- */
- ndisc_send_rs(ifp->idev->dev, &ifp->addr, &in6addr_linklocal_allrouters);
-
- spin_lock_bh(&ifp->lock);
- ifp->probes = 1;
- ifp->idev->if_flags |= IF_RS_SENT;
- addrconf_mod_timer(ifp, AC_RS, ifp->idev->cnf.rtr_solicit_interval);
- spin_unlock_bh(&ifp->lock);
- }
+ addrconf_rs_start(ifp);
}
static void addrconf_dad_run(struct inet6_dev *idev)
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 1/2] Issue NETDEV_CHANGE notification when bridge changes state
From: Adam Majer @ 2011-03-06 5:31 UTC (permalink / raw)
To: netdev
Cc: Stephen Hemminger, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, bridge, linux-kernel
In-Reply-To: <20110306051833.GA3098@mira.lan.galacticasoftware.com>
Hello,
As background for these 2 patches, the current bridge code does not
play very nicely with IPv6 autoconfiguration. What happens is,
[ 35.117030] device eth0 entered promiscuous mode
[ 35.120898] br0: port 1(eth0) entering learning state
[ 35.120901] br0: port 1(eth0) entering learning state
Here bridge is setup and both interface eth0 and br0 are indicated as
up via NETDEV_UP notification. The IPv6 autoconfiguration code
configures linklocal address and start to issue RS packets. These
timeout because bridge is in learning state, not forwarding state.
[ 45.168007] br0: no IPv6 routers present
[ 45.312020] eth0: no IPv6 routers present
RS timeouts and IPv6 is abandoned at this point.
[ 50.144011] br0: port 1(eth0) entering forwarding state
Now bridge entered forwarding state. Userland sets up IPv4 via DHCP or
otherwise.
[ 50.144487] ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
With the patches, NETDEV_CHANGE is issued by the bridge once it
changes state. The autoconfiguration code then checks that no RA
packets are received and only linklocal interface is setup. It then
retries soliciting router information.
This is my first attempt at a kernel patch so please be gentle :) Part
of the autoconf patch splits out the addrconf_rs_start() code from the
addrconf_dad_completed() function.
Cheers,
Adam
--
Adam Majer
adamm@zombino.com
^ permalink raw reply
* Re: [PATCH 1/2] Issue NETDEV_CHANGE notification when bridge changes state
From: Stephen Hemminger @ 2011-03-06 6:43 UTC (permalink / raw)
To: Adam Majer
Cc: Stephen Hemminger, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, bridge, netdev
In-Reply-To: <20110306051833.GA3098@mira.lan.galacticasoftware.com>
Why not set forwarding delay to zero? I don't think you are using STP?
P.s: removing linux-kernel mailing list, since there is no point
in copying the whole world on this thread.
^ permalink raw reply
* [Patch] ariadne: fix possible null dereference
From: j223yang @ 2011-03-06 7:08 UTC (permalink / raw)
To: rdunlap; +Cc: netdev, linux-kernel
Hi Randy,
I have tested my patch, and it is ok now.
Could you please try patching again? Sorry for previous trouble.
Thank you!
Jinqiu
------------------------------------------------------
This patch fixes bugzilla #13853:
https://bugzilla.kernel.org/show_bug.cgi?id=13853
The patch removes dereference of 'dev' after testing for NULL.
Signed-off-by: Jinqiu Yang<crindy646@gmail.com>
---
ariadne.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ariadne.c b/drivers/net/ariadne.c
--- a/drivers/net/ariadne.c 2011-03-04 11:16:42.332164362 -0500
+++ b/drivers/net/ariadne.c 2011-03-05 21:11:52.949164759 -0500
@@ -420,7 +420,7 @@ static inline void ariadne_reset(struct
static irqreturn_t ariadne_interrupt(int irq, void *data)
{
struct net_device *dev = (struct net_device *)data;
- volatile struct Am79C960 *lance = (struct Am79C960*)dev->base_addr;
+ volatile struct Am79C960 *lance;
struct ariadne_private *priv;
int csr0, boguscnt;
int handled = 0;
@@ -430,6 +430,7 @@ static irqreturn_t ariadne_interrupt(int
return IRQ_NONE;
}
+ lance = (struct Am79C960 *)dev->base_addr;
lance->RAP = CSR0; /* PCnet-ISA Controller Status */
if (!(lance->RDP & INTR)) /* Check if any interrupt has been */
^ permalink raw reply
* Re: [PATCH 1/2] Issue NETDEV_CHANGE notification when bridge changes state
From: Adam Majer @ 2011-03-06 8:03 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, bridge, netdev
In-Reply-To: <1154832100.13939.1299393783798.JavaMail.root@tahiti.vyatta.com>
On Sat, Mar 05, 2011 at 10:43:03PM -0800, Stephen Hemminger wrote:
> Why not set forwarding delay to zero? I don't think you are using STP?
>
> P.s: removing linux-kernel mailing list, since there is no point
> in copying the whole world on this thread.
I just sent patches where MAINTAINERS file told me to send it. ;)
No, I'm not relying on STP. I think setting learning->forwarding delay
to 0 could cause problems with STP like loops until the loop is
detected.
There may be a better spot where to insert the notification that the
bridge is forwarding data, though I'm not exactly certain where. The
patch will cause bridge to issue NETDEV_CHANGE notification for all
topology changes. This may or may not be useful but shouldn't be
harmful (I can't imagine these occur very often?) The IPv6 autoconf
patch will only act on this if it doesn't have IPv6 address configured
manually or via autoconf.
--
Adam Majer
adamm@zombino.com
^ permalink raw reply
* Re: [PATCH 03/18] ipvs: zero percpu stats
From: Eric Dumazet @ 2011-03-06 9:06 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, netfilter-devel, netfilter, lvs-devel, Julian Anastasov,
Hans Schillstrom
In-Reply-To: <1299368760-14271-4-git-send-email-horms@verge.net.au>
Le dimanche 06 mars 2011 à 08:45 +0900, Simon Horman a écrit :
> From: Julian Anastasov <ja@ssi.bg>
>
> Zero the new percpu stats because we copy from there.
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
> net/netfilter/ipvs/ip_vs_ctl.c | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index a2a67ad..fd74527 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -715,8 +715,25 @@ static void ip_vs_trash_cleanup(struct net *net)
> static void
> ip_vs_zero_stats(struct ip_vs_stats *stats)
> {
> + struct ip_vs_cpu_stats *cpustats = stats->cpustats;
> + int i;
> +
> spin_lock_bh(&stats->lock);
>
> + for_each_possible_cpu(i) {
> + struct ip_vs_cpu_stats *u = per_cpu_ptr(cpustats, i);
> + unsigned int start;
> +
> + /* Do not pretend to be writer, it is enough to
> + * sync with writers that modify the u64 counters
> + * because under stats->lock we are the only reader.
> + */
> + do {
> + start = u64_stats_fetch_begin(&u->syncp);
> + memset(&u->ustats, 0, sizeof(u->ustats));
> + } while (u64_stats_fetch_retry(&u->syncp, start));
Sorry this makes no sense to me.
This code _is_ a writer, and hardly a hot path.
Why try to pretend its a reader and confuse people ?
Either :
- Another writer can modify the counters in same time, and we must
synchronize with them (we are a writer after all)
- Another reader can read the counters in same time, and we must let
them catch we mihjt have cleared half of their values.
- No reader or writer can access data, no synch is needed, a pure
memset() is OK.
> + }
> +
> memset(&stats->ustats, 0, sizeof(stats->ustats));
> ip_vs_zero_estimator(stats);
>
^ permalink raw reply
* [PATCH] vhost: copy_from_user -> __copy_from_user
From: Michael S. Tsirkin @ 2011-03-06 11:33 UTC (permalink / raw)
To: Michael S. Tsirkin, kvm, virtualization, netdev, linux-kernel
copy_from_user is pretty high on perf top profile,
replacing it with __copy_from_user helps.
It's also safe because we do access_ok checks during setup.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/vhost/vhost.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index ade0568..01701b8 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1153,7 +1153,7 @@ int vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
i, vq->num, head);
return -EINVAL;
}
- ret = copy_from_user(&desc, vq->desc + i, sizeof desc);
+ ret = __copy_from_user(&desc, vq->desc + i, sizeof desc);
if (unlikely(ret)) {
vq_err(vq, "Failed to get descriptor: idx %d addr %p\n",
i, vq->desc + i);
--
1.7.3.2.91.g446ac
^ permalink raw reply related
* 2.6.38-rc7-git4: Reported regressions from 2.6.37
From: Rafael J. Wysocki @ 2011-03-06 12:08 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.37,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.37, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2011-03-06 70 27 26
2011-02-21 51 18 17
2011-02-12 39 20 18
2011-02-03 19 11 7
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=30472
Subject : 2.6.38-post-rc7 with radeon kms: reproducably locks up hard when using desktop cube of kwin
Submitter : Martin Steigerwald <Martin-3kZCPVa5dk2azgQtNeiOUg@public.gmane.org>
Date : 2011-03-05 15:10:24 (2 days old)
Message-ID : <201103051510.35057.Martin-3kZCPVa5dk2azgQtNeiOUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129933425306804&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=30462
Subject : High cpu usage when someone sends many ipv6 udp packages
Submitter : Ernst Sjöstrand <ernstp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-03-05 01:10 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=30142
Subject : Kernel Oops after hibernation
Submitter : Willi Mann <foss-ml-pz1JH+IlyL4@public.gmane.org>
Date : 2011-03-01 08:12 (6 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=30072
Subject : USB-to-serial problems in 2.6.37.1+ (pl2303)
Submitter : <akwatts-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org>
Date : 2011-02-28 12:39 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=30062
Subject : Huge amounts of "HDIO_GET_IDENTITY failed for /dev/sr0" messages during boot
Submitter : Bernd Eggink <monoped-mFg29aWZVEaELgA04lAiVw@public.gmane.org>
Date : 2011-02-28 10:52 (7 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=30032
Subject : r8169: 60 seconds delay when resuming from suspend
Submitter : Guillaume Ayoub <xovni-39ZsbGIQGT5GWvitb5QawA@public.gmane.org>
Date : 2011-02-27 16:52 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29992
Subject : boot hang 2.6.37.1 regression w/ intel_idle and CONFIG_NO_HZ=n - asus p7p55d le
Submitter : De Ganseman Amaury <amaury.deganseman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-02-27 10:38 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29952
Subject : btrfs as root filesystems hangs on mount after d863b50ab01333659314c2034890cb76d9fdc3c7
Submitter : Asbjørn Sannes <ace-8p7wLbfn+Bodnm+yROfE0A@public.gmane.org>
Date : 2011-02-26 15:59 (9 days old)
First-Bad-Commit: http://git.kernel.org/linus/d863b50ab01333659314c2034890cb76d9fdc3c7
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29902
Subject : System suspend failed after 1-2 successful resumes
Submitter : Alex Terekhov <a.terekhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-02-25 22:24 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29852
Subject : 2.6.38-rc5: nfsd: page allocation failure. spinlock trylock failure on UP
Submitter : Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-02-21 20:33 (14 days old)
Message-ID : <AANLkTi=14N_c_B7mLY0H8Dt8pte6C0mjFnVuC37e44Hs-JsoAwUIsXov1KXRcyAk9cg@public.gmane.orgl.com>
References : http://marc.info/?l=linux-netdev&m=129832042402668&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29812
Subject : Brightness levels too low on Dell Inspiron 13" Intel HD 4 Series
Submitter : Niklas Schnelle <niklas-74wnUeZ+fLazQB+pC5nmwQ@public.gmane.org>
Date : 2011-02-24 10:24 (11 days old)
First-Bad-Commit: http://git.kernel.org/linus/951f3512dba5bd44cda3e5ee22b4b522e4bb09fb
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29672
Subject : [regression][ALSA][hda-conexant][2.6.38-rcX] external microphone sound too quiet
Submitter : Shawn Starr <shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org>
Date : 2011-02-19 6:02 (16 days old)
Message-ID : <474630.25335.qm-LGyaPT5kzbjzJNTqFNLFoaJ1FwRQo79cG6kzb5Gsg2M@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129809536502092&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29312
Subject : Unmounting fails even after the underlying device is long gone
Submitter : Bart Van Assche <bart.vanassche-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-02-17 19:20 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29252
Subject : IPv6 doesn't work in a kvm guest.
Submitter : Kusanagi Kouichi <slash-cQ3dDVBNB1RrxjOHzPOmfA@public.gmane.org>
Date : 2011-02-16 13:03 (19 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29022
Subject : [REGRESSION? 2.6.38-rc4] nouveau NV50/NVA8 screen freeze
Submitter : Marc Koschewski <marc-e1Wt+8K1Ta8ZEwqihLH0+Q@public.gmane.org>
Date : 2011-02-13 12:29 (22 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28882
Subject : Screen corruption and GPU hangs
Submitter : Ko Mi <chaostya.test-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org>
Date : 2011-02-11 18:17 (24 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28842
Subject : 2.6.38-rc3 regression ipv6 TFTP download with curl failing in getpeername?
Submitter : Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Date : 2011-02-08 9:41 (27 days old)
Message-ID : <m1ei7iamnn.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129715811421534&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28642
Subject : ACPI broken on DELL Latitude E6410 in 2.6.38-rc3
Submitter : Adam Kovari <kovariadam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-02-08 22:22 (27 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28562
Subject : [BUG] usb problems in .38-rc3+
Submitter : Ed Tomlinson <edt-Yad3+ZauZac@public.gmane.org>
Date : 2011-02-05 19:17 (30 days old)
Message-ID : <201102051417.58953.edt-Yad3+ZauZac@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129693391417607&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28522
Subject : Unable to mount FAT-formatted floppy on /dev/fd0, plus WARN_ON when using /dev/fd0u1440
Submitter : Alex Villacis Lasso <avillaci-x0m+Mc+nT7uljOmnV8AmnkElSqmLX1BE@public.gmane.org>
Date : 2011-02-07 17:21 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28452
Subject : 2.6.38-rc3 regression on parisc: segfaults
Submitter : Meelis Roos <mroos-Y27EyoLml9s@public.gmane.org>
Date : 2011-02-01 22:00 (34 days old)
Message-ID : <alpine.SOC.1.00.1102012342200.25944-ptEonEWSGqKptlylMvRsHA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129659763426600&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28432
Subject : khugepaged: gets stuck when writing to USB flash, 2.6.38-rc2
Submitter : Jindřich Makovička <makovick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-01-31 19:28 (35 days old)
Message-ID : <AANLkTi=uOpN0PwWdGh6iri-vJwuMS+WMPxmaZjv0-TrV-JsoAwUIsXov1KXRcyAk9cg@public.gmane.orgl.com>
References : http://marc.info/?l=linux-kernel&m=129650210516627&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28422
Subject : kref and apparmor panic in 2.6.38-rc2.
Submitter : Tao Ma <tm-d1IQDZat3X0@public.gmane.org>
Date : 2011-01-31 10:06 (35 days old)
Message-ID : <4D46899B.80302-d1IQDZat3X0@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129646840303149&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28262
Subject : Slow resume from suspend/hibernate on Dell Inspiron M301Z
Submitter : Luca Ferretti <lferrett-rDKQcyrBJuzYtjvyW6yDsg@public.gmane.org>
Date : 2011-02-05 12:37 (30 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28102
Subject : New display errors in 2.6.38-rc2-00175-g6fb1b30
Submitter : Nico Schottelius <nico-kernel-20110117-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
Date : 2011-01-28 20:29 (38 days old)
Message-ID : <20110128202905.GB3395-xuaVFQXs+5hIG4jRRZ66WA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129624657425949&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27022
Subject : [REPORT] BUG: spinlock recursion on CPU#0, init/1
Submitter : Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
Date : 2011-01-10 15:33 (56 days old)
Message-ID : <a7a9bdaa5936630925fb7ffd1a1795b1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129467294808655&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29402
Subject : kernel panics while running ffsb scalability workloads on 2.6.38-rc1 through -rc5
Submitter : Eric Whitney <eric.whitney-VXdhtT5mjnY@public.gmane.org>
Date : 2011-02-18 21:47 (17 days old)
Handled-By : Lukas Czerner <lczerner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=49642
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.37,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=27352
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: [PATCH 03/18] ipvs: zero percpu stats
From: Julian Anastasov @ 2011-03-06 12:18 UTC (permalink / raw)
To: Eric Dumazet
Cc: Simon Horman, netdev, netfilter-devel, netfilter, lvs-devel,
Hans Schillstrom
In-Reply-To: <1299402367.2758.87.camel@edumazet-laptop>
Hello,
On Sun, 6 Mar 2011, Eric Dumazet wrote:
>> Zero the new percpu stats because we copy from there.
>>
>> Signed-off-by: Julian Anastasov <ja@ssi.bg>
>> Signed-off-by: Simon Horman <horms@verge.net.au>
>> ---
>> net/netfilter/ipvs/ip_vs_ctl.c | 17 +++++++++++++++++
>> 1 files changed, 17 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
>> index a2a67ad..fd74527 100644
>> --- a/net/netfilter/ipvs/ip_vs_ctl.c
>> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
>> @@ -715,8 +715,25 @@ static void ip_vs_trash_cleanup(struct net *net)
>> static void
>> ip_vs_zero_stats(struct ip_vs_stats *stats)
>> {
>> + struct ip_vs_cpu_stats *cpustats = stats->cpustats;
>> + int i;
>> +
>> spin_lock_bh(&stats->lock);
>>
>> + for_each_possible_cpu(i) {
>> + struct ip_vs_cpu_stats *u = per_cpu_ptr(cpustats, i);
>> + unsigned int start;
>> +
>> + /* Do not pretend to be writer, it is enough to
>> + * sync with writers that modify the u64 counters
>> + * because under stats->lock we are the only reader.
>> + */
>> + do {
>> + start = u64_stats_fetch_begin(&u->syncp);
>> + memset(&u->ustats, 0, sizeof(u->ustats));
>> + } while (u64_stats_fetch_retry(&u->syncp, start));
>
>
> Sorry this makes no sense to me.
Hm, yes, the comment is a little bit misleading.
I fixed it below...
> This code _is_ a writer, and hardly a hot path.
Yes, the picture is as follows:
- in 2.6.38-rc we remove the global spin lock (stats->lock)
from packet processing which is a hot path, adding percpu
counters instead
- we need protection for percpu counters and for the sum
- the chain is: interrupts increment percpu counters, the
estimation timer reads them and creates sum every 2 seconds,
then user context can read the sum or even to show the percpu
counters, not to forget the zeroing of sum and counters
The players in detail:
- packet processing:
- softirq context, hot path
- increments counters by using u64_stats_update_begin and
u64_stats_update_end, does not wait readers or zeroing
- sum not touched, stats->lock usage removed in 2.6.38-rc
- 2-second estimation timer:
- funcs: estimation_timer()
- timer context, softirq
- reads percpu counters with u64_stats_fetch_begin and
u64_stats_fetch_retry to sync with counter incrementing
- uses spin_lock (stats->lock) to protect the written sum
which is later read by user context: provides
at least u64 atomicity but additionally the relation
between packets and bytes
- sum readers:
- funcs: ip_vs_stats_show(), ip_vs_stats_percpu_show(),
ip_vs_copy_stats(), ip_vs_genl_fill_stats()
- user context, not a hot path
- uses spin_lock_bh (stats->lock) for atomic reading of
the sum created by estimation_timer()
- show percpu counters:
- funcs: ip_vs_stats_percpu_show()
- user context, not a hot path
- uses u64_stats_fetch_begin_bh and u64_stats_fetch_retry_bh
to synchronize with counter incrementing
- still missing: should use spin_lock_bh (stats->lock)
to synchronize with ip_vs_zero_stats() that modifies
percpu counters.
- zero stats and percpu counters
- funcs: ip_vs_zero_stats()
- user context, not a hot path
- uses spin_lock_bh (stats->lock) while modifying
sum but also while zeroing percpu counters because
we are a hidden writer which does not allow other
percpu counter readers at the same time but we are
still synchronized with percpu counter incrementing
without delaying it
To summarize, I see 2 solutions, in order of preference:
1. all players except packet processing should use stats->lock
when reading/writing sum or when reading/zeroing percpu
counters. Use u64_stats to avoid delays in incrementing.
2. Use seqlock instead of u64_stats if we want to treat the
percpu counters zeroing as writer. This returns us before
2.6.38-rc where we used global stats->lock even for counter
incrementing. Except that now we can use percpu seqlock
just to register the zeroing as writer.
> Why try to pretend its a reader and confuse people ?
>
> Either :
>
> - Another writer can modify the counters in same time, and we must
> synchronize with them (we are a writer after all)
Global mutex allows only one zeroing at a time.
But zeroing runs in parallel with incrementing, so we
have 2 writers for a per-CPU state. This sounds like
above solution 2 with percpu seqlock? But it adds extra
spin_lock in hot path, even if it is percpu. It only
saves the spin_lock_bh while reading percpu counters in
ip_vs_stats_percpu_show(). That is why a prefer solution 1.
> - Another reader can read the counters in same time, and we must let
> them catch we mihjt have cleared half of their values.
Yes, zeroing can run in parallel with /proc reading,
that is why I now try to serialize all readers with the
stats spin lock to guarantee u64 atomicity.
> - No reader or writer can access data, no synch is needed, a pure
> memset() is OK.
Packet processing can damage the counters while we
do memset, so we need at least u64_stats_fetch_* to sync
with incrementing.
>> + }
>> +
>> memset(&stats->ustats, 0, sizeof(stats->ustats));
>> ip_vs_zero_estimator(stats);
So, here is solution 1 fully implemented:
==============
Zero the new percpu stats because we copy from there.
Use the stats spin lock to synchronize the percpu zeroing with
the percpu reading, both in user context and not in a hot path.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
diff -urp lvs-test-2.6-8a80c79/linux/net/netfilter/ipvs/ip_vs_ctl.c linux/net/netfilter/ipvs/ip_vs_ctl.c
--- lvs-test-2.6-8a80c79/linux/net/netfilter/ipvs/ip_vs_ctl.c 2011-03-06 13:39:59.000000000 +0200
+++ linux/net/netfilter/ipvs/ip_vs_ctl.c 2011-03-06 13:44:56.108275455 +0200
@@ -713,8 +713,25 @@ static void ip_vs_trash_cleanup(struct n
static void
ip_vs_zero_stats(struct ip_vs_stats *stats)
{
+ struct ip_vs_cpu_stats *cpustats = stats->cpustats;
+ int i;
+
spin_lock_bh(&stats->lock);
+ for_each_possible_cpu(i) {
+ struct ip_vs_cpu_stats *u = per_cpu_ptr(cpustats, i);
+ unsigned int start;
+
+ /* Do not pretend to be writer, it is enough to
+ * sync with writers that modify the u64 counters
+ * because under stats->lock there are no other readers
+ */
+ do {
+ start = u64_stats_fetch_begin(&u->syncp);
+ memset(&u->ustats, 0, sizeof(u->ustats));
+ } while (u64_stats_fetch_retry(&u->syncp, start));
+ }
+
memset(&stats->ustats, 0, sizeof(stats->ustats));
ip_vs_zero_estimator(stats);
@@ -2015,16 +2032,19 @@ static int ip_vs_stats_percpu_show(struc
seq_printf(seq,
"CPU Conns Packets Packets Bytes Bytes\n");
+ /* Use spin lock early to synchronize with percpu zeroing */
+ spin_lock_bh(&tot_stats->lock);
+
for_each_possible_cpu(i) {
struct ip_vs_cpu_stats *u = per_cpu_ptr(cpustats, i);
unsigned int start;
__u64 inbytes, outbytes;
do {
- start = u64_stats_fetch_begin_bh(&u->syncp);
+ start = u64_stats_fetch_begin(&u->syncp);
inbytes = u->ustats.inbytes;
outbytes = u->ustats.outbytes;
- } while (u64_stats_fetch_retry_bh(&u->syncp, start));
+ } while (u64_stats_fetch_retry(&u->syncp, start));
seq_printf(seq, "%3X %8X %8X %8X %16LX %16LX\n",
i, u->ustats.conns, u->ustats.inpkts,
@@ -2032,7 +2052,6 @@ static int ip_vs_stats_percpu_show(struc
(__u64)outbytes);
}
- spin_lock_bh(&tot_stats->lock);
seq_printf(seq, " ~ %8X %8X %8X %16LX %16LX\n\n",
tot_stats->ustats.conns, tot_stats->ustats.inpkts,
tot_stats->ustats.outpkts,
^ permalink raw reply
* modprobe gets stuck on a mutex wile trying to load the e1000e driver
From: Edy H. @ 2011-03-06 12:23 UTC (permalink / raw)
To: e1000-devel, netdev, linux-net
[-- Attachment #1.1: Type: text/plain, Size: 7830 bytes --]
Hello,
I have an Intel® Server Board S5500BC which started to cause problems during
boot, mainly with the e1000e driver, raising the server without any NIC/s. A
reboot ususally recovers the NIC/s.
The following trace is seen from the unit boot, showing an inconsistent
problem while trying to load the e1000e driver.
Looking at the sources, it looks like it is stuck in a critical section. But
I frankly do not understand how it is possible, as there is no real reason
for it to hang on the mutex lock.
At the moment, except memory curroption/leak I cannot think of anything
else... I see it on several machines, so I assume it is not a specific HW
problem.
I will apriciate if someone could point me into some direction.
Note, the pasted message below repeats in a loop, always hangling on the
same lock. In addition, these units also hang from time to time on initramfs
shell, with an avarage of 3 times less frequent than the NIC issue.
I'm using the following Kernel version:
Linux version 2.6.32-29-generic-pae (buildd@roseapple) (gcc version 4.4.3
(Ubuntu 4.4.3-4ubuntu5) ) #58-Ubuntu SMP Fri Feb 11 19:15:25 UTC 2011
(Ubuntu 2.6.32-29.58-generic-pae 2.6.32.28+drm33.13)
Thanks,
Edy.
This is the relevant trace from the dmesg output:
[ 5.732070] lp: driver loaded but no devices found
[ 6.002709] Console: switching to colour frame buffer device 80x30
[ 6.023688] type=1505 audit(1299198224.576:5): operation="profile_load"
pid=820 name="/usr/sbin/tcpdump"
[ 6.023858] type=1505 audit(1299198224.576:6):
operation="profile_replace" pid=819 name="/sbin/dhclient3"
[ 6.024301] type=1505 audit(1299198224.576:7):
operation="profile_replace" pid=819
name="/usr/lib/NetworkManager/nm-dhcp-client.action"
[ 6.024550] type=1505 audit(1299198224.576:8):
operation="profile_replace" pid=819
name="/usr/lib/connman/scripts/dhclient-script"
[ 6.134782] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 6.177099] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 6.177269] CONFIG_NF_CT_ACCT is deprecated and will be removed soon.
Please use
[ 6.177271] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack
module option or
[ 6.177273] sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
[ 240.190031] INFO: task modprobe:178 blocked for more than 120 seconds.
[ 240.190534] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[ 240.191160] modprobe D 00183416 0 178 1 0x00000000
[ 240.191169] f6e8fd44 00000086 f829b248 00183416 00000000 c088f4c0
f6f85be4 c088f4c0
[ 240.191186] 6c1f8881 00000000 c088f4c0 c088f4c0 f6f85be4 c088f4c0
c088f4c0 f6e3ea00
[ 240.191202] 6a3827bd 00000000 f6f85940 f829b238 f829b23c ffffffff
f6e8fd70 c05b3bb6
[ 240.191216] Call Trace:
[ 240.191231] [<c05b3bb6>] __mutex_lock_slowpath+0xd6/0x140
[ 240.191239] [<c05b3ac5>] mutex_lock+0x25/0x40
[ 240.191255] [<f8285be1>] e1000_acquire_swflag_ich8lan+0x21/0xa0 [e1000e]
[ 240.191270] [<f8286aea>] e1000_reset_hw_ich8lan+0x7a/0x250 [e1000e]
[ 240.191287] [<f82940bd>] e1000e_reset+0xfd/0x330 [e1000e]
[ 240.191302] [<f82984e8>] e1000_probe+0x7b7/0xa09 [e1000e]
[ 240.191309] [<c0227745>] ? iput+0x25/0x60
[ 240.191316] [<c026af3b>] ? sysfs_addrm_finish+0x3b/0xf0
[ 240.191325] [<c0370043>] local_pci_probe+0x13/0x20
[ 240.191331] [<c0370e48>] pci_device_probe+0x68/0x90
[ 240.191339] [<c03fceed>] really_probe+0x4d/0x140
[ 240.191347] [<c040380e>] ? pm_runtime_barrier+0x4e/0xc0
[ 240.191354] [<c03fd01c>] driver_probe_device+0x3c/0x60
[ 240.191361] [<c03fd0c1>] __driver_attach+0x81/0x90
[ 240.191368] [<c03fc503>] bus_for_each_dev+0x53/0x80
[ 240.191375] [<c03fcdbe>] driver_attach+0x1e/0x20
[ 240.191382] [<c03fd040>] ? __driver_attach+0x0/0x90
[ 240.191389] [<c03fc785>] bus_add_driver+0xd5/0x280
[ 240.191396] [<c0370d80>] ? pci_device_remove+0x0/0x40
[ 240.191403] [<c03fd3ba>] driver_register+0x6a/0x130
[ 240.191410] [<c0371085>] __pci_register_driver+0x45/0xb0
[ 240.191423] [<f82a304b>] e1000_init_module+0x4b/0x67 [e1000e]
[ 240.191430] [<c0103041>] do_one_initcall+0x31/0x190
[ 240.191443] [<f82a3000>] ? e1000_init_module+0x0/0x67 [e1000e]
[ 240.191452] [<c018acb0>] sys_init_module+0xb0/0x210
[ 240.191458] [<c01097ac>] syscall_call+0x7/0xb
lshw network output:
*-network
description: Ethernet interface
product: 82574L Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:01:00.0
logical name: eth1
version: 00
serial: 00:1b:21:57:0a:54
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list rom ethernet
physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=off broadcast=yes driver=e1000e
driverversion=1.0.2-k2 duplex=full firmware=1.8-0 ip=127.0.1.1 latency=0
link=yes multicast=yes port=twisted pair speed=100MB/s
resources: irq:16 memory:b1a80000-b1a9ffff memory:b1a00000-b1a7ffff
ioport:2000(size=32) memory:b1aa0000-b1aa3fff
memory:b1c00000-b1c3ffff(prefetchable)
*-network
description: Ethernet interface
product: 82578DM Gigabit Network Connection
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0
logical name: eth0
version: 05
serial: 00:15:17:c8:0a:3d
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp 10bt
10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=off broadcast=yes driver=e1000e
driverversion=1.0.2-k2 duplex=full firmware=0.9-2 ip=127.0.0.1 latency=0
link=yes multicast=yes port=twisted pair speed=100MB/s
resources: irq:34 memory:b1b00000-b1b1ffff memory:b1b24000-b1b24fff
ioport:3020(size=32)
*-network
description: Ethernet interface
product: 82574L Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:03:00.0
logical name: eth2
version: 00
serial: 00:15:17:c8:0a:3c
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list ethernet
physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e
driverversion=1.0.2-k2 duplex=full firmware=1.9-0 ip=172.17.6.2 latency=0
link=yes multicast=yes port=twisted pair speed=100MB/s
resources: irq:16 memory:b1900000-b191ffff ioport:1000(size=32)
memory:b1920000-b1923fff
*-network:0 DISABLED
description: Ethernet interface
physical id: 1
logical name: eth1.24
serial: 00:1b:21:57:0a:54
size: 100MB/s
capacity: 1GB/s
capabilities: ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd
1000bt-fd autonegotiation
configuration: autonegotiation=off broadcast=yes driver=802.1Q VLAN
Support driverversion=1.8 duplex=full firmware=N/A link=yes multicast=yes
port=twisted pair speed=100MB/s
*-network:1
description: Ethernet interface
physical id: 2
logical name: vlan24
serial: 00:15:17:c8:0a:3d
size: 100MB/s
capacity: 1GB/s
capabilities: ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd
1000bt-fd autonegotiation
configuration: autonegotiation=off broadcast=yes driver=802.1Q VLAN
Support driverversion=1.8 duplex=full firmware=N/A ip=172.24.4.182 link=yes
multicast=yes port=twisted pair speed=100MB/s
[-- Attachment #2: Type: text/plain, Size: 309 bytes --]
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
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-2.6 6/8] bonding: move processing of recv handlers into handle_frame()
From: Nicolas de Pesloüan @ 2011-03-06 12:24 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <4D724DB4.9020207@gmail.com>
Le 05/03/2011 15:50, Nicolas de Pesloüan a écrit :
> Le 05/03/2011 15:43, Jiri Pirko a écrit :
>> Sat, Mar 05, 2011 at 03:33:30PM CET, nicolas.2p.debian@gmail.com wrote:
>>> Le 05/03/2011 11:29, Jiri Pirko a écrit :
>>>> Since now when bonding uses rx_handler, all traffic going into bond
>>>> device goes thru bond_handle_frame. So there's no need to go back into
>>>> bonding code later via ptype handlers. This patch converts
>>>> original ptype handlers into "bonding receive probes". These functions
>>>> are called from bond_handle_frame and they are registered per-mode.
>>>
>>> Does this still support having the arp_ip_target on a vlan?
>>>
>>> (eth0 -> bond0 -> bond0.100, with arp_ip_target only reachable
>>> through bond0.100).
>>
>> This case is still covered with vlan_on_bond_hook
>> eth0->
>> bond_handle_frame
>> bond0->
>> vlan_hwaccel_do_receive
>> bond0.5->
>> vlan_on_bond_hook -> reinject into bond0
>> -> bond_handle_frame (here it is processed)
>
> Sound good to me.
>
> Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
After another review, I think it won't work.
vlan_on_bond() will reinject into bond0, but bond_handle_frame() is registered as the rx_handler for
the slaves (eth0 in the above setup), not as the rx_handler for the master (bond0 in the above
setup). So, bond_handlee_frame() will never see the untagged ARP request/reply and bonding ARP
monitoring will fail.
That being said, the current vlan_on_bond_hook() hack already suffer other troubles and for example
won't support the following setup:
eth0 -> bond0 -> br0 -> br0.100.
I think we need to fix this stacking issue in a more general way.
Nicolas.
^ permalink raw reply
* 2.6.38-rc7-git4: Reported regressions 2.6.36 -> 2.6.37
From: Rafael J. Wysocki @ 2011-03-06 12:34 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, DRI, Florian Mickler, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
This message contains a list of some post-2.6.36 regressions introduced before
2.6.37, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.36 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2011-03-06 132 28 23
2011-02-21 128 35 26
2011-02-13 126 36 30
2011-02-03 118 36 31
2010-12-30 85 32 26
2010-12-19 73 28 24
2010-12-03 55 25 19
2010-11-19 39 29 25
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28812
Subject : DVI attached monitor is turned off while booting linux 2.6.37 and higher
Submitter : Markus Heinz <markus.heinz@uni-dortmund.de>
Date : 2011-02-10 19:33 (25 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28772
Subject : oops in nfs_revalidate_mapping
Submitter : Daniel Poelzleithner <bugzilla.kernel.org@poelzi.org>
Date : 2011-02-10 13:59 (25 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28662
Subject : i915 in kernel 2.6.38-rc4, high number of wakeups
Submitter : Kan-Ru Chen <kanru@kanru.info>
Date : 2011-02-09 07:06 (26 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28622
Subject : radeon video lockup
Submitter : Daniel Poelzleithner <bugzilla.kernel.org@poelzi.org>
Date : 2011-02-08 17:48 (27 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28612
Subject : regular soft lockup
Submitter : Alexandre Demers <alexandre.f.demers@gmail.com>
Date : 2011-02-08 16:39 (27 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28582
Subject : whole system hang when start X
Submitter : Gu Rui <chaos.proton@gmail.com>
Date : 2011-02-08 08:33 (27 days old)
First-Bad-Commit: http://git.kernel.org/linus/d5bb081b027b520f9e59b4fb8faea83a136ec15e
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28332
Subject : [RV620] Can not re-enable LVDS after using HDMI only
Submitter : Rafał Miłecki <zajec5@gmail.com>
Date : 2011-02-05 22:42 (30 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27892
Subject : SNB: GPU hang with Slip xscreensaver
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2011-01-31 12:06 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27842
Subject : [regression?] hang with 2.6.37 on a BTRFS test machine
Submitter : Martin Steigerwald <Martin@lichtvoll.de>
Date : 2011-01-23 12:06 (43 days old)
Message-ID : <<201101231306.23069.Martin@lichtvoll.de>>
References : http://marc.info/?l=linux-kernel&m=129578445613283&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27642
Subject : 2.6.37 says WARNING: at arch/x86/kernel/apic/apic.c:1287 setup_local_APIC+0x18f/0x263()
Submitter : Rob Landley <rlandley@parallels.com>
Date : 2011-01-18 13:11 (48 days old)
Message-ID : <4D359188.3040408@parallels.com>
References : http://marc.info/?l=linux-kernel&m=129535632319892&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27152
Subject : VGA output broken at cold boot
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2011-01-20 13:26 (46 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27132
Subject : flush-btrfs gets into an infinite loop
Submitter : Artem Anisimov <aanisimov@inbox.ru>
Date : 2011-01-20 11:51 (46 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26802
Subject : b43: Suspend failed
Submitter : Patrick Matthäi <patrick@linux-dev.org>
Date : 2011-01-15 18:56 (51 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26612
Subject : BUG in fs/inode.c:429
Submitter : Florian Kriener <florian@kriener.org>
Date : 2011-01-06 16:35 (60 days old)
Message-ID : <201101061735.40060.florian@kriener.org>
References : http://marc.info/?l=linux-kernel&m=129433235223735&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26582
Subject : NULL pointer dereference on pipe creation
Submitter : Ferenc Wágner <wferi@niif.hu>
Date : 2011-01-12 13:30 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26112
Subject : [LogFS] [2.6.37-rc8+] Kernel BUG at logfs/readwrite.c:297!
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2011-01-02 21:22 (64 days old)
Message-ID : <AANLkTinpoM8FuG8UkF88xs_V37dz_wgE8t-s0JPzaS-w@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129400335910652&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26102
Subject : [2.6.37-rc8] BUG kmalloc-256: Poison overwritten.
Submitter : Pawel Sikora <pluto@agmk.net>
Date : 2010-12-30 15:08 (67 days old)
Message-ID : <201012301608.40859.pluto@agmk.net>
References : http://marc.info/?l=linux-kernel&m=129372388925679&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26042
Subject : BUG: NULL pointer dereference at shrink_dcache_parent
Submitter : Ferenc Wágner <wferi@niif.hu>
Date : 2011-01-03 10:49 (63 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25832
Subject : kernel crashes upon resume if usb devices are removed when suspended
Submitter : rocko <rockorequin@hotmail.com>
Date : 2010-12-29 11:47 (68 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25732
Subject : i915 turns picture green when display switched off-on
Submitter : Tõnu Raitviir <jussuf@linux.ee>
Date : 2010-12-27 22:14 (70 days old)
First-Bad-Commit: http://git.kernel.org/linus/3c17fe4b8f40a112a85758a9ab2aebf772bdd647
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24822
Subject : Embedded DisplayPort is detected wrongly on HP ProBook 5320m
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2010-12-13 11:09 (84 days old)
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22942
Subject : [2.6.37-rc1, OOM] virtblk: OOM in do_virtblk_request()
Submitter : Dave Chinner <david@fromorbit.com>
Date : 2010-11-05 1:30 (122 days old)
Message-ID : <20101105013003.GE13830@dastard>
References : http://marc.info/?l=linux-kernel&m=128892062917641&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22642
Subject : 2.6.37-rc1: Disk takes 10 seconds to resume - MacBook2,1
Submitter : Tobias <devnull@plzk.org>
Date : 2010-11-10 19:33 (117 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=30322
Subject : BUG in xs_tcp_setup_socket
Submitter : Ben Hutchings <bhutchings@solarflare.com>
Date : 2011-03-01 20:34 (6 days old)
Patch : http://article.gmane.org/gmane.linux.nfs/38949
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29722
Subject : kworker consumes ~100% CPU on HP Elitebook 8540w after resume
Submitter : Ortwin Glück <odi@odi.ch>
Date : 2011-02-23 11:49 (12 days old)
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch : https://patchwork.kernel.org/patch/604371/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27202
Subject : Remote control of saa7134-based tv card "ASUSTeK P7131 Hybrid" stopped working in 2.6.37
Submitter : <acaizzo@gmail.com>
Date : 2011-01-20 17:23 (46 days old)
First-Bad-Commit: http://git.kernel.org/linus/4651918a4afdd49bdea21d2f919b189ef17a6399
Handled-By : Mauro Carvalho Chehab <mchehab@redhat.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=44532
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25922
Subject : IdeaPad Y530 brightness keys not functioning
Submitter : Tomasz <tm.temp@gmx.com>
Date : 2010-12-30 12:48 (67 days old)
Handled-By : Ike Panhc <ikepanhc@gmail.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=48702
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24982
Subject : Inconsistent DPMS handling with 2.6.37 DRM
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2010-12-16 16:32 (81 days old)
Handled-By : Takashi Iwai <tiwai@suse.de>
Keith Packard <keithp@keithp.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=40392
https://patchwork.kernel.org/patch/530921/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.36 and 2.6.37, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=21782
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* modprobe gets stuck on a e1000e driver mutex wile trying to load the it
From: Edy H. @ 2011-03-06 12:34 UTC (permalink / raw)
To: e1000-devel, linux-net, netdev
Hello,
I have an Intel® Server Board S5500BC which started to cause problems
during boot, mainly with the e1000e driver, raising the server without
any NIC/s. A reboot ususally recovers the NIC/s.
The following trace is seen from the unit boot, showing an
inconsistent problem while trying to load the e1000e driver.
Looking at the sources, it looks like it is stuck in a critical
section. But I frankly do not understand how it is possible, as there
is no real reason for it to hang on the mutex lock.
At the moment, except memory curroption/leak I cannot think of
anything else... I see it on several machines, so I assume it is not a
specific HW problem.
I will apriciate if someone could point me into some direction.
Note, the pasted message below repeats in a loop, always hangling on
the same lock. In addition, these units also hang from time to time on
initramfs shell, with an avarage of 3 times less frequent than the NIC
issue.
I'm using the following Kernel version:
Linux version 2.6.32-29-generic-pae (buildd@roseapple) (gcc version
4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #58-Ubuntu SMP Fri Feb 11 19:15:25 UTC
2011 (Ubuntu 2.6.32-29.58-generic-pae 2.6.32.28+drm33.13)
Thanks,
Edy.
This is the relevant trace from the dmesg output:
[ 5.732070] lp: driver loaded but no devices found
[ 6.002709] Console: switching to colour frame buffer device 80x30
[ 6.023688] type=1505 audit(1299198224.576:5):
operation="profile_load" pid=820 name="/usr/sbin/tcpdump"
[ 6.023858] type=1505 audit(1299198224.576:6):
operation="profile_replace" pid=819 name="/sbin/dhclient3"
[ 6.024301] type=1505 audit(1299198224.576:7):
operation="profile_replace" pid=819
name="/usr/lib/NetworkManager/nm-dhcp-client.action"
[ 6.024550] type=1505 audit(1299198224.576:8):
operation="profile_replace" pid=819
name="/usr/lib/connman/scripts/dhclient-script"
[ 6.134782] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 6.177099] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 6.177269] CONFIG_NF_CT_ACCT is deprecated and will be removed
soon. Please use
[ 6.177271] nf_conntrack.acct=1 kernel parameter, acct=1
nf_conntrack module option or
[ 6.177273] sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
[ 240.190031] INFO: task modprobe:178 blocked for more than 120 seconds.
[ 240.190534] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 240.191160] modprobe D 00183416 0 178 1 0x00000000
[ 240.191169] f6e8fd44 00000086 f829b248 00183416 00000000 c088f4c0
f6f85be4 c088f4c0
[ 240.191186] 6c1f8881 00000000 c088f4c0 c088f4c0 f6f85be4 c088f4c0
c088f4c0 f6e3ea00
[ 240.191202] 6a3827bd 00000000 f6f85940 f829b238 f829b23c ffffffff
f6e8fd70 c05b3bb6
[ 240.191216] Call Trace:
[ 240.191231] [<c05b3bb6>] __mutex_lock_slowpath+0xd6/0x140
[ 240.191239] [<c05b3ac5>] mutex_lock+0x25/0x40
[ 240.191255] [<f8285be1>] e1000_acquire_swflag_ich8lan+0x21/0xa0 [e1000e]
[ 240.191270] [<f8286aea>] e1000_reset_hw_ich8lan+0x7a/0x250 [e1000e]
[ 240.191287] [<f82940bd>] e1000e_reset+0xfd/0x330 [e1000e]
[ 240.191302] [<f82984e8>] e1000_probe+0x7b7/0xa09 [e1000e]
[ 240.191309] [<c0227745>] ? iput+0x25/0x60
[ 240.191316] [<c026af3b>] ? sysfs_addrm_finish+0x3b/0xf0
[ 240.191325] [<c0370043>] local_pci_probe+0x13/0x20
[ 240.191331] [<c0370e48>] pci_device_probe+0x68/0x90
[ 240.191339] [<c03fceed>] really_probe+0x4d/0x140
[ 240.191347] [<c040380e>] ? pm_runtime_barrier+0x4e/0xc0
[ 240.191354] [<c03fd01c>] driver_probe_device+0x3c/0x60
[ 240.191361] [<c03fd0c1>] __driver_attach+0x81/0x90
[ 240.191368] [<c03fc503>] bus_for_each_dev+0x53/0x80
[ 240.191375] [<c03fcdbe>] driver_attach+0x1e/0x20
[ 240.191382] [<c03fd040>] ? __driver_attach+0x0/0x90
[ 240.191389] [<c03fc785>] bus_add_driver+0xd5/0x280
[ 240.191396] [<c0370d80>] ? pci_device_remove+0x0/0x40
[ 240.191403] [<c03fd3ba>] driver_register+0x6a/0x130
[ 240.191410] [<c0371085>] __pci_register_driver+0x45/0xb0
[ 240.191423] [<f82a304b>] e1000_init_module+0x4b/0x67 [e1000e]
[ 240.191430] [<c0103041>] do_one_initcall+0x31/0x190
[ 240.191443] [<f82a3000>] ? e1000_init_module+0x0/0x67 [e1000e]
[ 240.191452] [<c018acb0>] sys_init_module+0xb0/0x210
[ 240.191458] [<c01097ac>] syscall_call+0x7/0xb
lshw network output:
*-network
description: Ethernet interface
product: 82574L Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:01:00.0
logical name: eth1
version: 00
serial: 00:1b:21:57:0a:54
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list rom
ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd
autonegotiation
configuration: autonegotiation=off broadcast=yes driver=e1000e
driverversion=1.0.2-k2 duplex=full firmware=1.8-0 ip=127.0.1.1
latency=0 link=yes multicast=yes port=twisted pair speed=100MB/s
resources: irq:16 memory:b1a80000-b1a9ffff
memory:b1a00000-b1a7ffff ioport:2000(size=32) memory:b1aa0000-b1aa3fff
memory:b1c00000-b1c3ffff(prefetchable)
*-network
description: Ethernet interface
product: 82578DM Gigabit Network Connection
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0
logical name: eth0
version: 05
serial: 00:15:17:c8:0a:3d
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp
10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=off broadcast=yes driver=e1000e
driverversion=1.0.2-k2 duplex=full firmware=0.9-2 ip=127.0.0.1
latency=0 link=yes multicast=yes port=twisted pair speed=100MB/s
resources: irq:34 memory:b1b00000-b1b1ffff
memory:b1b24000-b1b24fff ioport:3020(size=32)
*-network
description: Ethernet interface
product: 82574L Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:03:00.0
logical name: eth2
version: 00
serial: 00:15:17:c8:0a:3c
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list
ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd
autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e
driverversion=1.0.2-k2 duplex=full firmware=1.9-0 ip=172.17.6.2
latency=0 link=yes multicast=yes port=twisted pair speed=100MB/s
resources: irq:16 memory:b1900000-b191ffff ioport:1000(size=32)
memory:b1920000-b1923fff
*-network:0 DISABLED
description: Ethernet interface
physical id: 1
logical name: eth1.24
serial: 00:1b:21:57:0a:54
size: 100MB/s
capacity: 1GB/s
capabilities: ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd
1000bt-fd autonegotiation
configuration: autonegotiation=off broadcast=yes driver=802.1Q
VLAN Support driverversion=1.8 duplex=full firmware=N/A link=yes
multicast=yes port=twisted pair speed=100MB/s
*-network:1
description: Ethernet interface
physical id: 2
logical name: vlan24
serial: 00:15:17:c8:0a:3d
size: 100MB/s
capacity: 1GB/s
capabilities: ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd
1000bt-fd autonegotiation
configuration: autonegotiation=off broadcast=yes driver=802.1Q
VLAN Support driverversion=1.8 duplex=full firmware=N/A
ip=172.24.4.182 link=yes multicast=yes port=twisted pair speed=100MB/s
^ permalink raw reply
* Re: Possible regression in __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6
From: Nicolas de Pesloüan @ 2011-03-06 13:08 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev@vger.kernel.org, David Miller, Stephen Hemminger,
Jay Vosburgh, Patrick Mc Hardy, Eric Dumazet, Andy Gospodarek
In-Reply-To: <20110305220938.GK8573@psychotron.redhat.com>
Le 05/03/2011 23:09, Jiri Pirko a écrit :
> Sat, Mar 05, 2011 at 10:30:33PM CET, nicolas.2p.debian@gmail.com wrote:
>> Hi,
>>
>> Comparing __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6,
>> I noticed an important difference: The ptype_base loop used to
>> deliver to orig_dev and this is not true anymore.
>
> I believe this is adressed by submitted patch " net: allow handlers to
> be processed for orig_dev"
I wonder whether we should address it that way (which is the former way to address it).
There are still a difference between ptype_all and ptype_base delivery:
- For ptype_all, we deliver to every device crossed while walking the rx_handler path (inside the
another_round loop). (And there is no way to force exact match delivery).
- For ptype_base, we deliver to the lowest device (orig_dev) and to the highest (skb->dev) and we
can ask for exact match delivery.
This sounds very inconsistent. The only difference between ptype_all and ptype_base is the fact that
ptype->type is NULL (wildcard) for the first and not NULL (a particular protocol) for the second.
I think we should:
1/ deliver to both ptype_all and ptype_base while walking the rx_handler path, but only exact match
(ptype->dev == skb->dev).
2/ deliver to both ptype_all and ptype_base at the end of __netif_receive_skb(), but only wildcard
match (ptype->dev == NULL), skipping this part if the last rx_handler returned RX_HANDLER_EXACT.
Nicolas.
>> Imagine the following simple setup:
>>
>> eth0 -> bond0
>>
>> - A packet handler registered on eth0, with ptype->type == NULL will
>> receive the packet, because it will be delivered in the ptype_all
>> loop, which is inside the another_round loop.
>> - The same packet handler, registered on eth0, but with ptype->type
>> != NULL won't receive the packet, because the ptype_base loop doesn't
>> deliver to orig_dev anymore.
>>
>> I think this can lead to a regression for user space: an application
>> using af_packet to listen to eth0 will receive the packet flow if the
>> registered protocol is NULL, but won't receive anything if the
>> registered protocol is not NULL.
>>
>> Can someone confirm?
>>
>> Nicolas.
>
^ permalink raw reply
* [PATCH net-next-2.6] net: harmonize the call to ptype_all and ptype_base handlers.
From: Nicolas de Pesloüan @ 2011-03-06 13:25 UTC (permalink / raw)
To: netdev
Cc: davem, shemminger, eric.dumazet, kaber, fubar, andy,
Nicolas de Pesloüan
In-Reply-To: <4D738751.6050209@gmail.com>
Until now, ptype_all and ptype_base delivery in __netif_receive_skb() is
inconsistent.
- For ptype_all, we deliver to every device crossed while walking the
rx_handler path (inside the another_round loop), and there is no way to stop
wildcard delivery (no exact match logic).
- For ptype_base, we deliver to the lowest device (orig_dev) and to the highest
(skb->dev) and we can ask for exact match delivery.
This patch try and fix this, by:
1/ Doing exact match delivery for both ptype_all and ptype_base, while walking
the rx_handler path.
2/ Doing wildcard match delivery at the end of __netif_receive_skb(), if not
asked to do exact match delivery only.
Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
---
This apply on top of the last batch of patch from Jiri Pirko.
---
net/core/dev.c | 32 ++++++++++++++++++++++++--------
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index c71bd18..a368223 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3117,8 +3117,6 @@ static int __netif_receive_skb(struct sk_buff *skb)
{
struct packet_type *ptype, *pt_prev;
rx_handler_func_t *rx_handler;
- struct net_device *orig_dev;
- struct net_device *null_or_dev;
bool deliver_exact = false;
int ret = NET_RX_DROP;
__be16 type;
@@ -3134,7 +3132,6 @@ static int __netif_receive_skb(struct sk_buff *skb)
if (!skb->skb_iif)
skb->skb_iif = skb->dev->ifindex;
- orig_dev = skb->dev;
skb_reset_network_header(skb);
skb_reset_transport_header(skb);
@@ -3156,7 +3153,17 @@ another_round:
#endif
list_for_each_entry_rcu(ptype, &ptype_all, list) {
- if (!ptype->dev || ptype->dev == skb->dev) {
+ if (ptype->dev == skb->dev) {
+ if (pt_prev)
+ ret = deliver_skb(skb, pt_prev);
+ pt_prev = ptype;
+ }
+ }
+
+ type = skb->protocol;
+ list_for_each_entry_rcu(ptype,
+ &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
+ if (ptype->type == type && ptype->dev == skb->dev) {
if (pt_prev)
ret = deliver_skb(skb, pt_prev);
pt_prev = ptype;
@@ -3205,20 +3212,29 @@ ncls:
vlan_on_bond_hook(skb);
/* deliver only exact match when indicated */
- null_or_dev = deliver_exact ? skb->dev : NULL;
+ if (deliver_exact)
+ goto skip_wildcard_delivery;
+
+ list_for_each_entry_rcu(ptype, &ptype_all, list) {
+ if (!ptype->dev) {
+ if (pt_prev)
+ ret = deliver_skb(skb, pt_prev);
+ pt_prev = ptype;
+ }
+ }
type = skb->protocol;
list_for_each_entry_rcu(ptype,
&ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
- if (ptype->type == type &&
- (ptype->dev == null_or_dev || ptype->dev == skb->dev ||
- ptype->dev == orig_dev)) {
+ if (ptype->type == type && !ptype->dev) {
if (pt_prev)
ret = deliver_skb(skb, pt_prev);
pt_prev = ptype;
}
}
+skip_wildcard_delivery:
+
if (pt_prev) {
ret = pt_prev->func(skb, skb->dev, pt_prev);
} else {
--
1.7.2.3
^ permalink raw reply related
* Re: [patch net-next-2.6 6/8] bonding: move processing of recv handlers into handle_frame()
From: Jiri Pirko @ 2011-03-06 13:34 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <4D737D00.20406@gmail.com>
Sun, Mar 06, 2011 at 01:24:32PM CET, nicolas.2p.debian@gmail.com wrote:
>Le 05/03/2011 15:50, Nicolas de Pesloüan a écrit :
>>Le 05/03/2011 15:43, Jiri Pirko a écrit :
>>>Sat, Mar 05, 2011 at 03:33:30PM CET, nicolas.2p.debian@gmail.com wrote:
>>>>Le 05/03/2011 11:29, Jiri Pirko a écrit :
>>>>>Since now when bonding uses rx_handler, all traffic going into bond
>>>>>device goes thru bond_handle_frame. So there's no need to go back into
>>>>>bonding code later via ptype handlers. This patch converts
>>>>>original ptype handlers into "bonding receive probes". These functions
>>>>>are called from bond_handle_frame and they are registered per-mode.
>>>>
>>>>Does this still support having the arp_ip_target on a vlan?
>>>>
>>>>(eth0 -> bond0 -> bond0.100, with arp_ip_target only reachable
>>>>through bond0.100).
>>>
>>>This case is still covered with vlan_on_bond_hook
>>>eth0->
>>>bond_handle_frame
>>>bond0->
>>>vlan_hwaccel_do_receive
>>>bond0.5->
>>>vlan_on_bond_hook -> reinject into bond0
>>>-> bond_handle_frame (here it is processed)
>>
>>Sound good to me.
>>
>>Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
>
>After another review, I think it won't work.
>
>vlan_on_bond() will reinject into bond0, but bond_handle_frame() is
>registered as the rx_handler for the slaves (eth0 in the above
>setup), not as the rx_handler for the master (bond0 in the above
>setup). So, bond_handlee_frame() will never see the untagged ARP
>request/reply and bonding ARP monitoring will fail.
Damn, you are right. I mislooked.
>
>That being said, the current vlan_on_bond_hook() hack already suffer
>other troubles and for example won't support the following setup:
>
>eth0 -> bond0 -> br0 -> br0.100.
blah. Well correct me if my thinking is wrong but I cannot imagine
a scenario where there's not other way how to do arp monitoring than
over vlan.
So how about to just remove the vlan_on_bond_hook and forbid the
possibility. IMHO it should have never been introduced in the first
place.
>
>I think we need to fix this stacking issue in a more general way.
Well this issue is more or less out of the concept and breaks layering.
I cannot think of how to resolve this nicely atm.
>
> Nicolas.
^ permalink raw reply
* Re: [patch net-next-2.6 6/8] bonding: move processing of recv handlers into handle_frame()
From: Nicolas de Pesloüan @ 2011-03-06 14:25 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <20110306133413.GB2795@psychotron.redhat.com>
Le 06/03/2011 14:34, Jiri Pirko a écrit :
> Sun, Mar 06, 2011 at 01:24:32PM CET, nicolas.2p.debian@gmail.com wrote:
>> Le 05/03/2011 15:50, Nicolas de Pesloüan a écrit :
>>> Le 05/03/2011 15:43, Jiri Pirko a écrit :
>>>> Sat, Mar 05, 2011 at 03:33:30PM CET, nicolas.2p.debian@gmail.com wrote:
>>>>> Le 05/03/2011 11:29, Jiri Pirko a écrit :
>>>>>> Since now when bonding uses rx_handler, all traffic going into bond
>>>>>> device goes thru bond_handle_frame. So there's no need to go back into
>>>>>> bonding code later via ptype handlers. This patch converts
>>>>>> original ptype handlers into "bonding receive probes". These functions
>>>>>> are called from bond_handle_frame and they are registered per-mode.
>>>>>
>>>>> Does this still support having the arp_ip_target on a vlan?
>>>>>
>>>>> (eth0 -> bond0 -> bond0.100, with arp_ip_target only reachable
>>>>> through bond0.100).
>>>>
>>>> This case is still covered with vlan_on_bond_hook
>>>> eth0->
>>>> bond_handle_frame
>>>> bond0->
>>>> vlan_hwaccel_do_receive
>>>> bond0.5->
>>>> vlan_on_bond_hook -> reinject into bond0
>>>> -> bond_handle_frame (here it is processed)
>>>
>>> Sound good to me.
>>>
>>> Reviewed-by: Nicolas de Pesloüan<nicolas.2p.debian@free.fr>
>>
>> After another review, I think it won't work.
>>
>> vlan_on_bond() will reinject into bond0, but bond_handle_frame() is
>> registered as the rx_handler for the slaves (eth0 in the above
>> setup), not as the rx_handler for the master (bond0 in the above
>> setup). So, bond_handlee_frame() will never see the untagged ARP
>> request/reply and bonding ARP monitoring will fail.
>
> Damn, you are right. I mislooked.
So do I :-D
>> That being said, the current vlan_on_bond_hook() hack already suffer
>> other troubles and for example won't support the following setup:
>>
>> eth0 -> bond0 -> br0 -> br0.100.
>
> blah. Well correct me if my thinking is wrong but I cannot imagine
> a scenario where there's not other way how to do arp monitoring than
> over vlan.
If you are connected to a switch smart enough to allow non tagged delivery for one vlan and all you
arp_ip_targets are reachable through that vlan, then, yes, this hack might been useless...
But...
In real life, you may be connected to any kind of switch, including the most stupid one... or you
may have trouble explaining to the network team the reason why you need all packets to be tagged
expect for one vlan... or simply, some of your arp_ip_targets will be reachable through a router in
another vlan.
> So how about to just remove the vlan_on_bond_hook and forbid the
> possibility. IMHO it should have never been introduced in the first
> place.
If it was never introduced, we would have been able to simply forbid it, but the feature exist since
December 14th 2009, so I'm afraid we must keep it... :-/
And as a more general rule, I think we should support "all possible" interface stacking setups,
because this would force us to think generic, instead of adding special hacks for special stacking
setups.
>> I think we need to fix this stacking issue in a more general way.
>
> Well this issue is more or less out of the concept and breaks layering.
> I cannot think of how to resolve this nicely atm.
The only way I can imagine atm is something I described a few days ago:
1/ Add a late_delivery property to packet_type:
struct packet_type {
__be16 type; /* This is really htons(ether_type). */
struct net_device *dev; /* NULL is wildcarded here */
int (*func) (struct sk_buff *,
struct net_device *,
struct packet_type *);
struct sk_buff *(*gso_segment)(struct sk_buff *skb,
u32 features);
int (*gso_send_check)(struct sk_buff *skb);
struct sk_buff **(*gro_receive)(struct sk_buff **head,
struct sk_buff *skb);
int (*gro_complete)(struct sk_buff *skb);
void *af_packet_priv;
+ bool late_delivery;
struct list_head list;
};
2/ Use the late_delivery property inside the ptype_all and ptype_base loops in
__netif_receive_skb(), to skip the protocol handlers whose late_delivery property is false, while we
walk the rx_handler path.
3/ At the end of __netif_receive_skb(), deliver the final skb to those ptype_all and ptype_base
handlers whose late_delivery property is true.
4/ And revert back the bonding ARP monitoring to a normal protocol handler, having late_delivery ==
true.
This would work with eth0 -> bond0 -> bond0.100 and eth0 -> bond0 -> br0 -> br0.100.
This would also be reasonably generic, from my point of view. No reference to vlan, bonding, bridge
or whatever...
Nicolas.
^ permalink raw reply
* Re: [patch net-next-2.6 6/8] bonding: move processing of recv handlers into handle_frame()
From: Michał Mirosław @ 2011-03-06 16:32 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, netdev, davem, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <4D739947.6040603@gmail.com>
2011/3/6 Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>:
> Le 06/03/2011 14:34, Jiri Pirko a écrit :
>> Sun, Mar 06, 2011 at 01:24:32PM CET, nicolas.2p.debian@gmail.com wrote:
[...]
>>> That being said, the current vlan_on_bond_hook() hack already suffer
>>> other troubles and for example won't support the following setup:
>>>
>>> eth0 -> bond0 -> br0 -> br0.100.
>>
>> blah. Well correct me if my thinking is wrong but I cannot imagine
>> a scenario where there's not other way how to do arp monitoring than
>> over vlan.
>
> If you are connected to a switch smart enough to allow non tagged delivery
> for one vlan and all you arp_ip_targets are reachable through that vlan,
> then, yes, this hack might been useless...
>
> But...
>
> In real life, you may be connected to any kind of switch, including the most
> stupid one... or you may have trouble explaining to the network team the
> reason why you need all packets to be tagged expect for one vlan... or
> simply, some of your arp_ip_targets will be reachable through a router in
> another vlan.
>
>> So how about to just remove the vlan_on_bond_hook and forbid the
>> possibility. IMHO it should have never been introduced in the first
>> place.
>
> If it was never introduced, we would have been able to simply forbid it, but
> the feature exist since December 14th 2009, so I'm afraid we must keep it...
> :-/
>
> And as a more general rule, I think we should support "all possible"
> interface stacking setups, because this would force us to think generic,
> instead of adding special hacks for special stacking setups.
>
>>> I think we need to fix this stacking issue in a more general way.
>>
>> Well this issue is more or less out of the concept and breaks layering.
>> I cannot think of how to resolve this nicely atm.
>
> The only way I can imagine atm is something I described a few days ago:
>
> 1/ Add a late_delivery property to packet_type:
>
> struct packet_type {
> __be16 type; /* This is really
> htons(ether_type). */
> struct net_device *dev; /* NULL is wildcarded here
> */
> int (*func) (struct sk_buff *,
> struct net_device *,
> struct packet_type *);
> struct sk_buff *(*gso_segment)(struct sk_buff *skb,
> u32 features);
> int (*gso_send_check)(struct sk_buff
> *skb);
> struct sk_buff **(*gro_receive)(struct sk_buff
> **head,
> struct sk_buff *skb);
> int (*gro_complete)(struct sk_buff *skb);
> void *af_packet_priv;
> + bool late_delivery;
> struct list_head list;
> };
>
> 2/ Use the late_delivery property inside the ptype_all and ptype_base loops
> in __netif_receive_skb(), to skip the protocol handlers whose late_delivery
> property is false, while we walk the rx_handler path.
>
> 3/ At the end of __netif_receive_skb(), deliver the final skb to those
> ptype_all and ptype_base handlers whose late_delivery property is true.
>
> 4/ And revert back the bonding ARP monitoring to a normal protocol handler,
> having late_delivery == true.
>
> This would work with eth0 -> bond0 -> bond0.100 and eth0 -> bond0 -> br0 ->
> br0.100.
>
> This would also be reasonably generic, from my point of view. No reference
> to vlan, bonding, bridge or whatever...
Is there a particular reason why this ARP monitoring can't be done in
userspace (e.g. on AF_PACKET with suitable filter)? Marking slaves
up/down as their link goes in that direction is easy, but as more and
more link-state detecting methods/algorithms get added this is
becoming more of a mess.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [patch net-next-2.6 6/8] bonding: move processing of recv handlers into handle_frame()
From: Nicolas de Pesloüan @ 2011-03-06 17:37 UTC (permalink / raw)
To: Michał Mirosław
Cc: Jiri Pirko, netdev, davem, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <AANLkTi=Gt_ArqOVPJjnrAExO8Fihu8WzUhYSb_O6URQ_@mail.gmail.com>
Le 06/03/2011 17:32, Michał Mirosław a écrit :
[snip]
> Is there a particular reason why this ARP monitoring can't be done in
> userspace (e.g. on AF_PACKET with suitable filter)? Marking slaves
> up/down as their link goes in that direction is easy, but as more and
> more link-state detecting methods/algorithms get added this is
> becoming more of a mess.
Moving as much as possible of bonding into userspace is a long standing target.
I think we currently lack a good way to notify the bonding driver that a given slave is available or
not. Bringing the slave down on link failure is not appropriate, because it would prevent userspace
from receiving the ARP packets that would bring the slave up again upon link return.
The only thing we can do is writing into /sys/class/net/bond0/bonding/active_slave, to force the
active_slave. And this is strictly limited to active-backup mode.
I will let Jay / Andy comment on the general problem.
Nicolas.
^ 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