On Sat, 25 Jan 1997, Markus Baeurle wrote:

> The ibuf overflows are gone now as expected but I have some silo overflows now.
Hopefully these should be occuring at a much lower rate. SILO overflows
are caused by interrupt latency problems. A number of these could be due
to the console code disabling interrupts for long periods during redraws
etc.
 
> I'm not sure about the floppy corruptions but they must have improved a lot at
> least. I copied two kernels to different floppies and both could be read back
> under RiscOS without problems. I'd never have managed that before but I won't
> say yet that this problem is gone now, I want to do more testing before.
> I still get some soft errors (re-enabled them in ...arm32/mainbus/fd.c): "fd0a:
> soft error reading [or writing] fsbn 864 of 864-867" and the like.
> What is a soft error anyway?

Interrupt latency again ;-) These occur when the driver does not keep up
with the interrupt rate from the floppy drive. I need to clarify whether
this is just IRQ latency or FIQ latency as well as the fd driver uses
FIQ's for the actual data transfer.

Currently SA110 kernels will suffer for more interrupt latency problems
than voyager kernels and will do so until I improve the SA110 cache
cleaning code (coming shortly).

> I also did some benchmarking of the harddisk performance with bonnie.
> It did not improve speedwise (still creeping around at 110-120 kB/s, but with a
> 10 MB file on an almost full disk) but the CPU usage has dropped from 90-99% to
> 4-5% for block and 15-16% for char accesses and 6% for seeking now that
> interrupts are working.
> I have not had any disk related problems (apart from the usual vnode corruption
> problem) although I did a lot of compiling (kernel and ghostscript 4.02) with
> this kernel.

This is nice to hear ;-)

> Very bad news at the end: There... erm... Something has changed about the
> printing problem. The kernel is now locking solid when I try to print.
> The flashing cursor goes steady, console switching, CTRL-Esc, nothing is
> working any more.
> With "cat newpatches > /dev/lpt0" the text was spooled to the printer before
> the machine hung, so it was printed OK.
> With "lpr newpatches" the printer was woken up (started to clean its nozzles as
> the Epson Stylus Color II does constantly) but didn't start to print. Odd.

As soon as I sort a few other things out I think I need a brainstorming
session on the lpt driver ;-)
 
> Thanks for the good work, this is a noticable improvement.

A happy user, thats what I like to see ;-))))

Hopefully some more goodies should be coming soon.

Cheers,
				Mark