Hi,
I'd appreciate if you could CC me on any responses.
I'm trying to push a veth into a namespace and then give it an IP address
and a default route. The procedure that I have works fine at low scale,
but once I have ~100 veths on a moderately-loaded system, I start seeing
1s delays before
On 03/09/2015 13:10, "Eric Dumazet" <eric.duma...@gmail.com> wrote:
>On Thu, 2015-09-03 at 10:09 +0000, Shaun Crampton wrote:
>> >...
>> >> Is there anything I can do on a running system to help figure this
>>out?
>> >> Some sort of ker
>Looking at this one, I am still puzzeled where 0xa008772b and
>0xa008772b comes from ... some driver, bridge ...?
Is there anything I can do on a running system to help figure this out?
Some sort of kernel equivalent to pmap to find out what module or device
owns that chunk of
>...
>> Is there anything I can do on a running system to help figure this out?
>> Some sort of kernel equivalent to pmap to find out what module or device
>> owns that chunk of memory?
>
>Hmm, perhaps /proc/kallsyms could point to something. 0xa0087d81
>and 0xa008772b could be
> Make sure you backported commit
> 10e2eb878f3ca07ac2f05fa5ca5e6c4c9174a27a
> ("udp: fix dst races with multicast early demux")
I just tried the latest CoreOS alpha, which had that patch. Sadly, I saw
just as many reboots. Here's a sample of the different types of Oopses I
see (I've put the
And the kernel thinks it's
outside of any normal text section, so it does not try to dump any
code from before the instruction pointer.
0: 48 8b 88 40 03 00 00mov0x340(%rax),%rcx
7: e8 1d dd dd ff callq 0xff29
c: 5d pop%rbp
d:
Take a look at linkwatch_urgent_event at net/core/link_watch.c, and all
of
link_watch.c in general. That's where the 1s delay comes from.
Thanks for the diagnosis, I¹ll take a look.
-Shaun
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
