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?
> > > > > 
> > > > > 
> > > > 
> >