Howdy all,

Well, it seems my DAT problems have been solved (or will be solved once the
new stuff is stable :). Using a rather recent kernel (many thanks to
Michael Hitch, who was so friendly to provide one), my system got along
just fine past the SCSI detection phase (and recognised the DAT drive as a
tape device and even mentioned it's density code (0x13?)), so I'm quite
confident the new SCSI stuff will work OK.

BTW, these newer kernels do look a lot more 'professional' than the old
ones. All those ztwobus, zthreebus, etc messages look pretty impressive.
;-) But, do they have any relevance to underlying changes/mechanisms? :)

I did have another problem; I got a message sounding something like:

warning: nsectors (820 ) != nheads (10) * sectorspertrack (83)

After that it also printed something about dostypes being depreciated and
suggested other values (I guess that's because my partitions are still
marked with the BSD? dostypes), printed a "could not find root" and
subsequently paniced and went into the boot-monitor. In there I typed
c(ontinue). It then rebooted, which I suppose is meant to happen. I could
spot something like "dumping ..." before the screen went black, but I'm not
sure; the screen blanks too fast for me to read it.

Since I found the "nsectors != whatever" message always a bit scary and
because something looking like this also popped up under all previous
kernels when I mounted the mfs /tmp filesystem, I set forth to fix this
message (hoping it would fix the panic).

The tool I ended up using, after some experimentation (with little luck)
with HDToolBox, was RDPrep. For those interested, I'll describe the
procedure:

**** If you try this, you do this on your own risk. It worked for me, but
it won't necessary work for you. I.e., if you nuke your HD, data, whatever
I'm not responsible. (Phew! :) ****

Start up RDPrep, choose your harddrive if necessary, click "Read RDB", then
click "Save Mountfile" and choose a destination. Anything should do,
although a Rescue-type floppy would be rather handy. Also, don't forget to
put RDPrep on this floppy, together with some other DiskRepair-type
programs. (Just in case...)

After that, click RDPrep to the back (or exit it), and make a safety copy
of the file you just wrote (probably called "000.list"). Next, edit a copy
of the file "000.list", which is just a plain textfile, with your favourite
text-editor. In my case, I changed the value for BlocksPerTrack from 83 to
82 and then saved it. (The 820 number is what all prep-like programs seemed
to use; it's the 10*83=830!=820 number that produced the warnings and
errors. Probably a fluke of HDToolBox(?)).

Next, restart RDPrep if necessary, click "Load Mountfile" to load the
mountfile you've just modified into RDPrep. Next, check (in the other
RDPrep screens) everything is still allright _VERY_ carefully (Are
partitions the right size? Are the BlockPerTrack/Cylinder values OK? Etc,
etc.), and when you're convinced everything looks 100% okey-dokey, click
"Save RDB" to write it to your HD.

Next, reboot and keep your fingers crossed. If all comes up just fine,
you're all set and your troubles (and warnings from NetBSD) should be over.
If the system doesn't come up; scream, get the earlier made emergency
floppy, boot from floppy (a workbench floppy will do), start up RDPrep,
reload your original MountFile (you did keep a copy, didn't you?), and
write that one back to your HD. After a reboot all should be fine again and
you can retry the procedure (if you dare :).

Anyhow, after I fixed this, the new kernel continued just fine and
presented me with a single user prompt. Typing "ls -l" and some other
trivial (static) programs still worked OK (excluding of course ps and
friends). However, after mounting /usr, I tried some shared binaries but
then I got "could not map ld.so" or something to that effect and, of
course, these programs didn't work. I guess my binaries are too old.

What should I do now? The kernel looks pretty stable (is it Michael? :),
but I definately need new binaries... What I'm also wondering about is, how
do I do that? What should I build first? A new ld.so? Something else? Any
hints and/or tips would be appreciated.

And, what would 'supping' gain me over getting the .tar.gz snapshots from a
sun-lamp mirror?

While I'm on the question-asking tour, what is the status of the memory
management changes that were suggested quite a while ago? I have the
feeling NetBSD-Amiga is still far from usable in 4megs of RAM (and I mean
this with regard to console-only stuff). Even with 8megs (which I have) I
find memory still rather tight. Of course, I should just plunk in another
8megs and be done with it, but I find that a rather silly solution. :)

Also, I can remember the '040 support consisted of setting up a complete
level-[123] (?) page-table of about 60KB for every process started. Is this
still the case? If so, that would explain why I have so little memory left
after booting into multi-user mode. (I have 8 meg, but it leaves me,
according to vmstat, with about 300/400KB of free memory. Of course stuff
gets swapped out after a while.) Are there any plans to fix this? Is it
even fixable or is it a 'feature'?

After trying Linux/68k a while back, I couldn't help notice that their
console is much (MUCH) faster than NetBSD-Amiga's console, due to which it,
on the whole, just 'feels' (a lot) faster than NetBSD-Amiga. Is there any
chance the NetBSD-Amiga console could get any faster? Also, Linux/68k has
support for some neat (AGA?) modes (720x400@70Hz NI, 640x400@76Hz NI, etc).
Could the implementation of these be of any help to NetBSD-Amiga?

Well, that's it for now.

Regards,

Patrick.

------------------------------------------------------------------------------