Ok, finally. I compiled DDB into the kernel and had to wait
3 weeks until I finally got one of those random console lockups
(the console suddenly locks up and nothing is written out and no
input is accepted, but otherwise the machine seems to function ok,
because my network connection is ok).

I tried to make some sense out of the output of the "trace" command,
but I didn't find anything searching through the kernel sources.
I must add I'm really not an experienced kernel hacker :)

Ok, so here's the traceback:

[usuall stuff like _Debugger, upto _lev2intr(?), and then:]
_mi_switch(1,17,0,1c79f28,788)+1a
_tsleep(4ebc40,11a,77fae,0,2004)+144
_ttysleep(4ebc00,4ebc40,11a,7ffae,0)+20
_ttwrite(4ebc00,1c79f28,1,d03,788)+24a
_itewrite(d03,1c79f28,1)+36
_spec_write(1c79ed8,1c79eec,2ca84,1c79ed8,0)+a2
_ufsspec_write(1c79ed8)+28
_vn_write(5435c0,1c79e28,53c00)+ca
_write(512500,1c79f88,1c79f80)+a4
_syscall(4)+10a
_trap0()+e

That's all. All that I can see out of this is that it hangs
in some terminal output routine (yeah, I knew that before :-).
So can anyone here make any sense out of this? There must be
some change that was made somewhere around late June/early July,
becuase that's when the trouble started. So, were there any
important changes in the above routines at this time?
(I don't know where I could get back-issues of source-changes).

Please help!

TIA,
	Blaz

P.S.: This is an Amiga 2000 with IVS Vector/68030 running
a current kernel arround July 6th.

P.P.S: I'm crossposting this to current-users because the
above output seems to suggest that the trouble is in some
non-machine-specific part of the kernel.

-- 
  Blaz Zupan, Ljubljanska 19/b, 62000 Maribor, Slovenia
        blaz.zupan@uni-mb.si, blaz@boing.jump.org