figuei@max.sunysb.edu (Francisco Figueirido) (02/26/90)
I just finished the upgrade from 1.1 to 1.5.0 on my 1040ST (not
without problems, but the posted patches helped a lot). With the
patches to the directories stuff in the library more works fine,
but ls did still have problems with empty directories. I fixed this
in a rather trivial way: there is a function add_dir that reads the
directory entries and add them to a table. In the original posting
it returns void, but I changed it to return the number of actual
entries added and then check (I forgot which routine calls it, but
it is rather easy to find out since it is called from only one
place) its return value. If it is zero, skip the sorting of the
entries. I don't know whether this introduces any other problems ...
I still have some problems with the following commands:
(1) kermit compiles fine but gets a signal 10 and dumps core (it
used to get signal 4 but after I changed the time stuff in
ckutio.c to use asctime as V7 the signal number changed).
(2) has anyone managed to use rz,sz? I will welcome any comments.
(3) nroff gets signal 11 and dumps core.
(4) de ... problems too numerous to mention!
(5) cron seems to conflict with update, at least if I run update
BEFORE cron!
Any help will be greaty appreciated!
Francisco Figueirido
e-mail: figuei@max.sunysb.edumeulenbr@cstw68.prl.philips.nl (Frans Meulenbroeks) (02/27/90)
In article <1990Feb25.200833.21461@max.sunysb.edu> figuei@max.sunysb.edu (Francisco Figueirido) writes: You can apply all of the PC 1.5.3 command patches. Almost all of the commands then work (including ls) > I still have some problems with the following commands: >(1) kermit compiles fine but gets a signal 10 and dumps core (it > used to get signal 4 but after I changed the time stuff in > ckutio.c to use asctime as V7 the signal number changed). maybe you'll have to do a chmem to some larger value. >(2) has anyone managed to use rz,sz? I will welcome any comments. login on the remote system; start sz remote. locally say "rz </dev/tty1 >/dev/tty1" >(3) nroff gets signal 11 and dumps core. there is a call of time with argument 0 instead of (time_t *)0 will be fixed. >(4) de ... problems too numerous to mention! Even after the 1.5.3 upgrade?? If so I'd like to hear from you. >(5) cron seems to conflict with update, at least if I run update > BEFORE cron! Can you be more specific? I always run update before cron but I never saw a problem. Also try the 1.5.3 cron Frans Meulenbroeks (meulenbr@cst.philips.nl) Centre for Software Technology ( or try: ...!mcsun!phigate!prle!cst!meulenbr)
stailey@iris613.gsfc.nasa.gov (Ken Stailey) (02/28/90)
In article <1147@prles2.prl.philips.nl> meulenbr@cst.prl.philips.nl (Frans Meulenbroeks) writes: >In article <1990Feb25.200833.21461@max.sunysb.edu> figuei@max.sunysb.edu (Francisco Figueirido) writes: > >You can apply all of the PC 1.5.3 command patches. >Almost all of the commands then work (including ls) > >> I still have some problems with the following commands: >>(4) de ... problems too numerous to mention! >Even after the 1.5.3 upgrade?? If so I'd like to hear from you. 'tis true I can compile it and not much more. I would like to see either "ctrace" or a version of "mdb" that really works. But I will put debugging stuff in myself to find where is core dumps. INET stailey@iris613.gsfc.nasa.gov UUCP {backbone}!dftsrv!iris613!stailey
stailey@iris613.gsfc.nasa.gov (Ken Stailey) (02/28/90)
In article <1021@dftsrv.gsfc.nasa.gov> stailey@iris613.UUCP (Ken Stailey) writes: >> >>> I still have some problems with the following commands: >>>(4) de ... problems too numerous to mention! >>Even after the 1.5.3 upgrade?? If so I'd like to hear from you. >'tis true I can compile it and not much more. I would like to see >either "ctrace" or a version of "mdb" that really works. But I will >put debugging stuff in myself to find where it core dumps. > I just got it to work. I had to cast all the NULLs in "Init_Termcap()" into pointers to charaters and chmem it to be 40000. There may still be other problem spots but it comes up. Now I just have to learn how to use it 8-{) INET stailey@iris613.gsfc.nasa.gov UUCP {backbone}!dftsrv!iris613!stailey
figuei@max.sunysb.edu (Francisco Figueirido) (03/01/90)
First of all thanks very much to the people who answered my posting! I was a fool and didn't realize that I had to redirect both stdin AND stdout for rz, sz to work! I managed to compile de (with 1.5.0 sources). The problems I had to solve were the following: 1. When running cg on de.c I got a weird message, something like "Error: cannot find table entry for 45". I figured it was an error in the function Error and when I looked up its definition I found it was expecting three arguments but it was mostly called with one or two. What I did was a kludge: redefine it to accept as first argument the number of extra parameters passed. This solved the compiling problem. 2. In de_stdout.c there were calls to major() and minor() (I guessed to get the major and minor device numbers of a special file) but there were nowhere to be found. I wrote my own macros (something like #define major(dev) (((dev)>>MAJOR)&0377) after a hint in <minix/const.h>). 3. The rest of the problems were trivial: some include files were in the fs sources. After these patches I managed to compile and run de (I tried it only for reading on a write-protected floppy, of course). One comment: the source is pretty much based on the PC keyboard (the help command mentions PgUp and PgDown keys, and other weirdos ...). Has someone gotten the trouble of rewriting it for the atari (I know this is not a priority, but ...)? I will try to post soon more details about my weird cron problem, and to use the 1.5.3 sources also! Finally some questions: does anybody know whether minix (1.5.0 or later) will run on a ST with an accelerator board installed (like the Fast-16)? And also about GCC: I have the a GCC cross-compiler on the campus SGI and got the libraries for 1.36 and when I found out that the 16 bit libraries seem fine but when I use the 32 bit stuff (i.e., without the -mshort flag) I get a bus or segmentation violation fault. Anybody knows what happens? Thanks again! Francisco Figueirido e-mail: figuei@max.sunysb.edu
meulenbr@cstw68.prl.philips.nl (Frans Meulenbroeks) (03/01/90)
[heavily trimmed] In article <1990Feb28.165418.9954@max.sunysb.edu> figuei@max.sunysb.edu (Francisco Figueirido) writes: >1. When running cg on de.c I got a weird message, something like >"Error: cannot find table entry for 45". I figured it was an error I found this error too. It has to do with a nested switch where the inner switch uses the same label as the outer switch. I could not make a small example of this. If anyone can, I'd like to have a copy. Since I do not have the code of cg I could not fix it. Therefore I rewrote that section of the code. The fixes are in the 1.5.3 commands. [...] >2. In de_stdout.c there were calls to major() and minor() (I guessed >to get the major and minor device numbers of a special file) but there [...] fixed in 1.5.3. The definitions are: #define major(x) ( (x>>8) & 0377) #define minor(x) (x & 0377) >3. The rest of the problems were trivial: some include files were in >the fs sources. [...] >source is pretty much based on the PC keyboard (the help command >mentions PgUp and PgDown keys, and other weirdos ...). Has someone >gotten the trouble of rewriting it for the atari (I know this is not >a priority, but ...)? If someone does, please send me a copy. The PGUp and Down keys map to the arrow keys. Forgot which one. experiment.... [...] > Finally some questions: does anybody know whether minix (1.5.0 or >later) will run on a ST with an accelerator board installed (like I see no reason why it won't. But of course until someone donates such a board to me I cannot test or support it. In the past I played with an 68020 in my ST. Minix ST almost works with an 68020. You'll have to come up with a new bootstrap loader, and you might need to change some of the assembly files which deals with exception frames and so on. Not that difficult. [...] Please note that the 1.5.0 commands contain a lot of problems Between 1.5.0 and 1.5.3 I tried all of the commands (maybe not with all options), and I found a lot of problems which I reported to ast, and which are all fixed in 1.5.3. It is a very good idea to upgrade to 1.5.3 if it is alone for the commands. Regards, Frans Meulenbroeks (meulenbr@cst.philips.nl) Centre for Software Technology ( or try: ...!mcsun!phigate!prle!cst!meulenbr)
figuei@max.sunysb.edu (Francisco Figueirido) (03/03/90)
In article 1294 Frank Breure writes: > Some of the problems I have: > 1. "more" still crashes after the first window > > 2. "sh" crashes everytime I'm using regular expressions (like "ls -l *.c") > it gets signal 11 (SIGSEGV). > > 3. "mkdir" doesn't work, > it complains: "<directory>: cannot create" > even if your are the owner of the current the directory > and have "rwx" permissions to it. > > These are the major problems, I have not been testing all commands yet, but > these are the most important ones. > There were patches for the directory routines posted on the net which, at least in my case, solved the problems with "more". The problem with the shell could be actually in "ls", which as was posted had many bugs. Some of them were fixed with the patches to the direc- tory routines (some files in /usr/src/lib/other, but I don't remember now which ones). I found that it still had problems with empty direc- tories but that is easy to fix (surely 1.5.3 already fixed it?). I also had the problem with "mkdir". I think the point is that only root can create or destroy directory i-nodes, so both should be owned by root and have the setuid bit (do a chmod u+s mkdir rmdir). But be careful because there is a little bug: you can rmdir any directory even without write permission (rmdir should check the real uid but it seems it doesn't). Hope this helps! Francisco Figueirido e-mail: figuei@max.sunysb.edu BITNET: figueiri@sunysbnp
figuei@max.sunysb.edu (Francisco Figueirido) (03/06/90)
In article 1304 Jwahar Bammi writes (concerning writing directly to /dev/mem) > Not a good idea. Incorporating the screen mods into your present > kernel is fairly trivial (the origonal posting from eric smith gave > the diffs against the normal St kernel). I agree with this. What I would like is that the screen driver become part of the standard distribution of minix for the ST. As far as I see now there are two distributions (maybe more?): 1.5.3 (although I haven't seen kernel diff's posted yet) and the gnukernel. I would like to know whether they are going to merge in the future or we have to choose which path to follow. Personally I would like to have some of the drivers in the gnukernel (midi, screen, faster rs232) incorporated into the standard distribution, but I am sure the people involved have given much more thought to this than myself so I would appreciate any clarification to this point. Another thing: I compiled the commands for 1.5.3 and there were only three problems, which I haven't seen mentioned on the net: login.c didn't patch (the .cdif was far larger than the original!), mkdir and rmdir didn't work (they are owned by root and setuid). I noticed that the new sources were much smaller than the older ones. I tried ps but it complained that it couldn't read some kernel tables (I was root). Is this because it only works with the 1.5.3 kernel? If so I will wait till Frans Meulenbreoks posts the new diff's. As always, thanks for your replies. Francisco Figueirido
stailey@iris613.gsfc.nasa.gov (Ken Stailey) (03/06/90)
In article <1990Mar6.012337.20707@max.sunysb.edu> figuei@max.sunysb.edu (Francisco Figueirido) writes: >I tried ps but it complained that it couldn't read some kernel tables >(I was root). Is this because it only works with the 1.5.3 kernel? >If so I will wait till Frans Meulenbreoks posts the new diff's. ps looks for "/usr/src/kernel/kernel" "/usr/src/mm/mm" and "/usr/src/fs/fs" by default. On the ST these all end in ".mix". You must either modify the code to look for the ".mix" files or link the the files to the names ps wants. The source code mods are very trival because #defines are used. Also you must compile the kernel.mix mm.mix & fs.mix without stripping the symbol tables. Once you can get ps to work you may use the "-U" option to generate a small file called "/etc/psdatabase" and rm the ".mix" files. INET stailey@iris613.gsfc.nasa.gov UUCP {backbone}!dftsrv!iris613!stailey
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (05/02/90)
It is a trivial task to recompile the MINIX-ST code with the compiler I posted recently using 32-bit ints, but take care of the interface to the operating system: change all int's to short in message structures! Christoph van Wuellen. P.S.: although 32-bit ints are fine, 16-bit ints are the default with my compiler since it is much more efficient on an 68000. If you have a 32-bit machine, 16-bit ints make no sense.
evans@ditsyda.oz (Bruce.Evans) (05/03/90)
In article <18279@nigel.udel.EDU> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >It is a trivial task to recompile the MINIX-ST code with the compiler I >posted recently using 32-bit ints, but take care of the interface to the >operating system: change all int's to short in message structures! Changing the interface is more complicated than that. Look what happens with write(fd, buf, 0x10001). A short in the message structures will truncate the count to 1. The easiest thing to do do is recompile kernel+mm+fs+init with 32-bit ints. That is what I do for Minix-386. The C code will cause little trouble. The assembler code will cause trouble. Jwahar Bammi has already done stuff like this in gkernel for the ST. -- Bruce Evans evans@ditsyda.syd.dit.csiro.au
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (05/07/90)
<Problem mentioned: 32-bit programs under a 16-bit OS - letting read (fd,buf, 65537) fail.> Of course, this won't go. But my proposal helps those whose programs do not run due to invalid size assumptions. Programs which do not run because they try to transfer more than 64K of data in a single system call are not so frequently, I think. A System based on 32bit-ints totally is elegant, but not so efficient on 16-bit processors like the 68000. Christoph van Wuellen.