Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
>
>> On Thursday 15 November 2007 21:43, Ingo Molnar wrote:
>>
>>> * David Miller <[EMAIL PROTECTED]> wrote:
>>>
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 17:37:13 -0600
>
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Thursday 15 November 2007 21:43, Ingo Molnar wrote:
> > * David Miller <[EMAIL PROTECTED]> wrote:
> > > From: Matt Mackall <[EMAIL PROTECTED]>
> > > Date: Wed, 14 Nov 2007 17:37:13 -0600
> > >
> > > > No, the usual strategy for debugging problems -out
On Thursday 15 November 2007 22:28, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Anyway, I'm really happy to see you're testing and using SLOB upstream
> >
> > :) Is there any particular reason that you're using it?
>
> i sometimes test SLOB for -rt, but this time it's the res
* David Miller <[EMAIL PROTECTED]> wrote:
> Yeah I wish udev would just leave the damn devices alone.
>
> It even does things like try to rename a network device to the same
> name it already has, and other strange stuff.
>
> But that log difference is a good clue.
>
> Because udev can try to
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 12:03:25 +0100
> now that it's reproducible again i'll try more direct debugging.
> (Networking might not even be the cause of this - that was just a quick
> first impression that i had.)
>
> Btw., the .config is the result of automat
On Thursday 15 November 2007 21:43, Ingo Molnar wrote:
> * David Miller <[EMAIL PROTECTED]> wrote:
> > From: Matt Mackall <[EMAIL PROTECTED]>
> > Date: Wed, 14 Nov 2007 17:37:13 -0600
> >
> > > No, the usual strategy for debugging problems -outside- SLOB is to
> > > switch to another allocator with
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 11:43:32 +0100
> The crash logs contain this:
>
> VFS: Mounted root (ext3 filesystem) readonly.
> Freeing unused kernel memory: 396k freed
> Write protecting the kernel read-only data: 2056k
> udev: renamed network interface eth1 to
* David Miller <[EMAIL PROTECTED]> wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 17:37:13 -0600
>
> > No, the usual strategy for debugging problems -outside- SLOB is to
> > switch to another allocator with more extensive debugging facilities.
>
> Ok, so the thing we s
On Wed, Nov 14, 2007 at 03:41:43PM -0800, David Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 17:37:13 -0600
>
> > No, the usual strategy for debugging problems -outside- SLOB is to
> > switch to another allocator with more extensive debugging facilities.
>
> Ok,
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 17:37:13 -0600
> No, the usual strategy for debugging problems -outside- SLOB is to
> switch to another allocator with more extensive debugging facilities.
Ok, so the thing we still can do is do a dump_stack() at the
list debugging ass
On Wed, Nov 14, 2007 at 03:10:13PM -0800, David Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 16:53:36 -0600
>
> > He hit the bug using SLOB and there are no kmem (or any other) caches
> > in SLOB.
>
> That's unfortunate, is there any user tracking facility at
>
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 16:53:36 -0600
> He hit the bug using SLOB and there are no kmem (or any other) caches
> in SLOB.
That's unfortunate, is there any user tracking facility at
all?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Wed, Nov 14, 2007 at 02:39:38PM -0800, David Miller wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 20:05:01 +0100
>
> > the bug went away - and the only thing i did was a networking config
> > tweak. So maybe something in networking corrupts memory?
>
> This wouldn't
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 20:05:01 +0100
> the bug went away - and the only thing i did was a networking config
> tweak. So maybe something in networking corrupts memory?
This wouldn't surprise me at all.
I think we can make some headway on this bug, the next
On Wed, Nov 14, 2007 at 08:05:01PM +0100, Ingo Molnar wrote:
>
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > > > [ 61.245190] rc.sysinit used greatest stack depth: 1680 bytes left
> > > > [ 61.386859] list_add corruption. prev->next should be next
> > > > (407d973c), but was 418cf818. (p
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> > > [ 61.245190] rc.sysinit used greatest stack depth: 1680 bytes left
> > > [ 61.386859] list_add corruption. prev->next should be next (407d973c),
> > > but was 418cf818. (prev=41877098).
> > > [ 61.396328] [ cut here ]
On Wed, Nov 14, 2007 at 11:36:11AM -0600, Matt Mackall wrote:
> On Wed, Nov 14, 2007 at 12:20:01PM +0100, Ingo Molnar wrote:
> >
> > there's a new SLOB regression - the attached config crashes with:
> >
> > [ 61.245190] rc.sysinit used greatest stack depth: 1680 bytes left
> > [ 61.386859] li
On Wed, Nov 14, 2007 at 12:20:01PM +0100, Ingo Molnar wrote:
>
> there's a new SLOB regression - the attached config crashes with:
>
> [ 61.245190] rc.sysinit used greatest stack depth: 1680 bytes left
> [ 61.386859] list_add corruption. prev->next should be next (407d973c), but
> was 418cf8
18 matches
Mail list logo
