On Tue, Dec 17, 2002 at 05:06:06PM -0500, Brian F. Feldman wrote:
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
> > Whoop. Ok, here's a new patch. I think this covers all the cases.
> > I've done some testing and it appears to do the right thing, please
> > look it over (the last patch
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Whoop. Ok, here's a new patch. I think this covers all the cases.
> I've done some testing and it appears to do the right thing, please
> look it over (the last patch had type-o's and didn't cover the correct
> cases).
I haven't tested,
Whoop. Ok, here's a new patch. I think this covers all the cases.
I've done some testing and it appears to do the right thing, please
look it over (the last patch had type-o's and didn't cover the correct
cases).
-Matt
Index: kern/
oops, sorry, I blew that patch. exitingcnt would have to be incremented
unconditionally.
-Matt
Index: kern/kern_exit.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v
retrieving rev
Here's another go at a patch (untested).
-Matt
Index: kern/kern_exit.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v
retrieving revision 1.187
diff -u -r1.187 kern_exit.c
---
It's a big mess. exit1() sets up vm->vm_freer = p and then
vmspace_exitfree() tests that and calls vmspace_dofree(). It
looks like vm->vm_freer is acting like an exit-lock, so only
one process/thread actually frees the vmspace. But there are
still some serious race conditions
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> What about something like this. If the vm_refcnt is still being
> decremented too early, could it be moved to just before the thread_exit()
> call?
The problem that had to be fixed by removing this race was that two
processes with the same
Jake Burkholder <[EMAIL PROTECTED]> wrote:
> Apparently, On Sat, Dec 14, 2002 at 07:37:31PM -0500,
> Brian F. Feldman said words to the effect of;
>
> > John Baldwin <[EMAIL PROTECTED]> wrote:
> > >
> > > On 12-Dec-2002 Kris Kennaway wrote:
> > > > I got this on an alpha tonight. It was un
What about something like this. If the vm_refcnt is still being
decremented too early, could it be moved to just before the thread_exit()
call?
-Matt
Index: kern/kern_exit.c
=
:P_WEXIT is set, so the process won't get swapped out. The problem is that
:the vmspace refcnt is 0 when swapout_procs is called, since it was
:decremented in exit1. The refcnt is incremented before p_flag is tested
:for P_WEXIT, the swapout is skipped because its found to be set, and then
:vmsp
:The problem appears to be that swapout_procs() is swapping out a process
:that is in the process of exiting (in exit1()) and having already
:relinquished its vmspace, but has not set PRS_ZOMBIE yet (which would be
:preventing the swapout). It's clearly not correct for a process in exit1()
:t
Apparently, On Sat, Dec 14, 2002 at 07:37:31PM -0500,
Brian F. Feldman said words to the effect of;
> John Baldwin <[EMAIL PROTECTED]> wrote:
> >
> > On 12-Dec-2002 Kris Kennaway wrote:
> > > I got this on an alpha tonight. It was under heavy load at the time
> > > (18 simultaneous packa
John Baldwin <[EMAIL PROTECTED]> wrote:
>
> On 12-Dec-2002 Kris Kennaway wrote:
> > I got this on an alpha tonight. It was under heavy load at the time
> > (18 simultaneous package builds had just been spawned on the machine).
> > Any ideas?
> >
> > Slab at 0xfc00042d3fb8, freei 2 = 0.
> > p
Andrew Gallatin wrote:
> Ugh. Since it may call kmem_malloc(), UMA must hold Giant.
>
> This is the same problem the mbuf system has, and its what's
> keeping network device drivers under Giant in 5.0.
>
> Both subsytems should probably have GIANT_REQUIRED at all entry
> points so as to catch loc
Ugh. Since it may call kmem_malloc(), UMA must hold Giant.
This is the same problem the mbuf system has, and its what's
keeping network device drivers under Giant in 5.0.
Both subsytems should probably have GIANT_REQUIRED at all entry
points so as to catch locking problems like this earlier.
Dr
I think this is the same one I reported a few days ago (another alpha
under heavy load).
panic: mutex Giant not owned at /local0/src-client/sys/vm/vm_kern.c:312
db_print_backtrace() at db_print_backtrace+0x18
panic() at panic+0x104
_mtx_assert() at _mtx_assert+0xb4
kmem_malloc() at kmem_malloc+0x5
On 12-Dec-2002 Kris Kennaway wrote:
> I got this on an alpha tonight. It was under heavy load at the time
> (18 simultaneous package builds had just been spawned on the machine).
> Any ideas?
>
> Slab at 0xfc00042d3fb8, freei 2 = 0.
> panic: Duplicate free of item 0xfc00042d22e0 from zon
I got this on an alpha tonight. It was under heavy load at the time
(18 simultaneous package builds had just been spawned on the machine).
Any ideas?
Slab at 0xfc00042d3fb8, freei 2 = 0.
panic: Duplicate free of item 0xfc00042d22e0 from zone 0xfc0007d31800(VMSPACE)
db_print_backtrace
18 matches
Mail list logo
