Hey- Chuck, Chuck.... Look into it when you can! I think what you're doing is
great and NetBSD is *definitely* going in the right direction with the UBC
stuff. There is no 'priority' with this at all. But a freezeup in NetBSD where
neither Solaris nor Linux do so (and, yes, with both I ran myself out of room
on a local filesystem with the saem stress test) is something to remember
"really should fix". That's all....

On Mon, 5 Feb 2001, Chuck Silvers wrote:

> I think you're exaggerating a bit, matt.  a problem that only shows up
> in DEBUG kernels in a pre-release, development version of an OS, and
> there only in certain relatively obscure cases (since you're the first
> person to report this as being a problem, after all) with an easy workaround
> doesn't seem that to be that big of a deal.  even at that, the reason
> I'm not going to look at the problem immediately is that I'm going
> to be working on worse problems that more people are seeing, such
> as the bit where things seem to "freeze up" that you mentioned also.
> I think that I've got the right priorities here.
> 
> but then again, I shouldn't be the only person who can work on this.
> would anyone else like to figure out why this printf is being triggered?
> 
> (or is this just a misunderstanding?  the bit that I was saying was
> further down the priority list was the printf being triggered, which
> is what I thought you were asking about.  the performance problems
> are what I'm about to start looking into next.)
> 
> -Chuck
> 
> 
> On Sun, Feb 04, 2001 at 12:19:53PM -0800, Matthew Jacob wrote:
> > 
> > Actually, a clue on this was that I ran myself out of space on /. But instead
> > of getting "no space" I got these.
> > 
> > Hey- I haven't had this bother me for a while- I avoided the problem
> > again. But I'd really put it on your list not as something that you *have* to
> > have dbench to trigger (which, after all, doesn't do anything all *that*
> > clever)- but something to keep in mind as to how NetBSD just simply fails
> > to meet some simple goals for a server.
> > 
> > On Sun, 4 Feb 2001, Chuck Silvers wrote:
> > 
> > > well, the printf is already under ifdef DEBUG, I'm not sure what more
> > > I can do right away without just removing it.  I don't want to remove it
> > > since it's still useful if people are seeing it.
> > > 
> > > if it's causing you problems I'd recommend removing it in your local tree.
> > > I will look at what dbench does to trigger it, but there a lot of problems
> > > right now and I'm swamped just trying to get caught up from my time away
> > > in india.
> > > 
> > > -Chuck
> > > 
> > > 
> > > On Sun, Feb 04, 2001 at 11:34:56AM -0800, Matthew Jacob wrote:
> > > > 
> > > > It made the system so unresponsive that I had to power cycle it.
> > > > 
> > > > 
> > > > On Sun, 4 Feb 2001, Chuck Silvers wrote:
> > > > 
> > > > > that's a debug printf, complaining that we're trying to flush pages after EOF.
> > > > > nothing bad, just silly.  I should give dbench a try and see where we're
> > > > > going wrong.  that'll be quite a way down the todo list, though.
> > > > > 
> > > > > -Chuck
> > > > > 
> > > > > 
> > > > > On Sat, Jan 27, 2001 at 12:46:08PM -0800, Matthew Jacob wrote:
> > > > > > 
> > > > > > I'm running a neat little stress tester (dbench- quite useful for stressing a
> > > > > > system: ftp://samba.org/pub/tridge/dbench) on top of tree NetBSD on an
> > > > > > alpha....
> > > > > > 
> > > > > > A dbench 128 on a 128MB memory PC164 runs it out of memory pretty quick...
> > > > > > things sort of freeze up, but continue along... what's more alarming is this-
> > > > > > I'm getting continuous streams of these now:
> > > > > > 
> > > > > > uvn_flush: oor vp 0xfffffc000206e550 start 0x0 stop 0x8000 size 0x0
> > > > > > 
> > > > > > with various stop addressses and vnode pointers....
> > > > > > 
> > > > > > Was is das?
> > > > > > 
> > > > > > 
> > > > > 
> > > 
>