* Re: Hang: 2.6.32.4 sky2/DMAR (was [PATCH] sky2: Fix WARNING: at lib/dma-debug.c:902 check_sync)
From: Michael Breuer @ 2010-01-28 16:43 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jarek Poplawski, David Miller, akpm, flyboy, linux-kernel, netdev,
Michael Chan, Don Fry, Francois Romieu, Matt Carlson
In-Reply-To: <4B61ADF1.7060705@majjas.com>
On 01/28/2010 10:32 AM, Michael Breuer wrote:
> On 01/27/2010 01:45 PM, Michael Breuer wrote:
>> On 1/27/2010 1:08 PM, Michael Breuer wrote:
>>>
>>>
>>> I've got (both in 2.6.32.4 and 2.6.33-rc5: pci_unmap_len(re,
>>> data_size) vs., "length." I assume that I can just replace the
>>> pci_unmap_len with dma_size... but perhaps the intermediate change
>>> may have affected this as well?
>>>
>> Never mind - that was from one of the earlier patches I had been
>> trying out. will try the above patch after reestablishing that the
>> system still crashes without copybreak=1.
> Just FYI - still crashes with default copybreak. Didn't get the
> netdev watchdog this time - just DMAR and then HW watchdog reboot (see
> below).
>
> So what's known to be required to cause this crash:
>
> 1) sky2 @ 1Gb
> 2) High sustained RX load (> 40MBps)
> 3) Uptime (I can't cause this to happen just after boot).
> 4) DMAR enabled (doesn't crash w/o DMAR).
> 5) copybreak != 1
>
> What might be required but is unproven:
> 1) cifs traffic (I've only seen this when the high traffic was due to
> a Win7 box doing backup). I've tried but have been unable to recreate
> by just copying large files. Backups done from a Mac OS laptop don't
> trigger the issue even though that machine is also connecting with
> CIFS (TimeMachine works better that way).
> 2) DHCP traffic. There has always been some sort of DHCP exchange in
> the log before the first indication of a problem (DMAR).
> 3) Total throughput since boot. DK about this - however the uptime
> component before the latest crash was the shortest yet. In preparation
> I moved a bunch of large files around on the Windows box to ensure a
> larger than normal backup run. I also ran manually before going to bed
> (then moved the files around again). Didn't crash when I was watching
> - but did overnight. Total uptime before this crash was only about 6
> hours. Previously (with less backup data) the system didn't crash
> until 24-36 hours.
>
> Observations:
>
> Copybreak: I did play for an hour or so yesterday with copybreak=1000.
> Ran traffic, etc. No crash, but throughput was lower and the system
> was clearly working way harder than normal. Given the whine of the
> fans I'm not keen on leaving the system in that state for any extended
> period of time.
>
> MTU: Increasing the MTU to 9000 yesterday after the system had been up
> for some time (copybreak=1) crashed the system immediately.
> Subsequently I have been able to change the mtu without crashes
> (although the driver does end up in some sort of state that requires a
> restart after lowering the mtu). I suspect that over time something is
> being corrupted resulting in the crash when changing mtu. Whatever it
> becoming corrupted is probably related to the other crash as well.
> That suggests to me that copybreak=1 is preventing or delaying the
> manifestation of the underlying issue but is unrelated to the source
> of corruption.
>
> [no messages in the prior three minutes - there was a dhcp exchange
> (request/ack) at 06:02:27]
> Jan 28 06:05:58 mail kernel: DRHD: handling fault status reg 2
> Jan 28 06:05:58 mail kernel: DMAR:[DMA Read] Request device [06:00.0]
> fault addr ffdd06bfe000
> Jan 28 06:05:58 mail kernel: DMAR:[fault reason 06] PTE Read access is
> not set
> Jan 28 06:05:58 mail kernel: sky2 0000:06:00.0: error interrupt
> status=0x80000000
> Jan 28 06:05:58 mail kernel: sky2 0000:06:00.0: PCI hardware error
> (0x2010)
> [No further messages until restart at 06:09:46.]
>
Update: I played with dma-debug. Was being disabled due to lack of
memory. I forced it back on while pumping traffic through and got this:
Jan 28 11:39:30 mail kernel: ------------[ cut here ]------------
Jan 28 11:39:30 mail kernel: WARNING: at lib/dma-debug.c:902
check_sync+0xc1/0x43f()
Jan 28 11:39:30 mail kernel: Hardware name: System Product Name
Jan 28 11:39:30 mail kernel: sky2 0000:06:00.0: DMA-API: device driver
tries to sync DMA memory it has not allocated [device
address=0x0000ffff4fe37022] [size=1520 bytes]
Jan 28 11:39:30 mail kernel: Modules linked in: microcode(+)
ip6table_filter ip6table_mangle ip6_tables iptable_raw iptable_mangle
ipt_MASQUERADE iptable_nat nf_nat bridge stp appletalk psnap llc nfsd
lockd nfs_acl auth_rpcgss exportfs hwmon_vid coretemp sunrpc
acpi_cpufreq sit tunnel4 ipt_LOG nf_conntrack_netbios_ns
nf_conntrack_ftp xt_DSCP xt_dscp xt_MARK nf_conntrack_ipv6 xt_multiport
ipv6 dm_multipath kvm_intel kvm snd_hda_codec_analog snd_ens1371
gameport snd_rawmidi gspca_spca505 snd_hda_intel snd_ac97_codec
gspca_main snd_hda_codec videodev snd_hwdep snd_seq v4l1_compat i2c_i801
pcspkr ac97_bus v4l2_compat_ioctl32 snd_seq_device asus_atk0110 hwmon
snd_pcm firewire_ohci firewire_core crc_itu_t sky2 snd_timer snd
iTCO_wdt iTCO_vendor_support wmi soundcore snd_page_alloc fbcon tileblit
font bitblit softcursor raid456 async_raid6_recov async_pq raid6_pq
async_xor xor async_memcpy async_tx raid1 ata_generic pata_acpi
pata_marvell nouveau ttm drm_kms_helper drm agpgart fb i2c_algo_bit
cfbcopyarea i2c_core cfb
Jan 28 11:39:30 mail kernel: imgblt cfbfillrect [last unloaded: ip6_tables]
Jan 28 11:39:30 mail kernel: Pid: 5327, comm: bash Tainted: G W
2.6.32.4MMAPDMARAF3SKY2PSKBMAYPULL-00912-g914160d-dirty #6
Jan 28 11:39:30 mail kernel: Call Trace:
Jan 28 11:39:30 mail kernel: <IRQ> [<ffffffff810536ee>]
warn_slowpath_common+0x7c/0x94
Jan 28 11:39:30 mail kernel: [<ffffffff8105375d>]
warn_slowpath_fmt+0x41/0x43
Jan 28 11:39:30 mail kernel: [<ffffffff8127b891>] check_sync+0xc1/0x43f
Jan 28 11:39:30 mail kernel: [<ffffffff8146c51a>] ?
_spin_unlock_irqrestore+0x29/0x41
Jan 28 11:39:30 mail kernel: [<ffffffff813cac10>] ?
__netdev_alloc_skb+0x34/0x50
Jan 28 11:39:30 mail kernel: [<ffffffff8127bf62>]
debug_dma_sync_single_for_cpu+0x42/0x44
Jan 28 11:39:30 mail kernel: [<ffffffff813cac10>] ?
__netdev_alloc_skb+0x34/0x50
Jan 28 11:39:30 mail kernel: [<ffffffffa019aee8>] sky2_poll+0x4d5/0xb06
[sky2]
Jan 28 11:39:30 mail kernel: [<ffffffff81044840>] ?
enqueue_entity+0x26c/0x279
Jan 28 11:39:30 mail kernel: [<ffffffff8107decf>] ?
clockevents_program_event+0x7a/0x83
Jan 28 11:39:30 mail kernel: [<ffffffff813d18ae>] net_rx_action+0xb5/0x1f3
Jan 28 11:39:30 mail kernel: [<ffffffff8105af0f>] __do_softirq+0xf8/0x1cd
Jan 28 11:39:30 mail kernel: [<ffffffff810a3006>] ?
handle_IRQ_event+0x119/0x12b
Jan 28 11:39:30 mail kernel: [<ffffffff81012e1c>] call_softirq+0x1c/0x30
Jan 28 11:39:30 mail kernel: [<ffffffff810143a3>] do_softirq+0x4b/0xa6
Jan 28 11:39:30 mail kernel: [<ffffffff8105aaef>] irq_exit+0x4a/0x8c
Jan 28 11:39:30 mail kernel: [<ffffffff81470575>] do_IRQ+0xa5/0xbc
Jan 28 11:39:30 mail kernel: [<ffffffff81012613>] ret_from_intr+0x0/0x16
Jan 28 11:39:30 mail kernel: <EOI>
Jan 28 11:39:30 mail kernel: ---[ end trace 57f7151f6a5def07 ]---
Jan 28 11:39:30 mail kernel: DMA-API: debugging out of memory - disabling
^ permalink raw reply
* Re: [PATCH] sctp: IPsec rules are ineffective with ipv6
From: Vlad Yasevich @ 2010-01-28 16:36 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: David Miller, netdev, linux-sctp
In-Reply-To: <4B61B047.10908@dev.6wind.com>
Nicolas Dichtel wrote:
> What about this one?
>
> Only compilation tested.
>
> xfrm_lookup() is missing in IPv6 output path. Call it when dst is build.
> Initial patch was written by Junwei Zhang <junwei.zhang@6wind.com>
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Looks like it might do the right thing. Please run your tests
on this an let me.
Thanks
-vlad
>
> Le 28.01.2010 16:24, Vlad Yasevich a écrit :
>>
>> David Miller wrote:
>>> From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
>>> Date: Wed, 27 Jan 2010 15:12:59 +0100
>>>
>>>> xfrm_lookup() is missing in sctp_v6_xmit(), add it.
>>>>
>>>> Signed-off-by: Junwei Zhang <junwei.zhang@6wind.com>
>>>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>> Doing this every transmit packet is overkill.
>>>
>>> Whatever calculates the route that ends up in skb_dst(skb)
>>> should be making this xfrm_lookup() call, not here.
>>>
>>
>>
>> Hmm.. Interesting. Looks like ip_route_output_key() will
>> do xfrm_lookup for you, but there is no ipv6 route lookup call
>> that will do the same thing.
>>
>> I guess we'll need to add an xfrm_lookup call in sctp_v6_get_dst().
>>
>> -vlad
^ permalink raw reply
* Re: 0% cpu usasge after fresh boot or net restart but 10% CPU if kernel flush route cache
From: cold cold @ 2010-01-28 16:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1264694957.2930.15.camel@edumazet-laptop>
On Thu, Jan 28, 2010 at 6:09 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 28 janvier 2010 à 11:14 +0200, cold cold a écrit :
>
>>
>> RX Kpps : 57 TX Kpps : 53 RX Kbits : 331184 TX Kbits : 306213
>> RX Kpps : 59 TX Kpps : 54 RX Kbits : 345517 TX Kbits : 304323
>> RX Kpps : 56 TX Kpps : 52 RX Kbits : 331418 TX Kbits : 296032
>> RX Kpps : 60 TX Kpps : 54 RX Kbits : 362007 TX Kbits : 297371
>> RX Kpps : 59 TX Kpps : 52 RX Kbits : 360455 TX Kbits : 280603
>>
>>
>> ON one cpu, gc_interval to 1, gc_elasticity 2
>>
>> Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 72.0%id, 0.0%wa, 8.3%hi, 19.7%si, 0.0%st
>> Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
>> Cpu2 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
>> Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
>>
>> ------------------------------------------------------------------------------
>> PerfTop: 17064 irqs/sec kernel:98.0% [100000 cycles], (all, 4 CPUs)
>> ------------------------------------------------------------------------------
>>
>> samples pcnt kernel function
>> _______ _____ _______________
>>
>> 40388.00 - 27.8% : acpi_idle_do_entry
>> 24651.00 - 17.0% : read_hpet
>> 4271.00 - 2.9% : _spin_lock
>> 3388.00 - 2.3% : pskb_expand_head
>> 3288.00 - 2.3% : igb_poll [igb]
>> 3246.00 - 2.2% : irq_entries_start
>> 2868.00 - 2.0% : dev_gro_receive
>> 2665.00 - 1.8% : igb_xmit_frame_adv [igb]
>> 2513.00 - 1.7% : ip_route_input
>> 2144.00 - 1.5% : igb_clean_tx_irq [igb]
>> 1842.00 - 1.3% : __slab_free
>> 1544.00 - 1.1% : dev_queue_xmit
>> 1423.00 - 1.0% : igb_msix_rx [igb]
>> 1353.00 - 0.9% : __alloc_skb
>> 1285.00 - 0.9% : eth_type_trans
>> --
>
> All this seems pretty normal profile (regarding networking functions),
> your machine should scale without problem.
>
> Of course, the two first functions (acpi_idle_do_entry() & read_hpet())
> look suspicious but I have no idea why.
>
i make with flushing without gc on 2 cpu 2 time more traffic and CPU
usage about 5 times less
top - 11:22:04 up 6:45, 5 users, load average: 0.00, 0.10, 0.25
Tasks: 84 total, 1 running, 83 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.3%sy, 0.0%ni, 94.0%id, 0.0%wa, 1.7%hi, 4.0%si, 0.0%st
Cpu1 : 0.3%us, 0.0%sy, 0.0%ni, 97.7%id, 0.0%wa, 0.7%hi, 1.3%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
RX Kpps : 90 TX Kpps : 75 RX Kbits : 582791 TX Kbits : 413873
RX Kpps : 87 TX Kpps : 74 RX Kbits : 546327 TX Kbits : 415852
RX Kpps : 87 TX Kpps : 74 RX Kbits : 544820 TX Kbits : 418339
RX Kpps : 88 TX Kpps : 73 RX Kbits : 569143 TX Kbits : 406438
^ permalink raw reply
* [PATCH] igmp: fix ip_mc_sf_allow race [v5]
From: Flavio Leitner @ 2010-01-28 16:13 UTC (permalink / raw)
To: netdev; +Cc: David Miller, David Stevens, Eric Dumazet
In-Reply-To: <1262724742-5232-1-git-send-email-fleitner@redhat.com>
Hello,
This is another version considering the suggestions. Thanks!
I didn't convert to list_head yet because a lot more code needs
to be changed so I'd rather leave that to another patch.
8<---------
Almost all igmp functions accessing inet->mc_list are protected by
rtnl_lock(), but there is one exception which is ip_mc_sf_allow(),
so there is a chance of either ip_mc_drop_socket or ip_mc_leave_group
remove an entry while ip_mc_sf_allow is running causing a crash.
Signed-off-by: Flavio Leitner <fleitner@redhat.com>
---
include/linux/igmp.h | 2 +
net/ipv4/igmp.c | 83 +++++++++++++++++++++++++++++++++++++------------
2 files changed, 64 insertions(+), 21 deletions(-)
diff --git a/include/linux/igmp.h b/include/linux/igmp.h
index 724c27e..93fc244 100644
--- a/include/linux/igmp.h
+++ b/include/linux/igmp.h
@@ -153,6 +153,7 @@ extern int sysctl_igmp_max_msf;
struct ip_sf_socklist {
unsigned int sl_max;
unsigned int sl_count;
+ struct rcu_head rcu;
__be32 sl_addr[0];
};
@@ -170,6 +171,7 @@ struct ip_mc_socklist {
struct ip_mreqn multi;
unsigned int sfmode; /* MCAST_{INCLUDE,EXCLUDE} */
struct ip_sf_socklist *sflist;
+ struct rcu_head rcu;
};
struct ip_sf_list {
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 76c0840..54003a5 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1799,7 +1799,7 @@ int ip_mc_join_group(struct sock *sk , struct ip_mreqn *imr)
iml->next = inet->mc_list;
iml->sflist = NULL;
iml->sfmode = MCAST_EXCLUDE;
- inet->mc_list = iml;
+ rcu_assign_pointer(inet->mc_list, iml);
ip_mc_inc_group(in_dev, addr);
err = 0;
done:
@@ -1807,24 +1807,46 @@ done:
return err;
}
+static void ip_sf_socklist_reclaim(struct rcu_head *rp)
+{
+ struct ip_sf_socklist *psf;
+
+ psf = container_of(rp, struct ip_sf_socklist, rcu);
+ /* sk_omem_alloc should have been decreased by the caller*/
+ kfree(psf);
+}
+
static int ip_mc_leave_src(struct sock *sk, struct ip_mc_socklist *iml,
struct in_device *in_dev)
{
+ struct ip_sf_socklist *psf = iml->sflist;
int err;
- if (iml->sflist == NULL) {
+ if (psf == NULL) {
/* any-source empty exclude case */
return ip_mc_del_src(in_dev, &iml->multi.imr_multiaddr.s_addr,
iml->sfmode, 0, NULL, 0);
}
err = ip_mc_del_src(in_dev, &iml->multi.imr_multiaddr.s_addr,
- iml->sfmode, iml->sflist->sl_count,
- iml->sflist->sl_addr, 0);
- sock_kfree_s(sk, iml->sflist, IP_SFLSIZE(iml->sflist->sl_max));
- iml->sflist = NULL;
+ iml->sfmode, psf->sl_count, psf->sl_addr, 0);
+ rcu_assign_pointer(iml->sflist, NULL);
+ /* decrease mem now to avoid the memleak warning */
+ atomic_sub(IP_SFLSIZE(psf->sl_max), &sk->sk_omem_alloc);
+ call_rcu(&psf->rcu, ip_sf_socklist_reclaim);
return err;
}
+
+static void ip_mc_socklist_reclaim(struct rcu_head *rp)
+{
+ struct ip_mc_socklist *iml;
+
+ iml = container_of(rp, struct ip_mc_socklist, rcu);
+ /* sk_omem_alloc should have been decreased by the caller*/
+ kfree(iml);
+}
+
+
/*
* Ask a socket to leave a group.
*/
@@ -1854,12 +1876,14 @@ int ip_mc_leave_group(struct sock *sk, struct ip_mreqn *imr)
(void) ip_mc_leave_src(sk, iml, in_dev);
- *imlp = iml->next;
+ rcu_assign_pointer(*imlp, iml->next);
if (in_dev)
ip_mc_dec_group(in_dev, group);
rtnl_unlock();
- sock_kfree_s(sk, iml, sizeof(*iml));
+ /* decrease mem now to avoid the memleak warning */
+ atomic_sub(sizeof(*iml), &sk->sk_omem_alloc);
+ call_rcu(&iml->rcu, ip_mc_socklist_reclaim);
return 0;
}
if (!in_dev)
@@ -1974,9 +1998,12 @@ int ip_mc_source(int add, int omode, struct sock *sk, struct
if (psl) {
for (i=0; i<psl->sl_count; i++)
newpsl->sl_addr[i] = psl->sl_addr[i];
- sock_kfree_s(sk, psl, IP_SFLSIZE(psl->sl_max));
+ /* decrease mem now to avoid the memleak warning */
+ atomic_sub(IP_SFLSIZE(psl->sl_max), &sk->sk_omem_alloc);
+ call_rcu(&psl->rcu, ip_sf_socklist_reclaim);
}
- pmc->sflist = psl = newpsl;
+ rcu_assign_pointer(pmc->sflist, newpsl);
+ psl = newpsl;
}
rv = 1; /* > 0 for insert logic below if sl_count is 0 */
for (i=0; i<psl->sl_count; i++) {
@@ -2072,11 +2099,13 @@ int ip_mc_msfilter(struct sock *sk, struct ip_msfilter *msf, int ifindex)
if (psl) {
(void) ip_mc_del_src(in_dev, &msf->imsf_multiaddr, pmc->sfmode,
psl->sl_count, psl->sl_addr, 0);
- sock_kfree_s(sk, psl, IP_SFLSIZE(psl->sl_max));
+ /* decrease mem now to avoid the memleak warning */
+ atomic_sub(IP_SFLSIZE(psl->sl_max), &sk->sk_omem_alloc);
+ call_rcu(&psl->rcu, ip_sf_socklist_reclaim);
} else
(void) ip_mc_del_src(in_dev, &msf->imsf_multiaddr, pmc->sfmode,
0, NULL, 0);
- pmc->sflist = newpsl;
+ rcu_assign_pointer(pmc->sflist, newpsl);
pmc->sfmode = msf->imsf_fmode;
err = 0;
done:
@@ -2209,30 +2238,40 @@ int ip_mc_sf_allow(struct sock *sk, __be32 loc_addr, __be32 rmt_addr, int dif)
struct ip_mc_socklist *pmc;
struct ip_sf_socklist *psl;
int i;
+ int ret;
+ ret = 1;
if (!ipv4_is_multicast(loc_addr))
- return 1;
+ goto out;
- for (pmc=inet->mc_list; pmc; pmc=pmc->next) {
+ rcu_read_lock();
+ for (pmc=rcu_dereference(inet->mc_list); pmc; pmc=rcu_dereference(pmc->next)) {
if (pmc->multi.imr_multiaddr.s_addr == loc_addr &&
pmc->multi.imr_ifindex == dif)
break;
}
+ ret = inet->mc_all;
if (!pmc)
- return inet->mc_all;
+ goto unlock;
psl = pmc->sflist;
+ ret = (pmc->sfmode == MCAST_EXCLUDE);
if (!psl)
- return pmc->sfmode == MCAST_EXCLUDE;
+ goto unlock;
for (i=0; i<psl->sl_count; i++) {
if (psl->sl_addr[i] == rmt_addr)
break;
}
+ ret = 0;
if (pmc->sfmode == MCAST_INCLUDE && i >= psl->sl_count)
- return 0;
+ goto unlock;
if (pmc->sfmode == MCAST_EXCLUDE && i < psl->sl_count)
- return 0;
- return 1;
+ goto unlock;
+ ret = 1;
+unlock:
+ rcu_read_unlock();
+out:
+ return ret;
}
/*
@@ -2251,7 +2290,7 @@ void ip_mc_drop_socket(struct sock *sk)
rtnl_lock();
while ((iml = inet->mc_list) != NULL) {
struct in_device *in_dev;
- inet->mc_list = iml->next;
+ rcu_assign_pointer(inet->mc_list, iml->next);
in_dev = inetdev_by_index(net, iml->multi.imr_ifindex);
(void) ip_mc_leave_src(sk, iml, in_dev);
@@ -2259,7 +2298,9 @@ void ip_mc_drop_socket(struct sock *sk)
ip_mc_dec_group(in_dev, iml->multi.imr_multiaddr.s_addr);
in_dev_put(in_dev);
}
- sock_kfree_s(sk, iml, sizeof(*iml));
+ /* decrease mem now to avoid the memleak warning */
+ atomic_sub(sizeof(*iml), &sk->sk_omem_alloc);
+ call_rcu(&iml->rcu, ip_mc_socklist_reclaim);
}
rtnl_unlock();
}
--
1.6.5.2
^ permalink raw reply related
* Re: 0% cpu usasge after fresh boot or net restart but 10% CPU if kernel flush route cache
From: Eric Dumazet @ 2010-01-28 16:09 UTC (permalink / raw)
To: cold cold; +Cc: netdev
In-Reply-To: <41ac0f9e1001280114x17951046oda3fddcae4b8b9d3@mail.gmail.com>
Le jeudi 28 janvier 2010 à 11:14 +0200, cold cold a écrit :
>
> RX Kpps : 57 TX Kpps : 53 RX Kbits : 331184 TX Kbits : 306213
> RX Kpps : 59 TX Kpps : 54 RX Kbits : 345517 TX Kbits : 304323
> RX Kpps : 56 TX Kpps : 52 RX Kbits : 331418 TX Kbits : 296032
> RX Kpps : 60 TX Kpps : 54 RX Kbits : 362007 TX Kbits : 297371
> RX Kpps : 59 TX Kpps : 52 RX Kbits : 360455 TX Kbits : 280603
>
>
> ON one cpu, gc_interval to 1, gc_elasticity 2
>
> Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 72.0%id, 0.0%wa, 8.3%hi, 19.7%si, 0.0%st
> Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
> Cpu2 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
> Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
>
> ------------------------------------------------------------------------------
> PerfTop: 17064 irqs/sec kernel:98.0% [100000 cycles], (all, 4 CPUs)
> ------------------------------------------------------------------------------
>
> samples pcnt kernel function
> _______ _____ _______________
>
> 40388.00 - 27.8% : acpi_idle_do_entry
> 24651.00 - 17.0% : read_hpet
> 4271.00 - 2.9% : _spin_lock
> 3388.00 - 2.3% : pskb_expand_head
> 3288.00 - 2.3% : igb_poll [igb]
> 3246.00 - 2.2% : irq_entries_start
> 2868.00 - 2.0% : dev_gro_receive
> 2665.00 - 1.8% : igb_xmit_frame_adv [igb]
> 2513.00 - 1.7% : ip_route_input
> 2144.00 - 1.5% : igb_clean_tx_irq [igb]
> 1842.00 - 1.3% : __slab_free
> 1544.00 - 1.1% : dev_queue_xmit
> 1423.00 - 1.0% : igb_msix_rx [igb]
> 1353.00 - 0.9% : __alloc_skb
> 1285.00 - 0.9% : eth_type_trans
> --
All this seems pretty normal profile (regarding networking functions),
your machine should scale without problem.
Of course, the two first functions (acpi_idle_do_entry() & read_hpet())
look suspicious but I have no idea why.
^ permalink raw reply
* Re: Intel 82598, RSS and PPPoE
From: Eric Dumazet @ 2010-01-28 15:59 UTC (permalink / raw)
To: Alexander Lapidus; +Cc: netdev
In-Reply-To: <201001281334.51123.alex@wildpark.net>
Le jeudi 28 janvier 2010 à 13:34 +0200, Alexander Lapidus a écrit :
> Hello, everybody!
> Help is needed in such case. We have a linux-box, running under CentOS 5.4
> with a latest kernel. Intel 10 Gigabit AF DA Dual Port Server Adapter (based
> on Intel 82598EB) is used for routing purposes. Linux-box is dual CPU Xeon
> E5530 server. Interface eth0 is an uplink to the network core with pure IPv4
> trafic on it. Interface eth1 is an downlink to customers. We have 3000 802.1q
> VLANs on it. PPPoE server daemon is running on all VLAN interfaces. So we have
> ethernet frames with 802.1q VLAN tag and PPPoE header incapsulated. Our
> problem is with RX packet distribution between rx-queues on this interface.
> All those packets are coming to RX-queue-0. As i understood from Intel
> specification on 82598 chipset, problem is with RSS, which can't decode PPPoE
> header, so packet is going only to queue 0. My question is how to force such
> packets to spread between different queues. May be it's possible to use VMDq
> in this configuration, or any other solution?
>
> P.S. We tried this configuration with in-kernel driver and with latest driver
> from Intel (ixgbe-2.0.44.14). Situation is the same.
>
>
What exact linux kernel version are you using ?
If hardware is not able to spread packets into multiple receive queues
because of VLAN or PPOE encapsulation then you might try RPS (not yet
included in kernel) and add appropriate
PPOE decoding in low level frame handling.
RPS v5 pointer : http://www.spinics.net/lists/netdev/msg118378.html
^ permalink raw reply
* Re: [PATCH] sctp: IPsec rules are ineffective with ipv6
From: Nicolas Dichtel @ 2010-01-28 15:41 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: David Miller, netdev, linux-sctp
In-Reply-To: <4B61AC22.2050907@hp.com>
[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]
What about this one?
Only compilation tested.
xfrm_lookup() is missing in IPv6 output path. Call it when dst is build. Initial
patch was written by Junwei Zhang <junwei.zhang@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Le 28.01.2010 16:24, Vlad Yasevich a écrit :
>
> David Miller wrote:
>> From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
>> Date: Wed, 27 Jan 2010 15:12:59 +0100
>>
>>> xfrm_lookup() is missing in sctp_v6_xmit(), add it.
>>>
>>> Signed-off-by: Junwei Zhang <junwei.zhang@6wind.com>
>>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> Doing this every transmit packet is overkill.
>>
>> Whatever calculates the route that ends up in skb_dst(skb)
>> should be making this xfrm_lookup() call, not here.
>>
>
>
> Hmm.. Interesting. Looks like ip_route_output_key() will
> do xfrm_lookup for you, but there is no ipv6 route lookup call
> that will do the same thing.
>
> I guess we'll need to add an xfrm_lookup call in sctp_v6_get_dst().
>
> -vlad
[-- Attachment #2: x2.diff --]
[-- Type: text/x-diff, Size: 810 bytes --]
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index cc50fbe..4081ffb 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -258,13 +258,14 @@ static struct dst_entry *sctp_v6_get_dst(struct sctp_association *asoc,
}
dst = ip6_route_output(&init_net, NULL, &fl);
- if (!dst->error) {
- struct rt6_info *rt;
- rt = (struct rt6_info *)dst;
- SCTP_DEBUG_PRINTK("rt6_dst:%pI6 rt6_src:%pI6\n",
- &rt->rt6i_dst.addr, &rt->rt6i_src.addr);
- return dst;
- }
+ if (!dst->error)
+ if (xfrm_lookup(&init_net, &dst, &fl, asoc ? asoc->base.sk : NULL, 0) >= 0) {
+ struct rt6_info *rt;
+ rt = (struct rt6_info *)dst;
+ SCTP_DEBUG_PRINTK("rt6_dst:%pI6 rt6_src:%pI6\n",
+ &rt->rt6i_dst.addr, &rt->rt6i_src.addr);
+ return dst;
+ }
SCTP_DEBUG_PRINTK("NO ROUTE\n");
dst_release(dst);
return NULL;
^ permalink raw reply related
* Re: Hang: 2.6.32.4 sky2/DMAR (was [PATCH] sky2: Fix WARNING: at lib/dma-debug.c:902 check_sync)
From: Michael Breuer @ 2010-01-28 15:32 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jarek Poplawski, David Miller, akpm, flyboy, linux-kernel, netdev,
Michael Chan, Don Fry, Francois Romieu, Matt Carlson
In-Reply-To: <4B6089C7.4010803@majjas.com>
On 01/27/2010 01:45 PM, Michael Breuer wrote:
> On 1/27/2010 1:08 PM, Michael Breuer wrote:
>>
>>
>> I've got (both in 2.6.32.4 and 2.6.33-rc5: pci_unmap_len(re,
>> data_size) vs., "length." I assume that I can just replace the
>> pci_unmap_len with dma_size... but perhaps the intermediate change
>> may have affected this as well?
>>
> Never mind - that was from one of the earlier patches I had been
> trying out. will try the above patch after reestablishing that the
> system still crashes without copybreak=1.
Just FYI - still crashes with default copybreak. Didn't get the netdev
watchdog this time - just DMAR and then HW watchdog reboot (see below).
So what's known to be required to cause this crash:
1) sky2 @ 1Gb
2) High sustained RX load (> 40MBps)
3) Uptime (I can't cause this to happen just after boot).
4) DMAR enabled (doesn't crash w/o DMAR).
5) copybreak != 1
What might be required but is unproven:
1) cifs traffic (I've only seen this when the high traffic was due to a
Win7 box doing backup). I've tried but have been unable to recreate by
just copying large files. Backups done from a Mac OS laptop don't
trigger the issue even though that machine is also connecting with CIFS
(TimeMachine works better that way).
2) DHCP traffic. There has always been some sort of DHCP exchange in the
log before the first indication of a problem (DMAR).
3) Total throughput since boot. DK about this - however the uptime
component before the latest crash was the shortest yet. In preparation I
moved a bunch of large files around on the Windows box to ensure a
larger than normal backup run. I also ran manually before going to bed
(then moved the files around again). Didn't crash when I was watching -
but did overnight. Total uptime before this crash was only about 6
hours. Previously (with less backup data) the system didn't crash until
24-36 hours.
Observations:
Copybreak: I did play for an hour or so yesterday with copybreak=1000.
Ran traffic, etc. No crash, but throughput was lower and the system was
clearly working way harder than normal. Given the whine of the fans I'm
not keen on leaving the system in that state for any extended period of
time.
MTU: Increasing the MTU to 9000 yesterday after the system had been up
for some time (copybreak=1) crashed the system immediately. Subsequently
I have been able to change the mtu without crashes (although the driver
does end up in some sort of state that requires a restart after lowering
the mtu). I suspect that over time something is being corrupted
resulting in the crash when changing mtu. Whatever it becoming corrupted
is probably related to the other crash as well. That suggests to me that
copybreak=1 is preventing or delaying the manifestation of the
underlying issue but is unrelated to the source of corruption.
[no messages in the prior three minutes - there was a dhcp exchange
(request/ack) at 06:02:27]
Jan 28 06:05:58 mail kernel: DRHD: handling fault status reg 2
Jan 28 06:05:58 mail kernel: DMAR:[DMA Read] Request device [06:00.0]
fault addr ffdd06bfe000
Jan 28 06:05:58 mail kernel: DMAR:[fault reason 06] PTE Read access is
not set
Jan 28 06:05:58 mail kernel: sky2 0000:06:00.0: error interrupt
status=0x80000000
Jan 28 06:05:58 mail kernel: sky2 0000:06:00.0: PCI hardware error (0x2010)
[No further messages until restart at 06:09:46.]
^ permalink raw reply
* Re: [PATCH] sctp: IPsec rules are ineffective with ipv6
From: Vlad Yasevich @ 2010-01-28 15:24 UTC (permalink / raw)
To: David Miller; +Cc: nicolas.dichtel, netdev, linux-sctp
In-Reply-To: <20100128.055148.127214200.davem@davemloft.net>
David Miller wrote:
> From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
> Date: Wed, 27 Jan 2010 15:12:59 +0100
>
>> xfrm_lookup() is missing in sctp_v6_xmit(), add it.
>>
>> Signed-off-by: Junwei Zhang <junwei.zhang@6wind.com>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> Doing this every transmit packet is overkill.
>
> Whatever calculates the route that ends up in skb_dst(skb)
> should be making this xfrm_lookup() call, not here.
>
Hmm.. Interesting. Looks like ip_route_output_key() will
do xfrm_lookup for you, but there is no ipv6 route lookup call
that will do the same thing.
I guess we'll need to add an xfrm_lookup call in sctp_v6_get_dst().
-vlad
^ permalink raw reply
* Re: [PATCH 4/4] netns xfrm: ipcomp6 support
From: David Miller @ 2010-01-28 14:35 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, herbert
In-Reply-To: <20100125203909.GC6145@x200>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Mon, 25 Jan 2010 22:39:09 +0200
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/4] netns xfrm: ipcomp support
From: David Miller @ 2010-01-28 14:35 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, herbert
In-Reply-To: <20100125203834.GB6145@x200>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Mon, 25 Jan 2010 22:38:34 +0200
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/4] netns xfrm: xfrm6_tunnel in netns
From: David Miller @ 2010-01-28 14:35 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, herbert
In-Reply-To: <20100125203754.GA6145@x200>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Mon, 25 Jan 2010 22:37:54 +0200
> I'm not sure about rcu stuff near kmem cache destruction:
> * checks for non-empty hashes look bogus, they're done _before_
> rcu_berrier()
> * unregistering netns ops is done before kmem_cache destoy
> (as it should), and unregistering involves rcu barriers by itself
>
> So it looks nothing should be done.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/4] netns xfrm: fixup xfrm6_tunnel error propagation
From: David Miller @ 2010-01-28 14:35 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, herbert
In-Reply-To: <20100125202820.GA4482@x200>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Mon, 25 Jan 2010 22:28:21 +0200
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] l2tp: Fix a UDP socket reference count bug in the pppol2tp driver
From: David Miller @ 2010-01-28 14:07 UTC (permalink / raw)
To: jchapman; +Cc: netdev
In-Reply-To: <4B603C50.20406@katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Wed, 27 Jan 2010 13:14:56 +0000
> Does the above help?
Thanks for the detailed explanation, I'll take another look
at this.
^ permalink raw reply
* Re: [PATCH] netdev: remove more HAVE_ leftovers
From: David Miller @ 2010-01-28 14:01 UTC (permalink / raw)
To: adobriyan; +Cc: geert, linux-next, netdev, linux-kernel
In-Reply-To: <20100127201741.GA4855@x200>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Wed, 27 Jan 2010 22:17:41 +0200
> [PATCH] netdev: remove more HAVE_ leftovers
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Applied, thanks Alexey.
^ permalink raw reply
* Re: [PATCH 2.6.33-rc5] drivers/net: ks8851_mll ethernet network driver
From: David Miller @ 2010-01-28 13:59 UTC (permalink / raw)
To: bhutchings; +Cc: David.Choi, netdev
In-Reply-To: <1264609713.2839.3.camel@achroite.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 27 Jan 2010 16:28:33 +0000
> On Wed, 2010-01-27 at 08:03 -0800, Choi, David wrote:
>> Hello David Miller,
>>
>> I fix a bug in ks8851_mll driver, which has existed since 2.6.32-rc6.
>>
>> From : David J. Choi <david.choi@micrel.com>
>>
>> Fix a bug that the data pointers in the interrupt handler are set wrong, which is related with the 5th parameter of request_irq().
>>
>> Signed-off-by : David J. Choi <david.choi@micrel.com>
>
> This should go to stable as well since the driver will be useless
> without this.
Applied and queued to -stable.
^ permalink raw reply
* Re: [PATCH] bonding: bond_open error return value
From: David Miller @ 2010-01-28 13:58 UTC (permalink / raw)
To: shemminger; +Cc: fubar, bonding-devel, netdev
In-Reply-To: <20100126013415.0120d6a9@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 26 Jan 2010 01:34:15 -0800
> The convention for API functions in kernel is to return errno value;
> bond_open would return -1 if alb setup failed. The only reason that
> could happen is if kmalloc() failed.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/2] ixgbe: if ixgbe_copy_dcb_cfg is going to fail learn about it early
From: David Miller @ 2010-01-28 13:57 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, john.r.fastabend, peter.p.waskiewicz.jr
In-Reply-To: <20100128023805.19441.23796.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 27 Jan 2010 18:38:06 -0800
> From: John Fastabend <john.r.fastabend@intel.com>
>
> Call ixgbe_copy_dcb_cfg() earlier in the ixgbe_dcbnl_set_all() so that
> we can learn if this is going to fail as early as possible. Previously,
> ixgbe_down or ixgbe_close were being called before this check and the
> IXGBE_RESETTING bit was being set and cleared. Worse if this failed
> the corresponding ixgbe_up/ndo_open would not called.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> Acked-by: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] ixgbe: set the correct DCB bit for pg tx settings
From: David Miller @ 2010-01-28 13:56 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, john.r.fastabend, peter.p.waskiewicz.jr
In-Reply-To: <20100128023717.19441.27328.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 27 Jan 2010 18:37:44 -0800
> From: John Fastabend <john.r.fastabend@intel.com>
>
> Set the correct bit BIT_PG_TX when tx PG settings are set.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> Acked-by: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] igbvf: fix issue w/ mapped_as_page being left set after unmap
From: David Miller @ 2010-01-28 13:56 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20100128013012.18801.97398.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 27 Jan 2010 17:30:39 -0800
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change fixes an issue in igbvf with mapped_as_page being left set
> after a page is unmapped which results in buffers which are mapped via map
> single being unmapped as page.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sctp: IPsec rules are ineffective with ipv6
From: David Miller @ 2010-01-28 13:51 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, vladislav.yasevich, linux-sctp
In-Reply-To: <4B6049EB.8030803@dev.6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
Date: Wed, 27 Jan 2010 15:12:59 +0100
> xfrm_lookup() is missing in sctp_v6_xmit(), add it.
>
> Signed-off-by: Junwei Zhang <junwei.zhang@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Doing this every transmit packet is overkill.
Whatever calculates the route that ends up in skb_dst(skb)
should be making this xfrm_lookup() call, not here.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-01-27
From: David Miller @ 2010-01-28 13:43 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100127213511.GK2962@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 27 Jan 2010 16:35:12 -0500
> Dave,
>
> Here is another small collections of fixes intended for 2.6.33.
> Included are a NULL pointer dereference fix, a buffer leak fix,
> a warning fix, and a correction of an ath9k initialization change
> that was improperly limited to only dual-band hardware.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
^ permalink raw reply
* Re: CBQ broken in 2.6
From: Anton Ivanov @ 2010-01-28 13:34 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David Miller, netdev
In-Reply-To: <20100128125317.GA8931@ff.dom.local>
Hi Jarek,
The class was created as bounded and never changed. I do a full reload
of the hierarchy including a root qdisc delete via a script instead of
trying to adjust it.
It has 7 or so children and one sibling. It is parented to root.
I have recompiled sch_cbq.c with a number of printks in strategic
places. I have also added some debug output to tc. I have also rewritten
my test suite.
The results are as follows
Based on the printks cbq_set_lss and the cbq_change_class functions
correctly.
It indeed sets cl->borrow and cl->share to NULL as expected.
Based on results from the fixed test suite it also works as expected,
just with much lower precision than what I used to get from 2.6.9 and
2.6.18.
However, it still returns complete bonkers for stats.
Example (same class, I just moved the hierarchy around a bit trying to
get a better fix on this so it is now 1:15).
class cbq 1:15 parent 1: leaf 76: rate 5600Kbit (bounded) prio 1
Sent 10920592 bytes 14420 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
borrowed 8311 overactions 0 avgidle 78 undertime 0
It is bounded, but according to stats it has borrowed and has no
overactions.
If the stats are to be believed it is a bug somewhere which is eluding
me (and my test suite and printks are wrong somehow).
Alternatively, it may be a bug with the stats themselves which once
again I do not see in the actual sch_cbq.c file.
Brgds,
On Thu, 2010-01-28 at 12:53 +0000, Jarek Poplawski wrote:
> On 27-01-2010 13:28, Anton Ivanov wrote:
> > Thanks it is indeed sch_cbq.c,
> >
> > I have been going through the code in the meantime and found a place
> > where cl->tparent can be modified further down in the routine in
> > question. There is an invocation of cbq_set_lss() around the end of
> > cbq_change_class() which can do that.
> >
> > I am rebuilding the kernel for my CBQ box with a few printks at the
> > moment to see if it modified there or not.
> >
> > In any case here is the tell-tale symptom:
> >
> > class cbq 1:16 parent 1: leaf 76: rate 5600Kbit (bounded,isolated) prio
> > 2
> > Sent 162051 bytes 925 pkt (dropped 0, overlimits 0 requeues 0)
> > rate 0bit 0pps backlog 0b 0p requeues 0
> > borrowed 201 overactions 0 avgidle 78 undertime 0
> >
> > That is a bounded class. Its borrowed should be always 0 no matter what.
> > That is basically a broken CBQ implementation.
> >
> > An elementary network test suite shows the same result - it is being
> > allowed to borrow.
> >
> > I am happy to send the whole config if necessary if someone wants to
> > look at it.
>
> Was this class created as bounded or changed later? Did it have any
> child?
>
> Jarek P.
>
--
Understanding is a three-edged sword:
your side, their side, and the truth. --Kosh Naranek
A. R. Ivanov
E-mail: anton.ivanov@kot-begemot.co.uk
WWW: http://www.kot-begemot.co.uk/
^ permalink raw reply
* Re: CBQ broken in 2.6
From: Jarek Poplawski @ 2010-01-28 12:53 UTC (permalink / raw)
To: Anton Ivanov; +Cc: David Miller, netdev
In-Reply-To: <1264595308.29501.30.camel@tranquility.sigsegv.cx>
On 27-01-2010 13:28, Anton Ivanov wrote:
> Thanks it is indeed sch_cbq.c,
>
> I have been going through the code in the meantime and found a place
> where cl->tparent can be modified further down in the routine in
> question. There is an invocation of cbq_set_lss() around the end of
> cbq_change_class() which can do that.
>
> I am rebuilding the kernel for my CBQ box with a few printks at the
> moment to see if it modified there or not.
>
> In any case here is the tell-tale symptom:
>
> class cbq 1:16 parent 1: leaf 76: rate 5600Kbit (bounded,isolated) prio
> 2
> Sent 162051 bytes 925 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
> borrowed 201 overactions 0 avgidle 78 undertime 0
>
> That is a bounded class. Its borrowed should be always 0 no matter what.
> That is basically a broken CBQ implementation.
>
> An elementary network test suite shows the same result - it is being
> allowed to borrow.
>
> I am happy to send the whole config if necessary if someone wants to
> look at it.
Was this class created as bounded or changed later? Did it have any
child?
Jarek P.
^ permalink raw reply
* Re: PROBLEM: reproducible crash KVM+nf_conntrack all recent 2.6 kernels
From: Patrick McHardy @ 2010-01-28 12:19 UTC (permalink / raw)
To: Jon Masters; +Cc: linux-kernel, netdev, netfilter-devel
In-Reply-To: <1264658364.2793.105.camel@tonnant>
Jon Masters wrote:
> On Thu, 2010-01-28 at 00:46 -0500, Jon Masters wrote:
>
>> A number of people seem to have reported this crash in various forms,
>> but I have yet to see a solution, and can reproduce on 2.6.33-rc5 this
>> evening so I know it's still present in the latest upstream kernels too.
>> Userspace is Fedora 12, and this happens on both all recent F12 kernels
>> (sporadic in 2.6.31 until recently, solidly reproducible on 2.6.32) and
>> upstream 2.6.32, and 2.6.33-rc5 also - hard to find a "known good".
>
> Now I can capture the panic()s, I'm rebuilding the 2.6.33-rc5 kernel
> with some better debugging options to at least get some more data.
Could you try "ip6tables -t raw -I PREROUTING -j TRACE" after loading
the ip6t_LOG module? That way we can hopefully see the entire packet
paths through netfilter.
^ 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