madd@bu-cs.BU.EDU (Jim Frost) (02/13/89)
Since November I have been making extensive use of SunOS 4.0 on a Sun
386i/250. I have noticed several things which administrators and
users should be aware of. Sun is aware of all of these problems
although there are no fixes currently available to my knowledge.
Most serious is a problem with the mounting of a locally exported
filesystem. As configured on arrival, our Sun 386i under 4.0.1
(probably under 4.0 as well) had several exported filesystems locally
mounted. Under some circumstances, particularly with the use of the
'mv' command between these types of filesystems, an IUNLOCK panic will
occur. This happens very frequently and quite repeatably. My
solution is to remove all /export mounts from fstab and change their
mount points to symbolic links to the proper directories (found by
examining the /export symbolic links). This corrects the problem.
For the life of me, I can't figure out why they mounted locally
exported filesystems anyway, but what do I know.
There are a number of problems with dbx under SunOS 4.0 on the 386i.
It is completely unusable. The fix is to upgrade to 4.0.1. I can't
imagine that anyone even tried to run dbx before sending it out; the
simple program:
main()
{
strcpy(0L, "foo");
}
produces a core which dbx gives "text address error" messages about.
You can't get much simpler than that.
Dbx under all versions of SunOS (3.5+ I think) which have shared
libraries cannot locate shared library modules until the program has
been executed at least once. A simple test is:
% cat >foo.c
main()
{
exit(0);
}
^D
% cc -g foo.c -o foo
% dbx foo
(dbx) stop in exit
no module (etc) exit
(dbx) run
process exited, completion code 0
(dbx) stop in exit
(2) stop in exit
This is particularly annoying when writing X programs since it's nice
to know where an error came from.
SunOS 4.0.1 appears to have problems with virtual memory when running
X11R3 and very large X applications. While it is reasonable to expect
the X11 has some memory leakage (not that I think it does or
anything), this should not cause virtual memory panics. I have
observed "trap 0xe" panics (the following text made mention of a page
fault) when using large applications. Usually you will not have
enough memory to run large applications after awhile and you will have
to reboot, so this doesn't always occur. I have been talking to Sun
about this but unfortunately I have been unable to reproduce this
problem recently.
The 386i has a very pretty start-up screen. Unfortunately it is
cleared when rebooting, causing much of the information displayed on
the screen to be lost. Ordinarily I'd just check /usr/adm/messages
but it appears that panic messages may never make it there. I have
commented to Sun about this but have not received any response other
than "gee that would be a problem".
I hope these are helpful. If you have questions or comments, I am
available at the following address.
jim frost
associative design technology
madd@bu-it.bu.edu
..!harvard!bu-cs!maddguy@auspex.UUCP (Guy Harris) (02/13/89)
>Dbx under all versions of SunOS (3.5+ I think) which have shared >libraries No, 4.0+. >cannot locate shared library modules until the program has >been executed at least once. Not surprising, since they don't even exist in the process's address space until the program has been executed at least once; kind of hard to locate something if it doesn't exist.... "dbx" actually *does* start the program up when you enter it, at least if you don't have a core file; it might, conceivably, be able to let it continue a bit longer, so that it gets through the dynamic-link stage but stops before it hits "main", which would bring the shared libraries into the process's address space and let "dbx" find out where the library routines live. However, I don't know whether this would cause problems worse than the one it purports to solve; it may be that it does, and that Sun didn't do it for just that reason.