Date: Sun, 22 Aug 1999 21:45:03 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alan Cox <alc@cs.rice.edu>, Luoqi Chen <luoqi@watermarkgroup.com>, freebsd-smp@FreeBSD.ORG Subject: cripes, found it (was Re: Weird infinite lockup in splx()) Message-ID: <199908230445.VAA01758@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
Cripes. I think it's a tight loop between two or more high priority
system processes.
Here's what is going on:
kmem_alloc_wait() locks a vm_map, tries to find space, and if it
fails it unlocks the map and then tsleep's on the map.
What happens when you have two processes doing this? You would think
it would be ok.
But it isn't. Because the very first field of the vm_map structure
is a lock structure.
The locking functions are using the *SAME* wait address as the
kmem_alloc_wait and kmem_free_wakeup code!
Since we can get the locks just fine, if you have more then one process
in this section of code the N processes rotate between each other due to
the vm_map_unlock() calls waking up the tsleep() in the other process's
kmem_alloc_wait.
!!!!
Oops. Ok, but how to fix? I am going to try to simply switch the first
two fields in the vm_map structure so the lock does not sleep on the
same address as kmem_alloc_wait. I believe this will fix the problem.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908230445.VAA01758>