Date: Mon, 29 Sep 1997 10:41:43 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Peter Wemm <peter@netplex.com.au> Cc: Tor Egge <Tor.Egge@idi.ntnu.no>, freebsd-bugs@freebsd.org, dyson@freebsd.org Subject: Re: kern/4630: buffer_map might become corrupted Message-ID: <727.875522503@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 29 Sep 1997 16:05:18 %2B0800." <199709290805.QAA10988@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199709290805.QAA10988@spinner.netplex.com.au>, Peter Wemm writes: >Poul-Henning Kamp wrote: >> >> > This means that both vm_map_entry_dispose and vm_map_entry_create might >> > be called in an interrupt context, manipulating buffer_map and the free >> > pool of vm map entries. >> >> I think the problem here is calling brelse() at interrupt time, isn't it ? > >IMHO We _really_ need some low-cost assertions of assumptions that are on >by default but can be disabled via compile option perhaps.. Kinda like an >inverse of DIAGNOSTIC. yes. >BTW2; I wish there was an easy way of producing a stack trace automatically >on a panic or fatal trap, or as a diagnostic tool. Having a machine panic >and reboot is near for unattended machines. Having a stack trace in the >console log would be fantastic. :-) I looked at putting DDB output in the buffer and have DDB do a "trace" when it is entered, but it didn't prove much help. I can try to dig up the code... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?727.875522503>