Subject: Re: New kernels and DAT drive and other things
To: Patrick Vervoorn <vervoorn@dutiws.TWI.TUDelft.NL>
From: None <email@example.com>
Date: 05/25/1994 10:34:35
> 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
> 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
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
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...