hmm what baud rate are you running at ?

>Btw, I also compiled the mtools 3.0. Will you provide it as a set or should I
>prepare it? I would first have to sort out how to make sets though.
>I have a file which names all the files to be included, one per line. But how
>do I tell pax to put them into an archive. Or is it sufficient to use tar?

I have the binaries built but don't know when I will get them turned into a
set.
tar is ok. I have a few scripts I used to build a set from directory containing
various files describing a set. e.g. and mtree file, set file, filelist or
script to generate file list. One day I will try to neaten these up and put
them on line.

>I noticed something which is much worse: Printing still fails! I have reported
>that some time ago and also provided a trace, maybe you remember. It still
>fails in the same way.

I have not forgotten about that, I just have not had time to fix it yet.

>I also had a crash when I called ls (it's colour-ls):
>Permission error status 00f, address = 0724, pc=f00af454

Hmm ok I am not surprise that this address faulted (even in the kernel)
as it is a write to a zero page location.
As to the cause .... pass, looking at ufs_ihashget there is not obvious cause
that I can see. The only thing that comes to mind is if there was a fault on
the file system with the fs marked as clean so fsck was not being run to fix
it.

>The patch archive found on the ftp server is quite outdated now. I compiled a
>new archive by removing those patches which are no longer needed and by
>updating those patches where the file to be patched has changed so that the
>patch had to be applied by hand.
>I'm not sure about the sd.c patch for optical devices because something which
>comes after the inserted code in the patch is now before it. It's the hunk
with
>a comment something like "Keep in mind its an optical device, we need it
>later". Maybe you can check if I did everything the right way.

Yep the patch code is out of date and I should remove it.

The current compilcation is that there are a number of diffs between
the current kernel source tree and the supped source tree etc. I had hoped that
by now we would be back to supping current.
Also it is a pain having to maintain extra patches. Hopefully a lot of the
patches I current have will be merged before long e.g ATAPI.
Currently there is no simple solution to the csc.o problem. My current view
is well I cannot keep it completely up to date all the time (ok I know I have
not updated it for a real long time, but then I need to track updates for 1.2
and current).

If people find having to pull a object version of the csc driver annoying then
feel free to complain to cumana about there NDA policy. Note: All other SCSI
cards currently supported (Acorn, Oak, Powertex, Connect32) do not have this
problem. Why cumana should be so concerned when there are other cards available
that use DMA etc. (Although atm we do not even use that) I don't know.

>I also prepared a new csc-patch archive which contains the current csc.o and
>not the outdated one.
If you want to put it online I will move it to the patch directory.


I hope to start a major new effort on RiscBSD before the end of the month.
In the last couple of months I have not been able to spend much time on RiscBSD
due to work (I now keep a sleeping bag in my office).

Some of my goals before AW96 are

Revamp WWW site.
Clean up ftp site.
Get all remaining kernel changes merged
Get final 1.2 release out
Get complete StrongARM support running (mulituser mode)
Set up sup server
Set up cron jobs to build ftp & sup kernel source trees from kernel teams cvs
repository automatically.
Fix outstanding repeatable kernel bugs.
Replace installation script with new binary installer.

Plus several otherthings the be unveiled at a later date.

Cheers,
				Mark

-- 
Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716