Ken Wellsch <kwellsch@tampabay.rr.com> writes:

> Writing with putc()...^C^C^C^C^C^C^C^Z^Z^Z^Z^Z^Z^Z^\^\^\  (no affect)
> load: 6.38  cmd: bonnie 314 [uvn_fp1] 15.94u 7.80s 0% 296k
> load: 6.43  cmd: bonnie 314 [uvn_fp1] 15.93u 7.81s 0% 296k
> [...]
> with every new ^T I type, the load climbs...
> [...]
> system responds to pings also but that is about it.

This might be related to a problem I see from time to time recently (I
think it was introduced at the same time as (and thus might be related
to) the unified buffer cache, but of course I can't know that).

I get the same situation when I do something that writes to disk a lot
(trying to run a 'cvs update' on the NetBSD sources will do it), and
it looks just like the above, except that the state reported by ^T is
"[getnewbuf]".  The machine responds to ping, as Ken says, and if I go
to the console and hit CR, I'll get the newline echoed, but no login
prompt.  Hitting CR again does nothing.

After the reboot, fsck will typically have a lot of work to do -- if
'cvs update' was running, it'll typically report reams of "inode says
NNN blocks; should be 0", and sure enough, I'll have lots of size zero
files in the source tree.  Waiting a long time does not cause anything
to be properly flushed to disk, so I'm thinking along the lines of
something causing buffers not to be written, and then the system
simply runs out of memory when the in-core buffer cache has acquired
all core memory there is.

I've seen this with NetBSD-current on Sparc and Intel.

-tih
-- 
The basic difference is this: hackers build things, crackers break them.