> 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.
> 
	Ya, I had to add an entry to st.c for my C= 3070 CALIPER tape, always
	burps out illegal request when you first do an open but otherwise
	it works, no more read errors when untaring the 90M sup tree from
	work! Now, all we have to do is retrofit the rest of the Amiga
	port to all the changes in VM and core files in the past day or
	two. B^(. pmap_bootstrap_alloc() needs to be written in pmap.c
	and vm_machdep.c needs a cpu_swapin() and new core file format
	changes; sigh. And OF COURSE cdg is incommunicado for a few weeks;eeek!

> 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? :)
> 
	Yes, once you understand the profound meaning of the messages the
	new config system is mearly confusing as opposed to completly
	incomprehencable... B^).

> I did have another problem; I got a message sounding something like:
> warning: nsectors (820 ) != nheads (10) * sectorspertrack (83)
> 
	This is the result of a bad assumption in disksubr.c, for the
	line that sets lp->secpercyl you need to assign rdb->secpercyl to
	it rather than nheads * nsecpertrk. I hope to send Chris fixes
	later today. I REALLY messed up my NetBSD setup last night/this
	morning with the May 23rd sup; B^(...

> 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.
> 
	The new partition types are NB?\? where the first ? is R for root,
	S for swap and U for BSD FFS filesystems. The second ? is 7 for root
	and user, 1 for swap.

	I also added a few lines to adosglue.h and disksubr.c to recognise
	AMIX's UNI\? partitions so it will shut the fork() up if you have some.

	I also sprinkled some \n's around in various places so the output
	looks better.

	I have the ql and le drivers going for the new configure method although
	ql is unavailable as it uses AMIX proprietary 6502 code and the le
	driver can't get all the ethernet board's serial number, something in
	the config code seems to be truncating the serno field to 16 bits even
	though both structure members involved ints; bizzare.

	file.amiga.newconf also needed a ": ether ifnet" added after the le
	so the ether and ifnet kernel modules would be pulled in and attached
	to le. Some other minor tweeks were needed for le as well.

	See below for horrors from the May 23rd sup.

> 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).
> 
	It will but you might have seriously messed up your drive by dinking
	with the rdb. HDToolBox KNOWS what the fork() it's doing. There is
	a REASON why your drive told it there were fewer sectors per cyl
	that nheads * nsecpertrk would seem to indicate. They are called
	slip or spare sectors. The imbedded SCSI disk controller uses them to
	optimize sector reallocation when a sector goes bad on a track.

	The CORRECT solution is to fix the code in disksubr.c like I outlined
	above. The rdb should NEVER be messed with once these parameters are
	sucked off the drive by HDToolBox with a SCSI inquiry command.

> 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.

	Actually, they are just beginning! B^). No floppy driver, no ethernet
	driver. Slip appears not to work right and you'll probably have to
	add a tape unit type to sys/scsi/st.c. If you have the May 23rd sup,
	looks like the same stuff applys to the May 25th as well, you'll have
	all of the below to deal with; whew! I'm still running off the May 19th
	sup as pmap_bootstrap_alloc() and cpu_swapin() are puzzling me.

	1: amiga/mem.c - machine/pmap.h and vm/vm_prot.h includes have to
			 be swapped as pmap.h needs #define's in vm_prot.h
	2: amiga/pmap.c - 3 functions have to be explicitely declared void
			  to match new prototypes in /usr/include. You also
			  need to craft a pmap_bootstrap_alloc() functions,
			  the one shamelessly stolen from the hp300 port no
			  workee. B^(.
	3: amiga/vm_machdep.c - Need a cpu_swapin(stuct proc *) function but
			  no real definition of what the function should do
			  other than automagic related to an arch when a
			  program is paged back in at a different address.
	4: amiga/trap.c - 040 fans will pull there hair out. The nice clean
			  defines in m68k/frame.h were shamelessly renamed
			  to more cryptic values, in the TRUE BSD spirit of
			  obfusication, for the hell of it. B^(. Need to
			  print out the old headers and the new to compare
			  values and change. About 45 minutes of being pissed
			  off... Non-040 people have to do this as the 040
			  code is breezed over by 030/020 machines... B^(.

	 There are other annoyances but those are left as an exercise to
	 the kernel hacker... B^).


> 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.
> 
	Nope, alot of new binarys won't work either due to the mmap()
	syscall moving and sysctl() being put in it's place. The new
	X distribution is a victem of this. B^(. However, I have other
	things to worry about, like creating a kernel that won't panic...

> What should I do now? The kernel looks pretty stable (is it Michael? :),
	
	About as stable as nitro in an 8.x earthquake... Superkicked 3000
	owners also have the wonderful feature that in most cases you'll have
	to power cycle the machine after all reboots as the ROM image goes away 
	and the NetBSD panic, KDB and lockup scenerios don't restore it.
	Probably means some of the 3000's "More magic" bits aren't being
	twiggled correctly. The good news is that the reboot command will
	sometimes work although most of the time the kernel panic's with
	a message having to do with VM maps being whacked out and of course
	since it panic'd rather than running the reboot() function you
	lost your ROM image again... This probably doesn't effect the
	2.04 ROM systems as they don't store the ROM image in RAM exclusively.
		
	Well, enough gloom and doom for now. This stuff won't get fixed unless
	we all do the fixin'... Off I go...

		-Rob

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