Updating src tree:
P src/external/cddl/osnet/dist/lib/libdtrace/common/dt_module.c
P src/share/man/man9/module.9
P src/share/man/man9/pci.9
P src/sys/arch/evbarm/conf/RPI
P src/sys/arch/sparc/sparc/autoconf.c
P src/sys/arch/sparc/sparc/db_disasm.c
P src/sys/arch/sparc/sparc/db_interface.c
P
Date:Sun, 04 Oct 2015 18:03:26 +0700
From:Robert Elz
Message-ID: <10734.1443956...@andromeda.noi.kre.to>
| Paul's problem is with the image file (the core) - or more likely, with
| gdb (since crash(8) works).
Ignore me (aside from the part
On Sun, 4 Oct 2015, Robert Elz wrote:
Date:Sun, 4 Oct 2015 17:25:21 +0800 (PHT)
From:Paul Goyette
Message-ID:
| I'm pretty much convinced that the p_nstopchild accounting is screwed up
|
Updating src tree:
P src/libexec/lfs_cleanerd/lfs_cleanerd.c
P src/sbin/fsck_lfs/extern.h
P src/sbin/fsck_lfs/fsck.h
P src/sbin/fsck_lfs/lfs.c
P src/sbin/fsck_lfs/pass1.c
P src/sbin/fsck_lfs/pass6.c
P src/sbin/fsck_lfs/segwrite.c
P src/sbin/fsck_lfs/setup.c
P src/sys/dev/pci/pci_subr.c
P
I'm pretty much convinced that the p_nstopchild accounting is screwed up
somewhere. I'm planning on adding the following code in "optimization"
in kern_exit so I can catch it as soon as it happens.
Basically, if the optimization would cause us to stop looking for a
process to report, this
Date:Sun, 4 Oct 2015 10:26:10 +0300
From:Andreas Gustafsson
Message-ID: <22032.54418.500901.577...@guava.gson.org>
| Paul Goyette wrote:
| > In attempts to debug another problem (see the thread about "killing
| > zombies"), I've twice forced
Date:Sun, 4 Oct 2015 17:25:21 +0800 (PHT)
From:Paul Goyette
Message-ID:
| I'm pretty much convinced that the p_nstopchild accounting is screwed up
| somewhere.
I think I agree.
|
On Sun, 4 Oct 2015, Paul Goyette wrote:
| 1. Is it correct for init's p_nstopchild to be zero when it has several
| children whose p_state is SSTOP?
Depends whether those children have previously been waited for or not.
Stopped children don't go away when they're waited for, so there
On Sun, 4 Oct 2015, Andreas Gustafsson wrote:
Paul Goyette wrote:
In attempts to debug another problem (see the thread about "killing
zombies"), I've twice forced crash dumps from ddb. Once with the 'sync'
command, and once with 'reboot 0x104'.
[...]
Yet, gdb fails to process these files:
Paul Goyette wrote:
> In attempts to debug another problem (see the thread about "killing
> zombies"), I've twice forced crash dumps from ddb. Once with the 'sync'
> command, and once with 'reboot 0x104'.
[...]
> Yet, gdb fails to process these files:
PR 48915?
--
Andreas Gustafsson,
Date:Sun, 4 Oct 2015 20:52:43 +0800 (PHT)
From:Paul Goyette
Message-ID:
| I do occassionally switch to another wsdisplay screen (away from the X
| one), but not frequently. I
On Wed 30 Sep 2015 at 10:29:16 -0400, Greg Troxel wrote:
> Basically yes. Howver, you may want to do a final update of the tree
> From sourceforge and verify you have no uncommitted changes that you
> want to keep. (If so, you will have to manage them manually.)
which currently gives errors
12 matches
Mail list logo