SUN-Spots Digest, v4n31
Vicky Riffle
Sun-Spots-Request at RICE.EDU
Sat Oct 25 09:40:12 AEST 1986
SUN-SPOTS DIGEST Friday, 24 Oct 1986 Volume 4 : Issue 31
Today's Topics:
ditroff/troff/postscript previewer for SUNs
rlogin bug (long)
Can a Sun-3/260 do the work of an 8600
fun with NFS
1/2" Tape controllers
suntools -background
NFS between Sun 100's and Sun 3's (1)
SUN 3 rdump (2)
incompatibility between 68010 and 68020 exec files
SunView problems when using color
biff with NFS mounted /usr/spool/mail
new data communications packages from SUN
Need undump for Tex82 on Sun3?
D/A driver needed for Sun?
1/2 inch 1600/6250 bpi tape drives for Sun-3's?
netstat funny?
Problems with mmdfII on SUN workstations (3)?
Query: adding mouse and keyboard to Sun serial ports?
Magic on Sun-3/110?
mods to ttysw to allow boldfacing/underlining/reverse video
Network connections seem to lock up...?
Color windows running in suntools?
Eagle, 3rd party, installation problems?
iobus level 3 interrupt not serviced?
Query: getting carrier-detect status from zs0?
typesetting previewers for Sun workstations?
------------------------------------------------------------------------
Date: Sun, 19 Oct 86 10:16:40 EDT
From: timos at mimsy.umd.edu (Timos Sellis)
Subject: ditroff/troff/postscript previewer for SUNs
John Osterhout from UC Berkeley distributes a version of ditroff along
with the gremlin graphics package and a previewer for the SUNs. He can be
contacted as "ouster at kim.berkeley.edu" or ....!ucbvax!ucbkim!ouster.
Timos Sellis
CS Dept, University of Maryland, College Park
ARPA: timos at mimsy.umd.edu
UUCP: {decvax,allegra,...}!umcp-cs!timos
------------------------------
Date: 17 Oct 86 19:55:53 EDT (Fri)
From: lamy%utai.toronto.edu at CSNET-RELAY.ARPA (Jean-Francois Lamy)
Subject: rlogin bug
The version of rlogin distributed with 3.0 has a tendency to hang. It is
particularly bad mannered when GNU Emacs is used on the remote machine. Given
the wide variety of remote hardware/software configurations in which the
behavior is exhibited (see the two reports below), and the fact that
someone claims to had a fix, I thought it was relevant to forward the messages
to this list.
Jean-Francois Lamy
AI Group, Dept of Computer Science CSNet: lamy at ai.toronto.edu
University of Toronto EAN: lamy at ai.toronto.cdn
Toronto, ON, Canada M5S 1A4 UUCP: lamy at utai.uucp
------- Message 1
Date: 15 Oct 86 21:36:36 GMT
From: mwm at eris.berkeley.edu (Mike Meyer)
Subject: GNU Emacs hanging...
>>Sorry to bother you all, but I have an annoying problem. I run GNU
>>Emacs 17.57.18 from a sun2-window remotely logged in to a pyramid 98x
>>running [4].2 BSD Unix. I am quite often hung while trying to bring it
>>back to the foreground after suspending it.
>
>Exactly the same problem occurs with GNU 17.64 when remote logged on a
>4.2BSD Vax, from Sun 2/ Sun 3 Workstations running 3.0. To reproduce
>the bug, just edit with GNU long enough, going often to the background.
>There does not seem to be any correlation with what state GNU was in
>when you suspend it. GNU emacs is the only program I've seen that
>provokes that behavior.
Ditto, except for more data points:
rlogged in from either a Sun-3 any of a 4.[23] 750, a 4.3beta 8600, a
4.3 8600, or an Ultrix 2.0beta 8800. Also from a uvax ][ to either a
4.2 750 or a 4.3beta 8600.
GNU version is 17.63, and there's at least one version of microEmacs
that has the same problem.
The problem seems occurs more often with longer windows, and rlogged
in to faster hosts. I suspect a kernel bug, myself, but would be
interested to see any solution.
<mike
------- Message 2
Date: 17 Oct 86 04:53:48 GMT
From: chris at umcp-cs.UUCP (Chris Torek)
Subject: Re: GNU Emacs hanging...
In article <1456 at jade.BERKELEY.EDU> mwm at eris.berkeley.edu (Mike Meyer) writes:
>Ditto, except for more data points:
>
>rlogged in from either a Sun-3 any of a 4.[23] 750, a 4.3beta 8600, a
>4.3 8600, or an Ultrix 2.0beta 8800. Also from a uvax ][ to either a
>4.2 750 or a 4.3beta 8600.
I cannot quite parse that, but I gather the problem shows when running
rlogin within a window, whenever the remote host is `fast'.
>I suspect a kernel bug, myself, but would be interested to see any
>solution.
Rlogin bugs are more likely. The 4.2 version was thoroughly broken.
The 4.3 version was significantly reworked but still not quite
right. The Sun version was hopeless; I replaced it with a fixed 4.3
version. I know naught of the Ultrix rlogin.
The Solution (as far as I know):
Copy your 4.3 rlogin.c and your 4.3 /usr/src/lib/libc/net/rcmd.c
files to your Sun or uVax-II. Apply the changes shown below to
rlogin.c. Compile rlogin.c and rcmd.c to .o's, then link together
and test. This requires super-user privileges (alas!). You may
discover that you need to reverse the sense of the `pid' arguments
to the fcntl(F_SETOWN) calls; I forget whether they work as is on
the Suns. (4.2 had pid and pgrp logically reversed; `fixed in 4.3'
means `incompatible with 4.2'. So it goes.)
You may want to pull out the `isswitch' code. We used to use a
local hack to allow remote logins without local accounts, by adding
/etc/passwd entries of the form
imladris::20:199:& Switch:/tmp:/usr/ucb/rswtch
Logging in as `imladris' (ah, the name evokes such memories) would
send you over to my Sun-3/50, where you would then be asked for a
login name and password. We now have a different local hack; I just
log in as `chris at imladris' if I wish.
Anyway, here are the fixes for a 4.3 rlogin.c. Do not be concerned
by the size: I fixed all the lint fluff, and reworked some of the
Sun-specific window code for readability.
*** /x/chris/4.3tape/src/ucb/rlogin.c Sun Mar 30 19:39:06 1986
- --- rlogin.c Thu Aug 7 02:24:40 1986
***************
*** 22,25 ****
- --- 22,27 ----
#include <sys/file.h>
#include <sys/socket.h>
+ #include <sys/time.h>
+ #include <sys/resource.h>
#include <sys/wait.h>
***************
*** 38,42 ****
# endif TIOCPKT_WINDOW
! char *index(), *rindex(), *malloc(), *getenv();
struct passwd *getpwuid();
char *name;
- --- 40,49 ----
# endif TIOCPKT_WINDOW
! /* concession to sun */
! # ifndef SIGUSR1
! # define SIGUSR1 30
! # endif SIGUSR1
!
! char *index(), *rindex(), *malloc(), *getenv(), *strcat(), *strcpy();
struct passwd *getpwuid();
char *name;
***************
*** 43,46 ****
- --- 50,54 ----
int rem;
char cmdchar = '~';
+ int isswitch;
int eight;
int litout;
***************
*** 56,60 ****
#endif
#ifdef sun
- - struct ttysize winsize;
struct winsize {
unsigned short ws_row, ws_col;
- --- 64,67 ----
***************
*** 61,69 ****
unsigned short ws_xpixel, ws_ypixel;
};
- - #else sun
- - struct winsize winsize;
#endif sun
int sigwinch(), oob();
main(argc, argv)
int argc;
- --- 68,101 ----
unsigned short ws_xpixel, ws_ypixel;
};
#endif sun
+ struct winsize winsize;
int sigwinch(), oob();
+ /*
+ * The following routine provides compatibility (such as it is)
+ * between 4.2BSD Suns and others. Suns have only a `ttysize',
+ * so we convert it to a winsize.
+ */
+ #ifdef sun
+ int
+ get_window_size(fd, wp)
+ int fd;
+ struct winsize *wp;
+ {
+ struct ttysize ts;
+ int error;
+
+ if ((error = ioctl(0, TIOCGSIZE, &ts)) != 0)
+ return (error);
+ wp->ws_row = ts.ts_lines;
+ wp->ws_col = ts.ts_cols;
+ wp->ws_xpixel = 0;
+ wp->ws_ypixel = 0;
+ return (0);
+ }
+ #else sun
+ #define get_window_size(fd, wp) ioctl(fd, TIOCGWINSZ, wp)
+ #endif sun
+
main(argc, argv)
int argc;
***************
*** 85,88 ****
- --- 117,143 ----
if (!strcmp(host, "rlogin"))
host = *argv++, --argc;
+ else if (!strcmp(host, "rswtch")) {
+ printf("You really don't want to run this.\n");
+ exit(1);
+ } else if (argc == 0 && host[0] == '-') {
+ static char namebuf[128];
+ char *getlogin();
+
+ /*
+ * This is a hack. If you log in with "rswtch" as
+ * your shell, we assume you really want to remotely
+ * log in to some other host. This disables commands
+ * and makes us prompt for a login name.
+ */
+ if ((host = getlogin()) == NULL) {
+ printf("Oops - getlogin\n");
+ exit(1);
+ }
+ isswitch++;
+ (void) printf("Remote login name: ");
+ (void) fflush(stdout);
+ (void) gets(namebuf);
+ name = namebuf;
+ }
another:
if (argc > 0 && !strcmp(*argv, "-d")) {
***************
*** 117,124 ****
if (argc > 0)
goto usage;
! pwd = getpwuid(getuid());
! if (pwd == 0) {
! fprintf(stderr, "Who are you?\n");
! exit(1);
}
sp = getservbyname("login", "tcp");
- --- 172,181 ----
if (argc > 0)
goto usage;
! if (!isswitch) {
! pwd = getpwuid(getuid());
! if (pwd == 0) {
! fprintf(stderr, "Who are you?\n");
! exit(1);
! }
}
sp = getservbyname("login", "tcp");
***************
*** 129,146 ****
cp = getenv("TERM");
if (cp)
! strcpy(term, cp);
if (ioctl(0, TIOCGETP, &ttyb) == 0) {
! strcat(term, "/");
! strcat(term, speeds[ttyb.sg_ospeed]);
}
! #ifdef sun
! (void) ioctl(0, TIOCGSIZE, &winsize);
! #else sun
! (void) ioctl(0, TIOCGWINSZ, &winsize);
! #endif sun
! signal(SIGPIPE, lostpeer);
! signal(SIGURG, oob);
! oldmask = sigblock(sigmask(SIGURG));
! rem = rcmd(&host, sp->s_port, pwd->pw_name,
name ? name : pwd->pw_name, term, 0);
if (rem < 0)
- --- 186,199 ----
cp = getenv("TERM");
if (cp)
! (void) strcpy(term, cp);
if (ioctl(0, TIOCGETP, &ttyb) == 0) {
! (void) strcat(term, "/");
! (void) strcat(term, speeds[ttyb.sg_ospeed]);
}
! (void) get_window_size(0, &winsize);
! (void) signal(SIGPIPE, lostpeer);
! /* will use SIGUSR1 for window size hack, so hold it off */
! oldmask = sigblock(sigmask(SIGURG) | sigmask(SIGUSR1));
! rem = rcmd(&host, sp->s_port, isswitch ? "anybody" : pwd->pw_name,
name ? name : pwd->pw_name, term, 0);
if (rem < 0)
***************
*** 166,170 ****
int child;
int catchild();
! int writeroob();
int defflags, tabflag;
- --- 219,223 ----
int child;
int catchild();
! int copytochild(), writeroob();
int defflags, tabflag;
***************
*** 181,185 ****
struct sgttyb sb;
! ioctl(0, TIOCGETP, (char *)&sb);
defflags = sb.sg_flags;
tabflag = defflags & TBDELAY;
- --- 234,238 ----
struct sgttyb sb;
! (void) ioctl(0, TIOCGETP, (char *)&sb);
defflags = sb.sg_flags;
tabflag = defflags & TBDELAY;
***************
*** 187,198 ****
deferase = sb.sg_erase;
defkill = sb.sg_kill;
! ioctl(0, TIOCLGET, (char *)&deflflags);
! ioctl(0, TIOCGETC, (char *)&deftc);
notc.t_startc = deftc.t_startc;
notc.t_stopc = deftc.t_stopc;
! ioctl(0, TIOCGLTC, (char *)&defltc);
! signal(SIGINT, SIG_IGN);
! signal(SIGHUP, exit);
! signal(SIGQUIT, exit);
child = fork();
if (child == -1) {
- --- 240,251 ----
deferase = sb.sg_erase;
defkill = sb.sg_kill;
! (void) ioctl(0, TIOCLGET, (char *)&deflflags);
! (void) ioctl(0, TIOCGETC, (char *)&deftc);
notc.t_startc = deftc.t_startc;
notc.t_stopc = deftc.t_stopc;
! (void) ioctl(0, TIOCGLTC, (char *)&defltc);
! (void) signal(SIGINT, SIG_IGN);
! setsignal(SIGHUP, exit);
! setsignal(SIGQUIT, exit);
child = fork();
if (child == -1) {
***************
*** 202,207 ****
if (child == 0) {
mode(1);
! sigsetmask(oldmask);
! if (reader() == 0) {
prf("Connection closed.");
exit(0);
- --- 255,259 ----
if (child == 0) {
mode(1);
! if (reader(oldmask) == 0) {
prf("Connection closed.");
exit(0);
***************
*** 211,217 ****
exit(3);
}
! signal(SIGURG, writeroob);
! sigsetmask(oldmask);
! signal(SIGCHLD, catchild);
writer();
prf("Closed connection.");
- --- 263,277 ----
exit(3);
}
!
! /*
! * We may still own the socket, and may have a pending SIGURG
! * (or might receive one soon) that we really want to send to
! * the reader. Set a trap that simply copies such signals to
! * the child.
! */
! (void) signal(SIGURG, copytochild);
! (void) signal(SIGUSR1, writeroob);
! (void) sigsetmask(oldmask);
! (void) signal(SIGCHLD, catchild);
writer();
prf("Closed connection.");
***************
*** 219,229 ****
}
done(status)
int status;
{
mode(0);
! if (child > 0 && kill(child, SIGKILL) >= 0)
! wait((int *)0);
exit(status);
}
- --- 279,308 ----
}
+ /*
+ * Trap a signal, unless it is being ignored.
+ */
+ setsignal(sig, act)
+ int sig, (*act)();
+ {
+ int omask = sigblock(sigmask(sig));
+
+ if (signal(sig, act) == SIG_IGN)
+ (void) signal(sig, SIG_IGN);
+ (void) sigsetmask(omask);
+ }
+
done(status)
int status;
{
+ int w;
mode(0);
! if (child > 0) {
! /* make sure catchild does not snap it up */
! (void) signal(SIGCHLD, SIG_DFL);
! if (kill(child, SIGKILL) >= 0)
! while ((w = wait((union wait *)0)) > 0 && w != child)
! /*void*/;
! }
exit(status);
}
***************
*** 230,233 ****
- --- 309,321 ----
/*
+ * Copy SIGURGs to the child process.
+ */
+ copytochild()
+ {
+
+ (void) kill(child, SIGURG);
+ }
+
+ /*
* This is called when the reader process gets the out-of-band (urgent)
* request to turn on the window-changing protocol.
***************
*** 238,242 ****
if (dosigwinch == 0) {
sendwindow();
! signal(SIGWINCH, sigwinch);
}
dosigwinch = 1;
- --- 326,330 ----
if (dosigwinch == 0) {
sendwindow();
! (void) signal(SIGWINCH, sigwinch);
}
dosigwinch = 1;
***************
*** 249,253 ****
again:
! pid = wait3(&status, WNOHANG|WUNTRACED, 0);
if (pid == 0)
return;
- --- 337,341 ----
again:
! pid = wait3(&status, WNOHANG|WUNTRACED, (struct rusage *)0);
if (pid == 0)
return;
***************
*** 256,260 ****
*/
if (pid < 0 || pid == child && !WIFSTOPPED(status))
! done(status.w_termsig | status.w_retcode);
goto again;
}
- --- 344,348 ----
*/
if (pid < 0 || pid == child && !WIFSTOPPED(status))
! done((int)(status.w_termsig | status.w_retcode));
goto again;
}
***************
*** 290,294 ****
if (bol) {
bol = 0;
! if (c == cmdchar) {
bol = 0;
local = 1;
- --- 378,382 ----
if (bol) {
bol = 0;
! if (!isswitch && c == cmdchar) {
bol = 0;
local = 1;
***************
*** 308,312 ****
}
if (c != cmdchar)
! write(rem, &cmdchar, 1);
}
if (write(rem, &c, 1) == 0) {
- --- 396,400 ----
}
if (c != cmdchar)
! (void) write(rem, &cmdchar, 1);
}
if (write(rem, &c, 1) == 0) {
***************
*** 338,342 ****
*p++ = '\r';
*p++ = '\n';
! write(1, buf, p - buf);
}
- --- 426,430 ----
*p++ = '\r';
*p++ = '\n';
! (void) write(1, buf, p - buf);
}
***************
*** 345,351 ****
{
mode(0);
! signal(SIGCHLD, SIG_IGN);
! kill(cmdc == defltc.t_suspc ? 0 : getpid(), SIGTSTP);
! signal(SIGCHLD, catchild);
mode(1);
sigwinch(); /* check for size changes */
- --- 433,439 ----
{
mode(0);
! (void) signal(SIGCHLD, SIG_IGN);
! (void) kill(cmdc == defltc.t_suspc ? 0 : getpid(), SIGTSTP);
! (void) signal(SIGCHLD, catchild);
mode(1);
sigwinch(); /* check for size changes */
***************
*** 352,373 ****
}
- - #ifdef sun
sigwinch()
{
- - struct ttysize ws;
- -
- - if (dosigwinch && ioctl(0, TIOCGSIZE, &ws) == 0 &&
- - bcmp(&ws, &winsize, sizeof (ws))) {
- - winsize = ws;
- - sendwindow();
- - }
- - }
- -
- - #else sun
- - sigwinch()
- - {
struct winsize ws;
! if (dosigwinch && ioctl(0, TIOCGWINSZ, &ws) == 0 &&
bcmp(&ws, &winsize, sizeof (ws))) {
winsize = ws;
- --- 440,448 ----
}
sigwinch()
{
struct winsize ws;
! if (dosigwinch && get_window_size(0, &ws) == 0 &&
bcmp(&ws, &winsize, sizeof (ws))) {
winsize = ws;
***************
*** 375,379 ****
}
}
- - #endif
/*
- --- 450,453 ----
***************
*** 389,398 ****
obuf[2] = 's';
obuf[3] = 's';
- - #ifdef sun
- - wp->ws_row = htons(winsize.ts_lines);
- - wp->ws_col = htons(winsize.ts_cols);
- - wp->ws_xpixel = 0;
- - wp->ws_ypixel = 0;
- - #else sun
wp->ws_row = htons(winsize.ws_row);
wp->ws_col = htons(winsize.ws_col);
- --- 463,466 ----
***************
*** 399,403 ****
wp->ws_xpixel = htons(winsize.ws_xpixel);
wp->ws_ypixel = htons(winsize.ws_ypixel);
- - #endif sun
(void) write(rem, obuf, sizeof(obuf));
}
- --- 467,470 ----
***************
*** 409,413 ****
#define WRITING 2
! char rcvbuf[8 * 1024];
int rcvcnt;
int rcvstate;
- --- 476,480 ----
#define WRITING 2
! char rcvbuf[32 * 1024];
int rcvcnt;
int rcvstate;
***************
*** 452,477 ****
* Let server know about window size changes
*/
! kill(ppid, SIGURG);
}
if (!eight && (mark & TIOCPKT_NOSTOP)) {
! ioctl(0, TIOCGETP, (char *)&sb);
sb.sg_flags &= ~CBREAK;
sb.sg_flags |= RAW;
! ioctl(0, TIOCSETN, (char *)&sb);
notc.t_stopc = -1;
notc.t_startc = -1;
! ioctl(0, TIOCSETC, (char *)¬c);
}
if (!eight && (mark & TIOCPKT_DOSTOP)) {
! ioctl(0, TIOCGETP, (char *)&sb);
sb.sg_flags &= ~RAW;
sb.sg_flags |= CBREAK;
! ioctl(0, TIOCSETN, (char *)&sb);
notc.t_stopc = deftc.t_stopc;
notc.t_startc = deftc.t_startc;
! ioctl(0, TIOCSETC, (char *)¬c);
}
if (mark & TIOCPKT_FLUSHWRITE) {
! ioctl(1, TIOCFLUSH, (char *)&out);
for (;;) {
if (ioctl(rem, SIOCATMARK, &atmark) < 0) {
- --- 519,544 ----
* Let server know about window size changes
*/
! (void) kill(ppid, SIGUSR1);
}
if (!eight && (mark & TIOCPKT_NOSTOP)) {
! (void) ioctl(0, TIOCGETP, (char *)&sb);
sb.sg_flags &= ~CBREAK;
sb.sg_flags |= RAW;
! (void) ioctl(0, TIOCSETN, (char *)&sb);
notc.t_stopc = -1;
notc.t_startc = -1;
! (void) ioctl(0, TIOCSETC, (char *)¬c);
}
if (!eight && (mark & TIOCPKT_DOSTOP)) {
! (void) ioctl(0, TIOCGETP, (char *)&sb);
sb.sg_flags &= ~RAW;
sb.sg_flags |= CBREAK;
! (void) ioctl(0, TIOCSETN, (char *)&sb);
notc.t_stopc = deftc.t_stopc;
notc.t_startc = deftc.t_startc;
! (void) ioctl(0, TIOCSETC, (char *)¬c);
}
if (mark & TIOCPKT_FLUSHWRITE) {
! (void) ioctl(1, TIOCFLUSH, (char *)&out);
for (;;) {
if (ioctl(rem, SIOCATMARK, &atmark) < 0) {
***************
*** 495,499 ****
- --- 562,571 ----
longjmp(rcvtop, 1);
}
+
/*
+ * oob does not do FLUSHREAD (alas!)
+ */
+
+ /*
* If we filled the receive buffer while a read was pending,
* longjmp to the top to restart appropriately. Don't abort
***************
*** 507,511 ****
* reader: read from remote: line -> 1
*/
! reader()
{
#if !defined(BSD) || BSD < 43
- --- 579,584 ----
* reader: read from remote: line -> 1
*/
! reader(oldmask)
! int oldmask;
{
#if !defined(BSD) || BSD < 43
***************
*** 517,524 ****
char *bufp = rcvbuf;
! signal(SIGTTOU, SIG_IGN);
! fcntl(rem, F_SETOWN, pid);
ppid = getppid();
(void) setjmp(rcvtop);
for (;;) {
while ((remaining = rcvcnt - (bufp - rcvbuf)) > 0) {
- --- 590,599 ----
char *bufp = rcvbuf;
! (void) signal(SIGTTOU, SIG_IGN);
! (void) signal(SIGURG, oob);
ppid = getppid();
+ (void) fcntl(rem, F_SETOWN, pid);
(void) setjmp(rcvtop);
+ (void) sigsetmask(oldmask);
for (;;) {
while ((remaining = rcvcnt - (bufp - rcvbuf)) > 0) {
***************
*** 554,559 ****
int lflags;
! ioctl(0, TIOCGETP, (char *)&sb);
! ioctl(0, TIOCLGET, (char *)&lflags);
switch (f) {
- --- 629,634 ----
int lflags;
! (void) ioctl(0, TIOCGETP, (char *)&sb);
! (void) ioctl(0, TIOCLGET, (char *)&lflags);
switch (f) {
***************
*** 584,591 ****
return;
}
! ioctl(0, TIOCSLTC, (char *)ltc);
! ioctl(0, TIOCSETC, (char *)tc);
! ioctl(0, TIOCSETN, (char *)&sb);
! ioctl(0, TIOCLSET, (char *)&lflags);
}
- --- 659,666 ----
return;
}
! (void) ioctl(0, TIOCSLTC, (char *)ltc);
! (void) ioctl(0, TIOCSETC, (char *)tc);
! (void) ioctl(0, TIOCSETN, (char *)&sb);
! (void) ioctl(0, TIOCLSET, (char *)&lflags);
}
***************
*** 594,597 ****
- --- 669,673 ----
char *f;
{
+
fprintf(stderr, f, a1, a2, a3, a4, a5);
fprintf(stderr, CRLF);
***************
*** 600,604 ****
lostpeer()
{
! signal(SIGPIPE, SIG_IGN);
prf("\007Connection closed.");
done(1);
- --- 676,681 ----
lostpeer()
{
!
! (void) signal(SIGPIPE, SIG_IGN);
prf("\007Connection closed.");
done(1);
- --
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP: seismo!umcp-cs!chris
CSNet: chris at umcp-cs ARPA: chris at mimsy.umd.edu
------------------------------
Date: Wed, 15 Oct 86 00:39:12 MST
From: whm at arizona.edu (Bill Mitchell)
Subject: Can a Sun-3/260 do the work of an 8600?
I had an opportunity to run some benchmarks on a Sun-3/260 and an 8600.
The Sun seems to stack up pretty well against the big boy; for the entire
suite the VAX took about 25 minutes of real time and the Sun took about 30,
if I believe what I'm reading.
I believe that for equivalently configured systems with about 1G of disk
and 16M, the list price of the VAX is about 3-4 times that of the Sun.
When I ponder the price/performance ratio of the two machines, I have to
wonder under what conditions one might select an 8600 (or 8500 or 8700)
instead of a Sun-3/200. Well, you can't run VMS on a Sun, but that reason
is not of interest to me. If you buy a Sun-3/200 instead of an 8600,
you're probably going to have a couple $100k left over, but if you've got
to spend the money, you could buy a couple more Sun-3/200s.
Based on my benchmarks, I'm convinced that if you're going to be using
the system as a workstation, the Sun has just as much power as the VAX.
However, the multiuser performance question is really the one that
I'm interested in. For a specific question, if you put 20 busy users
on a Sun-3/260, would it hold up as well as an 8600? Is anyone doing this
now? Does anyone plan to do this? Has anyone canceled their order for
an 8000-series VAX and ordered a Sun-3/200 series machine instead?
If you know the answers to these or similar questions, I'd love to hear
from you.
On a somewhat related topic, does anyone know if Sun has ever given any
thought to making their UNIX available for VAXs? Sure, you can get 4.3
from UCB, 4.3+NFS from Mt. Xinu, and Ultrix from DEC, but we've got a
load of Suns and VAXs and it certainly would be nice to be running the
same UNIX on both machines. Obviously, there's a lot of stuff that would
be N/A on the VAX, but it would certainly be the system of choice for me
since I'm going to be working on both VAXs and Suns. I think it would be
a logical choice for sites that have Suns and who are looking for a vendor-
maintained UNIX for their VAXs.
Bill Mitchell
U of Arizona CS Dept.
whm at arizona.edu (preferred)
{ihnp4,noao,mcnc,utah-cs}!arizona!whm
IPC: 602-621-6613
------------------------------
Date: 15 October 1986 2202-PDT (Wednesday)
From: wallen at nprdc.arpa (Mark Wallen)
Subject: fun with NFS
When one runs NFS, there are some additional interesting things that seem
to become possible.
For instance, you could really run dual ported disks between two systems.
The old bugaboo with dual porting your drives was that only one port could
be read/write, so that you didn't completely scramble your disk.
And moreover, when lots of in core caching of disk data was done (like UNIX
likes to), the readonly port still gets only an inconsistent view of the
disk. In the brave new world of NFS, you would have your read/write port
as usual, but the second system mounts the disk as a NFS partition from the
read/write host. So far you have bought nothing; but when the NFS server
crashes then you umount the NFS partition and mount the file system (perhaps
an fsck would be prudent :-) on the second system. With clever software,
the original NFS server would become the client when it came back up!
Also, it seems as though it would be possible to build a "left handed" NFS
server. That is, one that read up a remote/foreign file system (byte swap,
etc) from a local disk. Thus, one should be able to use different hosts
(e.g., sun and vax) to implement the dual port scheme above. (Of course,
you probably also want a left hand fsck and dump).
Has anyone else thought of this (and found the holes)? Anyone actually done it?
Mark Wallen
Institute for Cognitive Science
UC San Diego
ucbvax!sdcsvax!sdics!wallen.uucp
wallen at ucsd.edu
wallen at nprdc.arpa
------------------------------
Date: Sun Oct 19 12:45:46 1986
>From davstoy!dav%csuf.uucp at ICS.UCI.EDU (David L. Markowitz)
Subject: 1/2" Tape controllers
Because of the lack of 32-bit wide VME controllers from Sun,
we have recently been trying other tape controllers out. One we
just got working is the Ciprico TM3000. It is a 32-bit native VME
board (it rwquires a form-factor conversion board). The manufacturer
has been trying very hard to get us up (we won't buy it until it
proves capable for our task :-).
The glossy claims an aggregate 10 Mb/s throughput, with as
much as 2.2 Mb/s per drive on up to 8 Pertec-interface drives (on 1
board!) daisy-chained. Since a 45 ips 6250 drive has a throughput
of ~325 Kb/s, I figure that 125 ips at 6250 bpi is around 900 Kb/s,
or well within the limits of this board.
After a little fiddling, I got it up on our Sun 3/160,
and it seemed quite happy doing dumps, tars, etc. We are using
Kennedy 9400's. I have not extensively tested it yet. (No
multi-drive tests yet, and no dd if=/dev/rxy0g of=/dev/rmt8,
for example).
The driver will be easy to install after I tell them how
to fix it and their installation instructions (minor changes only).
I am not trying to push their board, but with many people
asking about tape controllers I thought I'd share this experience.
I don't have the pricing with me right now, but if you want it or
their phone/mail address, drop me a line.
===============================================================================
David L. Markowitz
Real Time Trekker
Rockwell International (Where Science Gets Down To Busyness)
...!sdcsvax!ucivax\
...!ucbvax!trwrb!csuf!davstoy!dav
...!hplabs!felix/
------------------------------
Date: Mon, 20 Oct 86 01:37:05 EDT
From: chris at mimsy.umd.edu (Chris Torek)
Subject: suntools -background
I used Mark's program to convert an icon and ran suntools, but it
refused to load my new background. I took a guess at the problem
and was correct: the raster file must not be run length encoded.
In Mark's convertpicture program, change
if (pr_dump(image_pr, outfile, RMT_NONE, RT_BYTE_ENCODED, 0))
to
if (pr_dump(image_pr, outfile, RMT_NONE, RT_STANDARD, 0))
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP: seismo!umcp-cs!chris
CSNet: chris at umcp-cs ARPA: chris at mimsy.umd.edu
------------------------------
Date: Sun, 19 Oct 86 21:02:12 PDT
From: speck at vlsi.caltech.edu (Don Speck)
Subject: Re: NFS between Sun 100's and Sun 3's (1)
In Sun-Spots v4n30, goedel!harker (Robert Harker) writes:
> The real solution [to Sun 100's dropping NFS packets from Sun3 servers]
> is to replace your 3-Com Ethernet board with a Sun Ethernet board [...]
When I asked why we were ordering Sun Ethernet boards, our purchasing
agent told me very firmly that Sun 3.0 would not run with 3-Com's.
Weeks after I had 3.0 running on our 100U's, she still insisted that
we needed them.
The thing that finally changed her mind was when I found that the
internal ribbon cable on a 100U would reach the connector on a 3-Com
but would NOT reach the connector on a Sun Ethernet board.
> You should order the second Ethernet option instead of the 3-Com upgrade
> because they are the same price and you don't have to return your 3-Com
> Ethernet board.
And because when you find that the Sun Ethernet board doesn't fit,
you'll be glad that you saved that old 3-Com.
Don Speck speck at vlsi.caltech.edu {seismo,rutgers}!cit-vax!speck
------------------------------
Date: Sun, 19 Oct 86 20:19:09 PDT
From: speck at vlsi.caltech.edu (Don Speck)
Subject: SUN 3 rdump (1)
In Sun-Spots v4n30, mr-frog at sdcsvax.ucsd.edu.arpa (Dave Pare) writes:
> Our tape drive resides on a 4.3 BSD vax 11/750, and we were doing dumps
> from a sun 3/160 to the vax.
> The transfer rate under the old scheme runs around 11.5kb/sec, ...
> When I increased [tcp_sendspace and tcp_recvspace] to 4k per send/recv
> socket, the performance jumped up to 30.9kb/sec.
> This does not need to be done on 4.3, however, since they were clever enough
> to insert a "SO_SNDBUF" and SO_RCVBUF setsockopt calls ...
The fact that 4.3bsd /etc/rmt sets SO_RCVBUF is what *causes* the problem.
To illustrate the effects of varying the send and receive buffer
sizes, this is how the throughput changes as I vary tcp_sendspace
and tcp_recvspace:
recvspace: 2K 4K 10K 5K 6K
sendspace -- -- -- -- --
2K 66 70 72 12 KB/s
4K 74 91 94 KB/s
10K 73 87 99 KB/s
[Sun-3/160, Sun Unix 3.0 dumping 32Kbyte blocks to 4.2bsd Vax-11/750
equipped with Interlan NI1010A. rdump and rmt both double-buffered].
Observe that if tcp_recvspace is made too big relative to tcp_sendspace,
throughput is terrible. But tcp_sendspace can be made large without any
problems. This derives from some TCP window bug. Imagen has described
the same phenomenon.
4.3bsd /etc/rmt sets SO_RCVBUF to the dump blocksize, normally 10K,
which is much too big relative to the rdump's sendspace. So a third
solution presents itself: remove the offending setsockopt from /etc/rmt.
There is some efficiency to be gained by raising tcp_sendspace (fewer
ACKs), but ordinary rdump on a Sun is disk-limited, not network-limited.
(It reads 1K at a time, like in 4.1bsd). You won't see any significant
throughput improvement until Sun adopts 4.3bsd rdump, if they ever do.
Don Speck speck at vlsi.caltech.edu {seismo,rutgers}!cit-vax!speck
------------------------------
Date: Tue, 21 Oct 86 16:16:54 MDT
From: hi!cyrus at hc.arpa (Tait Cyrus)
Subject: SUN 3 rdump (2)
We had the same problem of SLOW rdumps from our SUN 3/160 running
UNIX 3.0 to a uVAX II running 4.3. What we did to speed up the
rdump was to use a 4.2 (Ultrix 2.1) version of /etc/rmt on the uVAX II.
Since we have both 4.2 and 4.3 using rdump to the uVAX we named the
4.2 version of /etc/rmt to /etc/Rmt and left the 4.3 version as /etc/rmt.
We then used adb on 'dump' (rdump is linked to dump) and changed the
strings "/etc/rmt" to "/etc/Rmt".
Before we made the above change our dumps were also at ~10-11 kb/sec.
After the change the dumps jumped to ~30 kb/sec.
Question????
Is there any relationship between our fix and your fix of tweaking the
kernel so that tcp_sendspace/tcp_recvspace are 4*1024 instead of 2*1024?
Will we get a higher throughput if we change our kernel and still
use our fix?
Thanks in advance
W. Tait Cyrus
University of New Mexico
Department of Electrical and Computer Engineering
Hypercube Project
Albuquerque, New Mexico 87131
(505) 277-0806
e-mail: cyrus at hc.dspo.gov
{gatech|ucbvax|convex}!unmvax!hi!cyrus
------------------------------
Date: Wed, 15 Oct 86 10:53:59 pdt
From: black at ee.UCLA.EDU (Rex Black)
Subject: incompatibility between 68010 and 68020 exec files
I realize that this is a reply to a fairly old article, but
I'm afraid Pierre is mistaken. The linker ld determines
dynamically the page sizes for the machine on which it is
running, which is what causes the incompatibility between
68010 & 68020 exec files. The libraries have nothing to
do with it, since these are relocatables and not dependent
on page sizes.
Rex Black (black at ee.ucla.edu), Sys. Admin., EE Dept.
------------------------------
Date: Fri, 17 Oct 86 13:57:41 PDT
From: vern at lbl-csam.arpa (Vern Paxson)
Subject: Re: SunView problems when using color
>> From: HOUSE%williams.csnet at CSNET-RELAY.ARPA
>> Subject: SunView problems when using color
>>
>> Under most circumstances there are no problems. However, certain calls to
>> the Pixrect drawing routines result in a variety of seemingly unexplainable
>> errors: e.g. on an 800x800 canvas a long vertical line (550+ pixels) drawn
>> with pw_vector() will be displayed properly when drawn "downward" but
>> will cause a core dump when drawn "upward". Other problems include system
>> hanging, improper returns from procedures, shifted graphic displays, etc.
>> The debugger seems to indicate that the system stack is getting clobbered.
> We found the same thing, and called Sun. They said it was a known bug and
> sent us a tape with a new libpixrect.a on it. Problem is solved. We had
> to return the tape. I suggest you contact Sun Software support.
Until you can get the new libpixrect.a, the following patches away the problem:
adb -w file <<!
mem_vector+0x6de?w 0x4e71
!
Vern Paxson
Real Time Systems Group
Lawrence Berkeley Laboratory
(415) 486-6411
vern at lbl-csam.arpa
------------------------------
Date: Fri, 17 Oct 86 16:23:56 EDT
From: budd at BU-CS.BU.EDU (Philip Budne)
Subject: biff with NFS mounted /usr/spool/mail
We run timesharing on a cluster of three SUN-3/180s. All three
machines share a single mail queue. Here are changes to make biff
work in this environment.
The first problem is that /bin/mail only sends udp packets to the
comsat on localhost. Here is a change so that /bin/mail will send
packets to each host named biffhost-1 .... biffhost-N
****************************************************************
mail.c
****************************************************************
sendmail(n, name, fromaddr)
More information about the Mod.computers.sun
mailing list