About the message like this.

	/netbsd: asc: DMA_OUT, fifo resid 16, len 2908, flags 0x32

I pointed out;

|| The debug messages REALLY hurt disk write performance.  Since around 1.2B
|| source code tree, the symptoms has been persisting.
 
Jonathan followed it;

|| I only just started seeing it.

And Michael also did;

|| I have been getting these messages on some RZ56 disks, but they haven't
|| been very frequent.  I may get a few when linking the kernel, and I also
|| see several when running elf2ecoff.

I think the debug message flood started since dev/tc/asc.c was
splitted into asc_ioasic.c and asc_tc.c for better NetBSD/{pmax,
alpha} code sharing.  I could not find out the functional differences
between before and after, though something seems to run differently
now.

Iozone benchmark revealed RZ25 write performance degregated to 50%,
whereas read performance was unaffected.  In the case of old Quantum
Pro80S, write performance was one third compared to one used to be.

Write slowdown can be seen easily with disk intensitive tasks; e.g.
making tar files, linking kernels, saving big text files with text
editors.

|| The message is left over from the time I was working on getting bugs out
|| of the asc driver relating to non-empty fifo conditions.  In this particular
|| instance, the fifo is full of data being sent to the disk, and I think the
|| disk has disconnected.

The DMA_IN_PROGRESS condition now happens more frequently than before.
Does it mean ASC.C runs faster than slow disks?  Seems more room for
improvement.

Tohru Nishimura
Nara Institute of Science and Technology