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 out what module or
>>device
>> >> owns that chunk of
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 out what module or device
> >> owns that chunk of memory?
> >
> >Hmm, perhaps /proc/kallsyms could point t
>...
>> 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
On 09/03/2015 10:13 AM, 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 out what module or device
owns that chunk of memory?
Hmm, perhaps /proc/kallsyms could point to something. 0xa0087d81
>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
On 09/02/2015 06:39 PM, Shaun Crampton wrote:
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 differ
> 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
On Thu, Aug 27, 2015 at 9:40 AM, David Miller wrote:
> From: Michael Marineau
> Date: Thu, 27 Aug 2015 09:16:06 -0700
>
>> On Thu, Aug 27, 2015 at 6:00 AM, Eric Dumazet wrote:
>>> Make sure you backported commit
>>> 10e2eb878f3ca07ac2f05fa5ca5e6c4c9174a27a
>>> ("udp: fix dst races with multicast
From: Michael Marineau
Date: Thu, 27 Aug 2015 09:16:06 -0700
> On Thu, Aug 27, 2015 at 6:00 AM, Eric Dumazet wrote:
>> Make sure you backported commit
>> 10e2eb878f3ca07ac2f05fa5ca5e6c4c9174a27a
>> ("udp: fix dst races with multicast early demux")
>
> Oh, interesting. Looks like that patch didn
On Thu, 2015-08-27 at 09:16 -0700, Michael Marineau wrote:
>
> Oh, interesting. Looks like that patch didn't get CC'd to stable
> though, is there a reason for that or just oversight?
We never CC stable for networking patches.
David Miller prefers to take care of this himself.
( this is in Doc
On Thu, Aug 27, 2015 at 9:30 AM, Eric Dumazet wrote:
> On Thu, 2015-08-27 at 09:16 -0700, Michael Marineau wrote:
>
>>
>> Oh, interesting. Looks like that patch didn't get CC'd to stable
>> though, is there a reason for that or just oversight?
>
> We never CC stable for networking patches.
>
> Dav
On Thu, Aug 27, 2015 at 6:00 AM, Eric Dumazet wrote:
> On Wed, 2015-08-26 at 13:54 -0700, Michael Marineau wrote:
>> On Wed, Aug 26, 2015 at 4:49 AM, Chuck Ebbert wrote:
>> > On Wed, 26 Aug 2015 08:46:59 +
>> > Shaun Crampton wrote:
>> >
>> >> Testing our app at scale on Google¹s GCE, runnin
On Wed, 2015-08-26 at 13:54 -0700, Michael Marineau wrote:
> On Wed, Aug 26, 2015 at 4:49 AM, Chuck Ebbert wrote:
> > On Wed, 26 Aug 2015 08:46:59 +
> > Shaun Crampton wrote:
> >
> >> Testing our app at scale on Google¹s GCE, running ~1000 CoreOS hosts: over
> >> approximately 1 hour, I see a
On Wed, Aug 26, 2015 at 4:49 AM, Chuck Ebbert wrote:
> On Wed, 26 Aug 2015 08:46:59 +
> Shaun Crampton wrote:
>
>> Testing our app at scale on Google¹s GCE, running ~1000 CoreOS hosts: over
>> approximately 1 hour, I see about 1 in 50 hosts hit one of the Oopses
>> below and then reboot (I¹m
>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
On Wed, 26 Aug 2015 08:46:59 +
Shaun Crampton wrote:
> Testing our app at scale on Google¹s GCE, running ~1000 CoreOS hosts: over
> approximately 1 hour, I see about 1 in 50 hosts hit one of the Oopses
> below and then reboot (I¹m not sure if the different oopses are related to
> each other).
16 matches
Mail list logo
