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 proc
On 03/09/2015 13:10, "Eric Dumazet" wrote:
>On Thu, 2015-09-03 at 10:09 +, Shaun Crampton wrote:
>> >...
>> >> Is there anything I can do on a running system to help figure this
>>out?
>> >> Some sort of kernel equivalent to pmap to find
>...
>> 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 fro
>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 me
> 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 re
>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
> 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 major
