Re: Another pmap related panic
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 same time. > Neither of Lukas's panics suggests that PADDR1/PMAP1 is being used. The faulting virtual addresses are fault virtual address = 0xbfca1974 and fault virtual address = 0xbfcadf10 which are within the PTmap, not PADDR1. In other words, pmap_pte_quick() concluded that the given pmap was currently active and therefore the pte was accessible through the mapping that each address space has to its own page table. Regards, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR with page queue mutex and vm object
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 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. > > > > > > > This is real. I'll look into it. > > Great, thanks. The machine is still in DDB if you need me to do > anything, otherwise I can dump it and obtain a gdb traceback. > The stack trace should suffice. Thanks, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR with page queue mutex and vm object
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. > This is real. I'll look into it. Thanks, Alan > > 1st 0xfc6e48d0 vm page queue mutex (vm page queue mutex) @ > /a/asami/portbuild/alpha/src-client/sys/vm/vm_pageout.c:405 > 2nd 0xfc0005102e00 vm object (vm object) @ > /a/asami/portbuild/alpha/src-client/sys/kern/vfs_bio.c:2280 > Stack backtrace: > db_print_backtrace() at db_print_backtrace+0x18 > backtrace() at backtrace+0x2c > witness_lock() at witness_lock+0x6fc > _mtx_lock_flags() at _mtx_lock_flags+0xc8 > vfs_setdirty() at vfs_setdirty+0x7c > bdwrite() at bdwrite+0x3b8 > ffs_update() at ffs_update+0x388 > ufs_inactive() at ufs_inactive+0x254 > ufs_vnoperate() at ufs_vnoperate+0x2c > vput() at vput+0x170 > vm_pageout_scan() at vm_pageout_scan+0x7ac > vm_pageout() at vm_pageout+0x3ac > fork_exit() at fork_exit+0x100 > exception_return() at exception_return > - > > >Part 1.2Type: application/pgp-signature ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Fwd: cvs commit: src/sys/i386/i386 pmap.c]
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 creates the potential for recursion on the page queues lock. I will fix that shortly. Regards, Alan > regards, > le > > -- > Lukas Ertl eMail: [EMAIL PROTECTED] > UNIX Systemadministrator Tel.: (+43 1) 4277-14073 > Vienna University Computer Center Fax.: (+43 1) 4277-9140 > University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR (vm_fault.c:286 and vm_kern.c:323)
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() uma_zone_slab() uma_zalloc_internal() uma_zfree_arg() ... is not a problem. Regards, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[Fwd: cvs commit: src/sys/i386/i386 pmap.c]
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 in pmap_insert_entry(). (I used to believe that the page's busy flag could be relied upon to synchronize access to the pv list. I don't any longer. See, for example, the call to pmap_insert_entry() from pmap_copy().) Revision ChangesPath 1.422 +2 -0 src/sys/i386/i386/pmap.c --- End Message --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000
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: > > > > > > > > panic: vm_fault: fault on nofault entry, addr: fe0007e8e000 > > > > > Two more panics on alpha: > > > > > > panic: vm_fault: fault on nofault entry, addr: fe0007fde000 > > > > > fatal kernel trap: > > > > > > trap entry = 0x2 (memory management fault) > > > > I'm also seeing a lot of random corruption going on on the alpha > > machines (these packages build successfully if I retry): > > Another one: > > panic: vm_fault: fault on nofault entry, addr: fe0007fbe000 > Debugger() at Debugger+0x38 > panic() at panic+0x168 > vm_fault() at vm_fault+0x1360 > trap() at trap+0x5c8 > XentMM() at XentMM+0x2c > --- memory management fault (from ipl 0) --- > bcopy() at bcopy+0x14 > copyout() at copyout+0x38 > uiomove() at uiomove+0x19c > pipe_read() at pipe_read+0x290 > dofileread() at dofileread+0x100 > read() at read+0x64 > syscall() at syscall+0x33c > XentSys() at XentSys+0x64 > --- syscall (3, FreeBSD ELF64, read) --- > --- user mode --- > Could you please do an objdump -d on sys_pipe.o (or similar) to verify that pipe_read+0x290 is the second call to uiomove() in pipe_read()? Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vm/map LOR
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 the locking of a user-level vm map, followed by vm_object #1, followed by the kmem_map. If this had proceeded to conclusion, you would have seen the locking of vm_object #2, the kmem_object. So, to witness this appears as a lock-order reversal. Unless vm_object #1 and vm_object #2 are the same, there is no possibility of deadlock. Witness is simply unable to distinguish the two vm objects because they have the same label. If they were given unique labels, witness would be overwhelmed because there are simply too many vm objects. Regards, Alan > > On Thu, Jul 31, 2003 at 04:46:06PM -0700, Lars Eggert wrote: > > Hi, > > > > with yesterday's -current: > > > > 1st 0xc6dfd094 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:434 > > 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:323 > > > > Stack backtrace: > > backtrace(c032000b,c082f110,c033362f,c033362f,c03334c6) at backtrace+0x17 > > witness_lock(c082f110,8,c03334c6,143,c082f0b0) at witness_lock+0x686 > > _mtx_lock_flags(c082f110,0,c03334c6,143,101) at _mtx_lock_flags+0xb5 > > _vm_map_lock(c082f0b0,c03334c6,143,c0374778,c03747a0) at _vm_map_lock+0x36 > > kmem_malloc(c082f0b0,1000,101,eb44db14,c02b0433) at kmem_malloc+0x3a > > page_alloc(c083a240,1000,eb44db07,101,0) at page_alloc+0x27 > > slab_zalloc(c083a240,101,c083a254,8,c0334e1e) at slab_zalloc+0xc2 > > uma_zone_slab(c083a240,101,c0334e1e,663,165) at uma_zone_slab+0xd9 > > uma_zalloc_internal(c083a240,0,101,6e7,0) at uma_zalloc_internal+0x4f > > uma_zfree_arg(c083a900,c6e31000,0,eb44dbc4,c029884d) at uma_zfree_arg+0x2a6 > > dev_pager_putfake(c6e31000,0,c0332b9e,be,c6dfd094) at dev_pager_putfake+0x35 > > dev_pager_dealloc(c6dfd094,1,c0334dcf,10c,0) at dev_pager_dealloc+0xb9 > > vm_pager_deallocate(c6dfd094,0,c0333f6c,261,1b2) at vm_pager_deallocate+0x3d > > vm_object_terminate(c6dfd094,0,c0333f6c,1b2,c6b894ec) at > > vm_object_terminate+0x1e5 > > vm_object_deallocate(c6dfd094,c082bd20,c6dfd094,c082bd20,eb44dca0) at > > vm_object_deallocate+0x35e > > vm_map_entry_delete(c6593e00,c082bd20,c033369d,897,c019f843) at > > vm_map_entry_delete+0x3c > > vm_map_delete(c6593e00,282e2000,282e3000,1000,282e2000) at > > vm_map_delete+0x3c3 > > vm_map_remove(c6593e00,282e2000,282e3000,0,c6b8a618) at vm_map_remove+0x55 > > munmap(c6ae24c0,eb44dd14,c0339293,3ee,2) at munmap+0x9e > > syscall(2f,2f,2f,f8000,1000) at syscall+0x260 > > Xint0x80_syscall() at Xint0x80_syscall+0x1d > > --- syscall (73), eip = 0x28257aa7, esp = 0xbfbffc1c, ebp = 0xbfbffc48 --- > > > > Lars > > -- > > Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute > > -- > Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] > TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Fwd: cvs commit: src/sys/kern sys_pipe.c]
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 earlier. The earlier problem report included the > > following stack trace: > > Great, thanks! > Be warned ... I believe that there is still another way for this error to come up in the pipe code. Let me know if it reoccurs. In general, I would encourage people to start filing problem reports for these sorts of things. Regards, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[Fwd: cvs commit: src/sys/kern sys_pipe.c]
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: exclusive sleep mutex system map r = 0 (0xf80067e92098) locked @ /usr/src/sys/vm/vm_map.c:2192 lock order reversal 1st 0xf80067e92098 system map (system map) @ /usr/src/sys/vm/vm_map.c:2192 2nd 0xc0354d70 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:312 Stack backtrace: _mtx_lock_flags() at _mtx_lock_flags+0xa0 msleep() at msleep+0x6a8 vm_object_pip_wait() at vm_object_pip_wait+0x48 vm_object_terminate() at vm_object_terminate+0x30 vm_object_deallocate() at vm_object_deallocate+0x374 vm_map_entry_delete() at vm_map_entry_delete+0x3c vm_map_delete() at vm_map_delete+0x32c vm_map_remove() at vm_map_remove+0x44 kmem_free() at kmem_free+0x20 pipe_free_kmem() at pipe_free_kmem+0x98 pipeclose() at pipeclose+0x124 pipe_close() at pipe_close+0x20 fdrop_locked() at fdrop_locked+0x134 fdrop() at fdrop+0x20 closef() at closef+0x1f8 close() at close+0x168 syscall() at syscall+0x2ac -- syscall (6, FreeBSD ELF64, close) %o7=0x10706c - Begin Message --- alc 2003/07/30 11:55:04 PDT FreeBSD src repository Modified files: sys/kern sys_pipe.c Log: The introduction of vm object locking has caused witness to reveal a long-standing mistake in the way a portion of a pipe's KVA is allocated. Specifically, kmem_alloc_pageable() is inappropriate for use in the "direct" case because it allows a preceding vm map entry and vm object to be extended to support the new KVA allocation. However, the direct case KVA allocation should not have a backing vm object. This is corrected by using kmem_alloc_nofault(). Submitted by: tegge (with the above explanation by me) Revision ChangesPath 1.140 +1 -1 src/sys/kern/sys_pipe.c --- End Message --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Disk/FS I/O issues in -CURRENT
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 fsck is fine.) > > > > The problem actually appears to be in vm_page_alloc(), not > > vm_pageout.c. Look for a commit to resolve this in a few hours. > > Has this been committed. I *so* ran into this yesterday (3 times) with a > 70gb /usr and a June 30th kernel. > Yes. Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Disk/FS I/O issues in -CURRENT
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 changes to the vm (vm_pageout.c). > I don't know if there's any connection to this problem? > 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 fsck is fine.) The problem actually appears to be in vm_page_alloc(), not vm_pageout.c. Look for a commit to resolve this in a few hours. Regards, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR in VM (with backtrace)
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 will > > never, however, be the same object. So, deadlock isn't a risk. > > In a closed source driver I maintain, I had to resort to passing a > string containing the meaningful name concatonated with some unique info > to mtx_init(). > > It seems like witness could just concat the address of the mutex along > with the strings passed to mtx_init() so as to make sure things were > unique.. > I'm not sure that witness could handle the 30,000 to 200,000 distinct mutex labels that would result from doing this for every vm object. Regards, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR in VM (with backtrace)
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(c03f450d,c082f110,c043190e,c043190e,c043178f) at Debugger+0x54 > witness_lock(c082f110,8,c043178f,148,d8ca79f8) at witness_lock+0x6ac > _mtx_lock_flags(c082f110,0,c043178f,148,c4496850) at _mtx_lock_flags+0xb1 > _vm_map_lock(c082f0b0,c043178f,148,c025dc34,246) at _vm_map_lock+0x36 > kmem_malloc(c082f0b0,1000,101,d8ca7a8c,c0390425) at kmem_malloc+0x65 > page_alloc(c083a240,1000,d8ca7a7f,101,c0457e2c) at page_alloc+0x27 > slab_zalloc(c083a240,101,c04332aa,66e,c414e5c4) at slab_zalloc+0x155 > uma_zone_slab(c083a240,101,c04332aa,66e,0) at uma_zone_slab+0xd8 > uma_zalloc_internal(c083a240,0,101,6ee,0) at uma_zalloc_internal+0x55 > uma_zfree_arg(c414e5a0,d7a86000,0,1,0) at uma_zfree_arg+0x2cc > swp_pager_meta_free(c45788ac,1d,0,1,0) at swp_pager_meta_free+0x1b2 > swap_pager_freespace(c45788ac,1d,0,1,0) at swap_pager_freespace+0x57 > vm_object_backing_scan(c4bec5c8,4,c0432299,5f7,c0432299) at > vm_object_backing_scan+0x28a > vm_object_collapse(c4bec5c8,0,c0432299,1ef,c45a0ec4) at vm_object_collapse+0x11a > vm_object_deallocate(c4fab940,c5093ce4,c4fab940,c5093ce4,d8ca7c60) at > vm_object_deallocate+0x28e > vm_map_entry_delete(c1506100,c5093ce4,c043197c,86d,c041ada4) at > vm_map_entry_delete+0x3b > vm_map_delete(c1506100,0,bfc0,c1506100,c4123f00) at vm_map_delete+0x413 > vm_map_remove(c1506100,0,bfc0,11d,65) at vm_map_remove+0x55 > exit1(c4496850,0,c041a26b,65,d8ca7d40) at exit1+0x63d > sys_exit(c4496850,d8ca7d10,c0437c26,3fd,1) at sys_exit+0x41 > syscall(2f,2f,2f,0,) at syscall+0x26e > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2829e9ff, esp = 0xbfbfde3c, ebp = > 0xbfbfde58 --- > 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 will never, however, be the same object. So, deadlock isn't a risk. I will probably disable witness checking on the "system map" mutexes (or at least the kmem_map's mutex) shortly so that folks don't become conditioned to ignoring these. Regards, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acquiring duplicate lock of same type: "system map"
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 system map mutex as duplicate ok, which it is. The commit was a few minutes ago. Regards, Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Repeatable panic from nautilus2
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 > > omitted. > > Is the attached diff appropriate, then? Yes, it is. I was just composing an e-mail to re@ about this. Thanks! > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Network Associates Laboratories > > Index: NOTES > === > RCS file: /data/fbsd-cvs/ncvs/src/sys/conf/NOTES,v > retrieving revision 1.1117 > diff -u -r1.1117 NOTES > --- NOTES 26 Nov 2002 17:32:39 - 1.1117 > +++ NOTES 9 Dec 2002 00:29:06 - > @@ -737,6 +737,9 @@ > # > # Enabling this will probably not give an overall speedup except for > # special workloads. > +# > +# WARNING: Do not enable this, it is known to be broken, and will result > +# in system instability, as well as possible data loss. > optionsENABLE_VFS_IOOPT > > # Cryptographically secure random number generator; /dev/[u]random To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Repeatable panic from nautilus2
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 message
Re: VM related panic during suspend/resume
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
Re: X11/panic after today's cvsup
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 the body of the message
Re: X11/panic after today's cvsup
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... panic: bremfree: bp 0xd359a250
> not locked
> kernel: Uptime: 6m15s
> kernel: pfs_vncache_unload(): 3 entries remaining
> kernel: Dumping 1535 MB
> kernel: ata0: resetting devices ..
>
> $FreeBSD: src/sys/vm/vm_map.c,v 1.273 2002/12/01 18:57:56 alc Exp $
> $FreeBSD: src/sys/i386/i386/pmap.c,v 1.375 2002/12/02 04:54:21 alc Exp $
>
> Regards,
>
> Marc
>
> "Premature optimization is the root of all evil." -- Donald E. Knuth
Can you say something more about how you produced this? Were you
shutting down your X server?
In any case, the attached patch should resolve this.
Regards,
Alan
Index: i386/i386/pmap.c
===
RCS file: /home/ncvs/src/sys/i386/i386/pmap.c,v
retrieving revision 1.375
diff -c -r1.375 pmap.c
*** i386/i386/pmap.c2 Dec 2002 04:54:21 - 1.375
--- i386/i386/pmap.c2 Dec 2002 18:50:39 -
***
*** 1213,1219
(pmap->pm_ptphint->pindex == ptepindex)) {
mpte = pmap->pm_ptphint;
} else {
! mpte = pmap_page_lookup(pmap->pm_pteobj, ptepindex);
pmap->pm_ptphint = mpte;
}
}
--- 1213,1221
(pmap->pm_ptphint->pindex == ptepindex)) {
mpte = pmap->pm_ptphint;
} else {
! while ((mpte = vm_page_lookup(pmap->pm_pteobj, ptepindex)) !=
NULL &&
! vm_page_sleep_if_busy(mpte, FALSE, "pulook"))
! vm_page_lock_queues();
pmap->pm_ptphint = mpte;
}
}
Re: More info on blocked procs with make -j3 buildworld
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 resources to avoid deadlock. Kris Kennaway reported that this resolved a similar problem for him last week. Regards, Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in latest pmap.c
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. > ENABLE_VFS_IOOPT (vfs.ioopt=1) was the problem. Turning it off fixed it. > ENABLE_VFS_IOOPT and vfs.ioopt were long ago disabled due to bugs. To the best of my knowledge, these bugs have never been resolved. Unfortunately, it appears that the documentation in NOTES doesn't mention this. Regards, Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in latest pmap.c
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: bp 0xd359d584 not locked > Nov 23 17:43:07 leeloo kernel: Uptime: 9m10s > Nov 23 17:43:07 leeloo kernel: pfs_vncache_unload(): 2 entries remaining > > * $FreeBSD: src/sys/i386/i386/pmap.c,v 1.371 2002/11/23 04:48:13 alc Exp $ > > Regards, > Marc Can you re-cvsup and update just to make sure everything is current? 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. Regards, Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Processes hanging in thrd_sleep
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_exec.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mutex Giant problems in latest -current
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. Regards, Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT AIO bug Re: How well does EVFILT_AIO work?
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 reading 8kb at a time from the file. > I believe that I've fixed this problem. Please update to revision 1.112 of kern/vfs_aio.c and retry your tests. Best regards, Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
