Is this a known issue?  I have a sparc64 machine with 4GB of  
memory.  I first noticed this problem on my RAIDframe-hosted  
installation, but have now reinstalled onto a spare disk so I know  
it's not RAIDframe based.

   I made a 6GB swap, and am running a netbsd-4 GENERIC on the  
machine.  When I send a break to drop into ddb, then "reboot 0x104",  
I see:

db> reboot 0x104
Frame pointer is at 0xe0015611
Call traceback:
13bc030(1, d, 0, 1857000, e0016190, 0, e00156e1) fp = e00156e1
10b93a0(104, 0, 185ff94, 185fc00, 185ff88, 185ff64, e00157a1) fp =  
e00157a1
10b8e20(e0016248, 0, 1, e0016128, 72, 72000000, e0015871) fp = e0015871
10b9294(180ef88, 1483308, 0, 0, e0016338, 19, e00159c1) fp = e00159c1
10bc8bc(13c5fa8, 0, 1, 1008a9d1, e0016d8800, 0, e0015ab1) fp = e0015ab1
13c7324(0, 0, 0, 0, 1896000, 1000000, e0015b81) fp = e0015b81
13c4e18(101, e0016b00, 0, 0, e0016cb8, 18a0000, e00160e1) fp = e00160e1

dumping to dev 7,1 offset 4310231
dump 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096  
4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096  
4096 4096 4096 4096 4096 4096 4096 4096 4096 4096 4096

and the 4096's go on forever until I hard-power-off the machine.   
There's a pause after the "dump " at the start of the line, then the  
4096's go by pretty quickly, I doubt it's even trying to write to the  
disk.

   I booted a -current sparc64 GENERIC kernel (built from this  
morning's sources), as well, with the 4.0_RC1 userland still  
installed.  It seems to behave the same way.  That's where I'll start  
looking into it.  I just wanted to ask folks if this was a known  
problem, and if so, if anyone has put any work into fixing it.

   Thanks....

                                 - Chris