brunner@joyce.istc.sri.com (Thomas Eric Brunner) (04/11/89)
<> I'd like to know what other users of the rt as a 4.3 platform have collected in the way of unfixed bugs or undesirable features, as well as their experience with IBM's support for the current release. I was asked by several people at the course I taught with Ron Natalie last week in Boston (Network Operation and Security) where or how they could get support for the product, and neither Ron nor I had any useful answers for them, or could point out to them a list of "known" problems or "known" fixes. I might know myself if I'd rt's here but my shop is mostly sun (100+) and hp boxes, my sole rt is a six month loaner to a client site in Leavenworth Kansas, and the local (Leavenworth) support for the product is non-existant. Since I'm posting off of a host I don't usually use, my return address may be munged. I can be reached at: Internet: brunner@spam.istc.sri.com I follow this list (comp.sys.ibm.pc.rt), so posting back to the list is fine ... provided the AIX people don't get tired of seeing "academic" traffic or "bsd-isms". I'll summarize and post in a weeks time anything I think is generally useful. Cheers! Eric -- Thomas Eric Brunner (if UK, reverse domains).
schwartz@shire.cs.psu.edu (Scott Schwartz) (04/11/89)
brunner@joyce (Thomas Eric Brunner) writes: |I'd like to know what other users of the rt as a 4.3 platform have |collected in the way of unfixed bugs or undesirable features, as well |as their experience with IBM's support for the current release. My impression, as a grad student who is not in any way speaking for the department, is that the (unix) programmers at IBM Palo Alto are doing a pretty good job, but that somebody higher up couldn't care less about offering 4.3BSD as a (viable) product and is seeing to it that anyone who tries to get it and make it work is given a hard time. This might be totally off base, in which case I apologise for doubting such a fine company as IBM, but it sure seems that way to me. (Question for the IBM folks reading this: what is the ratio of AOS developers to AIX developers? Ratio of budgets for each group?) Three general problems: (1) The 6152's malfunction at will; if they have to deal with an ethernet, for example. (2) X11R3 doesn't work on any flavor of RT. (3) The C compilers IBM ships generate bad code. To a first approximation, this is just not acceptable, especially considering that the competition seems able to get all these things to work. The desirable features are clear: It is real live 4.3BSD unix, just like we have on all our other (non IBM) machines. (If we wanted to run VM/AIX, we would have bought another 3090, right?) This is not just grousing because we don't want something new. It means that we can seamlessly interoperate with a diverse set of platforms. It also means that the thousands of man years that have been put into the development of BSD unix are available to us. One small example: we recently installed a modified rwho daemon (a round of applause for Jeff Forys, from Boulder, for making the modifications) that supports packet forwarding between networks, and point to point packet transmission. Sure, we probably could develop something similar for AIX, but with BSD it was already done. And it was by it's very nature done for all our machines (sun, vax, rt, etc). -- Scott Schwartz <schwartz@shire.cs.psu.edu>
news@phoenix.Princeton.EDU (USENET News System) (04/12/89)
In article <4456@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes: >Three general problems: (1) The 6152's malfunction at will; if they >have to deal with an ethernet, for example. (2) X11R3 doesn't work on >any flavor of RT. (3) The C compilers IBM ships generate bad code. We are running the December '88 release on a bunch of 6150s here at Princeton, and are having very few problems with X11R3. We do have some complaints about the apa16 driver and diagonal solid lines, but it seems pretty fairly stable to us. As far as the compilers generating bad code is concerned, I believe that hc was used for the entire X11R3 distribution (maybe that explains the diagonal line problems, I'll have to look into that :-). I have also built the NYSERNet SNMP applications without any problems. Perhaps we just haven't tickled the compiler problems that you had. /Chris ==========----------==========---------+---------==========----------========== ...princeton!deepthought!tengi tengi@deepthought.Princeton.EDU TENGI@PUCC.BITNET
moore@cygnusx1.cs.utk.edu (Keith Moore) (04/12/89)
brunner@joyce (Thomas Eric Brunner) writes: >I'd like to know what other users of the rt as a 4.3 platform have >collected in the way of unfixed bugs or undesirable features, as well >as their experience with IBM's support for the current release. Scott Schwartz <schwartz@shire.cs.psu.edu> replies: >My impression, as a grad student who is not in any way speaking for >the department, is that the (unix) programmers at IBM Palo Alto are >doing a pretty good job, but that somebody higher up couldn't care >less about offering 4.3BSD as a (viable) product and is seeing to it >that anyone who tries to get it and make it work is given a hard time. >This might be totally off base, in which case I apologise for doubting >such a fine company as IBM, but it sure seems that way to me. My impression is that IBM would really like to support only one UNIX for RTs, and that they have a difficult time understanding why lots of us prefer 4.3 to AIX. The fact that they support 4.3 at all is to their credit, when some other manufacturers seem to be moving away from 4.3. >Three general problems: (1) The 6152's malfunction at will; if they >have to deal with an ethernet, for example. (2) X11R3 doesn't work on >any flavor of RT. (3) The C compilers IBM ships generate bad code. (1) I can't speak for 6152's. We don't have any here. (2) X11R3 works fine for me on a 6150 and a 6151. It did require a few patches. This is with the December 1988 release of 4.3, but I had a reasonable server working with a much earlier release. (3) The latest release of 4.3 from IBM contains 3 (!) C compilers, all of which are somehow fundamentally brain-damaged. Fortunately, for any piece of software I have found, at least one of them seems to work. I'd much rather have a single C compiler that can be trusted to work properly. (Why hasn't someone ported the AIX C compiler to 4.3? Surely it wouldn't be hard to change the codegen for the 4.3 function calling convention; what else would be required? Of course, then there would be 4 C compilers...) >To a first approximation, this is just not acceptable, especially >considering that the competition seems able to get all these things to >work. My feeling about the RT 4.3 is that despite the above limitations, it is the least brain-damaged UNIX derivative we have here at UT. That doesn't mean that it's the best-maintained or most up-to-date, but the serious bugs seem to get fixed between releases. I wish I could say the same for SunOS. >This is not just grousing because we don't want something new. It >means that we can seamlessly interoperate with a diverse set of >platforms. It also means that the thousands of man years that have >been put into the development of BSD unix are available to us. I agree; this is a major win. I've tried several SysV-ish boxes with "BSD emulation", and the porting effort for non-trivial applications is always several times that of porting an application from one BSD to another. One of the best things about 4.3 is that it's very compatible with vanilla BSD, not only at the C source code but also at the shell script level...all of the commands are there. -- Keith Moore UT Computer Science Dept. Internet/CSnet: moore@utkcs2.cs.utk.edu 107 Ayres Hall, UT Campus BITNET: moore@utkvx Knoxville Tennessee 37996-1301 Telephone: +1 615 974 0822
esj@stringbikini.cis.ufl.edu (Eric S. Johnson) (04/13/89)
Well, We just got a 6150 here last weekend. It has 16M of memory and 3 of the 310M drives. It does not have a display. We have the Dec 88 AOS release. Im actually quite impressed with the machine. Our goal is to replace our old Vax 11/750 running BSD with it. The ole vax is our uucp/news/nameserver/printserver/younameitserver for our dept, and much of our campus. Porting our software from the Vax has been a joy. But thats not to say there haven't been problems... The first was that no one mentioned that you need to have option SGP in kernel config file. About four hours of testing various kernels found that one out. The next surprise was that it didn't arrive with bind 4.8 resolver routines in libc.a. I would have imagined a release dated 12-88 would have them. (Aside, does the 12/88 system use the VJ congestion control tcp code. I haven't looked yet, but after seeing bind 4.7.3, I am not optimistic.) The last bug I have found so far was in the makefile in /usr/src/lib/libc/net. The routine getnetgent.c uses alloca, but is not compiled with the -ma flag. We make extensive use of yp netgroups to control access, and spent a bit of time scratching our heads wondering why finger would dump core. The AOS support number IBM gave us was a nice gesture, but the people there have not been much help. I haven't called them personally yet, but the word is their reply to the SGP problem was "You just have to put it in some kernels", and the reply to the getnetgent problem was "We don't run yp at all here". But, don't get me wrong, I LIKE this machine. It sure flys compared to our 750. Eric P.S. Does anyone know the AMP part number for the serial card cabels?
rg@psgdc (Dick Gill) (04/14/89)
In article <20065@uflorida.cis.ufl.EDU> esj@stringbikini.cis.ufl.edu (Eric S. Johnson) writes: > > >P.S. >Does anyone know the AMP part number for the serial card cabels? Check the IBM-RT Planning Guide, page 4-28. If you don't have one let me know and I will fax you the information. Dick
ehrlich@shire.cs.psu.edu (Dan Ehrlich) (04/14/89)
In article <19072@joyce.istc.sri.com>, brunner@joyce (Thomas Eric Brunner) writes: ><> >I'd like to know what other users of the rt as a 4.3 platform have collected >in the way of unfixed bugs or undesirable features, as well as their experience >with IBM's support for the current release. > >I was asked by several people at the course I taught with Ron Natalie last >week in Boston (Network Operation and Security) where or how they could get >support for the product, and neither Ron nor I had any useful answers for >them, or could point out to them a list of "known" problems or "known" fixes. >I might know myself if I'd rt's here but my shop is mostly sun (100+) and >hp boxes, my sole rt is a six month loaner to a client site in Leavenworth >Kansas, and the local (Leavenworth) support for the product is non-existant. > The list of `known' bugs is much to extensive to include here. There is a very buggy C compiler (generates bad code, seg faults while compiling). The file system quotas do not work out of the box, we spent two days fixing the code. Also, the version of NFS that comes with AOS 4.3 is what was running on SunOS 3.2 with all of the bugs that version had still in place. The alleged support comes out of a group at USC called the Advanced Computing Support Ceneter (1-800-426-2272). I say alleged because we have had an ongoing problem with AOS 4.3 on the RT 6152 since last November. It took us until the end of December to convince IBM that there actually was a problem. We were getting "The problem can not be recreated here so you must be imagining things" as an answer from the ACSC. IBM's support of AOS 4.3 is much less than enthusiastic. There are appearently no plans for any future releases of AOS beyond the December 1988 release. It seems that IBM is too busy scrambling around trying to rescue AIX from death to spend a lot of time on supporting AOS. Another bone of contention is that it would appear that IBM has no intentions of ever releasing X11 R3 under AOS 4.3. The release avaible from MIT has massive bugs that make it unusable on the RT and IBM does not distribute all of the source code for the server. Of course the bugs are in the binary only pieces of the server. >Since I'm posting off of a host I don't usually use, my return address may >be munged. I can be reached at: > > Internet: brunner@spam.istc.sri.com > >I follow this list (comp.sys.ibm.pc.rt), so posting back to the list is >fine ... provided the AIX people don't get tired of seeing "academic" >traffic or "bsd-isms". I'll summarize and post in a weeks time anything I >think is generally useful. Gee, I had always assumed that the AIX folk were intruding on an AOS/BSD news group. :-) > >Cheers! >Eric >-- >Thomas Eric Brunner >(if UK, reverse domains). -- Dan Ehrlich <ehrlich@shire.cs.psu.edu> | Disclaimer: The opinions expressed are The Pennsylvania State University | my own, and should not be attributed Department of Computer Science | to anyone else, living or dead. University Park, PA 16802 |
penneyj@servio.UUCP (D. Jason Penney) (04/15/89)
OK, here are the bugs we've found using AIX 2.1 in-house. The
bug numbers are from our own internal reporting system, and I'll
provide a brief description of each. Some of the bugs are not
BSD specific, but may be of interest to this newsgroup anyway:
bug2956: dbx does not handle .hc files -- We have files with executable
c functions that are included by other c files. SunOs handles this
all right, but it is VERY difficult to debug this code under AIX.
bug2957: c compiler problems with void * -- The following program
generates a compiler error under AIX:
main()
{ void * junkPtr;
junkPtr = 0;
}
You get the error,
"bar.c", line 5: junkPtr undefined
Cute, huh? This works OK on our other compilers, including SunOs.
bug2958: cc has problem with -o option -- The manual says that "-o"
specifies the name of the resulting object file. Experimentation shows that
1) cc does not allow an extension (i.e. ".o") to be specified in the file
name.
2) Even if you omit the extension, cc places the .o file in the current
directory, and with the same name as the c file.
We've had this experience with the Sequent machine, so this problem may
be pervasive to BSD and not unique to AIX.
bug2961: uname() and unamex() problem -- This is minor and AIX specific.
The calls are supposed to return -1 on success, but they actually seem
to return some nonnegative value.
bug2962: AIX include problems:
1) <unistd.h> is included by multiple files in /usr/include, and even worse,
it has a typedef so the multiple inclusion causes compilation errors.
2) <sys/select.h> has a typedef of struct timeval instead of itself
including <time.h> which has the same struct defined. This of course
gives you grief if you attempt to include both h files.
bug2966: getpwname() failure in AIX: This is a bug from the BSD point
of view, but probably a feature from the point of view of security.
getpwnam() will NOT returned the encrypted password of a user unless you
are running as root. BSD definitely allows anyone to see the encrypted
password, and thus anyone can verify whether a password is correct.
bug2972: Can't Debug Using AIX Tools: Several moderately sized
executables in-house cause both dbx and sdb to go into an infinite loop
when you attempt to "run" the program. A bit of spying suggests that
the program prolog code is getting overwritten with trash.
bug2983: sdb Can't Handle FuncTypes: Since our code runs on several
pANS compilers, we declare our function pointers as typedefs so the
compiler can check number and types of arguments. Example:
typedef void aFuncType(/* prototype omitted in AIX */);
main() {
aFuncType * junkPtr;
(*junkPtr)();
}
When you sdb this you get the weird message,
Proc Aux entry missing for aFuncType
bug3111: setpgrp() Incorrectly Documented: The manuals describe a
System V version of setpgrp() when in fact the runtime library only
behaves properly if you use the BSD version of the definition. This
is actually a help if you're porting from a BSD system.