webber@csd.uwo.ca (Robert E. Webber) (11/10/90)
Am running on a MacPlus with 4 meg of ram and a hard disk and MacOS
6.0. The system was originally installed using the ``MACMINIX hard
disk guide'' posted by Pickert, which lived up to its title (10 Easy
Steps to MacMinix Hard Disk Happiness).
Poking around, I immediately noticed that in the grand tradition of
unix distributions, most of the file permissions were either more
restrictive than reasonable or less restrictive than reasonable.
Used find to change permissions and created some new users and groups.
Managed to core dump elle and noticed that the ROOT partition was rather
tight. Built new ROOT partition following `Initialize the Root File
System' instructions (except edited /etc/setup_root to mv $1 from ram
disk to /dev/hd0, since I am no longer using ram disk (as per 10 Easy
Steps ...). Was a bit nervous about this since version 7 mknod didn't
have a size parameter for block devices (considering the instructions
in 10 Easy ... I get the feeling that the size parameter doesn't really
have any effect anywhere -- anyone know for sure?). Now have nice big 5
meg root partition that can hold a core dump when necessary (which will
come back to haunt me later).
Noticed that I hadn't set the time on my Mac since the Fall time change.
Used date as root to change it. Date reported the new time. Logged out
and quit. Rebooted and found that the change had been forgotten. Sigh.
Another minor nuisance that got noticed is that the TTY0 and TTY1 windows
come up a pixel or two lower than one would want (so text on the bottom line
looses its descenders). Only fix I have found so far is to manually move
the windows with the mouse each time I reboot.
About this time, decided to rebuild minix from source. Started by
running make in /usr/kernel. Had problems with compiling idle.c, printer.c,
rs232.c, and console.c. Apparently the mac include files blow away the
preprocessor stage in cc. chmem'ing cc doesn't effect this. chmem'ing
/usr/lib/cpp doesn't fix this either if compiling with cc. However, it
does help if the sequence is:
/usr/lib/cpp -DACK idle.c >idle.i.c
cc -c -DACK -T. -c idle.i.c
rm idle.i.c
mv idle.i.o idle.o
for example. The header of the makefile says that CPP may need changing
to /usr/lib/cpp, but setting a CPP variable to /usr/lib/cpp didn't seem
to help (couldn't find any documentation on the compiler that would
indicate whether or not this should have worked). Ended up inserting
4 line sequences like the above directly in the Makefile.
Compiling the kernel (and other system files) occasionally kicks up
complaints about loss of accuracy in assigning pointers into ints.
Most of these seem to be ok, but couldn't convince myself that this
was the case for the one that occurs in case 6 of the function do_trace
in system.c of kernel directory. So, changed the definition of i to be
reg_t rather than int and then changed the casts to int that occur in
case 6 to casts to reg_t.
Another pointer to int cast occurs in fs/open.c in the function do_mknod.
I suspect this relates to the max file size limit, so just put in a test
to see if the cast was loosing any bits (and if it was to panic with an
error message).
Trying to do the make in tools raised problems with rmaker. Eventually
had to chmem it up to 300000. At this point I was rewarded with the
bomb icon. Spent a lot of wasted time trying to track this down because
%d doesn't work with longs, you have to use %ld (also printfs with %g in
them (and casts of the long to float as arguement) seem to never return).
16 bit ints with 32 bit pointers are definitely not part of the original
Version 7 look and feel.
Anyway, the problem with rmaker turns out to be that sbrk will return
odd addresses when it feels like it. However, when this result is passed
by from smalloc in smalloc.c (of /usr/src/commands/mac/rmaker) it gets
used sometimes as a pointer to an aligned structure. My fix was to
insert
p = p + 4 - (((long)p) % 4);
immediately after
p = sbrk(0);
in the smalloc routine.
With this everything seemed to build ok. By the way, a number of times
during makes, write errors occurred during the ld phase. Rerunning the
make would repeat the ld and succeed the second time. Not sure what is
causing this problem.
Finally built and ran my new kernel boot application. It blows up
complaining of not enought memory. Many trace messages later (forget
linpacks - the true measure of machine speed is how long a kernel
rebuild takes) it turns out that the problem is that configuration
changes don't get inherited in the new kernel. So increases in heap
size (which I upped to 1000k) and deactivating ram disk have to be
done each time a new boot application / kernel is created. This was
causing a blow up because my current ROOT is 5 meg which won't fit in
memory. The fix was to boot with an old copy of ROOT that would fit
and then fiddle with the configuration menu. Then back out and rename
the ROOT partition I wanted and reboot again.
Finally have my new kernel up and running with the source mods mentioned
above and some config.h changes (long line wrap around and immediate inode
write to disk options). Go into /usr/src/test directory, compile the tests
and run them. First 16 return ok. 17th and 18th report many screen fulls
of errors. 19th and 20th run ok. Get tired of waiting on 21 (last test)
to see if it is ok. Reboot with old boot application and run tests
again. They run ok until they get to the 13th test. The 13th test
seems to hang. Running elle in the other tty window, it freaks. Specifically,
the keybindings seem to alter so that control-s pushes a subshell; control-r
replaces strings; control-f skips forward words instead of characters;
control-n deletes words, etc.
This problem with elle I had seen before - back when I decided that the
ROOT partition was too small. At the time, I figured it had to do with
running on a disk that it didn't have room to write to. Now I am not
so sure. Elle is the editor I have been regularly using under MacMinix;
so far it has freaked like this on me twice. Of course, sans mmu, it
is hard to tell which process is the victim and which is the victor.
Incidently, running test17 in isolation under the original kernel produced
the same set of error messages as it did under my new kernel. Essentially
creat complains about wrong filedes returned (f0, f1, f2, thru f16). Then
creat says bad errno-value EACCES should have been EMFILE (I am willing to
take its word on this). The close complains about not being able to close
MAXOPEN files. Many more error messages follow from creat, link, open_alot,
pipe, fstat, stat, open, dup, unlink, and close, but I suspect these just
reflect whatever caused the earlier creat failures).
Any thoughts? Anyone else running MacMinix on a similar MacPlus
configuration? Anyone else rebuilt the kernel from the P-H distribution?
Anyone else run the /usr/src/test programs?
--- BOB (webber@csd.uwo.ca)archetyp@uxh.cso.uiuc.edu (Joseph R Pickert) (11/13/90)
webber@csd.uwo.ca (Robert E. Webber) writes: >Noticed that I hadn't set the time on my Mac since the Fall time change. >Used date as root to change it. Date reported the new time. Logged out >and quit. Rebooted and found that the change had been forgotten. MACMINIX gets its time from the system clock when it boots. From then on it keeps its own time, so you can set the time that MINIX thinks it is, but the next time you boot it reads the system time again. Set the macintosh system time with the control panel DA and then things will work the way (I assume) you want. >About this time, decided to rebuild minix from source. Started by >running make in /usr/kernel. Had problems with compiling idle.c, printer.c, >rs232.c, and console.c. Apparently the mac include files blow away the >preprocessor stage in cc. chmem'ing cc doesn't effect this. chmem'ing >/usr/lib/cpp doesn't fix this either if compiling with cc. /usr/lib/cpp is NOT USED by the compiler. It is there for the convience of other programs. cpp functionality is built into /usr/lib/cem, so that is the one you want to chmem. >Anyway, the problem with rmaker turns out to be that sbrk will return >odd addresses when it feels like it. However, when this result is passed >by from smalloc in smalloc.c (of /usr/src/commands/mac/rmaker) it gets >used sometimes as a pointer to an aligned structure. My fix was to >insert > p = p + 4 - (((long)p) % 4); >immediately after > p = sbrk(0); >in the smalloc routine. Sure enough this is a problem on a 68000 processor. 68020's can do longword accesses on a short boundry, but 68000's can't. >With this everything seemed to build ok. By the way, a number of times >during makes, write errors occurred during the ld phase. Rerunning the >make would repeat the ld and succeed the second time. Not sure what is >causing this problem. Somebody else has reported this problem to me. If anyone finds the problem please let me know.