Hi,

I'm having some problems with NetBSD on an Amiga 4000/040 + GVP Series II,
so I'm hoping some of you know how to figure them out All of it worked
quite well (no problems) before I started experimenting..

First of all, does the ld.so, as distributed in the last binary
distribution (the one dated with 0219), contain the patches for using it on
the '040?

After installing that version and copying the right libs to the /usr/lib
dir I get loads of trapsignals, and nothing using shared libraries works
anymore. This looks very much like the problems I had several months ago,
which turned out to be due to the then current ld.so not flushing the
caches on the '040 when it should. Either Markus Wild or Michael Hitch
should know the details for fixing.

The ld.so that (still) works for me (but NOT with the newer versions of the
shared libraries and, consequently, NOT with the new binaries. Why's that?)
is the one I once got from Markus Wild. When running new binaries with the
old ld.so, they just seem to 'hang', eating loads of CPU time. No
trapsignals, they just 'hang' indefinately. Running them with trace report
something like "could not bind address". Then trace and the traced command
just silently quit.

Secondly, the latest generic kernel (dated 940226) doesn't seem to work in
PAL hires mode (640x256@50Hz). After I do

binpatch -s _ite_default_height -r 256 vmunix.940226

all I get is a strange coloured screen (some sort of purplish pinkish
darkish kind of colour). NTSC Hires (640x200@60Hz) works without problems,
and so does PAL Hires Laced (640x512). Strange indeed.

Thirdly, the binpatch-array util as it can be found on ftp.eunet.ch doesn't
work quite 100% on my system. It prints out the right values contained in
binpatchable locations, but when I use the -r option to actually replace
values it doesn't do anything it all. All values remain the same. I have no
idea what causes this. Some kind of '040 + 3.0 problem?

The NetBSD executable of the same binpatch prints out pure bogus values
when I even try to look at the values contained in binpatchable locations
(very large numbers mostly, when the location should contain a 1 or a 0).

Fourth, what is my current option on getting the latest kernel sources? I
don't know what this so-called "sup"-ing that everybody's talking about
lately is, but I don't think it would be feasable (or even possible) for me
to do it (if I ever figure it out :). What would I need for this and how
much room do I need on the UNIX machine I do it with?

Isn't there just a .tar file I can grab from somewhere (sun-lamp?) that
contains a (pretty) current, compilable kernel-source? (ie, without loads
of warnings, umpteen misplaced files and stuff like that).

It looks like ftp.eunet.ch:/pub/NetBSD-Amiga isn't quite the main
NetBSD-Amiga site anymore, but I could be wrong.

Well, that should be enough questions for now. :)

However, to add some positive notes :) to my message, several things have
become better. Reboot now cleanly reboots my A4000/040 into AmigaOS. This,
combined with the new ps reporting real CPU usage percentages is enough
reason for me to keep using the latest kernel (in NTSC Hires; 640x218).

Regards,

Patrick.

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