> In any case, this should not be a fatal condition,
	> and you can probably work around it by disablinng
	> the streaming cache entirely or using only COHERENT
	> mappings.
	> 
	> Altought, looking at the code:
	> 

	There are also:

		if (!is->is_sb)
			return (0);

Obviously if it prints out that message then the streaming
cache is enabled.

		is->is_flush = 0;

This is where it resets the bit that the IOMMU sets when
the flush completes.

	> #ifdef DIAGNOSTIC
	> 	if (!is->is_flush) {
	> 		printf("iommu_strbuf_flush: flush timeout %p at %p\n",
	> 		    (void *)(u_long)is->is_flush, 
	> 		    (void *)(u_long)is->is_flushpa); /* panic? */
	> 

	and another one:
			Debugger();

	So I'd expect this code to fire up debugger right after it gets there
	after streaming buffer gets enabled. And this happen after a while.
	I havn't find yet a place where that buffer is enabled.

This happens in the bus controller attach routine, specifically 
`sbus_attach()' in your case.

	I'll try to continue from ddb and see what happens.

	> if is->is_flush really is 0x100000000, either the code generation
	> is broken, or the value was set between the test and the printf ()
	> call.  Maybe you should just increase the timeout a bit.

	I can compile without optimization, it helped me before with 
	code generation. Don't understand yet that 'timeout' magic. 

Hm.  It should work.  is_flush is volatile.  Could be D$
coherency issues.  Try adding a call to `blast_vcache()' just
before the test of `is->is_flush' to see if it fixes the problem
(this is DIAGNOSTIC code, after all.)

Eduardo