>Hi I'v been compiling the kernel from ftp.kcl.ac.uk, but I want to get hold of
>the latest sources to be able to compile the StrongARM version etc. I beleave
>that I need to use sup but I don't know where I need to sup from or what I
>should ask for. Can someone tell me where, what and anything else I need.

Ok for starters install the sup set that can be found in any of the 1.1 or 1.2
distributions of RiscBSD.

In addition to transferring files et.c sup alos tracks the dates files were
updated so once you have supped everything you want sucessive sups will just
retrieve the changed files.

As to set up you can try reading ftp.netbsd.org:/pub/NetBSD/sup/README.sup
for more info on setting it up.

Alternative create a file (e.g. ./supfile) containing

current release=ksrc-common host=sup.NetBSD.ORG hostbase=/a/anon_ftp
base=/usr/sup/current prefix=/usr/sup/current backup use-rel-suffix delete

current release=ksrc-arm32 host=sup.NetBSD.ORG hostbase=/a/anon_ftp
base=/usr/sup/current prefix=/usr/sup/current backup use-rel-suffix delete

NOTE: Each of these lines should not be broken.

Then
mkdir -p /usr/sup/current

sup -v ./supfile


You can add extra lines to the supfile to sup different collections or releases
etc.
For example the release ksrc contains the full kernel source for all
architectures and the release all-src contains the full exportable netbsd
source tree. (See the file referred to above for a list of available
collections and releases).

>As a second question the other day when updating the sets to 1.2-beta the
>system started reporting the following.
>
>Oct 23 02:00:04 court4 /netbsd: ffs_update: bad indirect addr (1):
inode=122882
>4194304/00400000 ip=f1589200 adr=f15892b0
>Oct 23 02:00:04 court4 /netbsd: inode vp: type VBLK, usecount 640, writecount
>0, refcount 52,
>Oct 23 02:00:04 court4 /netbsd:         tag VT_UFS, ino 5924, on dev 16, 0
>
>This appears to be a disc related problem and when I subsequentially ran fsck
>each of the ino values appeared as a lost inode. It then took two runs of
>fsck to clear these - the first died half way through (reset button job).
>
>This happened with the atapi-4339 kernel. I have since compiled a new kernel
>(as above) and the problem has yet to repeat. Any help / advice ?

Ok this is a warning of a inode trash problem. There should have been a line
saying that it had patched the inode (this may not have been present in the
4339 kernel but is in more recent ones).

This is a bug very high on my fix it list. The indirect address of an inode can
get trashes with the value 0x00400000. All recent kernels that I have built
have a extra bit of code that catches this and attempts to fix the problem (It
will report a patched message if it does). Without the fix any inodes that are
trashes will be removed by fsck.
My suggestion would be to try a newer kernel so if the problem occurs again you
will not lose files.

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