>Hello everybody,
>
>yesterday, I updated my DS5000/200 from the 1.2 distribution to the march
>snapshot, using the kernel binary from the same directory.  Since then,
>I keep getting lots of messages like

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

>when doing disk-intensive things like unpacking tar files.  I cannot see any-
>thing that actually goes wrong, so I guess it's just something like a debug
>message...

Yes, these messages are harmless.  The SCSI driver corrects for this
condition.  You can safely ignore them.


>Another (minor) point that also nags me a bit on my Sun 3/60 with NetBSD is
>the output of the ping command:

zam965# ping zam331
PING zam331.zam.kfa-juelich.de (134.94.16.76): 56 data bytes
64 bytes from 134.94.16.76: icmp_seq=0 ttl=255 time=3.904 ms
64 bytes from 134.94.16.76: icmp_seq=1 ttl=255 time=0.003 ms
64 bytes from 134.94.16.76: icmp_seq=2 ttl=255 time=0.003 ms
64 bytes from 134.94.16.76: icmp_seq=3 ttl=255 time=0.005 ms
                                                    ^^^^^^^^
                                                    ||||||||

>5 Microseconds is far faster than a 10MBits Ethernet can transfer a 56 byte
>packet...

Yes, it is.  What's going on here is that the real-time clock ticks
256 times a second.  The kernel can't keep track of time at finer
granularity than that. The kernel also has to return
microsecond-granularity times with certain system calls. The way it
does this is to make sure the result of microtime() increases by at
least 1 usec between successive calls.

All the above output means is that there were three to five calls
to microtime() betweeen each packet; at least one of which was
probably  from the LANCE network driver itself.  This is entirely
normal.

On a 5000/2x or a 5000/240 you should see true microsecond granularity
times; those systems have microsecond-granularity clocks.  The 3100,
5000/200, and 5000/1xx don't. Sun workstations have relatively
high-resolution clocks, so you wouldn't see this effect there either.


>I know that using a snapshot might not necessarily lead to a stable system,
>but I only have a RZ55 as disk and getting a few megabytes of free disk space
>by installing shared libs was too tempting...

I try and make sure the snapshots are stable; I don't put one out
until I've run it for a few days.  The snapshot today was an
exception; it's just a re-link of the entire userland.