Date: Sun, 10 Nov 2002 11:10:34 +0000 From: Doug Rabson <dfr@nlsystems.com> To: "Alan L. Cox" <alc@imimic.com>, Jeff Roberson <jroberson@chesapeake.net> Cc: Matthew Jacob <mjacob@feral.com>, Andrew Gallatin <gallatin@cs.duke.edu>, alpha@FreeBSD.ORG, alc@FreeBSD.ORG, John Baldwin <jhb@FreeBSD.ORG> Subject: Re: alpha: top of tree kernel blooie Message-ID: <200211101110.34153.dfr@nlsystems.com> In-Reply-To: <3DCD7244.DEEA7387@imimic.com> References: <20021109150359.B97372-100000@mail.chesapeake.net> <3DCD7244.DEEA7387@imimic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 09 November 2002 8:38 pm, Alan L. Cox wrote: > Jeff Roberson wrote: > > On Fri, 8 Nov 2002, Matthew Jacob wrote: > > > > Can you 'ps aux -o wchan' ? > > > > > > I tried a buildworld -j4 again- this time it was too far hung to > > > let anyone log in... > > > > I ran into the vm_map_delete() duplicate free again. This has been > > the same code path too many times for it to be a non logic bug. > > > > Jeff > > I'm still wondering if this isn't a false positive: > > 1. My reading of the UMA debug code is that two or more processors > can simultaneously read and modify us_freelist[]. The only lock held > during an access is the CPU private lock. > > 2. Don't we compile by default for the older Alphas that lack byte > manipulation instructions? Thus, a byte store is implemented by a > read-modify-write sequence of instructions. Thus, two simultaneous > uma_dbg_alloc()s on adjacent locations in us_freelist could cause > corruption. It was exactly this kind of breakage that prompted me to write the=20 atomic_* functions in the first place. Note that it is often possible=20 to get corruption even on a UP machine if an interrupt happens mid=20 sequence. --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211101110.34153.dfr>