dave@sdeggo.UUCP (05/27/87)
I've been running Microport for close to five months now and have turned
up a fair number of bugs. Microport claims that their System V is virtually
identical to AT&T's UNIX for the 6300+. I have a friend who had a 6300+
for a while (but no longer, unfortunately) and claims that the 6300+ does
not have many of the bugs which plague Microport.
Anyhow, I am asking any owners of the 6300+ running UNIX if they can help
me determine if the 6300+ has the same bugs as Microport.
Microport bugs:
(the official list as of release 2.2)
Communicating with Honey-Danber UUCP is a problem is the other system has
a name longer than 6 characters
fdisk may panic the system when non-standard hardware (such as network boards)
is installed in the system
mail messages > 32K cause mail to die
The C optimizer has "several problems" which cause it not to work at times
df on a mounted floppy filesystem may cause the filesystem to be closed
prematurely.
DOS read/write facilities access partions 1-4 of the hard disk, but cannot
access /dev/rdsk/0s5 which is defined as the DOS partition. (but you could
still access it by another name)
labelit does not work properly for floppies
A data exception such as Divide by Zero hangs the system, only when an 80287
is installed. (wow, I'm glad I don't have one!)
Data terminals using 8 bit protocols are not supported through gettydefs
Declaring an array of pointers to structures whose total size would be greater
than 64K causes the C compiler to complain even though the array itself is not
greater than 64K.
Environment variables such as $PROMPT are not accessible from csh (though you
can set them via setenv)
The f77 char conversion does not work on integer*4
The C compile may generate the error message "wasted space" when a variable has
the same name as the function within which it is contained.
ar will core dump when asked to build libraries larger than 200K
under unknown circumstances the as assembler returns the error "hash table
overflow"
commands excuted from within the C shell which return errors will core dump
if enclosed in backquotes.
while using vi typing << may put the user into ex mode
using fprintf to a file opened in r+ mode will cause written data to be lost
graphics characters will not print on the console unless preceeeded by
a printable ascii character
uucico will dump core when used with the -x option
malloc(3x) the new version of malloc may dump core. The older version works
tar does not work across multiple floppies
the -m option to ld does not work
========
Problems I personally have found and verified:
The clock is incredibly inaccurate (loses about 5 minutes/hour on 8Mhz AT)
cron starts jobs twice randomly
The floating point emulation has got major problems and will sometimes
generate an exception which generates another exception which will panic
the system with a "double fault" It is not readily reproducible, but it
has been verified by Microport. This may not be a problem on the 6300+
if it comes with an 80287 as standard equipment.
The C compiler will generate bad assembly language for the following bit
of code:
#include <stdio.h>
main()
{
double test;
test=.0000001;
fprintf("test is %f\n",test);
}
--------
I'm curious about all this because if these bugs do not exist in the AT&T
version, there is something wrong with Microport's claims and I can go holler
at them to get the latest release from AT&T. If not, well, at least I have
the consolation of knowing the AT&T can't get it right.
Does anyone know if there is something similar to the Microport "link kit"
available from AT&T? This is a collection of all the object files necessary
to build a new kernel. If AT&T has this and does not have the bugs it might
be possible to mix and match a new kernel with the Microport drivers and AT&T
kernel.
Please mail to me and I will summarize to the net.
Thanks in advance,
David L. Smith
sdcsvax!sdamos!sdeggo!dave, ihnp4!jack!man!sdeggo!dave, hp-sdd!crash!sdeggo!dave
sdeggo!dave@sdamos.ucsd.edu
"It took us a long time to put a fan in the Mac, so it might be a while before
we put a refrigerator in it." -- Steve Sakaman of Apple on superconductors and
their impact on new Apple products.karld@chinet.UUCP (Karl Denninger) (05/27/87)
In article <63@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >I've been running Microport for close to five months now and have turned >up a fair number of bugs. > >Microport bugs: > >(the official list as of release 2.2) (Excerpted list of bugs follows) > >fdisk may panic the system when non-standard hardware (such as network boards) >is installed in the system > >mail messages > 32K cause mail to die > >DOS read/write facilities access partions 1-4 of the hard disk, but cannot >access /dev/rdsk/0s5 which is defined as the DOS partition. (but you could >still access it by another name) > >Data terminals using 8 bit protocols are not supported through gettydefs > We have Microport here, and have been running it since November of last year (started on 1.3.6, now have 2.2). Some observations on the "official" bug list, and some bugs which are "unofficial" but not unreported, let me assure you! ;-) 1) Terminals: It is "getty" which does not support 8 bit protocols properly. The real problem is the "sane" flag, which sets CS7. A pd version of getty, or a *REAL* long gettydefs line, solves that problem. (Note: the "original" getty sometimes will skip past the 8 bit entries, although I have been able to get them to work. The "new" getty I run here, on all except the console (which, as of 2.2, *must* run the normal one), works fine for 8 bit - we have several users using it regularly.) 2) There are some wierd problems with the serial driver. I have been able to panic the system due to SIO driver failures (Ie: DTR disappears -- you do anything which touches the port and the system panics). This is under evaluation. (note that this is new to V2.2) 3) There is a problem with floating-point emulation -- under certain conditions you can panic after an "exec". This has been fixed and a new kernel is on the way to me. (Believe it or not, this first showed up here in "Phantasia"!) No idea what the exact sequence of things to do to kill it is, from the phantasia example it would seem to be floating point math after an execl(), but there is more to it than that as an quick example program proved (it did not panic). 4) DOSCP does *not* work if you copy TO a hard disk. If you attempt to do this, it will seem to work, but trash the allocation on the HD, leaving myriad cross-linked and orphaned clusters. It works fine going to floppys or FROM any media. 5) Mail messages > 32K cause mail to complain, but the mail is sent anyways. (We use a different mailer here, so this is not a problem). 6) Fdisk will hang/panic the system if a non-initialized secondary hard disk is installed and you run it on the primary (actually, what blows it seems to be some kind of internal parameter read, you can crash in *multiple* utilities, including format, with this. Fix is to disable the secondary drive (set type not installed) while formatting/partitioning the primary, then enable the secondary and all is ok. -- Karl Denninger UUCP : ...ihnp4!ddsw1!karl Macro Computer Solutions Dial : +1 (312) 566-8912 (300-2400) "Quality systems at a fair price" Voice: +1 (312) 566-8910 (24 hrs)