Mark Tinguely wrote:
>
> It could be a memory problem. Could you also please apply an assert
> to pmap_enter_quick() + INVARIANTS. This is a quick test that checks
> all the other paths that call pmap_enter_quick() are locked out so
> that two processors cannot be using the PADDR1/PMAP1 at the sam
Kris Kennaway wrote:
>
> On Mon, Aug 18, 2003 at 11:40:09PM -0500, Alan L. Cox wrote:
> > Kris Kennaway wrote:
> > >
> > > I got this on alpha just now (kernel updated 2 days ago, filesystems
> > > created with -b 32768 -f 4096 to test reports of panics with
Kris Kennaway wrote:
>
> I got this on alpha just now (kernel updated 2 days ago, filesystems
> created with -b 32768 -f 4096 to test reports of panics with these
> settings, which may or may not be relevant). I don't think I've seen
> this trace before...apologies if it's another false positive.
Lukas Ertl wrote:
>
> On Wed, 6 Aug 2003, Alan L. Cox wrote:
>
> > If your i386 system has panic()ed in pmap_remove_all() recently, I would
> > encourage you to update your pmap.c.
>
> This is definitely good news! Thanks!
>
I've just realized that this cre
Kris Kennaway wrote:
>
> I don't think I've seen this i386 traceback before. Is it harmless as
> well?
>
Yes. In general, any LOR involving a system map mutex and a vm object
mutex that has a stack trace looking like
_mtx_lock_flags()
_vm_map_lock()
kmem_malloc()
page_alloc()
slab_zalloc()
um
If your i386 system has panic()ed in pmap_remove_all() recently, I would
encourage you to update your pmap.c.
Regards,
Alan--- Begin Message ---
alc 2003/08/06 11:46:48 PDT
FreeBSD src repository
Modified files:
sys/i386/i386pmap.c
Log:
Acquire the page queues lock i
Kris Kennaway wrote:
>
> On Thu, Jul 31, 2003 at 08:04:11PM -0700, Kris Kennaway wrote:
> > On Thu, Jul 31, 2003 at 01:48:42PM -0700, Kris Kennaway wrote:
> >
> > > > I upgraded the alpha package machines tonight, and one of them fell
> > > > over shortly after taking load, with the following:
> >
Bosko Milekic wrote:
>
> fakepg_zone should probably be UMA_ZONE_VM. Or the vm_object lock
> needs to be dropped before allocating or freeing to that zone.
>
> What does Alan think? (cc'd)
>
Perhaps. Regardless, in this case, the lock-order reversal is a false
positive. What it shows is t
Kris Kennaway wrote:
>
> On Wed, Jul 30, 2003 at 11:15:09PM -0500, Alan L. Cox wrote:
> > I believe that the attached commit addresses the "panic: sleeping thread
> > owns a mutex" problem reported by Kris and another related problem
> > reported a few days ea
I believe that the attached commit addresses the "panic: sleeping thread
owns a mutex" problem reported by Kris and another related problem
reported a few days earlier. The earlier problem report included the
following stack trace:
Sleeping on "objtrm" with the following non-sleepablelocks held:
David O'Brien wrote:
>
> On Mon, Jun 30, 2003 at 03:30:06PM -0500, Alan L. Cox wrote:
> > I've been able to reproduce what I believe is the problem. (In my case,
> > I reset my machine and watched the background fsck slowly grind to a
> > halt. Foreground
Peter Holm wrote:
>
> On Mon, Jun 30, 2003 at 03:26:13PM +0200, Eirik Oeverby wrote:
> > Hi,
> >
> > Good to see I'm not the only one.
> > I'm currently going back to a kernel dated 2003.06.27.12.00.00, and I'll test
> > again with that one.
> >
>
> Ok.
>
> I see that alc@ made some recent chang
Andrew Gallatin wrote:
>
> Alan L. Cox writes:
> > Thanks for letting me know. This is another false positive: Witness
> > can't distinguish the lock on the object being destroyed from the lock
> > on the object used by UMA because their labels are the same. They
Kris Kennaway wrote:
>
> CURRENT dated June 19;
>
> lock order reversal
> 1st 0xc45788ac vm object (vm object) @
> /a/asami/portbuild/i386/src-client/sys/vm/vm_object.c:1506
> 2nd 0xc082f110 system map (system map) @
> /a/asami/portbuild/i386/src-client/sys/vm/vm_kern.c:328
>
> Debugger(c03f
Kris Kennaway wrote:
>
> bento found the following about 5 minutes after I upgraded it to 5.0.
>
> acquiring duplicate lock of same type: "system map"
> 1st system map @ ../../../vm/vm_map.c:2168
> 2nd system map @ ../../../vm/vm_kern.c:325
Thanks for the stack trace. I've finally flagged the
Robert Watson wrote:
>
> On Sun, 8 Dec 2002, Alan L. Cox wrote:
>
> > Please remove ENABLE_VFS_IOOPT from your kernel configuration. This
> > code has never been safe for general use.
> >
> > Unfortunately, when it was documented in NOTES, this was fact was
Please remove ENABLE_VFS_IOOPT from your kernel configuration. This
code has never been safe for general use.
Unfortunately, when it was documented in NOTES, this was fact was
omitted.
Alan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the me
I've just committed a fix for this assertion failure.
Regards,
Alan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
David Wolfskill wrote:
> ...
> >In any case, the attached patch should resolve this.
>
> >Index: i386/i386/pmap.c
> >
>
> It did for me (too) -- thanks!
>
I've just committed the change.
Regards,
Alan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in t
Marc Recht wrote:
>
> Hi!
>
> After cvsup I got this:
>
> kernel: recursed on non-recursive lock (sleep mutex) vm page queue mutex @
> ../../../i386/i386/pmap.c:928
> kernel: first acquired @ ../../../vm/vm_map.c:2077
> kernel: panic: recurse
> kernel:
> kernel: syncing disks, buffers remaining.
Does your kernel include the following?
Revision 1.200 / (download) - annotate - [select for diffs], Sun Nov 17
09:33:00 2002 UTC (8 days, 21 hours ago) by jeff
Branch: MAIN
Changes since 1.199: +4 -4 lines
Diff to previous 1.199 (colored)
- Release the imgp vnode prior to freeing exec_map re
Marc Recht wrote:
>
> > Can you re-cvsup and update just to make sure everything is current?
> I did cvsup everything.
>
> > Every place that pmap_remove_all() is called appears to hold the page
> > queue mutex. The only exception is long-broken code that is compiled
> > under ENABLE_VFS_IOOPT.
Marc Recht wrote:
>
> Hi!
>
> I got this with the latest pmap.c
> Nov 23 17:43:07 leeloo kernel: panic: mutex vm page queue mutex not owned
> at ../../../i386/i386/pmap.c:1881
> Nov 23 17:43:07 leeloo kernel:
> Nov 23 17:43:07 leeloo kernel: syncing disks, buffers remaining... panic:
> bremfree:
This late-night commit might help:
jeff2002/11/17 01:33:00 PST
Modified files:
sys/kern kern_exec.c
Log:
- Release the imgp vnode prior to freeing exec_map resources to avoid
deadlock.
Revision ChangesPath
1.200 +4 -4 src/sys/kern/kern_exe
Hiten,
You're aborting on an assertion that no longer exists in vm_map.c. This
appears to be a case where your new kernel is based upon the new
vm_mmap.c but an old vm_map.c.
Please make sure that both vm_map.c and vm_mmap.c are updated and try a
"make clean" before building your kernel.
Regar
k Macy wrote:
>
> It turns that this problem is specific to AIO in
> -CURRENT. I wrote a simple program that uses
> the three different completion mechanisms (polling
> with aio_error, polling with kevent, and using SIGIO)
> to fill up a file by writing 8kb at a time to the
> file and then readin
26 matches
Mail list logo
