Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22448; 2 Sep 89 3:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22366; 2 Sep 89 2:49 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa22355; 2 Sep 89 2:41 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06567; 2 Sep 89 2:33 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22916; Fri, 1 Sep 89 23:26:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 2 Sep 89 04:41:44 GMT From: George Phillips Organization: UBC Department of Computer Science, Vancouver, B.C., Canada Subject: GIF file viewer Message-Id: <4870@ubc-cs.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Since I got more requests for this program than I could count on my fingers, I decided to post it. Included is a GIF file viewer and a viewer for 24 bit images as found on venera.isi.edu. These programs both require a 24 bit deep display and have only been tried on a personal iris. I hope they'll end up in the archives at vgr.brl.mil, but if not I'll try and put them there myself. I look forward to your improvements. George Phillips phillips@cs.ubc.ca {alberta,uw-beaver,uunet}!ubc-cs!phillips #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'README' <<'END_OF_FILE' XThere are 2 programs here. igif will display GIF files on a personal Xiris workstation. vimg displays 24 bit RGB files in the venera imglib Xformat. Images in the imglib format can be found on venera.isi.edu. X XEach program uses very simple interfaces to graphics and windows. They Xwork and are more or less directly transliterated from examples in the Xgraphics documentation that came with our iris. X XBoth programs could use improvement, like getting rid of 24 bit mode or Xadding scroll bars and so on. If you do make improvements, please send Xthem to me (phillips@cs.ubc.ca {alberta,uw-beaver,uunet}!ubc-cs!phillips) Xand maybe I can keep track of future versions. X XBut most of all, have fun displaying images. X XGeorge Phillips XDepartment of Computer Science XUniversity of British Columbia END_OF_FILE if test 793 -ne `wc -c <'README'`; then echo shar: \"'README'\" unpacked with wrong size! fi # end of 'README' fi if test -f 'Makefile' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'Makefile'\" else echo shar: Extracting \"'Makefile'\" \(273 characters\) sed "s/^X//" >'Makefile' <<'END_OF_FILE' XCFLAGS= X X# If this doesn't work, try LIB=-Zg XLIB=-lgl_s X Xall: igif vimg X Xigif: igif.o decoder.o X cc -o igif igif.o decoder.o $(LIB) X Xdecoder.o: errs.h std.h X Xvimg: vimg.o X cc -o vimg vimg.o $(LIB) X Xshar: X shar README Makefile igif.c decoder.c errs.h std.h vimg.c >img.shar END_OF_FILE if test 273 -ne `wc -c <'Makefile'`; then echo shar: \"'Makefile'\" unpacked with wrong size! fi # end of 'Makefile' fi if test -f 'igif.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'igif.c'\" else echo shar: Extracting \"'igif.c'\" \(6871 characters\) sed "s/^X//" >'igif.c' <<'END_OF_FILE' X/* X * igif.c -- display a GIF image on the personal iris. X * X * usage: igif [ file.gif ] X * X * Will display the GIF file given as the first argument or a GIF file X * read from standard input if no arguments are given. X * X * This is not a particularly pretty piece of code. This works on the X * personal iris we have here, but has not been tested on other irises X * or other SGI machines. It uses 24 bit RGB mode because that's all X * I have looked into (plus it's easy :-). GIF images are pretty much X * limited to 256 colours, so using some sort of colourmap mode should X * be possible. Those with more experience could also modify the program X * to display multiple GIF images with a single invocation. X * X * Copyright 1989 by George Phillips X * X * Permission is granted to freely distribute this program in whole or in X * part provided you don't make money off it, you don't pretend that you X * wrote it and that this notice accompanies the code. X * X * The GIF LZW decoder was written by someone else who's copyright notice X * is contained in decode.c. X * X * George Phillips X * Department of Computer Science X * University of British Columbia X */ X X#include X#include X#include X#include X X#include "errs.h" X Xint bad_code_count; XFILE* glob_fp; Xstatic char* gif_name; X Xmain(argc, argv) Xint argc; Xchar* argv[]; X{ X FILE* fp; X X if (argc > 2) { X fprintf(stderr, "Sorry, I can only do one GIF file at a time.\n"); X exit(1); X } X X if (argc == 1) { X gif_name = "standard input"; X gif_display(glob_fp = stdin); X } X else { X char* p; X char* lastslash; X X for (p = argv[1], lastslash = argv[1] - 1; *p; p++) X if (*p == '/') X lastslash = p; X X gif_name = lastslash + 1; X X if ((fp = fopen(argv[1], "r")) == NULL) { X fprintf(stderr, "can't open '%s'\n", argv[1]); X exit(1); X } X gif_display(glob_fp = fp); X } X screen_manage(); X exit(0); X} X Xstatic int err = 0; Xstatic long global[256]; Xstatic long local[256]; Xstatic long* cmap; Xstatic long* screen; Xstatic long* lineptr; Xstatic int i_y; Xstatic int pass; Xstatic long* imagestart; Xstatic int s_width; Xstatic int s_height; Xstatic int i_height; Xstatic int is_interlaced; X X#define error(x) printf("%s at byte %d\n", x, ftell(fp)); return(0) X#define reterr(x) if (err != 0) { error(x); } X#define reteof() reterr("Unexpected EOF") X#define skipbyte(x) getbyte(x); reteof() X Xgif_display(fp) XFILE* fp; X{ X static unsigned char buf[4096]; X int s_control, back; X int i_top, i_left, i_width, i_control; X int ch; X int nc; X int i, j; X X /* read signature */ X if (fread(buf, 3, 1, fp) != 1) { X error("File too short"); X } X X if (strncmp(buf, "GIF", 3)) { X error("Not a GIF file"); X } X X if (fread(buf, 3, 1, fp) != 1) { X error("File too short"); X } X X if (strncmp(buf, "87a", 3)) { X buf[3] = '\0'; X printf("unknown version '%s'\n", buf); X return(0); X } X X /* read screen descriptor */ X s_width = getword(fp); reteof(); X s_height = getword(fp); reteof(); X s_control = getbyte(fp); reteof(); X back = getbyte(fp); reteof(); X skipbyte(fp); X X if ((screen = (long*)malloc(sizeof(long) * s_width * s_height)) == NULL) { X fprintf(stderr, "not enough memory for screen, bye!\n"); X exit(1); X } X /* sure, I should use bzero. Whatever */ X { register int i; X for (i = 0; i < s_width * s_height; i++) X screen[i] = 0; X } X prefsize(s_width, s_height); X winopen(gif_name); X RGBmode(); X gconfig(); X X if (s_control & 128) { /* global colour map */ X if (fread(buf, (2 << (s_control & 7)) * 3, 1, fp) != 1) { X error("EOF in global colourmap"); X } X gif2rgb(buf, global, 2 << (s_control & 7)); X } X X for (;;) { X ch = getbyte(fp); X reterr("no terminator"); X switch (ch) { X case ',': /* image follows */ X i_left = getword(fp); reteof(); X i_top = getword(fp); reteof(); X i_width = getword(fp); reteof(); X i_height = getword(fp); reteof(); X i_control = getbyte(fp); reteof(); X is_interlaced = i_control & 64; X nc = 2 << (s_control & 7); X cmap = global; X if (i_control & 128) { /* local colour map */ X if (fread(buf, (2 << (i_control & 7)) * 3, 1, fp) != 1) { X error("EOF in local colourmap"); X } X nc = 2 << (i_control & 7); X gif2rgb(buf, local, nc); X cmap = local; X } X bad_code_count = 0; X imagestart = lineptr = screen + (s_width * i_top) + i_left + X (i_height - 1) * s_width; X i_y = 0; X pass = 0; X decoder(i_width); X /* ignore rest of blocks used by decoder */ X skipblocks(fp); reterr("Bad block in image"); X break; X case ';': /* terminator ... */ X return(0); X case '!': /* extension block */ X skipbyte(fp); /* function code */ X skipblocks(fp); reterr("Bad block in extension block"); X break; X default: X /* Supposed to ignore any unknown characters up to the image X * separator, but I prefer to be tight about these things because X * there are many corrupt images out there. X */ X printf("Unknown block type '%c' (%d) at byte %d\n", X ch, ch, ftell(fp)); X return(0); X } X } X} X X/* Convert the GIF colourmap into long rgb components which can be directly X * plunked into an lrect. X * X * GIF colourmap is a byte stream: rgbrgbrgb X * lrect format is in 4 byte words: abgr abgr abgr X * (the a is alpha, which should be zero) X */ Xgif2rgb(g, r, len) Xchar* g; Xlong* r; Xint len; X{ X register int i; X register int j; X X for (i = j = 0; i < len; i++, j += 3) X r[i] = g[j] | (g[j+1] << 8) | (g[j+2] << 16); X} X Xstatic int pass_width[] = { 8, 8, 4, 2 }; Xstatic int pass_start[] = { 0, 4, 2, 1 }; X Xout_line(pixel, linelen) Xunsigned char* pixel; Xint linelen; X{ X register int i; X X for (i = 0; i < linelen; i++) X lineptr[i] = cmap[pixel[i]]; X X if (!is_interlaced) { X lineptr -= s_width; X } X else { X lineptr -= pass_width[pass] * s_width; X i_y += pass_width[pass]; X if (i_y >= i_height) { X pass++; X i_y = pass_start[pass]; X lineptr = imagestart - pass_start[pass] * s_width; X } X } X} X Xint get_byte() X{ X return(getbyte(glob_fp)); X} X Xint getbyte(fp) XFILE* fp; X{ X int ch; X X err = 0; X if ((ch = fgetc(fp)) == EOF) { X err = 1; X return(READ_ERROR); X } X return(ch & 255); X} X Xint getword(fp) XFILE* fp; X{ X int c1, c2; X X err = 0; X if ((c1 = fgetc(fp)) == EOF) { X err = 1; X return(0); X } X if ((c2 = fgetc(fp)) == EOF) { X err = 1; X return(0); X } X return(((c2 & 255) << 8) | (c1 & 255)); X} X Xskipblocks(fp) XFILE* fp; X{ X int len; X static char buf[256]; X X err = 0; X X for (;;) { X len = getbyte(fp); X reterr("EOF in blocks"); X X if (len == 0) X return(0); X X if (fread(buf, len, 1, fp) != 1) { X puts("EOF in blocks"); X err = 1; X return(0); X } X } X} X Xscreen_manage() X{ X lrectwrite(0, 0, s_width - 1, s_height - 1, screen); X X qdevice(REDRAW); X qdevice(PIECECHANGE); X qdevice(WINQUIT); X X while (1) { X short data; X X switch (qread(&data)) { X case REDRAW: X case PIECECHANGE: X lrectwrite(0, 0, s_width - 1, s_height - 1, screen); X break; X case WINQUIT: X exit(0); X default: X break; X } X } X} X END_OF_FILE if test 6871 -ne `wc -c <'igif.c'`; then echo shar: \"'igif.c'\" unpacked with wrong size! fi # end of 'igif.c' fi if test -f 'decoder.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'decoder.c'\" else echo shar: Extracting \"'decoder.c'\" \(12570 characters\) sed "s/^X//" >'decoder.c' <<'END_OF_FILE' X/* DECODE.C - An LZW decoder for GIF X * Copyright (C) 1987, by Steven A. Bennett X * X * Permission is given by the author to freely redistribute and include X * this code in any program as long as this credit is given where due. X * X * In accordance with the above, I want to credit Steve Wilhite who wrote X * the code which this is heavily inspired by... X * X * GIF and 'Graphics Interchange Format' are trademarks (tm) of X * Compuserve, Incorporated, an H&R Block Company. X * X * Release Notes: This file contains a decoder routine for GIF images X * which is similar, structurally, to the original routine by Steve Wilhite. X * It is, however, somewhat noticably faster in most cases. X * X * GWP -- if GINFO if defined, it will use a global variable and X * stdio routines in place of most of the get_byte calls to speed X * things along. X */ X X#define GINFO X X#ifdef GINFO X X#include Xextern FILE* glob_fp; X X#endif X X#include "std.h" X#include "errs.h" X XIMPORT TEXT *malloc(); /* Standard C library allocation */ X X/* IMPORT INT get_byte() X * X * - This external (machine specific) function is expected to return X * either the next byte from the GIF file, or a negative number, as X * defined in ERRS.H. X */ XIMPORT INT get_byte(); X X/* IMPORT INT out_line(pixels, linelen) X * UBYTE pixels[]; X * INT linelen; X * X * - This function takes a full line of pixels (one byte per pixel) and X * displays them (or does whatever your program wants with them...). It X * should return zero, or negative if an error or some other event occurs X * which would require aborting the decode process... Note that the length X * passed will almost always be equal to the line length passed to the X * decoder function, with the sole exception occurring when an ending code X * occurs in an odd place in the GIF file... In any case, linelen will be X * equal to the number of pixels passed... X */ XIMPORT INT out_line(); X X/* IMPORT INT bad_code_count; X * X * This value is the only other global required by the using program, and X * is incremented each time an out of range code is read by the decoder. X * When this value is non-zero after a decode, your GIF file is probably X * corrupt in some way... X */ XIMPORT INT bad_code_count; X X#ifndef GINFO X#define NULL 0L X#endif X X#define MAX_CODES 4095 X X/* Static variables */ XLOCAL WORD curr_size; /* The current code size */ XLOCAL WORD clear; /* Value for a clear code */ XLOCAL WORD ending; /* Value for a ending code */ XLOCAL WORD newcodes; /* First available code */ XLOCAL WORD top_slot; /* Highest code for current size */ XLOCAL WORD slot; /* Last read code */ X X/* The following static variables are used X * for seperating out codes X */ XLOCAL WORD navail_bytes = 0; /* # bytes left in block */ XLOCAL WORD nbits_left = 0; /* # bits left in current byte */ XLOCAL UTINY b1; /* Current byte */ XLOCAL UTINY byte_buff[257]; /* Current block */ XLOCAL UTINY *pbytes; /* Pointer to next byte in block */ X XLOCAL LONG code_mask[13] = { X 0, X 0x0001, 0x0003, X 0x0007, 0x000F, X 0x001F, 0x003F, X 0x007F, 0x00FF, X 0x01FF, 0x03FF, X 0x07FF, 0x0FFF X }; X X X/* This function initializes the decoder for reading a new image. X */ XLOCAL WORD init_exp(size) X WORD size; X { X curr_size = size + 1; X top_slot = 1 << curr_size; X clear = 1 << size; X ending = clear + 1; X slot = newcodes = ending + 1; X navail_bytes = nbits_left = 0; X return(0); X } X X/* get_next_code() X * - gets the next code from the GIF file. Returns the code, or else X * a negative number in case of file errors... X */ XLOCAL WORD get_next_code() X { X WORD i, x; X ULONG ret; X X if (nbits_left == 0) X { X if (navail_bytes <= 0) X { X X /* Out of bytes in current block, so read next block X */ X pbytes = byte_buff; X#ifdef GINFO X if ((navail_bytes = fgetc(glob_fp)) == EOF) X return(READ_ERROR); X#else X if ((navail_bytes = get_byte()) < 0) X return(navail_bytes); X#endif X else if (navail_bytes) X { X#ifdef GINFO X if (fread(byte_buff, navail_bytes, 1, glob_fp) != 1) X return(READ_ERROR); X#else X for (i = 0; i < navail_bytes; ++i) X { X if ((x = get_byte()) < 0) X return(x); X byte_buff[i] = x; X } X#endif X } X } X b1 = *pbytes++; X nbits_left = 8; X --navail_bytes; X } X X ret = b1 >> (8 - nbits_left); X while (curr_size > nbits_left) X { X if (navail_bytes <= 0) X { X X /* Out of bytes in current block, so read next block X */ X pbytes = byte_buff; X#ifdef GINFO X if ((navail_bytes = fgetc(glob_fp)) == EOF) X return(READ_ERROR); X#else X if ((navail_bytes = get_byte()) < 0) X return(navail_bytes); X#endif X else if (navail_bytes) X { X#ifdef GINFO X if (fread(byte_buff, navail_bytes, 1, glob_fp) != 1) X return(READ_ERROR); X#else X for (i = 0; i < navail_bytes; ++i) X { X if ((x = get_byte()) < 0) X return(x); X byte_buff[i] = x; X } X#endif X } X } X b1 = *pbytes++; X ret |= b1 << nbits_left; X nbits_left += 8; X --navail_bytes; X } X nbits_left -= curr_size; X ret &= code_mask[curr_size]; X return((WORD)(ret)); X } X X X/* The reason we have these seperated like this instead of using X * a structure like the original Wilhite code did, is because this X * stuff generally produces significantly faster code when compiled... X * This code is full of similar speedups... (For a good book on writing X * C for speed or for space optomisation, see Efficient C by Tom Plum, X * published by Plum-Hall Associates...) X */ XLOCAL UTINY stack[MAX_CODES + 1]; /* Stack for storing pixels */ XLOCAL UTINY suffix[MAX_CODES + 1]; /* Suffix table */ XLOCAL UWORD prefix[MAX_CODES + 1]; /* Prefix linked list */ X X/* WORD decoder(linewidth) X * WORD linewidth; * Pixels per line of image * X * X * - This function decodes an LZW image, according to the method used X * in the GIF spec. Every *linewidth* "characters" (ie. pixels) decoded X * will generate a call to out_line(), which is a user specific function X * to display a line of pixels. The function gets it's codes from X * get_next_code() which is responsible for reading blocks of data and X * seperating them into the proper size codes. Finally, get_byte() is X * the global routine to read the next byte from the GIF file. X * X * It is generally a good idea to have linewidth correspond to the actual X * width of a line (as specified in the Image header) to make your own X * code a bit simpler, but it isn't absolutely necessary. X * X * Returns: 0 if successful, else negative. (See ERRS.H) X * X */ X XWORD decoder(linewidth) X WORD linewidth; X { X FAST UTINY *sp, *bufptr; X UTINY *buf; X FAST WORD code, fc, oc, bufcnt; X WORD c, size, ret; X X /* Initialize for decoding a new image... X */ X if ((size = get_byte()) < 0) X return(size); X if (size < 2 || 9 < size) X return(BAD_CODE_SIZE); X init_exp(size); X X /* Initialize in case they forgot to put in a clear code. X * (This shouldn't happen, but we'll try and decode it anyway...) X */ X oc = fc = 0; X X /* Allocate space for the decode buffer X */ X if ((buf = (UTINY *)malloc(linewidth + 1)) == NULL) X return(OUT_OF_MEMORY); X X /* Set up the stack pointer and decode buffer pointer X */ X sp = stack; X bufptr = buf; X bufcnt = linewidth; X X /* This is the main loop. For each code we get we pass through the X * linked list of prefix codes, pushing the corresponding "character" for X * each code onto the stack. When the list reaches a single "character" X * we push that on the stack too, and then start unstacking each X * character for output in the correct order. Special handling is X * included for the clear code, and the whole thing ends when we get X * an ending code. X */ X while ((c = get_next_code()) != ending) X { X X /* If we had a file error, return without completing the decode X */ X if (c < 0) X { X free(buf); X return(0); X } X X /* If the code is a clear code, reinitialize all necessary items. X */ X if (c == clear) X { X curr_size = size + 1; X slot = newcodes; X top_slot = 1 << curr_size; X X /* Continue reading codes until we get a non-clear code X * (Another unlikely, but possible case...) X */ X while ((c = get_next_code()) == clear) X ; X X /* If we get an ending code immediately after a clear code X * (Yet another unlikely case), then break out of the loop. X */ X if (c == ending) X break; X X /* Finally, if the code is beyond the range of already set codes, X * (This one had better NOT happen... I have no idea what will X * result from this, but I doubt it will look good...) then set it X * to color zero. X */ X if (c >= slot) X c = 0; X X oc = fc = c; X X /* And let us not forget to put the char into the buffer... And X * if, on the off chance, we were exactly one pixel from the end X * of the line, we have to send the buffer to the out_line() X * routine... X */ X *bufptr++ = c; X if (--bufcnt == 0) X { X if ((ret = out_line(buf, linewidth)) < 0) X { X free(buf); X return(ret); X } X bufptr = buf; X bufcnt = linewidth; X } X } X else X { X X /* In this case, it's not a clear code or an ending code, so X * it must be a code code... So we can now decode the code into X * a stack of character codes. (Clear as mud, right?) X */ X code = c; X X /* Here we go again with one of those off chances... If, on the X * off chance, the code we got is beyond the range of those already X * set up (Another thing which had better NOT happen...) we trick X * the decoder into thinking it actually got the last code read. X * (Hmmn... I'm not sure why this works... But it does...) X */ X if (code >= slot) X { X if (code > slot) X ++bad_code_count; X code = oc; X *sp++ = fc; X } X X /* Here we scan back along the linked list of prefixes, pushing X * helpless characters (ie. suffixes) onto the stack as we do so. X */ X while (code >= newcodes) X { X *sp++ = suffix[code]; X code = prefix[code]; X } X X /* Push the last character on the stack, and set up the new X * prefix and suffix, and if the required slot number is greater X * than that allowed by the current bit size, increase the bit X * size. (NOTE - If we are all full, we *don't* save the new X * suffix and prefix... I'm not certain if this is correct... X * it might be more proper to overwrite the last code... X */ X *sp++ = code; X if (slot < top_slot) X { X suffix[slot] = fc = code; X prefix[slot++] = oc; X oc = c; X } X if (slot >= top_slot) X if (curr_size < 12) X { X top_slot <<= 1; X ++curr_size; X } X X /* Now that we've pushed the decoded string (in reverse order) X * onto the stack, lets pop it off and put it into our decode X * buffer... And when the decode buffer is full, write another X * line... X */ X while (sp > stack) X { X *bufptr++ = *(--sp); X if (--bufcnt == 0) X { X if ((ret = out_line(buf, linewidth)) < 0) X { X free(buf); X return(ret); X } X bufptr = buf; X bufcnt = linewidth; X } X } X } X } X ret = 0; X if (bufcnt != linewidth) X ret = out_line(buf, (linewidth - bufcnt)); X free(buf); X return(ret); X } X END_OF_FILE if test 12570 -ne `wc -c <'decoder.c'`; then echo shar: \"'decoder.c'\" unpacked with wrong size! fi # end of 'decoder.c' fi if test -f 'errs.h' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'errs.h'\" else echo shar: Extracting \"'errs.h'\" \(366 characters\) sed "s/^X//" >'errs.h' <<'END_OF_FILE' X/* Various error codes used by decoder X * and my own routines... It's okay X * for you to define whatever you want, X * as long as it's negative... It will be X * returned intact up the various subroutine X * levels... X */ X#define OUT_OF_MEMORY -10 X#define BAD_CODE_SIZE -20 X#define READ_ERROR -1 X#define WRITE_ERROR -2 X#define OPEN_ERROR -3 X#define CREATE_ERROR -4 X END_OF_FILE if test 366 -ne `wc -c <'errs.h'`; then echo shar: \"'errs.h'\" unpacked with wrong size! fi # end of 'errs.h' fi if test -f 'std.h' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'std.h'\" else echo shar: Extracting \"'std.h'\" \(278 characters\) sed "s/^X//" >'std.h' <<'END_OF_FILE' X/* STD.H - My own standard header file... X */ X X#define LOCAL static X#define IMPORT extern X X#define FAST register X Xtypedef short WORD; Xtypedef unsigned short UWORD; Xtypedef char TEXT; Xtypedef unsigned char UTINY; Xtypedef long LONG; Xtypedef unsigned long ULONG; Xtypedef int INT; X END_OF_FILE if test 278 -ne `wc -c <'std.h'`; then echo shar: \"'std.h'\" unpacked with wrong size! fi # end of 'std.h' fi if test -f 'vimg.c' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'vimg.c'\" else echo shar: Extracting \"'vimg.c'\" \(4677 characters\) sed "s/^X//" >'vimg.c' <<'END_OF_FILE' X/* X * vimg -- display a venera imglib 24 bit image. X * X * usage: vimg picture X * or X * vimg picture.a X * X * This program will display the 24 bit RGB images which can be ftp'ed from X * venera.isi.edu. The format is very simple. Using some base name (like X * "picture"), the following files are relevant: X * X * picture.a -- contains width and height information X * picture.r -- red component of image (1 byte per pixel) X * picture.g -- green component of image (ditto) X * picture.b -- blue component of image (ditto) X * X * The program will either take a base name or the .a version. Also, if any of X * the files are compressed, it will run uncompress -c on them. In other words, X * it will also look for .r.Z, .b.Z and .g.Z files. I'm not really sure what X * the standard iris setup is, but if you don't have /usr/bsd in you path, X * it won't work. Either add it to your path or change "uncompress" to X * /usr/bsd/uncompress in the program. X * X * BUGS: X * X * If image is bigger than 1024 on any side, then I should clip it. But I X * don't since it gives me the urge for scrollbars... X * X * It seems if any optimization is turned on, then it will break if any of the X * red, green or blue components (.r, .g or .b files) is _not_ compressed. X * X * X * Copyright 1989 by George Phillips X * X * Permission is granted to freely distribute this program in whole or in X * part provided you don't make money off it, you don't pretend that you X * wrote it and that this notice accompanies the code. X * X * George Phillips X * Department of Computer Science X * University of British Columbia X */ X X#include X#include X#include X#include X Xint width; Xint height; X Xlong* img; Xchar* buf; X Xmain(argc, argv) Xint argc; Xchar* argv[]; X{ X int i; X FILE* fp; X char att[256], red[256], green[256], blue[256]; X char* myalloc(); X FILE* myopen(); X char* p; X char* lastdot; X char* shortname; X char ch; X char dimen[256]; X X if (argc != 2) { X fprintf(stderr, "usage: vimg basename OR vimg basename.a\n"); X exit(1); X } X X shortname = argv[1] - 1; X lastdot = NULL; X for (p = argv[1]; *p; p++) X if (*p == '.') X lastdot = p; X else if (*p == '/') X shortname = p; X X shortname++; X X if (lastdot != NULL && !strcmp(lastdot, ".a")) X *lastdot = '\0'; X X sprintf(att, "%s.a", argv[1]); X fp = myopen(att); X fgets(dimen, 256, fp); X ch = dimen[4]; X dimen[4] = '\0'; X width = atoi(dimen); X dimen[4] = ch; X dimen[8] = '\0'; X height = atoi(dimen + 4); X X printf("%s: width = %d, height = %d\n", argv[1], width, height); X myclose(); X X img = (long*)myalloc(sizeof(long) * width * height); X buf = myalloc(width); X X for (i = 0; i < width * height; i++) X img[i] = 0; X X sprintf(red, "%s.r", argv[1]); X printf("reading %s\n", red); X getcom(myopen(red), 0); X myclose(); X X sprintf(green, "%s.g", argv[1]); X printf("reading %s\n", green); X getcom(myopen(green), 8); X myclose(); X X sprintf(blue, "%s.b", argv[1]); X printf("reading %s\n", blue); X getcom(myopen(blue), 16); X myclose(); X X prefsize(width, height); X winopen(shortname); X RGBmode(); X gconfig(); X lrectwrite(0, 0, width - 1, height - 1, img); X X qdevice(REDRAW); X qdevice(PIECECHANGE); X qdevice(WINQUIT); X X while (1) { X short data; X X switch (qread(&data)) { X case REDRAW: X case PIECECHANGE: X lrectwrite(0, 0, width - 1, height - 1, img); X break; X case WINQUIT: X exit(0); X default: X break; X } X } X} X Xgetcom(fp, shift) XFILE* fp; Xint shift; X{ X FILE* fp; X long* line; X int i; X X line = img + width * height - width; X while (fread(buf, width, 1, fp) == 1) { X if (line < img) { X printf("extra data, oh well, ignored\n"); X break; X } X for (i = 0; i < width; i++) X line[i] |= (buf[i] << shift); X line -= width; X } X} X Xfatal(s) Xchar* s; X{ X fprintf(stderr, "%s\n", s); X exit(1); X} X X/* open a file, or a pipe to uncompress -c if it is compressed */ X/* myclose is very hardwired, but will work as long as only 1 file */ X/* is opened by myopen at a time */ X Xint ftype; XFILE* glob_fp; X XFILE* myopen(fname) Xchar* fname; X{ X FILE* fp; X char cmd[256]; X X if ((fp = fopen(fname, "r")) == NULL) { X sprintf(cmd, "%s.Z", fname); X if (access(cmd, 4) < 0) { X fprintf(stderr, "Can't open %s or %s.Z\n", fname, fname); X exit(1); X } X sprintf(cmd, "uncompress -c %s.Z", fname); X if ((fp = popen(cmd, "r")) == NULL) { X fprintf(stderr, "can't open %s or %s.Z\n", fname, fname); X exit(1); X } X ftype = 2; X } X else X ftype = 1; X return(glob_fp = fp); X} X Xmyclose() X{ X if (ftype == 1) X fclose(glob_fp); X else X pclose(glob_fp); X} X X/* malloc or die! */ Xchar* myalloc(size) Xint size; X{ X char* p; X X if ((p = malloc(size)) == NULL) { X fprintf(stderr, "out of memory\n"); X exit(1); X } X return(p); X} END_OF_FILE if test 4677 -ne `wc -c <'vimg.c'`; then echo shar: \"'vimg.c'\" unpacked with wrong size! fi # end of 'vimg.c' fi echo shar: End of shell archive. exit 0   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25692; 2 Sep 89 18:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25646; 2 Sep 89 18:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25634; 2 Sep 89 18:19 EDT Received: from uunet.UU.NET by SMOKE.BRL.MIL id aa16834; 2 Sep 89 18:01 EDT Received: from lsr-vax.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA17702; Sat, 2 Sep 89 17:59:47 -0400 Received: from lsr-sunl. by (4.1/SMI-4.0) id AA19954; Sat, 2 Sep 89 17:39:06 EDT Date: Sat, 2 Sep 89 17:39:06 EDT From: Art Hays - PSTAFF Message-Id: <8909022139.AA19954@> To: uunet!brl.mil!info-iris@uunet.uu.net Subject: Question re: Remote backup to Exabytes I have an Exabyte on a Sun. I would like to backup an Iris 4D/120 to it over the network. I would appreciate some info: 1.) What would the "/etc/brutab" entry be for a remote Exabyte? 2.) Is there a better way than 'bru' to do remote backups to Exabytes? Art Hays, Nat. Eye Institute, uunet!lsr-vax!art Nat. Institutes of Health, Bethesda, MD (301) 496-7143   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29647; 3 Sep 89 6:12 EDT Received: by VMB.BRL.MIL id aa29481; 3 Sep 89 6:02 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29077; 3 Sep 89 2:44 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa29064; 3 Sep 89 2:34 EDT Received: from uxc.cso.uiuc.edu by SMOKE.BRL.MIL id aa21877; 3 Sep 89 2:31 EDT Received: from kailand.UUCP by uxc.cso.uiuc.edu with UUCP (5.61+/IDA-1.2.8) id AA29277; Sun, 3 Sep 89 00:39:14 -0500 Received: by kailand.kai.com (4.12/kai2.5c/09-20-88) id AA04861; Sat, 2 Sep 89 21:34:21 cdt Date: Sat, 2 Sep 89 21:34:21 cdt From: Patrick Wolfe Message-Id: <8909030234.AA04861@kailand.kai.com> To: info-iris@BRL.MIL Subject: Question re: Remote backup to Exaby >From: Art Hays - PSTAFF > I have an Exabyte on a Sun. I would like to backup an Iris >4D/120 to it over the network. I would appreciate some info: > >2.) Is there a better way than 'bru' to do remote backups to Exabytes? I suggest GNU tar (anonymous ftp it from prep.ai.mit.edu, plus you'll want the diffs I posted here a couple weeks back). I currently use it to backup from our System V hosts (including two 4D's) to our BSD hosts, where our 1/2" tape drives are. Our 2 Gb drive is due to arrive within a week. With over 7 Gb online, you can imagine my excitement. I will now be able to transport our full backups on four tiny cartridges instead of 40 10-1/2" reels. Also, Since I'll no longer need to be present to mount tapes, our weekly and daily incremental backups will be run overnight, when nobody is online, and a little extra disk I/O won't be noticed.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00724; 4 Sep 89 2:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00611; 4 Sep 89 1:46 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00608; 4 Sep 89 1:33 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00711; 4 Sep 89 1:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA24000; Sun, 3 Sep 89 22:05:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Sep 89 04:53:51 GMT From: Rayan Zachariassen Subject: Re: 'w' for Iris 4D Message-Id: <89Sep4.005321edt.2142@neat.cs.toronto.edu> References: <3263@watale.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL neat.cs.toronto.edu:~ftp/pub/sgi/w.tar.Z contains w.c and etc/lavd.c, the latter a daemon which puts the load average in shared mem segment for the benefit of w.c. This is for 3.1, and should work under 3.2 although it seems avenrun will be available in 3.2. Hmm, perhaps the kernel should maintain the shmem segment. This stuff is PD as a subtle encouragement for SGI to provide a 'w' with their releases. (hint, wink, nudge, ...) rayan   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01579; 4 Sep 89 10:53 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01560; 4 Sep 89 10:42 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa01558; 4 Sep 89 10:36 EDT Received: from decwrl.dec.com by ADM.BRL.MIL id aa25952; 4 Sep 89 10:23 EDT Received: by decwrl.dec.com; id AA00575; Mon, 4 Sep 89 06:52:03 -0700 Received: from es37.escd.uucp by esyp.uucp (3.2/SMI-3.2) id AA13243; Sun, 3 Sep 89 22:06:27 PDT Received: by es37.escd.uucp (3.2/SMI-3.2) id AA04472; Sun, 3 Sep 89 22:09:53 PDT Date: Sun, 3 Sep 89 22:09:53 PDT From: Nils Davis Message-Id: <8909040509.AA04472@es37.escd.uucp> To: info-iris@BRL.MIL Subject: Mandelbrot set with neighborhood approximation In one of the Iris magazines a few months back there was an article about a fast algorithm for approximating Mandelbrot sets. It used a function that determined how far a given point was to the Mandelbrot set, then eliminated a circle that size, around that point, from its calculations. If any of you have figured out what I'm talking about, can you send me either the source for this program or a description of the algorithm? Thanks in advance -- please mail directly to me, as I don't read this group normally. I will post to the net if I anyone asks (or whoever responds to this can post to the net, as long as you mail to me also :-) ). Nils Davis Evans & Sutherland Computer Division ...decwrl!escd!nils 415/969-9300 "Does anyone have an alibi for Tuesday night? I don't, of course." "No you don't, to put it gently. Being at the scene of a crime at the moment of its commission is not normally considered an alibi..." Double Negative by David Carkeet   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02318; 4 Sep 89 16:11 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02287; 4 Sep 89 16:00 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa02282; 4 Sep 89 15:49 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa27485; 4 Sep 89 15:38 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA00789; Mon, 4 Sep 89 12:27:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Sep 89 19:20:17 GMT From: Timothy Hall Organization: Boston Univ. Subject: mmode and patch Message-Id: <37519@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does the 'patch' routine work while in 'mmode( MVIEWING )' ? When I tried this I got a singular matrix error from invert matrix. (Yes, one of my patch matricies is singular) When I replaced the patch routine with moves and draws it worked fine. Granted using the patch routine and mmode( MVIEWING ) doesn't normally make much sense but I was playing around with stereo viewing and using two different projection matricies. It would be easiest to just load these into the graphics engine projection matrix rather than saving the transformation matrix and applying the projection each time I want to render a scene. While on the subject of 3-D viewing. Has anybody out there tried the LCD glasses? (I'm just using colored lenses) A figuere of $2k seems to stick in my mind for them - is that right? If so, has anybody tried going to Toys R' Us and getting Sega or Nintendo glasses and hooking them up to the SGI? (These run about $100) -Tim Hall Boston Univ. Computer Graphics Lab tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03255; 4 Sep 89 23:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03192; 4 Sep 89 23:36 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa03186; 4 Sep 89 23:25 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa29801; 4 Sep 89 23:18 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA21132; Mon, 4 Sep 89 20:05:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 89 02:54:16 GMT From: Pablo Fernicola Organization: UF Machine Intelligence Laboratory Subject: SGI PI <--> Sun Message-Id: <20824@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL We just got our Personal Iris connected to an Ethernet. There is a Sun on the same Ethernet and I would like to "drive" the Personal Iris graphics from within an application running on the Sun. I would appreciate _ANY_ suggestions on how I can do this. Thanks!! Pablo pff@beach.cis.ufl.edu -- pff@beach.cis.ufl.edu Pablo Fernicola - Machine Intelligence Laboratory - UF "If we knew how it works, it wouldn't be called research."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08546; 5 Sep 89 10:20 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08299; 5 Sep 89 10:09 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08243; 5 Sep 89 9:53 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa03530; 5 Sep 89 8:56 EDT Received: Tue, 5 Sep 89 08:54:33 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 5 Sep 89 08:54:33 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8909051554.AA00507@aero4.larc.nasa.gov> To: tjh@bu-cs.bu.edu Subject: Re: mmode and patch Cc: info-iris@BRL.MIL I saw the LCD glasses at SIGGRAPH '89. They didn't work for me, but I was in a rush, so I don't know if I was using them correctly. I just got pricing information from the company. The glasses ONLY are $1745. What else you buy depends on what kind of hardware you already have. Here is the company and their address: StereoGraphics Corporation P.O. Box 2309 San Rafael, CA 94912 (415) 459-4500 FAX: 415-459-3020 Personally, I think the passive glasses systems sound more economical. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09647; 5 Sep 89 12:02 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09547; 5 Sep 89 11:52 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09413; 5 Sep 89 11:35 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa00285; 5 Sep 89 11:21 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA24002; Tue, 5 Sep 89 08:16:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 89 14:13:00 GMT From: wcwang@iuvax.cs.indiana.edu Organization: Indiana University CSCI, Bloomington Subject: 3D real-time workstations Message-Id: <56600001@iuvax> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A group of professors here at Indiana University are in the process of selecting computers for running experiments using visual stimuli. Our needs range from modest to demanding -- the most demanding is real time animation of high resolution, shaded 3D =================== ========= objects, the least demanding is animation of low-resolution 2D objects. In all cases, we need to collect reaction time responses from subjects. This probably requires real-time workstations. Does anyone have recommendatios regards to our requirements? Our burget is somehow limited to be about 4 workstations with a prices tag of less than $20,000 per unit. My main concern right now is to find out what's available in the market in our price range and get some details about them. We're interested in any and all information we can get, regarding configurations, compatibilities, caveats, endorsements... We're starting from scratch. Please e-mail me the responses if possible. Thanks very much. Bill Wang US Mail = Psychology Dept., Indiana University, Bloomington, IN 47405 UUCP = {rutgers, att, ames}!iuvax!wcwang Internet = wcwang@iuvax.cs.indiana.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16401; 5 Sep 89 16:40 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16010; 5 Sep 89 16:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa15889; 5 Sep 89 16:18 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa10996; 5 Sep 89 16:08 EDT Received: Tue, 5 Sep 89 16:05:58 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 5 Sep 89 16:05:58 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8909052305.AA02346@aero4.larc.nasa.gov> To: wcwang@iuvax.cs.indiana.edu Subject: Re: 3D real-time workstations Cc: info-iris@BRL.MIL I don't think you can do it, unless SGI gives you a big discount since you are a University. The only thing I have seen that would come close to what you want would be and SGI Personal IRIS 4D/20. I think that would give you 8 bit planes of color, 19" color monitor, and a disk, I think. 19" monitor is a must. I would buy an extra 8Mb of memory from a 3rd party to make a total of 16Mb on the Personal. 8Mb in a 4D/20 just isn't enough to do anything and 16Mb is the current max memory on them. 8 bit planes may not be enough color for you. For the price you are limited to, SGI 4D/20 would be the best way to go. Can you be any more specific on your requirements? I hope this is some help. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16933; 5 Sep 89 17:08 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab16401; 5 Sep 89 16:47 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16219; 5 Sep 89 16:32 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa11265; 5 Sep 89 16:17 EDT Received: Tue, 5 Sep 89 16:14:45 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Tue, 5 Sep 89 16:14:45 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8909052314.AA02365@aero4.larc.nasa.gov> To: mailrus!uflorida!beach.cis.ufl.edu!pff@purdue.edu Subject: Re: SGI PI <--> Sun Cc: info-iris@BRL.MIL For the 3000's there is a remote graphics library avaiable, I think, from SGI. If you can't get one from them, send mail to Diana Choi her email address is choi@prandtl.nas.nasa.gov. She should be able to help you or tell you who to contact. We use PLOT3D on Cray 2's and it uses the remote graphics library. All the calculations are done on the Cray and the graphics are done on the IRIS. It also works on Convex's too. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17593; 5 Sep 89 17:36 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17122; 5 Sep 89 17:26 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16930; 5 Sep 89 17:08 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11917; 5 Sep 89 16:50 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA11386; Tue, 5 Sep 89 13:42:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 89 20:27:13 GMT From: Gary Tarolli Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: SGI PI <--> Sun Message-Id: <41310@sgi.sgi.com> References: <20824@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <20824@uflorida.cis.ufl.EDU>, pff@beach.cis.ufl.edu (Pablo Fernicola) writes: > We just got our Personal Iris connected to an Ethernet. There is a Sun > on the same Ethernet and I would like to "drive" the Personal Iris graphics > from within an application running on the Sun. > SGI now sells the source to the DGL. It works on machines like SUN, VAX, and naturally the IRIS. In the near future it will work on CONVEX, CRAY, etc. You must still recompile the source and support it on your non-SGI machine, as we do not intend do buy one of each of the above mentioned machines. However, this work should be minimal once the initial port is working. Contact John Edelson at the main corporate number for details. There is an actual product code and a price and license agreement... -- Gary Tarolli   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18176; 5 Sep 89 19:56 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18134; 5 Sep 89 19:46 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18120; 5 Sep 89 19:35 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13992; 5 Sep 89 19:19 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA19480; Tue, 5 Sep 89 16:13:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 89 22:55:11 GMT From: Mark Moraes Organization: University of Toronto, CSRI Subject: semaphores vs locks? Message-Id: <1989Sep5.185510.7836@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL On an Iris4d multiprocessor, what is the difference between a semaphore and a lock? I couldn't find any specific mention of the difference in the documentation. As far as I can tell, semaphores have queues in which threads wait till the semaphore is freed, whereas locks are continuously retried (assuming ussetlock) with some delay. For a system with hardware locks, which is faster/cheaper - a semaphore or a lock? Does a lock consume much cpu time while spinning? Is the cost of going to sleep and awakening on a semaphore high? Does anyone have any numbers on these? Is there a section of the manual summarizing the parallel facilities available? (Suggestion: Perhaps a future release of the documentation could group manual pages by subsection and alphabetically - i.e. all manual pages for 3P together, rather than alphabetically across all subsections) The following is a list I've created, with some attempt to order them in 'recommended reading order'. Have I missed anything? usinit, _utrace (3P) - semaphore and lock initialization routine usconfig (3P) - semaphore and lock configuration operations taskblock, taskunblock, tasksetblockcnt (3P) - routines to block/unblock tasks taskcreate (3P) - create a new task taskdestroy (3P) - destroy a task taskctl (3P) - operations on a task barrier, new_barrier, free_barrier (3P) - barrier functions usnewlock (3P) - allocates and initializes a lock usinitlock (3P) - initializes a lock ussetlock, uscsetlock, uswsetlock, ustestlock, usunsetlock (3P) - lock routines usfreelock (3P) - free a lock usctllock (3P) - lock control operations usnewsema (3P) - allocates and initializes a semaphore usinitsema (3P) - initializes a semaphore uspsema (3P) - attempt to acquire a semaphore usvsema (3P) - frees a resource to a semaphore ustestsema (3P) - return the value of a semaphore uscpsema (3P) - attempts to acquire a semaphore, and fails if not possible usfreesema (3P) - free a semaphore usctlsema (3P) - semaphore control operations usmalloc, usfree, usrealloc (3P) - user shared memory allocator acreate, adelete, amalloc, afree, arealloc, acalloc, amallopt, amallinfo (3P) - arbitrary arena main memory allocator pcreate: pcreatel, pcreatev, pcreateve, pcreatelp, pcreatevp (3P) - create a process m_fork, m_kill_procs, m_set_procs, m_get_numprocs, m_get_myid, m_next, m_lock, m_unlock, (3P) - parallel programming primitives sproc (2) - create a new share group process blockproc, unblockproc, setblockproccnt (2) - routines to block/unblock processes Thanks.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18412; 5 Sep 89 20:38 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18043; 5 Sep 89 19:19 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18023; 5 Sep 89 19:04 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13476; 5 Sep 89 18:21 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA15210; Tue, 5 Sep 89 14:51:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Sep 89 21:07:33 GMT From: Thant Tessman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: mmode and patch Message-Id: <41314@sgi.sgi.com> References: <8909051554.AA00507@aero4.larc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909051554.AA00507@aero4.larc.nasa.gov>, blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854") writes: > > I saw the LCD glasses at SIGGRAPH '89. They didn't work for me, but > I was in a rush, so I don't know if I was using them correctly. They have four little buttons on the side for turning them on/off, clear/shuttered, stereo and pseudo. People of course messed with these a lot so the chances that you got them in the right mode is slim. > What else you buy depends on what kind of hardware you already have. > Here is the company and their address: > > StereoGraphics Corporation > P.O. Box 2309 > San Rafael, CA 94912 > (415) 459-4500 > FAX: 415-459-3020 They are also available through SGI as StereoView. > > Personally, I think the passive glasses systems sound more economical. Actually, they are much cheaper than the Z-screens (from both SteroGraphics and Tektronics) and they have better transmission and much less ghosting. Great taste AND less filling. Actually, if you wanted to show a roomfull of people a stereo image from a projection monitor, then the z-screen is cheaper than buying a couple dozen Crystal-Eyes. Call a sales type for pricing. thant@sgi.com -- ----------------------------------------------------------------------------- Let us say, then, to summarize, that a mythology is an organization of images conceived as a rendition of the sense of life, and that this sense is to be apprehended in two ways, namely: 1) the way of thought, and 2) the way of experience. As thought mythology approaches -or is a primative prelude to- science; and as expierience it is precicely art. - Joseph Campbell -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18647; 5 Sep 89 22:06 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa18608; 5 Sep 89 21:45 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18592; 5 Sep 89 21:31 EDT Received: from SNOW-WHITE.MERIT-TECH.COM by SMOKE.BRL.MIL id aa15407; 5 Sep 89 21:20 EDT Received: by snow-white.merit-tech.com (4.1/SMI-DDN) id AA11356; Tue, 5 Sep 89 15:17:00 CDT Date: Tue, 5 Sep 89 15:17:00 CDT From: Mike Goss Message-Id: <8909052017.AA11356@snow-white.merit-tech.com> To: blbates@aero4.larc.nasa.gov Subject: Passive glasses for stereo Cc: info-iris@BRL.MIL, tjh@bu-cs.bu.edu In reference to: > Date: Tue, 5 Sep 89 08:54:33 EDT > From: "Brent L. Bates AAD/TAB MS294 x42854" > Message-Id: <8909051554.AA00507@aero4.larc.nasa.gov> > To: tjh@bu-cs.bu.edu > Subject: Re: mmode and patch > . > . > . > Personally, I think the passive glasses systems sound more economical. As of about a year ago, the passive system (LCD screen polarizer plate, control box, and passive glasses) from Stereographics cost about $9000 to add to an IRIS 4D. This included hardware mods to the monitor. The price may have changed since. Although probably more expensive, the passive system is much more practical to use, and is more easily viewed by several people, since extra glasses are quite cheap. ------------------------------ Mike Goss Merit Technology Inc. (214)733-7018 goss@snow-white.merit-tech.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23588; 6 Sep 89 8:53 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21351; 6 Sep 89 8:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21132; 6 Sep 89 7:40 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa20849; 6 Sep 89 7:38 EDT Received: Wed, 6 Sep 89 07:36:37 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 6 Sep 89 07:36:37 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8909061436.AA04221@aero4.larc.nasa.gov> To: sgi!thant%horus.sgi.com@ucbvax.berkeley.edu Subject: Re: mmode and patch Cc: info-iris@BRL.MIL The though of asking a boss for $1800 for A pair of glasses, just didn't appeal to me. That is another reason the Z-screens sounded better too. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07027; 6 Sep 89 19:48 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06832; 6 Sep 89 18:45 EDT Received: from jarvis.csri.toronto.edu by VMB.BRL.MIL id aa06820; 6 Sep 89 18:28 EDT Received: by jarvis.csri.toronto.edu id 4956; Wed, 6 Sep 89 18:25:33 EDT To: info-iris@vmb.brl.mil From: dret@dgp.toronto.edu (George Drettakis) Subject: Power Series Arch Description Request Keywords: Cache, Locks, Scheduling, Threads Organization: University of Toronto, CSRI Distribution: list Date: Wed, 6 Sep 89 18:25:14 EDT Message-Id: <89Sep6.182533edt.4956@jarvis.csri.toronto.edu> I am interested in getting my hands on a document that will describe the Power Series parallel architecture. I am particularily interested in getting information on how the cache is organised both physically and from a software point of view, the cache consistency alg., how the hardware locks are implemented (the bus structure etc), how spin locks interact with the unix multi-programming environment, how the scheduler handles the "light-weight" threads and how they get assigned to processors and how the virtual address space is managed. A solid, public domain document (paper/tech report/memo/whatever) would be more than appreciated. Thanks, -- George Drettakis (416) 978 5473 Dynamic Graphics Project UUCP: ..!uunet!dgp.toronto.edu!dret Computer Systems Research Institute Bitnet: dret@dgp.utoronto University of Toronto Internet: dret@dgp.toronto.edu Toronto Ontario M5S 1A4 CANADA Ean: dret@dgp.toronto.cdn -- Live where it's never below 25 deg. C.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07840; 6 Sep 89 23:42 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07741; 6 Sep 89 23:21 EDT Received: by VMB.BRL.MIL id aa07728; 6 Sep 89 23:09 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07415; 6 Sep 89 21:45 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15381; 6 Sep 89 21:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09065; Wed, 6 Sep 89 18:23:12 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Sep 89 23:32:18 GMT From: Sanjay Iyer Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Sound chip for the Personal IRIS Message-Id: <41372@sgi.sgi.com> References: <8908311403.AA05313@zorac.DCIEM.DND.CA> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8908311403.AA05313@zorac.DCIEM.DND.CA>, tim@zorac.dciem.dnd.ca (Tim Pointing) writes: > > The sound chip exists on all Personal Irises. The only documentation is > > the man page for the driver /dev/audio. You will need to get a speaker > > and microphone. The PI has miniature audio jacks in the back. > > Does anybody have any info on things like leves and impedences for these > jacks or are they some "standard"? This ought to help: PERSONAL IRIS AUDIO I/O INFORMATION Line input: +/- 2.5 v (input is AC coupled) is full scale to ADC ADC is 8-bit, 2's complement Input impedance is 22K ohms. Input gains not adjustable. Frequency response: 20 Hz - 13 KHz @ 32K/sec sampling rate 20 Hz - 6.6 KHz @ 16K/sec sampling rate 20 Hz - 3.3 KHz @ 8K/sec sampling rate Microphone input: +/- 3.8 mv (input is AC coupled) is full scale to ADC ADC is 8-bit, 2's complement Input impedance 330 ohms. Designed for use with 300 ohm microphone. Input is summed (analog) with line input. Output: With full output gain (0xff) and no load, output swings +/- 4.9 v. Reduced output gain linearly reduces swing. Output is AC coupled (~4 ohms in series with 220 uf). Can directly drive 8 ohm speaker. (By the way there is no single sound chip; the audio circuit is composed of a combined ADC-DAC, another DAC for output gain control, a switched-capacitor filter, and misc amps).   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08123; 7 Sep 89 0:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07900; 7 Sep 89 0:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07867; 6 Sep 89 23:44 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16790; 6 Sep 89 23:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA16070; Wed, 6 Sep 89 20:31:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 89 02:58:44 GMT From: David Naegle Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: mmode and patch Message-Id: <41386@sgi.sgi.com> References: <37519@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <37519@bu-cs.BU.EDU>, tjh@bu-cs.BU.EDU (Timothy Hall) writes: > While on the subject of 3-D viewing. Has anybody out there tried the LCD > glasses? (I'm just using colored lenses) A figuere of $2k seems to stick > in my mind for them - is that right? If so, has anybody tried going to > Toys R' Us and getting Sega or Nintendo glasses and hooking them up to the SGI? > (These run about $100) > > -Tim Hall > Boston Univ. Computer Graphics Lab > tjh@bu-pub.bu.edu I haven't seen these glasses in operation, so I can't comment on the contrast ratio or the switching speed they provide. I think they are designed to work with 60Hz display monitors, which results in a refresh rate of 30Hz per eye. While it works, I doubt you'd be comfortable watching it for very long. We decided that 30Hz was an unacceptable refresh rate for an SGI product. (note: low refresh rates tend to make you crazy; scene update rates have much lower acceptable limits in most applications) To fix this flicker problem, we offer a multi-sync monitor as a neccessary part of the StereoView option. This monitor displays at 60Hz for all non-stereo applications, and automatically switches to a 120Hz display when a stereo application is run, so in either case you see 60Hz per eye. The stereo field signal (left eye/right eye) is only available in stereo mode (120Hz video) so you need the multi-sync monitor, even if you try to interface cheap game-type LCD glasses to the system. The current cost of the monitor is something like $3K (see a sales type for accurate pricing). In article <8909051554.AA00507@aero4.larc.nasa.gov>, blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS294 x42854") writes: > > Personally, I think the passive glasses systems sound more economical. Depends on your needs. A schoolbus is cheaper than a sports car on a per-seat basis, but it costs more than a sports car. (not to mention being a lot less fun to drive :-) I expect active stereo glasses to complement passive eyewear systems. Passive eyewear stereo systems should be used for group presentations because that's what's most economical. For individual users (a much bigger market in my opinion) you need a stereo technology which costs less than 10% of the workstation price. Also note that customer costs are tied to materials costs; it's going to be hard to make z-screens too much cheaper because of the high costs and low yeilds of the large-area LCDs involved. Active LCD glasses, on the other hand, are easy to make cheaper as the volumes increase, and multi-sync monitors are not much more expensive than other high-resolution monitors. So there are technical reasons to believe that active eyewear stereo will be an inexpensive, ubiquitous technology in the 3-D workstation market. David Naegle Graphics Hardware Manager naegle@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16198; 7 Sep 89 14:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15996; 7 Sep 89 14:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa15944; 7 Sep 89 14:07 EDT Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa02501; 7 Sep 89 13:57 EDT Received: Thu, 7 Sep 89 07:55:15 PDT by prandtl.nas.nasa.gov (5.51/1.2) Received: Thu, 7 Sep 89 10:56:07 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Thu, 7 Sep 89 11:10:08 EDT by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Thu, 7 Sep 89 11:10:08 EDT From: Tony Facca Message-Id: <8909071510.AA25465@lerc08.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: 3.1G lp problem/fix I don't remember if its been mentioned in this newsgroup yet or not, but everyone here who has upgraded to 3.1G has run across this problem, so I thought I'd mention it (again?): After the upgrade, you may notice that the lp spooler is not working properly. This is because the permissions on the /usr/spool/lp directory are inconsistent. Some of the symptoms may be: the lp command hangs, the lpstat command hangs, the scheduler is stopped, and some other minor anomilies which I don't quite understand (having to do with FIFO and SCHEDLOCK). To "fix" the problem, change the owner of the /usr/spool/lp directory to lp: chown lp /usr/spool/lp Everything seems to work quite nicely again. -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16739; 7 Sep 89 15:32 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16552; 7 Sep 89 15:22 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16468; 7 Sep 89 15:06 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04268; 7 Sep 89 14:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA28942; Thu, 7 Sep 89 11:22:12 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 89 16:17:00 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Overview of Parallel Synchronization Message-Id: <41394@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here is a formatted version of a section of the original IRIX software specification, written by yours truly. I can supply the raw MM source to anyone who wants it. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb --------------- cut here -------------------- Section 2 - 1 - Section_2:_Software_Synchronization ($Revision: 1.12 $ $Date: 86/09/23 17:27:33 $) 1. UNIX_On_Multiprocessors Much of the discussion in this section follows that in [1]. This section assumes that the Clover 2 multiprocessor structure will consist of two or more CPU's that share common memory and peripherals. Such a structure can potentially provide much greater throughput since processes can run concurrently on different processors. Each CPU executes independently, but all of them execute a single copy of the kernel. In general, processes are unaware that they are running on a multiprocessor, and can migrate between processors transparently. Unfortunately, a process does not consume less CPU time. Allowing several processors to execute simultaneously in the kernel causes integrity problems unless protection mechanisms are used. The original design of UNIX assumed that only a single processor would ever execute the kernel. Thus, kernel data structures could be protected by not preempting a process in the kernel. A kernel process gives up control of the processor voluntarily, through the normal UNIX sleep/wakeup mechanism. There are three ways in which corruption of kernel data structures can be prevented on a multiprocessor: 1. Execute the kernel on one processor only, which protects all kernel data structures but serializes all system functions. 2. Serialize small sections of code (critical regions) with locking primitives. This approach adds locking overhead, and may increase context switching. 3. Redesign algorithms to avoid contention for data structures. In many cases, this may be impossible to do and still maintain reasonable performance. AT&T currently sells a multiprocessor version of UNIX for the 3B20A attached processor system. In this UNIX kernel, locking primitives are used to create short critical sections where contention for kernel data structures may occur. This approach was chosen because, if properly designed and implemented, the problems of such locking can be managed easily without sacrificing system throughput or causing major redesigns of kernel algorithms. By partially porting and otherwise using this code as an example, it will September 7, 1989 Company Confidential Section 2 - 2 - be possible to implement a multiprocessor kernel in a short period of time that meets the response and throughput requirements of Clover 2. The remainder of this section is devoted to describing the locking primitives, how they are used in general and how they will be used in the Clover 2 kernel. 2. Semaphores 2.1 Spinlocks 2.1.1 General_Description The class of locking primitives used in the UNIX kernel goes under the general name of semaphores. The simplest semaphore is a spinlock. To access some critical resource, a processor attempts to acquire the lock using the simple algorithm: loop: if lock is set goto loop; set lock; The lock is obviously released simply by clearing it, which will allow at most one other processor to obtain it. If the testing and setting of the lock are not atomic, then it is possible that two processors may believe they have obtained the lock at the same time, or that neither has obtained the lock. The first case can result in corrupted data structures, while the second results in deadlock. Spinlocks can be implemented atomically in software (see [1]), however this solution is slow and may potentially waste a substantial number of cycles. Instead, most modern computers provide atomic test-and-set instructions, which allow a processor to obtain the lock in a single operation. 2.1.2 Spinlock_Usage Spinlocks are used whenever the time in which the lock is actually held by any one processor is very short. In these cases it is more efficient simply to wait for the lock rather than attempting to find some other useful work to do; the time spent searching for other work may exceed the time spent waiting for the lock. In a multiprocessor system, it is difficult to know when a spinlock may be more efficient than a mutual exclusion semaphore. The use of spinlocks must be empirically determined during system tuning, when the effects can be measured. Any very short operation is a candidate for spin locking. September 7, 1989 Company Confidential Section 2 - 3 - Example uses of sinplocks are for controlling free list access or performing linear scans of system tables. 2.1.3 Spinlocks_and_Interrupts One important aspect of locking that becomes apparent in any interrupt-driven system is the possibility that an asynchronous routine started by the hardware may take control of the CPU while it is attempting to obtain the lock. If the interrupt occurs after the lock has been obtained, then the time for which the lock is held can increase dramatically, seriously impacting system performance. If a spinlock is used to protect a resource to which an interrupt routine needs access, then similar problems arise. The interrupt routine remains active while spinning, blocking other important interrupt processing and degrading system performance. Finally, the consequence if an interrupt routine attempts to obtain the same lock that normal processing has just obtained is guaranteed deadlock of the system. To avoid all these problems, interrupts are disabled while attempting to obtain and while holding a spinlock. This re-enforces the necessity for spinlocks to be held as short a time as possible. 2.1.4 Hardware_Support The Clover 2 hardware will supply a large set of "virtual" locks, which will provide atomic test-and-set capabilities between the processors in the system. This provides a powerful mechanism for implementing spinlocks, since traffic on the multiprocessor bus can be avoided. The importance of having a very large set of these locks will become apparent in the following sections. 2.2 Mutual_Exclusion_Semaphores Once spinlocks are available, it becomes possible to implement more sophisticated types of semaphores. Once of these is the mutual exclusion semaphore, which is used to protect critical sections of code in a more intelligent manner than a spinlock. Such a semaphore is a data structure which consists of a counter and a queue of processes. The counter is initialized to the value one. There are two operations possible on such a semaphore, allocation, often called the acquire operation, and de- allocation and wakeup, often called the release operation. A process attempting to acquire the semaphore does so using the following (abbreviated) algorithm: September 7, 1989 Company Confidential Section 2 - 4 - if (counter <= 0) then add this process to end of queue of processes; block this process (allow another to run); on return, decrement the counter; continue with critical section; else decrement counter; continue with critical section; fi The release operation is performed in the following manner: increment counter; if (a process is waiting on the queue) { decrement counter; unblock the first process on the queue; } Obviously the above operations must be atomic in nature; a spinlock is used to protect the semaphore, and is locked before and unlocked after each of the above operations. 2.2.1 Usage Mutual exclusion semaphores are used where the length of the critical section to be protected is long or variable in length. This allows other processes to run and do useful work even though certain work must wait. Examples of such usage are when holding region entries for managing segments of virtual memory, or when using an inode to access disk files or devices. 2.2.2 Counting_Semaphores The mutual exclusion semaphore is a special case of a general counting semaphore. A counting semaphore is initialized to a value greater than one, allowing more than one process to acquire the semaphore at once. Counting semaphores are often used in resource allocation, where there is a fixed number of resources available. Another use is to provide atomic counters; the semaphore is released each time the counter should be incremented, but never acquired. The AT&T multiprocessor code uses many atomic counters but no counting semaphores; the Clover 2 product may include the use of counting semaphores for controlling certain resources. September 7, 1989 Company Confidential Section 2 - 5 - 2.3 Synchronization_Semaphores This third type of semaphore is used to synchronize different processes (possibly on different processors). A synchronization semaphore is actually a mutual exclusion semaphore, however the acquire and release operations are performed by different processes, affecting a rendezvous operation. Example usage is in awakening the paging daemon from the clock handler when memory is in short supply and a sufficient time interval has elapsed. 3. Multiprocessor_Semaphore_Primitives The AT&T 3B20A kernel introduced several new primitives to the kernel to provide semaphore facilities. One of the stated goals of the implementation was to provide a kernel that could run on either uniprocessors or multiprocessors with no modification to the kernel code, and to achieve this goal with only a minor decrease in uniprocessor performance. This goal was met. Each set of semaphore primitives is described below. Spinlock Primitives lock_t lock; spsema(&lock); - acquire the lock, spin until acquired svsema(&lock); - release the lock On a uniprocessor the spinlock primitives are commented out using the C preprocessor (since spinlocks are meaningless on a uniprocessor): # define spsema # define svsema The actual implementation of the spinlock is done using a 3B20 microcoded instruction for speed. On the MIPS processor, there is no test-and-set instruction. Thus, hardware support must be provided to insure that a high- performance path exists for performing this operation. The Clover 2 system will provide a separate, high-speed bus for synchronization among the processors in the complex. This bus will provide similar functionality to the SLIC VLSI chip done for the Sequent Balance multi-processor [2] The Sequent implementation provides 64 test-and-set variables which are global to all processors. In addition, a number of 32-bit September 7, 1989 Company Confidential Section 2 - 6 - registers were available that could be transferred between processors in an atomic fashion, provided a general message facility. This facility was used for distributing interrupts from I/O devices and communication between the processors. The Clover 2 implementation will be based on cheaper gate- array technology, and will be called the SYNC bus for brevity. Access to the SYNC bus will be through normal load and store operations in the physical address space of each processor. The SYNC bus will provide 4096 test-and-set locks. Each lock will be atomic in nature, thus a processor can use these locks for access control, busy waiting, or other uses. The locks will be grouped into 128 pages, each having 32 locks. This allows a group of locks to be mapped into the virtual address space of the processor, allowing user access to certain locks if so desired. Other facilities will be provided by the SYNC bus; they are not of interest here 1. Unlike the Sequent system, such a large number of locks allows each semaphore in the kernel to have a private lock, improving the overall performance of the system. Since no memory cycles are used once the busy-wait instruction has been loaded from memory, all memory traffic is eliminated. With high-speed spinlocks available, the semaphore operations can be defined. Synchronization Primitives sema_t sema; psema(&sema, PRI); - acquire the semaphore vsema(&sema); - release the semaphore cpsema(&sema, PRI); - conditionally acquire the semaphore Algorithmically, psema() is implemented as: __________ 1. The SYNC bus will provide 4 8-bit registers that can be incremented, decremented or set in an atomic fashion. This allows certain algorithms to be speeded up. In addition, the SYNC bus will be used for messaging interrupts both from the I/O system and between processors, eliminating this load on the system memory bus. September 7, 1989 Company Confidential Section 2 - 7 - BEGIN acquire semaphore lock; if (count <= 0) { decrement count; acquire semaphore queue lock; release semaphore lock; add process to semaphore queue; release semaphore queue lock; switch to another process; on return, return to caller; } else decrement count; release semaphore lock; return to caller; END The routine vsema() is implemented as: BEGIN acquire semaphore lock; increment count; if (count > 0) { acquire semaphore queue lock; if (a process is queued) { remove process from queue; unblock process; decrement count; } release semaphore lock; release semaphore queue lock; return; } release semaphore lock; END The routine cpsema() is used by a process which does not wish to block if the semaphore cannot be acquired. This is used in two instances. First, if the caller is an interrupt routine wishing access to a data structure, than it may not block. Thus, it uses cpsema() to acquire the semaphore, and takes some other action if the critical section is in use. Second, some algorithms require that multiple semaphores be used when updating related data structures. In this case, it is necessary to avoid blocking so that the system does not deadlock. This type of algorithm usually appears as: September 7, 1989 Company Confidential Section 2 - 8 - loop: psema(&sem1); . . . if (cpsema(&sem2)) { vsema(&sem1); goto loop; } . . . vsema(&sem2); vsema(&sem1); Cpsema() is also used in cases where semaphores must be acquired in a different order than they will be released. This is also a case where only a conditional operation will avoid deadlock. Cpsema() is implemented as: BEGIN acquire semaphore lock; if (count <= 0) { release semaphore lock; return failure; } else decrement count; release semaphore lock; Mutual Exclusion Primitives sema_t sema; appsema(&sema, PRI); - acquire the semaphore apvsema(&sema, PRI); - release the semaphore apcpsema(&sema); - conditionally acquire semaphore These primitives are implemented differently depending on whether the target system is a uniprocessor or a multiprocessor. The following C preprocessor definitions control this: September 7, 1989 Company Confidential Section 2 - 9 - # ifdef multiprocessor # define appsema psema # define apvsema vsema # define apcpsema cpsema # else # define appsema # define apvsema # define apcpsema # endif Thus, on a uniprocessor, these operations are not performed, since they would only add overhead and perform no useful purpose. On a multiprocessor, these operations are equivalent to the previously defined psema() and vsema() operations. Miscellaneous Primitives sema_t sema; initsema(&sema, value); - initialize the given semaphore valusema(&sema) - return the value of the semaphore 4. Uniprocessor_UNIX_Semaphore_Usage Although not explicitly shown in the code, normal UNIX uses several implicit semaphores to manage kernel data space in a crude manner. First, a single semaphore is used to protect all data structures from access by other processes: the mode, e.g., kernel or user. When in kernel mode, the current process may not be preempted, protecting kernel data structures. This is obviously a crude method of protection, but has the advantage of elegance and simplicity. This semaphore is a mutual exclusion semaphore. Second, the interrupt level of the processor is used to protect from access by interrupt routines. There are as many of these semaphores as there are interrupt levels in the processor. The kernel routines used to acquire and release these semaphores are the spl routines. These semaphores are spinlocks, since the interrupt is blocked by the processor only for short periods of time, and other processing (except higher priority interrupts) cannot continue while the lock is held. Third, process synchronization is performed using the sleep and wakeup primitives, which provide an inefficient yet elegant method for synchronization. The usual sequence for September 7, 1989 Company Confidential Section 2 - 10 - acquiring the semaphore is: while (flag & BUSY) { flag |= WANT; sleep(&flag); } flag |= BUSY; The sequence for releasing the semaphore is: flag &= ~BUSY; if (flag & WANT) { flag &= ~WANT; wakeup(&flag); } Thus, if more than one process is waiting on the semaphore, they will all awake at once, and must contend for the semaphore once again. 5. Multiprocessor_UNIX_Semaphore_Usage A multiprocessor UNIX kernel must abandon the mode semaphore, since multiple processors may be executing in the kernel at once. The sleep and wakeup primitives are replaced with synchronization semaphores. This provides a more efficient implementation, since only the first process waiting on the semaphore will awake, and that process will hold the semaphore once it does. Even through the multiprocessor UNIX kernel abandons the mode semaphore, it still disallows preemption of kernel processes on the same processor. This is for performance reasons. For example, consider the case where a kernel process is preempted, but the next process chosen to run needs access to the same resource. Eventually control will pass back to the preempted process, but only after a substantial amount of time and several unnecessary context switches. At points where the uniprocessor kernel used interrupt blocking to protect from interrupt routines, the multiprocessor kernel must also provide spinlocks to protect from other processors. Thus, a common sequence in the multiprocessor kernel is: September 7, 1989 Company Confidential Section 2 - 11 - x = spl6(); spsema(&lock); /* spsema() is discussed below */ . . . svsema(&lock); /* svsema is discussed below */ splx(x); The most difficult change is the use of mutual exclusion semaphores to protect kernel data structures that previously were protected by the mode semaphore. Thus, areas such as the buffer cache, process management and virtual memory management must be modified to use semaphores to insure exclusive access to structures. 5.1 Semaphores_and_Signals One aspect of the normal sleep/wakeup mechanism is that signal handling may be performed within these primitives if desired by the caller. This allows long waits to be interrupted by the user or application and proper cleanup to be performed. Thus, both mutual exclusion and synchronization semaphores provide the means by which a signal can be ignored or handled, in the same manner as that used by sleep/wakeup. An example call to a mutual exclusion semaphore is: psema(&sema, PPRI); psema(&sema, PPRI | PCATCH); In the first case, if the priority PPRI is greater than PZERO, than a signal which is sent to the process will cause the process to wake up, cleanup it's entry on the semaphore queue, and use longjmp() to return to the system call handler for return to the user. If the priority is less than PZERO, than such signals will always be ignored, and the process can only be woken by: vsema(&sema); In the second case, the PCATCH flag causes control to be returned to the caller when a signal occurs (if the priority is greater than PZERO, as before). Thus, the caller can take any necessary cleanup actions before returning to the application. September 7, 1989 Company Confidential Section 2 - 12 - 6. Semaphore_Performance In a semaphored system, there are a number of different factors that effect the performance of the system. Obviously, the more semaphore operations performed, the fewer cycles that will be devoted to real work. The speed with which a semaphore can be accessed and updated is also critical. AT&T dealt with this problem by micro-coding special instructions to handle the most common semaphore operations. There is one factor, however, that has an overriding effect on performance. This is the hit ratio on a semaphore. This is defined as the ratio of the number of times a semaphore could be acquired immediately to the number of attempts to acquire the semaphore. By examining the above algorithms, the reader can see that the optimal path is to immediately acquire the semaphore - blocking a process is an expensive and time-consuming operation. During construction of the multiprocessor kernel, AT&T discovered that a hit ratio of at least 95% on all semaphores was necessary to achieve adequate performance of the system. To achieve this goal, it is often necessary to break up data structure accesses into smaller chunks, and to isolate accesses as much as possible. For instance, the buffer cache is broken up into a large set of hash buckets that can be searched individually, reducing the contention on any one semaphore. Fortunately, AT&T has already done most of this work, providing the Clover 2 effort with high performance debugged algorithms for handling most of these cases. 7. Driver_Semaphore_Use Clover 2 will obtain most of it's UNIX drivers from the Clover I system. Converting drivers to semaphore use would be a long, costly and painful process, perhaps not worth the effort. To avoid the same situation for the 3B20A port, AT&T added the concept of driver semaphores to the kernel. Since a driver can only be entered in certain well-defined ways, it was possible to place a semaphore sequence around each entry to the driver. In general, these entry points are the open, close, read, write and ioctl entries. This is much like the mode semaphore in normal UNIX, in that it prevents any other process from entering the driver simultaneously. Three separate types of protection are provided. September 7, 1989 Company Confidential Section 2 - 13 - First, the entire driver can be semaphored on it's major device number. Before the kernel invokes the driver, it calls psema() to lock the driver semaphores, and after return from the driver it calls vsema() to unlock the semaphore. Second, each minor device number access to the driver can be semaphored. Instead of locking a single semaphore, each possible minor device number has a semaphore associated with it. The kernel locks the semaphore associated with the minor device before entering the driver and unlocks it after return. For example, this used in protecting the tty driver, which maintains independent structures for each minor device supported. Third, a driver can be given no protection, in which case it is responsible for protecting it's own data structures. This means that structures within the driver that are shared between processes or with interrupt routines must be protected with semaphores. To protect from interrupt access while a driver semaphore is locked, the kernel checks the driver semaphore before launching the interrupt routine. If the semaphore is locked, the kernel queues the interrupt and returns. The code which unlocks the driver semaphore checks for the queued interrupt, and if one exists it launches the interrupt routine at that time. Note that this behavior is only possible with major device locking. A driver that uses minor device locking must be modified to block the interrupt routine explicitly (if it does not already do so). If a driver choses to access kernel data structures, it will not be possible to port it directly to the multiprocessor environment. This is because it will not follow the kernel's locking strategy for the structures accessed. Such drivers must be modified to use the proper locking strategy before they can be used in the multiprocessor kernel. The Clover 2 kernel will implement the 3B20A driver concept, maximizing the use of currently existing drivers. In most cases, it should be possible to directly use drivers written for Clover I. It is expected that some drivers will require a porting effort. September 7, 1989 Company Confidential Section 2 - 14 - 8. Further_Reading Much of this discussion is based on the actual code for the AT&T 3B20A implementation, as well as [3] and [1]. September 7, 1989 Company Confidential Section 2 - 15 - REFERENCES 1. Bach, Maurice J., The Design of the UNIX Operating System, Prentice-Hall, Englewood Cliffs, N. J., 1986. 2. Beck, B., and Kasten, B., VLSI Assist in Building a Multiprocessor UNIX System, Sequent Computer Systems, Portland Oregon, not dated. 3. Bach, M. J., and Buroff, S. J., Multiprocessor UNIX Operating Systems, AT&T Bell Laboratories Technical Journal, Vol. 63, No. 8, October 1984. September 7, 1989 Company Confidential   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17362; 7 Sep 89 16:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16957; 7 Sep 89 15:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16801; 7 Sep 89 15:40 EDT Received: from SNOW-WHITE.MERIT-TECH.COM by SMOKE.BRL.MIL id aa03352; 7 Sep 89 14:22 EDT Received: by snow-white.merit-tech.com (4.1/SMI-DDN) id AA15114; Thu, 7 Sep 89 07:36:03 CDT Date: Thu, 7 Sep 89 07:36:03 CDT From: Mike Goss Message-Id: <8909071236.AA15114@snow-white.merit-tech.com> To: info-iris@BRL.MIL Subject: Stereo viewing techniques Regarding the continuing discussion of active vs. passive stereo viewing techniques, there is another point which is relevant to the choice of system. It is sometimes necessary for the user of a stereo system to view other, non-stereo video monitors in addition to a stereo display. With active glasses, it is necessary to remove the glasses to view other video sources; the glasses cause severe flicker otherwise. With passive glasses, it is still possible to view other video sources without flicker. Also, if multiple stereo monitors are in use, active glasses require that all video monitors have synchronized refresh cycles in order to be viewed simultaneously; passive glasses do not have this requirement. ------------------------------ Mike Goss Merit Technology Inc. (214)733-7018 goss@snow-white.merit-tech.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17362; 7 Sep 89 16:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab16957; 7 Sep 89 15:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab16801; 7 Sep 89 15:40 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04975; 7 Sep 89 15:05 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA01245; Thu, 7 Sep 89 11:58:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 89 14:31:31 GMT From: Tom Haapanen Organization: WATMIMS Research Group, University of Waterloo Subject: Iris 4D questions Message-Id: <3268@watale.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Two questions about booting an Iris 4D70: 1. Is it possible to make the machine boot automatically? Right now I have to type 'auto' on the console before it starts up. This means I have to come in to start it up if we have a power failure on a weekend, for example. 2. When the machine boots up, it starts a NeWS session with one window, containing the login. However, the 'tools' icon lets me create a shell, which automatically signs on as root!!! So anybody could get superuser access by rebooting the machine. Is there a way to make the system not generate a NeWS session? We're running 3.1G ... And one more: 3. Did anyone get the recent GIF viewer working on a 4D70? It compiled, and igif creates a window, but then says: ERROR #91 : is not implemented. What does this mean? Who didn't implement it? Thanks in advance! \tom haapanen "now, you didn't really expect tom@mims-iris.waterloo.edu my views to have anything to do watmims research group with my employer's, did you?" university of waterloo Amount taken in the average bank robbery in Canada in 1988: $ 4,000 In the average computer fraud in the same period: $ 42,000 -Report on Business Magazine, Sept/89   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17803; 7 Sep 89 16:38 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17557; 7 Sep 89 16:27 EDT Received: by VMB.BRL.MIL id aa17485; 7 Sep 89 16:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16402; 7 Sep 89 15:03 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03840; 7 Sep 89 14:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA28018; Thu, 7 Sep 89 11:06:08 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 89 15:53:07 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: 3D real-time workstations Message-Id: <41389@sgi.sgi.com> References: <56600001@iuvax> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <56600001@iuvax>, wcwang@iuvax.cs.indiana.edu writes: > > > A group of professors here at Indiana University are in the process > of selecting computers for running experiments using visual stimuli. > Our needs range from modest to demanding -- > the most demanding is real time animation of high resolution, shaded 3D > =================== ========= Actually, this is available on our low-end Personal IRIS machines with the Super graphics option. It is not demanding at all for an IRIS - real time movement of Gourad shaded 3D objects is what the machines were built to do. > objects, the least demanding is animation of low-resolution 2D objects. In Of course, 2D is a primitive subset of 3D ... > all cases, we need to collect reaction time responses from subjects. > This probably requires real-time workstations. Does anyone have > recommendatios regards to our requirements? Our burget is somehow > limited to be about 4 workstations with a prices tag of less than > $20,000 per unit. My main concern right now is to find out what's > available in the market in our price range and get some details > about them. The educational discount on a Super 4D/20 with minimal memory and disk should fit right into this price range (contact a salesperson for details). > > We're interested in any > and all information we can get, regarding configurations, compatibilities, > caveats, endorsements... We're starting from scratch. > Our sales force will be happy to give you all this stuff. > Please e-mail me the responses if possible. > > Thanks very much. > > Bill Wang > US Mail = Psychology Dept., Indiana University, Bloomington, IN 47405 > UUCP = {rutgers, att, ames}!iuvax!wcwang > Internet = wcwang@iuvax.cs.indiana.edu -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17803; 7 Sep 89 16:38 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab17557; 7 Sep 89 16:27 EDT Received: by VMB.BRL.MIL id ab17485; 7 Sep 89 16:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab16402; 7 Sep 89 15:03 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03938; 7 Sep 89 14:39 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA28918; Thu, 7 Sep 89 11:21:51 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 89 16:10:03 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: semaphores vs locks? Message-Id: <41392@sgi.sgi.com> References: <1989Sep5.185510.7836@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Sep5.185510.7836@jarvis.csri.toronto.edu>, moraes@csri.toronto.edu (Mark Moraes) writes: > On an Iris4d multiprocessor, what is the difference between a semaphore > and a lock? I couldn't find any specific mention of the difference in > the documentation. As far as I can tell, semaphores have queues in > which threads wait till the semaphore is freed, whereas locks are > continuously retried (assuming ussetlock) with some delay. > Semaphores and spinlocks are standard OS primitives which have existed for 25 years or more. There are many professors and others who have made their living writing textbooks about how to use these in operating systems. For a description in a UNIX context, Maurice Bach's book, "The Design of the UNIX Operating System" has a chapter dedicated to multiprocessing, where he describes how these primitives work (be careful though - there is a bug in the algorithm for psema() he gives). Fundamentally, a spinlock is a loop in software that does the following: while (!(location changes)) ; Thus, the spinlock reacts very quickly when the location changes, but some time may be wasted waiting for it. A semaphore is a queue with a counter, using a spinlock to protect the queue and the counter. Semaphores were originally designed by Edgar Dijkstra, as documented in the seminal paper "Cooperating Sequential Processes" which has been reprinted in hundreds of places. I'm posting a section of the original kernel design document that goes into some detail on this stuff. > For a system with hardware locks, which is faster/cheaper - a > semaphore or a lock? Does a lock consume much cpu time while spinning? > Is the cost of going to sleep and awakening on a semaphore high? Does > anyone have any numbers on these? Cost of a lock < cost of a semaphore. A semaphore implies that a context switch may happen, while none happens with a spinlock. The generic rule is that if the time spent spinning on the average is greater than the time to block a process and switch to another one, use a semaphore, else use a spinlock. > > Is there a section of the manual summarizing the parallel facilities > available? (Suggestion: Perhaps a future release of the documentation > could group manual pages by subsection and alphabetically - i.e. all > manual pages for 3P together, rather than alphabetically across all > subsections) The following is a list I've created, with some attempt > to order them in 'recommended reading order'. Have I missed anything? > The list given is complete. The parallel programmers guide is in final edit now, and should be available from SGI Real Soon Now. > Thanks. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17973; 7 Sep 89 16:56 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac17803; 7 Sep 89 16:45 EDT Date: Thu, 7 Sep 89 16:29:59 EDT From: Gary S. Moss (VLD/VMB) To: Tom Haapanen cc: info-iris@BRL.MIL Subject: Re: Iris 4D questions Message-ID: <8909071630.aa17656@VMB.BRL.MIL> [from Message-Id: <3268@watale.waterloo.edu>] < 3. Did anyone get the recent GIF viewer working on a 4D70? It < compiled, and igif creates a window, but then says: < ERROR #91 : is not implemented. < What does this mean? Who didn't implement it? Well, I got it running on a 4D60T by replacing the call to lrectwrite() with some code from the BRL-CAD package. Here is a patch that should do the trick, though I really wish 'lrectwrite' would get implemented the rest of the way... -moss *** igif.c Thu Sep 7 16:17:25 1989 --- igif.c.save Thu Sep 7 16:17:25 1989 *************** *** 303,309 **** screen_manage() { ! lrectwrite(0, 0, s_width - 1, s_height - 1, screen); qdevice(REDRAW); qdevice(PIECECHANGE); --- 303,309 ---- screen_manage() { ! fake_rectwrite(0, 0, s_width - 1, s_height - 1, screen ); qdevice(REDRAW); qdevice(PIECECHANGE); *************** *** 315,321 **** switch (qread(&data)) { case REDRAW: case PIECECHANGE: ! lrectwrite(0, 0, s_width - 1, s_height - 1, screen); break; case WINQUIT: exit(0); --- 315,321 ---- switch (qread(&data)) { case REDRAW: case PIECECHANGE: ! fake_rectwrite(0, 0, s_width - 1, s_height - 1, screen); break; case WINQUIT: exit(0); *************** *** 325,327 **** --- 325,385 ---- } } + + /* + * This is the format of the buffer for lrectwrite(), + * and thus defines the format of the in-memory framebuffer copy. + */ + struct sgi_pixel { + unsigned char alpha; /* this will always be zero */ + unsigned char blue; + unsigned char green; + unsigned char red; + }; + + /* + * F A K E _ L R E C T W R I T E + * + * fake_rectwrite is necessary as lrectwrite is not yet supported + * for non-GT hardware in IRIX version 3.1 or earlier. There is + * however, a stub in the library which states that lrectwrite is not yet + * available for these systems. To allow us to still use + * shared libraries and have the same executables across the + * 4D series of workstations, if the system does not contain + * the GT hardware upgrade then this fake routine is used. + * + * Note that the real lrectwrite() subroutine operates in the pixel + * coordinates of the WINDOW, not the current viewport. + * To simplify things, this fake_rectwrite() subroutine operates in + * the coordinates of the VIEWPORT, because cmov2i() and writeRGB() do. + * Having the callers convert to window, and then to convert back in here, + * is more inefficient than is necessary. However, this required the + * calling sequences to be somewhat altered -vs- the lrectwrite() replaced. + */ + fake_rectwrite( x1, y1, x2, y2, pixels) + short x1, y1; + short x2, y2; + register struct sgi_pixel * pixels; + { + register struct sgi_pixel * p; + register short n; + register short scan; + register short i; + static unsigned char Red_pixels[1280]; + static unsigned char Green_pixels[1280]; + static unsigned char Blue_pixels[1280]; + + p = pixels; + n = x2 - x1 + 1; + for( scan = y1; scan <= y2; scan++) { + for ( i = 0; i < n; i++) { + Red_pixels[i] = p->red; + Green_pixels[i] = p->green; + Blue_pixels[i] = p->blue; + p++; + } + + cmov2i( x1, scan); + writeRGB( n, Red_pixels, Green_pixels, Blue_pixels); + } + }   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18838; 7 Sep 89 19:05 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18747; 7 Sep 89 18:55 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18733; 7 Sep 89 18:49 EDT Received: from SNOW-WHITE.MERIT-TECH.COM by SMOKE.BRL.MIL id aa11227; 7 Sep 89 18:16 EDT Received: by snow-white.merit-tech.com (4.1/SMI-DDN) id AA16067; Thu, 7 Sep 89 17:14:44 CDT Date: Thu, 7 Sep 89 17:14:44 CDT From: Mike Goss Message-Id: <8909072214.AA16067@snow-white.merit-tech.com> To: mailrus!jarvis.csri.toronto.edu!utgpu!watmath!maytag!vlsi!watale!mims-iris.waterloo.edu!tom@tut.cis.ohio-state.edu Subject: Re: Iris 4D questions Cc: info-iris@BRL.MIL In reply to: > Date: 7 Sep 89 14:31:31 GMT > From: Tom Haapanen > Organization: WATMIMS Research Group, University of Waterloo > Subject: Iris 4D questions > Message-Id: <3268@watale.waterloo.edu> > . > . > . > 3. Did anyone get the recent GIF viewer working on a 4D70? It > compiled, and igif creates a window, but then says: > ERROR #91 : is not implemented. > What does this mean? Who didn't implement it? I haven't tried the GIF viewer, but "lrectwrite" is a function which I believe is available only on the 4D GT, GTX, and Personal IRIS series. If you have an early (non-GT) 4D, it doesn't have this function (this function writes a block of pixels to the screen from a user buffer). ------------------------------ Mike Goss Merit Technology Inc. (214)733-7018 goss@snow-white.merit-tech.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19466; 7 Sep 89 21:20 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa19417; 7 Sep 89 21:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa19410; 7 Sep 89 21:01 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa13061; 7 Sep 89 20:50 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22499; Thu, 7 Sep 89 17:36:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 89 00:29:04 GMT From: Mark Moraes Organization: University of Toronto, CSRI Subject: SysV lint -> BSD lint format filter Message-Id: <1989Sep7.202904.26523@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Maybe it's just that I'm used to BSD lint, but I find SysV lint output rather hard to read. - rather than the one line per error format that my editor could parse, that I could grep and grep -v through, SysV lint now provides several lines per error in the simpler cases, and even worse, a tabular format for some cases. The following is a quick awk filter to transform lint errors to something close to BSD format. (Alas, you can't use 4.3 lint on the Iris because some of the header files have prototypes. Has anyone made pcc (the mip/ part) understand prototypes?) The script probably doesn't cover all the cases but it did work on several examples I tried. The irrationality of the lint error message format should be evident from the amount of awk needed to "sanitize" it. The other useful trick is to use -u, -x and -h. The first two stop it from complaining about all the external variables that there aren't a lint library for, and aren't in your source. The -h stops it from complaining about every use of malloc, or every pointer cast. (the meaning of -h is the reverse of BSD lint) #!/bin/sh # To unbundle, sh this file echo mungelint 1>&2 Adding file mungelint sed 's/^-//' >mungelint <<'!' -#! /bin/sh -# Takes the absolutely horrendous mess that System V lint outputs and tries -# to make it semi-parsable - i.e. more like the V7/BSD lint. -# At least, Jove can now understand some of the error patterns. -# If you ever see the '** Unmatched pattern' message, it means that this -# script has exhausted its limited heuristic knowledge. Please try to come up -# with a good rule for it and let me know. Thanks. -# Mark Moraes, University of Toronto awk 'NF == 1 && $0 ~ /^[^ ]+/ && $1 != "==============" { - # print "*** pat1: " $0 - maybefile = $1; - err=""; - next; - } - NF == 1 && $1 == "==============" { - # print "*** pat2: " $0 - file=maybefile; - err=""; - next; - } - NF == 0 { - # print "*** pat3: " $0 - maybefile = ""; - file="XXXX"; - err=""; - next; - } - NF > 1 && $0 ~ /^[^:]+:[^()]+$/ { - # print "*** pat4: " $0 - err=$0; - next; - } - NF > 1 && $0 ~ /^[^:]+: \([0-9]+\)/ { - line=$2; - $2=""; - printf "%s%s: %s\n", file, line, $0; - next; - } - file != "" && $0 ~ /^ +\([0-9]+\)/ { - for(i = 1; i <= NF; i++) { - printf "%s%s: %s\n", file, $i, err; - } - next; - } - file == "" && $0 ~ /^[^ ]/ { - err=$0; - next; - } - file == "" && NF > 0 && $0 ~ /^ +.*\([0-9]+\)/ { - proc=$1; - $1 = ""; - printf "%s, %s %s\n", proc, err, $0; - next; - } - file == "" && NF > 0 && $0 ~ /^ +[^ ]+/ { - for(i = 1; i <= NF; i++) { - printf "%s %s\n", $i, err; - } - next; - } - { printf "Unmatched pattern: %s\n", $0} -' ! chmod +x mungelint echo shar unpacked fully exit   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20418; 8 Sep 89 0:26 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20336; 8 Sep 89 0:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa20176; 8 Sep 89 0:00 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14898; 7 Sep 89 23:54 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA02569; Thu, 7 Sep 89 20:40:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 89 21:31:12 GMT From: "Thomas P. Mitchell" Organization: Silicon Graphics Computer Systems, Mountain View CA. Subject: Re: Power Series Arch Description Request Message-Id: <473@odin.SGI.COM> References: <89Sep6.182533edt.4956@jarvis.csri.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Sep6.182533edt.4956@jarvis.csri.toronto.edu> dret@DGP.TORONTO.EDU (George Drettakis) writes: >I am interested in getting my hands on a document that will describe >the Power Series parallel architecture. Here are some pointers: 1) "UNIX Papers for UNIX Developers and Power Users" see: Article 14 Multiprocessor UNIX by Tom Jermoluk (Tom is here at SGI.) Edited by Mitchell Waite Howard W. Sams and Company ISBN 0-672-22578-6 2) Wagner, J.C., and Barton, J.M., "Threads in System V: Letting UNIX parallel Process", a work-in-progress paper presented in ;login:, USENIX Association, Vol. 12, No. 5, September/October 1987. 3) Beck, Bob, and Olien, Dave, "A Parallel Programming Process model", in USENIX Conference Procedings, Winter, 1987. 4) Barton, J.M., Wagner, J.C. "Beyond Threads: Resource Sharing in UNIX," USENIX Procedings, 1987. 5) Dijkstra, E.W. "Cooperating Sequential Processes," Technical Report EWD-123, Technological University, Eindhoven, The Netherlands, 1965. 6) Gerry Kane. "mips RISC Architecture" Prentice Hall, Englewood Cliffs, N.J. ISBN 0-13-584293-X Keys to understanding are: There is one run queue. Parallel regions in code are managed as seperate processes. All the rules of shared memory problems apply. It is the responsibility of the programmer (in 'c') to understand any data dependancies. The pfa (Power FORTRAN Accelerator) identifies regions at the do loop level which may safely be run in parallel for the FORTRAN compiler. Yea the programmer may know of other regions. Worse yet, he may think he does. The user may need to discover (profile) if the overhead of spawning the sub-processes and resyncronizing is greater than the work done in the loop. Unix needs a good spelling checker (from vi). Thomas P. Mitchell (ARPA:mitch@csd.sgi.com, UUCP: {decwrl,ucbvax}!sgi!mitch ) Rainbows -- The best (well second best) reason for windows.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21090; 8 Sep 89 3:48 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21066; 8 Sep 89 3:38 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21053; 8 Sep 89 3:28 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa18022; 8 Sep 89 3:24 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA13976; Fri, 8 Sep 89 00:17:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Sep 89 23:24:08 GMT From: Mark Callow Subject: Re: PostScript previewing [WAS: GIF to SGI...?] Message-Id: <477@odin.SGI.COM> References: <453@alias.UUCP>, <8908301329.AA27741@snow-white.merit-tech.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <453@alias.UUCP>, rae%alias@csri.utoronto.ca (Reid Ellis) writes: > Path: odin!shinobu!sgi!arisia!lll-winken!uunet!cs.utexas.edu!tut.cis.ohio-stat e.edu!mailrus!jarvis.csri.toronto.edu!utgpu!utfyzx!alias!rae%alias > Be warned that psview doesn't work for bitmaps [i.e. "image"s]. However, if > you hide/stow all your windows, you can use the desktop itself via 'psh', the > PostScript shell. Just say something like "psh psview can display images. The problem is that most of the programs that send PostScript images use some pretty gross code that expects the image data to be coming in on "currentfile". Because psview reads all the data into a temporary file so that it can page around it, the object that "currentfile" returns is not what these programs expect. If you put the data into an array psview will display it just fine. -Mark   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25269; 8 Sep 89 10:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24915; 8 Sep 89 10:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24690; 8 Sep 89 9:56 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24918; 8 Sep 89 9:49 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA01412; Fri, 8 Sep 89 06:39:52 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 89 13:23:32 GMT From: Pablo Fernicola Organization: UF Machine Intelligence Laboratory Subject: Zbuffering Message-Id: <20845@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL When buying the machine, we were given the impression that there would be a software implementation of Z-buffering. We were told that it would be much slower than the hardware, but that your application code would be the same, independent of you running the hardware or software z-buffering. Is there any truth to this?? Thanks, Pablo -- pff@beach.cis.ufl.edu Pablo Fernicola - Machine Intelligence Laboratory - UF "If we knew how it works, it wouldn't be called research."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab25269; 8 Sep 89 10:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab24915; 8 Sep 89 10:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab24690; 8 Sep 89 9:57 EDT Received: from NYU.EDU by SMOKE.BRL.MIL id aa24923; 8 Sep 89 9:50 EDT Received: from XP.PSYCH.NYU.EDU by cmcl2.NYU.EDU (5.61/1.34) id AA26475; Fri, 8 Sep 89 09:49:03 -0400 Message-Id: <8909081349.AA26475@cmcl2.NYU.EDU> Received: by xp.psych.nyu.edu; Fri, 8 Sep 89 09:40:37 EDT Date: Fri, 8 Sep 89 09:40:37 EDT From: Aries Arditi X-Mailer: Mail User's Shell (6.4 2/14/89) To: wcwang@iuvax.cs.indiana.edu Subject: real-time and 3D workstations Cc: info-iris@BRL.MIL I've been following the discussion following your request to info-iris for a machine on which to conduct your experiments. I'm afraid that most of the discussants don't quite understand what the demands of an RT experiment are. The IRIS machines, and most other 3D workstations are UNIX based, which almost by definition means they are NOT real-time in the sense you need for accurate measurement of time. Depending on what is happening at any given time, any number of processes are competing for the CPU's time. This means that you will always have some uncertainty as to the onset of your stimulus. Additionally, you will have some uncertainty as to the button time, unless you have an external real-time clock hung on the back (Personal IRISes have only one VME bus slot, so only 1 such device can be on your system at once), and even then, since you don't know exactly when the stimulus onset was, you still have error. I think the IRIS sounds like the machine in your price range to generate your stimuli, but may or may not be depending on how accurately you need to measure RT. Here are 2 possible solutions: 1. There are versions of "real-time" UNIX available (I know not where, but someone at AT&T Murray Hill developed one of them for DEC PDP 11's. Possibly an SGI sales rep will do some legwork to find one for you if he thinks that's necessary to make the sale. In the PDP 11 market, these real-time versions of UNIX varied quite extensively both in quality, I understand, and in the extent to which they are "real-time." So be careful here. You will need to know that you can still run the software for your experiment, under this operating system. 2. The solution I have used with some success, on another multi-tasking (i. e. not real time) machine, is to count video frames when measuring time, rather than waiting for an interrupt from a clock or other device. It's very easy, but your accuracy is limited to +/- 16.66667 msec. If that's OKAY for your application. Sometimes you can degrade your stimulus or task in some irrelevant way in order toraise all your RT's so 17 msec isn't such a big deal. Anyway, computer graphics people usually think that real-time just means animated, so watch out for that. Good luck. -Aries Arditi Vision Research Laboratory The Lighthouse 111 E 59th Street New York, NY 10022   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27571; 8 Sep 89 12:14 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27193; 8 Sep 89 12:03 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa26956; 8 Sep 89 11:50 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28256; 8 Sep 89 11:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA06958; Fri, 8 Sep 89 08:27:55 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 89 15:07:56 GMT From: Thant Tessman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Stereo viewing techniques Message-Id: <41437@sgi.sgi.com> References: <8909071236.AA15114@snow-white.merit-tech.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909071236.AA15114@snow-white.merit-tech.com>, goss@SNOW-WHITE.MERIT-TECH.COM (Mike Goss) writes: > Regarding the continuing discussion of active vs. passive stereo viewing > techniques, there is another point which is relevant to the choice of > system. It is sometimes necessary for the user of a stereo system to > view other, non-stereo video monitors in addition to a stereo display. > With active glasses, it is necessary to remove the glasses to view other > video sources; the glasses cause severe flicker otherwise. StereoView (CrystalEyes) have a button on the side that turns them clear, so not only is there no flicker, but there is very little light being cut out, just like wearing clear glasses. This is even better than passive glasses which always cut out at least half the light. > Also, if multiple stereo monitors are in use, active glasses require that > all video monitors have synchronized refresh cycles in order to be viewed > simultaneously; passive glasses do not have this requirement. You are right about viewing them simultaneously, but the StereoView glasses sync to the monitor you are facing, so it is possible to look back and forth between more than one monitor and always be synced to the one you are looking at. thant -- ----------------------------------------------------------------------------- There's a pattern there to see, and the point will soon be clear to me. -Stewart Copeland -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02543; 8 Sep 89 15:49 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01541; 8 Sep 89 15:38 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01487; 8 Sep 89 15:30 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04399; 8 Sep 89 14:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA17939; Fri, 8 Sep 89 11:42:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Sep 89 18:22:04 GMT From: Paul Connally Organization: University of Colorado, Boulder Subject: 4D/20 - 4DGifts Message-Id: <11487@boulder.Colorado.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL First off I would like to say what a fine machine the Personal IRIS is. I had some problems at first with a lack of manuals but that got straightened out and now everything is humming right along. OK, now for some questions (some of which have probably already been posted but, oh well, sorry for the waste of bandwith). Do the sources for the 4Dgifts programs come with the PI usually? If not, is there an ftp sight where I can get them (or some of them)? My main problem is with icut and ipaste: How do you change the window size for icut? Is there a problem with ipaste or icut if you only have eight bit planes? Where can I find more info on these? There's a man page for ipaste but it doesn't seem to say much, and no man page for icut. I realize that these programs are gifts and aren't really supported but they could be really useful to me. Thanks,   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04887; 8 Sep 89 21:47 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04821; 8 Sep 89 21:16 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04819; 8 Sep 89 21:11 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01005; 8 Sep 89 21:05 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA10632; Fri, 8 Sep 89 18:02:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Sep 89 00:15:44 GMT From: David Naegle Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Stereo viewing techniques Message-Id: <41485@sgi.sgi.com> References: <8909071236.AA15114@snow-white.merit-tech.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909071236.AA15114@snow-white.merit-tech.com>, goss@SNOW-WHITE.MERIT-TECH.COM (Mike Goss) writes: > [] It is sometimes necessary for the user of a stereo system to > view other, non-stereo video monitors in addition to a stereo display. > With active glasses, it is necessary to remove the glasses to view other > video sources; the glasses cause severe flicker otherwise. With passive > glasses, it is still possible to view other video sources without flicker. > Also, if multiple stereo monitors are in use, active glasses require that > all video monitors have synchronized refresh cycles in order to be viewed > simultaneously; passive glasses do not have this requirement. It is true that active eyewear will cause you to see slow-moving dark bands on a non-stereo video monitor. That's why one of the four buttons on the StereoView eyewear is a 'clear' mode button. When you press this button, you can look at non-stereo video screens with no problems. Press it again, and you're back in stereo mode. This is somewhat less inconvenient than actually removing the glasses, in most applications. To deal with the situation where multiple stereo monitors are in use, the infrared transmitter is designed to broadcast a wide-angle pattern of stereo field (right/left) signal, and the glasses are designed to 'see' a narrow pattern. That way, the eyewear will lock onto the stereo signal of whichever video display you're viewing at the moment. There *are* arrangements of monitors which can cause trouble, like trying to view stereo on two unsynchronized monitors placed side-by-side, especially from the maximum range. This arrangement puts the stereo transmitters too close together for the eyewear to lock onto one or the other reliably, since the angle of incidence is nearly identical for both I.R. beams. Usually, though, if you have to view multiple stereo screens at the same time, they can be arranged so that the I.R. beams don't come from nearly the same place. Considering that it would cost $16K-$25K for two passive-eyewear stereo systems to handle the rare instances which cannot be handled as described above, most users would just do without stereo in those cases. If you want theatre viewing, use a z-screen, or better yet, a polarizing stereo video projector. StereoView glasses are meant for low-cost, one-on-one applications. > > ------------------------------ > Mike Goss > Merit Technology Inc. > (214)733-7018 > goss@snow-white.merit-tech.com David Naegle Graphics Hardware Manager naegle@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05802; 9 Sep 89 1:34 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05617; 9 Sep 89 1:24 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05602; 9 Sep 89 1:06 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03794; 9 Sep 89 0:49 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22227; Fri, 8 Sep 89 21:37:11 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Sep 89 03:58:42 GMT From: lhary meyer Organization: Whole Earth 'Lectronic Link, Sausalito, CA Subject: Re: Stereo viewing techniques Message-Id: <13525@well.UUCP> References: <8909071236.AA15114@snow-white.merit-tech.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In response to Mike Goss at Merit: The CrystalEyes/StereoView glasses have a BRIGHT mode ( rear switch, right side) that opens both eyes & stops shuttering. Thus you can look at another monitor without "beat bars". The IR transmitter has a very wide dispaersion beam, nearly 180 degs. but the glasses have a narrow acceptance angle, only 20-30 degrees, so they only "see" the monitor that you're looking at. The IR emitters have a HI/LOW switch to provide a range of about 4'/10' to allow fairly close monitors without syncronizing them. Still, if you prefer the ZScreen approach, we intend to continue them until nobody wants them anymore. Take your pick!! Lhary Meyer // Stereographics   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08073; 9 Sep 89 16:26 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08037; 9 Sep 89 16:05 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa08031; 9 Sep 89 15:55 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa25932; 9 Sep 89 15:50 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA03682; Sat, 9 Sep 89 12:37:12 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Sep 89 19:22:03 GMT From: Jean-Francois Lamy Subject: make behaviour vs symlinks. Message-Id: <89Sep9.152126edt.2301@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL If one has a makefile of the form prereq: echo "beurk!" with prereq a symlink to a directory on an NFS mounted file system, then make prereq will always cause the "echo", even if prereq points to an existing directory (so this does not seem to be a follow/not follow symlink isssue, but rather one with SGI's particular implementation of symlinks). The expected behaviour is obtained if prereq is a real directory. The behaviour is repeatable with both SGI's make and GNU make, and does not happen on the other *nixes that we have around (SunOS 3.5,4.0.3, Ultrix 2.2 and 3.1, where I've been ironing out yet more subtle incompatibilies that cropped up building a new TeX source distribution). (I think we will start a print queue called sgi-questions; people will lpr their questions there so we can make sure the list gets at least one a day :-) Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00750; 10 Sep 89 0:51 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00419; 10 Sep 89 0:09 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab00311; 9 Sep 89 23:53 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa01174; 9 Sep 89 21:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA18596; Sat, 9 Sep 89 17:54:08 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Sep 89 21:33:36 GMT From: Gary Klaassen Organization: York U. Computing Services Subject: personal iris monitors Message-Id: <3693@yunexus.UUCP> References: <8908171336.AA13518@castor.wustl.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Silicon Graphics provides two color monitor options with the Personal Iris, a 19" and a 14". Does anyone know what pixel resolution is for the 14 inch? Has anyone had any experience (good or otherwise) with the 14 inch monitor? Thanks in advance, G. Klaassen, York University   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01353; 10 Sep 89 4:18 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01254; 10 Sep 89 4:07 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01251; 10 Sep 89 3:52 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03301; 10 Sep 89 3:19 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA05779; Sun, 10 Sep 89 00:08:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 89 01:11:38 GMT From: "Frank J. Henigman" Organization: U. of Waterloo, Ontario Subject: Re: GL event que (GTX/120) Message-Id: <11432@watcgl.waterloo.edu> References: <56867@aerospace.AERO.ORG>, <3045@amelia.nas.nasa.gov>, <41279@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <41279@sgi.sgi.com> msc@ramoth.esd.sgi.com (Mark Callow) writes: >Trying to use the GL queue for interprocess communication is really gross. >Use one of the many real IPC mechanisms available under IRIX. >If you need to check for activity on both your GL queue and your IPC file >descriptors, open the special file /dev/queue and add its file descriptor to >the list you are handing to select. A select on /dev/queue indicates there >is data available in you GL input queue. Can you do this with any "real IPC mechanism" other than a socket? Like maybe shared memory/semaphores or inter-process message queues? -- fjhenigman@watcgl.uwaterloo.ca Computer Graphics Lab fjhenigman@watcgl.waterloo.edu Frank J. Henigman University of Waterloo ...!watmath!watcgl!fjhenigman Waterloo, Ontario, Canada   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02454; 10 Sep 89 13:55 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02433; 10 Sep 89 13:45 EDT Received: from jarvis.csri.toronto.edu by VMB.BRL.MIL id aa02431; 10 Sep 89 13:40 EDT Received: by jarvis.csri.toronto.edu id 4287; Sun, 10 Sep 89 13:38:00 EDT To: info-iris@vmb.brl.mil From: lamy@ai.utoronto.ca (Jean-Francois Lamy) Subject: TeX/Metafont source distribution. Date: Sun, 10 Sep 89 13:37:35 EDT Message-Id: <89Sep10.133800edt.4287@jarvis.csri.toronto.edu> The TeX/Metafont source distribution on neat.cs.utoronto.ca (128.100.1.65) announced here a few weeks back has been revised and now compiles and installs without hassles on Irix 3.1G, Ultrix 3.1, Ultrix 3.2, SunOS 3.5 and 4.0, and BSD 4.2 and 4.3. Various wrinkles have been ironed out since the previous release (which were mostly due to the fact that some licensed software had to be omitted when building the distribution, breaking some Makefiles). Please retrieve pub/tex.README first, read it, and only retrieve the pub/tex.tar.Z.* files if you intend to use them, as our Internet connection has finite bandwidth. If you retrieved the old distribution and ran into problems, please try again; you should have better luck this time. Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02945; 10 Sep 89 17:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02921; 10 Sep 89 17:28 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02907; 10 Sep 89 17:13 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08125; 10 Sep 89 17:04 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09958; Sun, 10 Sep 89 13:52:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 10 Sep 89 20:11:21 GMT From: Jim Bennett Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Zbuffering Message-Id: <41514@sgi.sgi.com> References: <20845@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <20845@uflorida.cis.ufl.EDU>, pff@beach.cis.ufl.edu (Pablo Fernicola) writes: > When buying the machine, we were given the impression that there would be a > software implementation of Z-buffering. We were told that it would be much > slower than the hardware, but that your application code would be the same, > independent of you running the hardware or software z-buffering. Is > there any truth to this?? There is no support for software Z buffer on the current Personal Iris, and none planned from SGI. There is, however, a third party solution called "Soft Z". I don't know anything about this product, other than its name, but perhaps your sales rep. can dig up something for you. > pff@beach.cis.ufl.edu Pablo Fernicola - Machine Intelligence Laboratory - UF > "If we knew how it works, it wouldn't be called research." Jim Bennett bennett@esd.sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04257; 10 Sep 89 21:54 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04177; 10 Sep 89 21:43 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04141; 10 Sep 89 21:33 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa10844; 10 Sep 89 21:19 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22488; Sun, 10 Sep 89 18:20:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 89 00:48:59 GMT From: Shaul Peleg Organization: NetCom- The Bay Area's Public Access Unix System {408 997-9175 guest} Subject: Seek used IRIS Message-Id: <2312@netcom.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hello there. I attended SigGraph this summer and noticed on the billboard that an IRIS was being sold for $2000. At the time, I should of jumped at the opportunity but I didn't have the money. Right now I am in a position with some money and an Amiga to sell. So, is anyone selling an IRIS for a really low price? I don't care for any special model as long as there is a monitor and system software. Secondly, can anyone tell me if it is worth it even though I am only doind it for learning purposes. By this I mean, does SGI still support the old machines... is there a C compiler for them.. etc. Thanks. Shaul Peleg   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09721; 11 Sep 89 10:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09429; 11 Sep 89 9:59 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09309; 11 Sep 89 9:48 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa20132; 11 Sep 89 9:27 EDT Received: Mon, 11 Sep 89 09:26:34 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Mon, 11 Sep 89 09:26:34 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8909111626.AA01010@aero4.larc.nasa.gov> To: sgi!naegle%oberon.sgi.com@ucbvax.berkeley.edu Subject: Re: mmode and patch Cc: info-iris@BRL.MIL The Stereographis system requires a 120Hz monitor too. One thing to note on these systems is that in order to get the 120Hz, you sacrifice vertical resolution. The bandwidth is constant, so in order to get twice as many frames/second, they cut the vertical resolution in half. The software must create the stereo images one above the other (at 60Hz), so that when viewed at 120Hz you have two images one right after the other. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11976; 11 Sep 89 12:43 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11835; 11 Sep 89 12:33 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa11686; 11 Sep 89 12:17 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25407; 11 Sep 89 11:51 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA02886; Mon, 11 Sep 89 08:40:30 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 11 Sep 89 15:15:31 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: real-time and 3D workstations Message-Id: <41523@sgi.sgi.com> References: <8909081349.AA26475@cmcl2.NYU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909081349.AA26475@cmcl2.NYU.EDU>, aries@XP.PSYCH.NYU.EDU (Aries Arditi) writes: > [ ... discussion of some aspects of RT UNIX ... ] > > I think the IRIS sounds like the machine in your price range to generate > your stimuli, but may or may not be depending on how accurately you need > to measure RT. Here are 2 possible solutions: > > 1. There are versions of "real-time" UNIX available (I know not where, but > someone at AT&T Murray Hill developed one of them for DEC PDP 11's. > Possibly an SGI sales rep will do some legwork to find one for you if he > thinks that's necessary to make the sale. In the PDP 11 market, these > real-time versions of UNIX varied quite extensively both in quality, I > understand, and in the extent to which they are "real-time." So be careful > here. You will need to know that you can still run the software for your > experiment, under this operating system. Actually, IRIX has some real-time features which may be adequate for this application. First, it is possible to fix a process priority and thus exempt it from normal priority degradation. These are various priorities supported, and of course the highest is gauranteed control of the processor when it wants. Fine grained memory locking, which is probably not needed for this application, allows total control over what's in memory. > 2. The solution I have used with some success, on another multi-tasking > (i. e. not real time) machine, is to count video frames when measuring > time, rather than waiting for an interrupt from a clock or other device. > It's very easy, but your accuracy is limited to +/- 16.66667 msec. If > that's OKAY for your application. Sometimes you can degrade your stimulus > or task in some irrelevant way in order toraise all your RT's so 17 msec > isn't such a big deal. The accuracy of gettimeofday() is 1 millisecond, which should be more than adequate for human/machine interaction (which is on the order of tenths of seconds). Using itimers gives interrupts at a 100HZ rate, or as pointed out you can use the graphics system frame rate as a clock as well. > Anyway, computer graphics people usually think that real-time just means > animated, so watch out for that. Some of use know what REAL real-time means, even though we do graphics too. IRIX is a "soft" real-time system, in that the mechanisms for gauranteed response and resource control are good down to ~1 millisecond. A "hard" real-time system doesn't run UNIX and can get down to 10's of microseconds. Human/machine interaction is definitely "soft". > Good luck. > -Aries Arditi > Vision Research Laboratory > The Lighthouse > 111 E 59th Street > New York, NY 10022 -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15054; 11 Sep 89 16:33 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14860; 11 Sep 89 16:22 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa14778; 11 Sep 89 16:10 EDT Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa02439; 11 Sep 89 15:40 EDT Received: Mon, 11 Sep 89 12:39:41 pdt by prandtl.nas.nasa.gov (5.51/1.2) Received: Mon, 11 Sep 89 15:40:31 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Mon, 11 Sep 89 15:57:11 EDT by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Mon, 11 Sep 89 15:57:11 EDT From: Tony Facca Message-Id: <8909111957.AA01954@lerc08.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: Seek used IRIS From: Shaul Peleg writes: > Hello there. I attended SigGraph this summer and noticed on the billboard > that an IRIS was being sold for $2000. At the time, I should of jumped at the > opportunity but I didn't have the money. Right now I am in a position with > some money and an Amiga to sell. So, is anyone selling an IRIS for a really > low price? I don't care for any special model as long as there is a monitor > and system software. Secondly, can anyone tell me if it is worth it even > though I am only doind it for learning purposes. By this I mean, does SGI > still support the old machines... is there a C compiler for them.. etc. I saw that memo on the billboard, too. Did you notice that the machine was a 2500 Turbo with 2meg of memory? The 2500T is refrigerator-sized machine and 2M isn't enough memory to do any real work. However, for $2K it seemed like a real good deal especially if you are just using it for learning. You would probably have to pay another $2K(?) to have the machine moved to your facility I imagine. We have a 2500T at the lab and yes, SGI still supports it (as far as main- tenance). Actually, they are supporting it all the time :-) They run all the software that the 3000 series stuff runs, including C, Fortran, Pascal, Emacs, etc. You'd probably want to upgrade the memory a bit. We got away with 4M for a while in the "old days". -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18037; 12 Sep 89 4:04 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17548; 12 Sep 89 3:12 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa17508; 12 Sep 89 3:00 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09997; 12 Sep 89 0:49 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA18651; Mon, 11 Sep 89 21:38:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 89 04:31:32 GMT From: Pablo Fernicola Organization: UF Machine Intelligence Laboratory Subject: User Dialog Message-Id: <20862@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Okay, I thought this was going to be simple but it wasn't (after all it deals with computers :-) ). I'm trying to pop up a little window where the user gets to type some input and whatever is typed is echoed back. Here is a fragemnt of my code main() { char input[15]; int charCount; [init graphic stuff] [init font stuff] qdev( KEYB ); [cmove instruction] fmprstr( "Enter string : "); [cmove instruction] charCount = 0; while( charCount <= 14 ) { qread( input[ charCount ] ); fmprstr( input ); charCount++; } } I get the window, I get the message Enter string and then I crash. Any clues are wellcomed. -- pff@beach.cis.ufl.edu Pablo Fernicola - Machine Intelligence Laboratory - UF "If we knew how it works, it wouldn't be called research."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25634; 12 Sep 89 13:24 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25333; 12 Sep 89 13:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25297; 12 Sep 89 13:04 EDT Received: from cgl.ucsf.EDU by SMOKE.BRL.MIL id aa22878; 12 Sep 89 12:45 EDT Received: from cardio.ucsf.EDU by cgl.ucsf.EDU (5.59/GSC4.17) id AA00317 for info-iris@brl.arpa; Tue, 12 Sep 89 09:43:40 PDT Received: by cardio (1.2/GSC4.15) id AA10900; Tue, 12 Sep 89 09:44:18 pdt Date: Tue, 12 Sep 89 09:44:18 pdt From: Ashutosh Goel Message-Id: <8909121644.AA10900@cardio> To: info-iris@BRL.MIL Subject: Plotting Software Cc: goel@cardio.ucsf.edu Hi! We at UCSF just bought an IRIS 4D/70GT and were wondering if there is any plotting software available which is simillar to DISSPLA...we need it in the form of subroutines so that we can call it inside the program and see the results as program progresses...Please send your responses to goel@cardio.ucsf.edu....thanks..goel   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25897; 12 Sep 89 13:35 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24473; 12 Sep 89 12:13 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa24433; 12 Sep 89 12:00 EDT Received: from [128.32.133.1] by ADM.BRL.MIL id aa11450; 12 Sep 89 11:54 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22746; Tue, 12 Sep 89 08:43:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 89 15:15:12 GMT From: Thant Tessman Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: User Dialog Message-Id: <41627@sgi.sgi.com> References: <20862@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <20862@uflorida.cis.ufl.EDU>, pff@beach.cis.ufl.edu (Pablo Fernicola) writes: > Okay, I thought this was going to be simple but it wasn't (after all > it deals with computers :-) ). > > I'm trying to pop up a little window where the user gets to type some > input and whatever is typed is echoed back. > > > Here is a fragemnt of my code > > main() > { > char input[15]; > int charCount; > > > [init graphic stuff] > [init font stuff] > > qdev( KEYB ); > > [cmove instruction] > fmprstr( "Enter string : "); > [cmove instruction] > charCount = 0; > while( charCount <= 14 ) > { > qread( input[ charCount ] ); ^^^^^^^^^^^^^^^^^^ Change to either: qread( &input[charCount] ); or: qread( input + charC ); > fmprstr( input ); > charCount++; > } > } > thant -- ----------------------------------------------------------------------------- There's a pattern there to see, and the point will soon be clear to me. -Stewart Copeland -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26187; 12 Sep 89 13:53 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab25897; 12 Sep 89 13:43 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa25704; 12 Sep 89 13:27 EDT Received: from cisco.nosc.mil by SMOKE.BRL.MIL id aa23281; 12 Sep 89 12:57 EDT Date: Tue, 12 Sep 89 08:33 PST From: MIKE@cisco.nosc.mil Subject: tar formats To: info-iris@BRL.MIL X-VMS-To: IN%"info-iris@brl.mil" Message-ID: <8909121257.aa23281@SMOKE.BRL.MIL> What's the trick on using tar to dump files on quarter inch tape from a personal iris so the files can be read on a 3120? Mike Pawka Naval Ocean Systems Center San Diego, CA 92152 mike@cisco.nosc.mil pawka@nosc-tecr.arpa   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29134; 12 Sep 89 16:28 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28530; 12 Sep 89 16:07 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa28434; 12 Sep 89 15:53 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28215; 12 Sep 89 15:05 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA04695; Tue, 12 Sep 89 12:05:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 89 18:42:54 GMT From: HOUFAC Organization: Control Data Corp., Houston, Texas Subject: Mouse Problems? Message-Id: <14000@shamash.cdc.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just heard a rumor that there is some problem with the mouse on Personal Iris systems that causes trouble with System 3.2. Can anyone verify or refute this? --Pete   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa29957; 12 Sep 89 17:51 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab29773; 12 Sep 89 17:41 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa29748; 12 Sep 89 17:29 EDT Received: from gatech.edu by SMOKE.BRL.MIL id aa02138; 12 Sep 89 16:57 EDT Received: from hydra.gatech.edu by gatech.edu (5.58/GATECH-8.6) id AA14406 for ; Tue, 12 Sep 89 16:44:57 EDT Received: by hydra.gatech.edu (4.12/2.5) id AA22943; Tue, 12 Sep 89 16:44:02 edt Date: Tue, 12 Sep 89 16:44:02 edt From: "SCHREIBER, O. A." Message-Id: <8909122044.AA22943@prism.gatech.edu> To: info-iris@BRL.MIL Subject: error flag 15 caused window server to crash Cc: ccsupos@prism.gatech.edu Has anybody ever had the problem error signal 15 caused window server to abort on an IRIS 4D GT. It seems like it is an overload problem. Thanks Olivier Schreiber (404)894 6147, Office of Computing Services Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccsupos ARPA: ccsupos@prism.gatech.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01248; 12 Sep 89 22:14 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01209; 12 Sep 89 22:04 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01193; 12 Sep 89 21:57 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06901; 12 Sep 89 21:36 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA26266; Tue, 12 Sep 89 18:33:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 89 00:07:33 GMT From: donl mathis Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: User Dialog Message-Id: <41663@sgi.sgi.com> References: <20862@uflorida.cis.ufl.EDU>, <41627@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <41627@sgi.sgi.com>, thant@horus.sgi.com (Thant Tessman) writes: > > char input[15]; > >[...] > > qread( input[ charCount ] ); > Change to either: > qread( &input[charCount] ); > or: > qread( input + charC ); Closer, but it doesn't seem quite right. Qread's argument is supposed to be the address of a short, not a character. I'm too tired to figure out which half of the short the character is in and which neighboring character gets trashed, but it seems like a bad idea in any case. It might also be wise to check that (qread() == KEYBD) before you assume that you're getting a character. Here's my best guess, without echoing... #include #include main () { char buff [128], *p; short dev, ch; winopen ("temp"); qdevice (KEYBD); p = buff; while (dev = qread (&ch)) { if (dev == KEYBD) { if (ch == '\n' || ch == '\r') { break; } *p++ = ch; } } *p = '\0'; printf ("%s\n", buff); gexit (); exit (0); } -- - donl mathis at Silicon Graphics Computer Systems, Mountain View, CA donl@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01248; 12 Sep 89 22:14 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00791; 12 Sep 89 20:44 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00770; 12 Sep 89 20:34 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05684; 12 Sep 89 20:08 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA21275; Tue, 12 Sep 89 17:03:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 12 Sep 89 22:14:28 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Spinlocks and Semaphores Revisited Message-Id: <41656@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL It was pointed out to me that I posted the section of the software spec with the "Company Confidential" still on it. Guess I'll be in engineering a long time - I haven't been able to train myself properly about such things. In any case, here is a distributable version with the "Confidential" removed, so you can copy it, give it away, etc., but try to maintain it in the state it is. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb ---------- cut here ----------- Section 2 - 1 - Section_2:_Software_Synchronization James M. Barton Silicon Graphics Computer Systems Copyright (c) 1989 Silicon Graphics, Inc. All Rights Reserved ($Revision: 1.12 $ $Date: 86/09/23 17:27:33 $) 1. UNIX_On_Multiprocessors Much of the discussion in this section follows that in [1]. This section assumes that the Clover 2 multiprocessor structure will consist of two or more CPU's that share common memory and peripherals. Such a structure can potentially provide much greater throughput since processes can run concurrently on different processors. Each CPU executes independently, but all of them execute a single copy of the kernel. In general, processes are unaware that they are running on a multiprocessor, and can migrate between processors transparently. Unfortunately, a process does not consume less CPU time. Allowing several processors to execute simultaneously in the kernel causes integrity problems unless protection mechanisms are used. The original design of UNIX assumed that only a single processor would ever execute the kernel. Thus, kernel data structures could be protected by not preempting a process in the kernel. A kernel process gives up control of the processor voluntarily, through the normal UNIX sleep/wakeup mechanism. There are three ways in which corruption of kernel data structures can be prevented on a multiprocessor: 1. Execute the kernel on one processor only, which protects all kernel data structures but serializes all system functions. 2. Serialize small sections of code (critical regions) with locking primitives. This approach adds locking overhead, and may increase context switching. 3. Redesign algorithms to avoid contention for data structures. In many cases, this may be impossible to do and still maintain reasonable performance. AT&T currently sells a multiprocessor version of UNIX for the 3B20A attached processor system. In this UNIX kernel, locking primitives are used to create short critical sections where contention for kernel data structures may occur. This approach was chosen because, if properly designed and implemented, the problems of such locking can be managed easily without sacrificing system throughput or causing major redesigns of kernel algorithms. By partially September 12, 1989 Silicon Graphics Inc. Section 2 - 2 - porting and otherwise using this code as an example, it will be possible to implement a multiprocessor kernel in a short period of time that meets the response and throughput requirements of Clover 2. The remainder of this section is devoted to describing the locking primitives, how they are used in general and how they will be used in the Clover 2 kernel. 2. Semaphores 2.1 Spinlocks 2.1.1 General_Description The class of locking primitives used in the UNIX kernel goes under the general name of semaphores. The simplest semaphore is a spinlock. To access some critical resource, a processor attempts to acquire the lock using the simple algorithm: loop: if lock is set goto loop; set lock; The lock is obviously released simply by clearing it, which will allow at most one other processor to obtain it. If the testing and setting of the lock are not atomic, then it is possible that two processors may believe they have obtained the lock at the same time, or that neither has obtained the lock. The first case can result in corrupted data structures, while the second results in deadlock. Spinlocks can be implemented atomically in software (see [1]), however this solution is slow and may potentially waste a substantial number of cycles. Instead, most modern computers provide atomic test-and-set instructions, which allow a processor to obtain the lock in a single operation. 2.1.2 Spinlock_Usage Spinlocks are used whenever the time in which the lock is actually held by any one processor is very short. In these cases it is more efficient simply to wait for the lock rather than attempting to find some other useful work to do; the time spent searching for other work may exceed the time spent waiting for the lock. In a multiprocessor system, it is difficult to know when a spinlock may be more efficient than a mutual exclusion semaphore. The use of spinlocks must be empirically determined during system tuning, when the effects can be measured. Any very short operation is a candidate for spin September 12, 1989 Silicon Graphics Inc. Section 2 - 3 - locking. Example uses of sinplocks are for controlling free list access or performing linear scans of system tables. 2.1.3 Spinlocks_and_Interrupts One important aspect of locking that becomes apparent in any interrupt-driven system is the possibility that an asynchronous routine started by the hardware may take control of the CPU while it is attempting to obtain the lock. If the interrupt occurs after the lock has been obtained, then the time for which the lock is held can increase dramatically, seriously impacting system performance. If a spinlock is used to protect a resource to which an interrupt routine needs access, then similar problems arise. The interrupt routine remains active while spinning, blocking other important interrupt processing and degrading system performance. Finally, the consequence if an interrupt routine attempts to obtain the same lock that normal processing has just obtained is guaranteed deadlock of the system. To avoid all these problems, interrupts are disabled while attempting to obtain and while holding a spinlock. This re-enforces the necessity for spinlocks to be held as short a time as possible. 2.1.4 Hardware_Support The Clover 2 hardware will supply a large set of "virtual" locks, which will provide atomic test-and-set capabilities between the processors in the system. This provides a powerful mechanism for implementing spinlocks, since traffic on the multiprocessor bus can be avoided. The importance of having a very large set of these locks will become apparent in the following sections. 2.2 Mutual_Exclusion_Semaphores Once spinlocks are available, it becomes possible to implement more sophisticated types of semaphores. Once of these is the mutual exclusion semaphore, which is used to protect critical sections of code in a more intelligent manner than a spinlock. Such a semaphore is a data structure which consists of a counter and a queue of processes. The counter is initialized to the value one. There are two operations possible on such a semaphore, allocation, often called the acquire operation, and de- allocation and wakeup, often called the release operation. A process attempting to acquire the semaphore does so using September 12, 1989 Silicon Graphics Inc. Section 2 - 4 - the following (abbreviated) algorithm: if (counter <= 0) then add this process to end of queue of processes; block this process (allow another to run); on return, decrement the counter; continue with critical section; else decrement counter; continue with critical section; fi The release operation is performed in the following manner: increment counter; if (a process is waiting on the queue) { decrement counter; unblock the first process on the queue; } Obviously the above operations must be atomic in nature; a spinlock is used to protect the semaphore, and is locked before and unlocked after each of the above operations. 2.2.1 Usage Mutual exclusion semaphores are used where the length of the critical section to be protected is long or variable in length. This allows other processes to run and do useful work even though certain work must wait. Examples of such usage are when holding region entries for managing segments of virtual memory, or when using an inode to access disk files or devices. 2.2.2 Counting_Semaphores The mutual exclusion semaphore is a special case of a general counting semaphore. A counting semaphore is initialized to a value greater than one, allowing more than one process to acquire the semaphore at once. Counting semaphores are often used in resource allocation, where there is a fixed number of resources available. Another use is to provide atomic counters; the semaphore is released each time the counter should be incremented, but never acquired. The AT&T multiprocessor code uses many atomic counters but no counting semaphores; the Clover 2 product may include the use of counting semaphores for controlling certain resources. September 12, 1989 Silicon Graphics Inc. Section 2 - 5 - 2.3 Synchronization_Semaphores This third type of semaphore is used to synchronize different processes (possibly on different processors). A synchronization semaphore is actually a mutual exclusion semaphore, however the acquire and release operations are performed by different processes, affecting a rendezvous operation. Example usage is in awakening the paging daemon from the clock handler when memory is in short supply and a sufficient time interval has elapsed. 3. Multiprocessor_Semaphore_Primitives The AT&T 3B20A kernel introduced several new primitives to the kernel to provide semaphore facilities. One of the stated goals of the implementation was to provide a kernel that could run on either uniprocessors or multiprocessors with no modification to the kernel code, and to achieve this goal with only a minor decrease in uniprocessor performance. This goal was met. Each set of semaphore primitives is described below. Spinlock Primitives lock_t lock; spsema(&lock); - acquire the lock, spin until acquired svsema(&lock); - release the lock On a uniprocessor the spinlock primitives are commented out using the C preprocessor (since spinlocks are meaningless on a uniprocessor): # define spsema # define svsema The actual implementation of the spinlock is done using a 3B20 microcoded instruction for speed. On the MIPS processor, there is no test-and-set instruction. Thus, hardware support must be provided to insure that a high- performance path exists for performing this operation. The Clover 2 system will provide a separate, high-speed bus for synchronization among the processors in the complex. This bus will provide similar functionality to the SLIC VLSI chip done for the Sequent Balance multi-processor [2] The Sequent implementation provides 64 test-and-set variables which are global to all processors. In addition, a number of 32-bit September 12, 1989 Silicon Graphics Inc. Section 2 - 6 - registers were available that could be transferred between processors in an atomic fashion, provided a general message facility. This facility was used for distributing interrupts from I/O devices and communication between the processors. The Clover 2 implementation will be based on cheaper gate- array technology, and will be called the SYNC bus for brevity. Access to the SYNC bus will be through normal load and store operations in the physical address space of each processor. The SYNC bus will provide 4096 test-and-set locks. Each lock will be atomic in nature, thus a processor can use these locks for access control, busy waiting, or other uses. The locks will be grouped into 128 pages, each having 32 locks. This allows a group of locks to be mapped into the virtual address space of the processor, allowing user access to certain locks if so desired. Other facilities will be provided by the SYNC bus; they are not of interest here 1. Unlike the Sequent system, such a large number of locks allows each semaphore in the kernel to have a private lock, improving the overall performance of the system. Since no memory cycles are used once the busy-wait instruction has been loaded from memory, all memory traffic is eliminated. With high-speed spinlocks available, the semaphore operations can be defined. Synchronization Primitives sema_t sema; psema(&sema, PRI); - acquire the semaphore vsema(&sema); - release the semaphore cpsema(&sema, PRI); - conditionally acquire the semaphore Algorithmically, psema() is implemented as: __________ 1. The SYNC bus will provide 4 8-bit registers that can be incremented, decremented or set in an atomic fashion. This allows certain algorithms to be speeded up. In addition, the SYNC bus will be used for messaging interrupts both from the I/O system and between processors, eliminating this load on the system memory bus. September 12, 1989 Silicon Graphics Inc. Section 2 - 7 - BEGIN acquire semaphore lock; if (count <= 0) { decrement count; acquire semaphore queue lock; release semaphore lock; add process to semaphore queue; release semaphore queue lock; switch to another process; on return, return to caller; } else decrement count; release semaphore lock; return to caller; END The routine vsema() is implemented as: BEGIN acquire semaphore lock; increment count; if (count > 0) { acquire semaphore queue lock; if (a process is queued) { remove process from queue; unblock process; decrement count; } release semaphore lock; release semaphore queue lock; return; } release semaphore lock; END The routine cpsema() is used by a process which does not wish to block if the semaphore cannot be acquired. This is used in two instances. First, if the caller is an interrupt routine wishing access to a data structure, than it may not block. Thus, it uses cpsema() to acquire the semaphore, and takes some other action if the critical section is in use. Second, some algorithms require that multiple semaphores be used when updating related data structures. In this case, it is necessary to avoid blocking so that the system does not deadlock. This type of algorithm usually appears as: September 12, 1989 Silicon Graphics Inc. Section 2 - 8 - loop: psema(&sem1); . . . if (cpsema(&sem2)) { vsema(&sem1); goto loop; } . . . vsema(&sem2); vsema(&sem1); Cpsema() is also used in cases where semaphores must be acquired in a different order than they will be released. This is also a case where only a conditional operation will avoid deadlock. Cpsema() is implemented as: BEGIN acquire semaphore lock; if (count <= 0) { release semaphore lock; return failure; } else decrement count; release semaphore lock; Mutual Exclusion Primitives sema_t sema; appsema(&sema, PRI); - acquire the semaphore apvsema(&sema, PRI); - release the semaphore apcpsema(&sema); - conditionally acquire semaphore These primitives are implemented differently depending on whether the target system is a uniprocessor or a multiprocessor. The following C preprocessor definitions control this: September 12, 1989 Silicon Graphics Inc. Section 2 - 9 - # ifdef multiprocessor # define appsema psema # define apvsema vsema # define apcpsema cpsema # else # define appsema # define apvsema # define apcpsema # endif Thus, on a uniprocessor, these operations are not performed, since they would only add overhead and perform no useful purpose. On a multiprocessor, these operations are equivalent to the previously defined psema() and vsema() operations. Miscellaneous Primitives sema_t sema; initsema(&sema, value); - initialize the given semaphore valusema(&sema) - return the value of the semaphore 4. Uniprocessor_UNIX_Semaphore_Usage Although not explicitly shown in the code, normal UNIX uses several implicit semaphores to manage kernel data space in a crude manner. First, a single semaphore is used to protect all data structures from access by other processes: the mode, e.g., kernel or user. When in kernel mode, the current process may not be preempted, protecting kernel data structures. This is obviously a crude method of protection, but has the advantage of elegance and simplicity. This semaphore is a mutual exclusion semaphore. Second, the interrupt level of the processor is used to protect from access by interrupt routines. There are as many of these semaphores as there are interrupt levels in the processor. The kernel routines used to acquire and release these semaphores are the spl routines. These semaphores are spinlocks, since the interrupt is blocked by the processor only for short periods of time, and other processing (except higher priority interrupts) cannot continue while the lock is held. Third, process synchronization is performed using the sleep and wakeup primitives, which provide an inefficient yet elegant method for synchronization. The usual sequence for September 12, 1989 Silicon Graphics Inc. Section 2 - 10 - acquiring the semaphore is: while (flag & BUSY) { flag |= WANT; sleep(&flag); } flag |= BUSY; The sequence for releasing the semaphore is: flag &= ~BUSY; if (flag & WANT) { flag &= ~WANT; wakeup(&flag); } Thus, if more than one process is waiting on the semaphore, they will all awake at once, and must contend for the semaphore once again. 5. Multiprocessor_UNIX_Semaphore_Usage A multiprocessor UNIX kernel must abandon the mode semaphore, since multiple processors may be executing in the kernel at once. The sleep and wakeup primitives are replaced with synchronization semaphores. This provides a more efficient implementation, since only the first process waiting on the semaphore will awake, and that process will hold the semaphore once it does. Even through the multiprocessor UNIX kernel abandons the mode semaphore, it still disallows preemption of kernel processes on the same processor. This is for performance reasons. For example, consider the case where a kernel process is preempted, but the next process chosen to run needs access to the same resource. Eventually control will pass back to the preempted process, but only after a substantial amount of time and several unnecessary context switches. At points where the uniprocessor kernel used interrupt blocking to protect from interrupt routines, the multiprocessor kernel must also provide spinlocks to protect from other processors. Thus, a common sequence in the multiprocessor kernel is: September 12, 1989 Silicon Graphics Inc. Section 2 - 11 - x = spl6(); spsema(&lock); /* spsema() is discussed below */ . . . svsema(&lock); /* svsema is discussed below */ splx(x); The most difficult change is the use of mutual exclusion semaphores to protect kernel data structures that previously were protected by the mode semaphore. Thus, areas such as the buffer cache, process management and virtual memory management must be modified to use semaphores to insure exclusive access to structures. 5.1 Semaphores_and_Signals One aspect of the normal sleep/wakeup mechanism is that signal handling may be performed within these primitives if desired by the caller. This allows long waits to be interrupted by the user or application and proper cleanup to be performed. Thus, both mutual exclusion and synchronization semaphores provide the means by which a signal can be ignored or handled, in the same manner as that used by sleep/wakeup. An example call to a mutual exclusion semaphore is: psema(&sema, PPRI); psema(&sema, PPRI | PCATCH); In the first case, if the priority PPRI is greater than PZERO, than a signal which is sent to the process will cause the process to wake up, cleanup it's entry on the semaphore queue, and use longjmp() to return to the system call handler for return to the user. If the priority is less than PZERO, than such signals will always be ignored, and the process can only be woken by: vsema(&sema); In the second case, the PCATCH flag causes control to be returned to the caller when a signal occurs (if the priority is greater than PZERO, as before). Thus, the caller can take any necessary cleanup actions before returning to the application. September 12, 1989 Silicon Graphics Inc. Section 2 - 12 - 6. Semaphore_Performance In a semaphored system, there are a number of different factors that effect the performance of the system. Obviously, the more semaphore operations performed, the fewer cycles that will be devoted to real work. The speed with which a semaphore can be accessed and updated is also critical. AT&T dealt with this problem by micro-coding special instructions to handle the most common semaphore operations. There is one factor, however, that has an overriding effect on performance. This is the hit ratio on a semaphore. This is defined as the ratio of the number of times a semaphore could be acquired immediately to the number of attempts to acquire the semaphore. By examining the above algorithms, the reader can see that the optimal path is to immediately acquire the semaphore - blocking a process is an expensive and time-consuming operation. During construction of the multiprocessor kernel, AT&T discovered that a hit ratio of at least 95% on all semaphores was necessary to achieve adequate performance of the system. To achieve this goal, it is often necessary to break up data structure accesses into smaller chunks, and to isolate accesses as much as possible. For instance, the buffer cache is broken up into a large set of hash buckets that can be searched individually, reducing the contention on any one semaphore. Fortunately, AT&T has already done most of this work, providing the Clover 2 effort with high performance debugged algorithms for handling most of these cases. 7. Driver_Semaphore_Use Clover 2 will obtain most of it's UNIX drivers from the Clover I system. Converting drivers to semaphore use would be a long, costly and painful process, perhaps not worth the effort. To avoid the same situation for the 3B20A port, AT&T added the concept of driver semaphores to the kernel. Since a driver can only be entered in certain well-defined ways, it was possible to place a semaphore sequence around each entry to the driver. In general, these entry points are the open, close, read, write and ioctl entries. This is much like the mode semaphore in normal UNIX, in that it prevents any other process from entering the driver simultaneously. Three separate types of protection are provided. September 12, 1989 Silicon Graphics Inc. Section 2 - 13 - First, the entire driver can be semaphored on it's major device number. Before the kernel invokes the driver, it calls psema() to lock the driver semaphores, and after return from the driver it calls vsema() to unlock the semaphore. Second, each minor device number access to the driver can be semaphored. Instead of locking a single semaphore, each possible minor device number has a semaphore associated with it. The kernel locks the semaphore associated with the minor device before entering the driver and unlocks it after return. For example, this used in protecting the tty driver, which maintains independent structures for each minor device supported. Third, a driver can be given no protection, in which case it is responsible for protecting it's own data structures. This means that structures within the driver that are shared between processes or with interrupt routines must be protected with semaphores. To protect from interrupt access while a driver semaphore is locked, the kernel checks the driver semaphore before launching the interrupt routine. If the semaphore is locked, the kernel queues the interrupt and returns. The code which unlocks the driver semaphore checks for the queued interrupt, and if one exists it launches the interrupt routine at that time. Note that this behavior is only possible with major device locking. A driver that uses minor device locking must be modified to block the interrupt routine explicitly (if it does not already do so). If a driver choses to access kernel data structures, it will not be possible to port it directly to the multiprocessor environment. This is because it will not follow the kernel's locking strategy for the structures accessed. Such drivers must be modified to use the proper locking strategy before they can be used in the multiprocessor kernel. The Clover 2 kernel will implement the 3B20A driver concept, maximizing the use of currently existing drivers. In most cases, it should be possible to directly use drivers written for Clover I. It is expected that some drivers will require a porting effort. September 12, 1989 Silicon Graphics Inc. Section 2 - 14 - 8. Further_Reading Much of this discussion is based on the actual code for the AT&T 3B20A implementation, as well as [3] and [1]. September 12, 1989 Silicon Graphics Inc. Section 2 - 15 - REFERENCES 1. Bach, Maurice J., The Design of the UNIX Operating System, Prentice-Hall, Englewood Cliffs, N. J., 1986. 2. Beck, B., and Kasten, B., VLSI Assist in Building a Multiprocessor UNIX System, Sequent Computer Systems, Portland Oregon, not dated. 3. Bach, M. J., and Buroff, S. J., Multiprocessor UNIX Operating Systems, AT&T Bell Laboratories Technical Journal, Vol. 63, No. 8, October 1984. September 12, 1989 Silicon Graphics Inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01650; 13 Sep 89 0:04 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01633; 12 Sep 89 23:53 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01598; 12 Sep 89 23:42 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07298; 12 Sep 89 22:05 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA27686; Tue, 12 Sep 89 18:58:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 89 01:44:42 GMT From: Jean-Francois Lamy Subject: various boot-related questions. Message-Id: <89Sep12.214425edt.2245@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL People on the phone on the hotline are giving me blank stares :-) when asked the following: a) on an SGI 4D/240 using a tty as a console, how does one forcibly enter the PROM monitor? (this is often accomplished by BREAK on ttys). While we understand this may not be desirable by default, there oughta be a way to make the machine pay attention without having to depress its belly button... b) How does one do the equivalent of a "savecore" upon reboot (the goal is to be able to save memory state and peek around to see where things hang). Since someone will ask why on earth we'd want to do that - we have a machine that runs for several days and all of the sudden refuses to fork off new commands (i.e. after typing a command to the shell, all you can do is interrupt it; you can connect to the telnet daemon but won't get a shell; ping replies do get answered, etc.). There is plenty of memory and plenty of swap space and plenty of process slots. And while I'm at it, the whole fsck picture makes me and a bunch more people shudder. c) What exactly are the "minor repairs" where fsck -b will seek to reboot? d) What exactly is checked by fsstat? Is the dirty bit just that, a bit, that could, say happen to be in a bad block and be wrong? Is fsck under efs guaranteed to clean the filesystem in one pass, or does it suffer from the berkeley heritage and therefore sometimes two or three fscks of the same partition are required before fsck succeeds twice in a row? Why did a message arrive in my mailbox this very second suggesting we comment out all the calls to fsstat in the boot sequence and get rid of the -c flags in mountall? e) Can we get a -p flag on fsck (i.e. repair minor damage, report error on major damage, causing machine to stay in single user mode). Using -y in the boot sequence sounds like a bit trusting. Brrrrrr. Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02112; 13 Sep 89 1:33 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01942; 13 Sep 89 1:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01930; 13 Sep 89 1:06 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09917; 13 Sep 89 0:50 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA07315; Tue, 12 Sep 89 21:45:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 89 03:30:47 GMT From: Gail Murphy Organization: Microtel Pacific Research Ltd., Burnaby, B.C., Canada Subject: Tcsh for 3130 Message-Id: <1800@eric.mpr.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Can anyone point me to an ftp site for the sources or binaries for tcsh for a 3130? Thanks in advance. Gail Murphy | murphy@joplin.mpr.ca Microtel Pacific Research | joplin.mpr.ca!murphy@uunet.uu.net 8999 Nelson Way, Burnaby, BC | murphy%joplin.mpr.ca@relay.ubc.ca Canada, V5A 4B5, (604) 293-5462 | ...!ubc-vision!joplinmpr.ca!murphy   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11214; 13 Sep 89 13:49 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09098; 13 Sep 89 12:47 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09017; 13 Sep 89 12:30 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa24035; 13 Sep 89 11:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA10530; Wed, 13 Sep 89 08:43:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 89 15:28:11 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: various boot-related questions. Message-Id: <41678@sgi.sgi.com> References: <89Sep12.214425edt.2245@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Sep12.214425edt.2245@neat.cs.toronto.edu>, lamy@ai.utoronto.ca (Jean-Francois Lamy) writes: > People on the phone on the hotline are giving me blank stares :-) when > asked the following: > > a) on an SGI 4D/240 using a tty as a console, how does one forcibly enter > the PROM monitor? (this is often accomplished by BREAK on ttys). While we > understand this may not be desirable by default, there oughta be a way > to make the machine pay attention without having to depress its belly > button... I'm not surprised you get a (over-the-phone) blank stare on this one. The PROM monitor is only active when the OS isn't. There isn't any magic key to press to get into it, although the magic key sequence "init 0" will get you there - without UNIX :-). To get more complex, you can get into the built in kernel debugger by lboot'ing a system with 'idbg' INCLUDE'd. See /usr/sysgen, and edit system to INCLUDE idbg. Then execute /etc/init.d/autoconfig and reboot. This will also allow you to use the IRIX command 'idbg' to poke around kernel data structures. As a warning, though, don't call the Hotline if you have problems with playing around with this - it's not in the normal operating mode of most places. > > b) How does one do the equivalent of a "savecore" upon reboot (the goal is to > be able to save memory state and peek around to see where things hang). > > Since someone will ask why on earth we'd want to do that - we > have a machine that runs for several days and all of the sudden refuses > to fork off new commands (i.e. after typing a command to the shell, all > you can do is interrupt it; you can connect to the telnet daemon but > won't get a shell; ping replies do get answered, etc.). There is plenty > of memory and plenty of swap space and plenty of process slots. I haven't heard of this problem running released software for the 240. Be sure you are running 3.1F, or preferably 3.1G. The 3.1D release will run a 240, but only poorly, and it has the bug you mention. Even better, bug your SE to get 3.2 (see below). The system ALREADY does a 'savecore' on reboot if it crashed before. It doesn't work on a hang, since reset has to be pushed to get back. Installing the debugger as above, and then using the '^A' key on the console will drop you into the debugger, from which you can get a stack trace and poke around the kernel data structures. Of course, you will recognize little, since IRIX is a V.3 kernel with many 4.3 extensions re-written for a multiprocessor ... > And while I'm at it, the whole fsck picture makes me and a bunch more people > shudder. > > c) What exactly are the "minor repairs" where fsck -b will seek to reboot? > d) What exactly is checked by fsstat? Is the dirty bit just that, a bit, that > could, say happen to be in a bad block and be wrong? Is fsck under efs > guaranteed to clean the filesystem in one pass, or does it suffer from > the berkeley heritage and therefore sometimes two or three fscks of the > same partition are required before fsck succeeds twice in a row? > Why did a message arrive in my mailbox this very second suggesting we > comment out all the calls to fsstat in the boot sequence and get rid of > the -c flags in mountall? > e) Can we get a -p flag on fsck (i.e. repair minor damage, report error > on major damage, causing machine to stay in single user mode). Using > -y in the boot sequence sounds like a bit trusting. The 3.2 release re-mounts the root filesystem instead of rebooting. The dirty bit is kept in the superblock, and is set dirty unless the filesystem is unmounted, in which case it is set clean. Fsck WILL clean the filesystem in one pass. And I'd ignore the mail message, unless you'd like even more pain and suffering in a few days. Finally, you are certainly welcome to remove the '-y' option, but remember that all us UNIX guru's out here rely on it. After all, how many people have the sophistication to understand when to say 'no' to fsck? (There are maybe two or three people out here). EFS is pretty robust, and getting better, and I haven't heard of data losses after a crash being a big problem. > Brrrrrr. > > Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy > AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4 -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00517; 13 Sep 89 16:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00083; 13 Sep 89 16:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa13030; 13 Sep 89 15:20 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa29438; 13 Sep 89 14:22 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA20304; Wed, 13 Sep 89 11:13:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 89 17:56:32 GMT From: "G. Murdock Helms" Organization: Swamp Creatures, Inc. Subject: Re: error flag 15 caused window server to crash Message-Id: <5101@eos.UUCP> References: <8909122044.AA22943@prism.gatech.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL ("SCHREIBER, O. A.") writes: >Has anybody ever had the problem >error signal 15 caused window server to abort >on an IRIS 4D GT. Yeah, here. I've got an Iris 4DGTX that likes to do that if I've left one of my graphics programs up and running unattended for longer than 20 to 30 minutes. It's not actually *doing* anything while it's sitting there, but when I come back later the program is dead and the screen has the error you've described above. Gretchen Helms A3I Project NASA/Ames Research Center timelord@eos.arc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02018; 13 Sep 89 20:01 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01638; 13 Sep 89 19:09 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01595; 13 Sep 89 19:00 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02575; 13 Sep 89 18:35 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA06137; Wed, 13 Sep 89 15:33:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 89 18:39:18 GMT From: Ruth Milner Organization: University of Toronto Physics/Astronomy/CITA Subject: Re: various boot-related questions. Message-Id: <1989Sep13.183918.8050@helios.physics.utoronto.ca> References: <89Sep12.214425edt.2245@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Sep12.214425edt.2245@neat.cs.toronto.edu> lamy@ai.utoronto.ca (Jean-Francois Lamy) writes: >People on the phone on the hotline are giving me blank stares :-) when >asked the following: > >a) on an SGI 4D/240 using a tty as a console, how does one forcibly enter > the PROM monitor? (this is often accomplished by BREAK on ttys). While we > understand this may not be desirable by default, there oughta be a way > to make the machine pay attention without having to depress its belly > button... > I called the hotline about this back in June, and was told there is no way to do this. I suggested that there should be, but I don't know whether my suggestion was taken seriously enough that it was submitted as a change request. I have also suggested that there should be a way for it to i) automatically reboot after a crash, without depressing its belly button :-), and ii) have it actually HALT after the shutdown sequence has completed, rather than rebooting if you aren't there in time to press . I often initiate shutdowns from my desk, and then go to the machine room a minute or two later. In the IRIS' case, it had cleverly rebooted by this time and I had to shut it down again. There have been some hints that new PROMs might fix at least one of these problems, but it has been like pulling teeth to get any concrete information. While I can live without ii), part i) is absolutely vital. If it crashes due to power problems or greedy people filling up swap or something, there is no reason why it shouldn't go ahead and reboot. And in other situations, I can get the information from /usr/adm/SYSLOG (or from the console if it can't reboot). -- Ruth Milner UUCP - {uunet,pyramid}!utai!helios.physics!sysruth Systems Manager BITNET - sysruth@utorphys U. of Toronto INTERNET - sysruth@helios.physics.toronto.edu Physics/Astronomy/CITA Computing Consortium   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02168; 13 Sep 89 20:16 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac02018; 13 Sep 89 20:06 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab01956; 13 Sep 89 19:58 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03099; 13 Sep 89 19:33 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09840; Wed, 13 Sep 89 16:35:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 89 20:16:57 GMT From: "John D. McCalpin" Organization: Supercomputer Computations Research Institute Subject: NFS on PI Message-Id: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am having terrible trouble with NFS between a PI and several other machines. The PI hangs (completely dead) randomly when transferring large files via NFS. The problem almost always occurs when I am reading and writing large files on NFS-mounted disks. This happens every few days when the input and output files are on the same (remote) machine, and every few hours when the input and output files are on different machines. The worst problems are with the NeXT machine (O/S 0.9), but I also get failures with SGI 3000's (O/S 3.6). The PI is running a recent version of the O/S also, 3.14711181642.... Changing things like hard vs soft mount does not help.... Is this just another SGI trick to get us to buy more disk drives for the PI? -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu mccalpin@scri1.scri.fsu.edu mccalpin@delocn.udel.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02240; 13 Sep 89 20:27 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab02018; 13 Sep 89 20:06 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01956; 13 Sep 89 19:58 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03094; 13 Sep 89 19:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09791; Wed, 13 Sep 89 16:34:58 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 89 23:29:04 GMT From: Seth Teller Organization: University of California at Berkeley Subject: needed: working psview / dvi2ps Message-Id: <17158@pasteur.Berkeley.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL i am using 'psview' on a silicon graphics box to preview the output of the 'latex .. dvi2ps' process. although the dvi2ps output prints perfectly to the laserwriter, it hangs the sgi previewer software (for reasons unknown to me). as a workaround, it would be great to have either A) a working previewer or B) a dvi2ps which produces 'better behaved' postscript. (i don't know a whole lot about it, but from the looks of dvi2ps's output, there seem to be a lot of printer-specific commands generated; binary font specs and the like. these are apparently the cause of the hangs.) can anyone supply these things, or suggest a place to look further? thanks, seth teller seth@miro.berkeley.edu ucbvax!miro.berkeley.edu!seth   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02900; 13 Sep 89 23:25 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02856; 13 Sep 89 23:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02843; 13 Sep 89 23:03 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04632; 13 Sep 89 22:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA19692; Wed, 13 Sep 89 19:25:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 13 Sep 89 15:04:18 GMT From: "D. Christopher Dunlap" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: tar formats Message-Id: <520@odin.SGI.COM> References: <8909121257.aa23281@SMOKE.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909121257.aa23281@SMOKE.BRL.MIL> MIKE@CISCO.NOSC.MIL writes: > > What's the trick on using tar to dump files on quarter inch tape from a >personal iris so the files can be read on a 3120? > > Mike Pawka > Naval Ocean Systems Center > San Diego, CA 92152 > mike@cisco.nosc.mil > pawka@nosc-tecr.arpa The standard tape drive for a Personal Iris is a 150Mb model. With this tape drive, the Personal Iris can READ lower density tapes, but it CAN"T WRITE THEM. There is an option (P5-TC2) for a 60Mb SCSI tape drive for a Personal Iris, which allows you to create the lower density tapes. chris D. Christopher Dunlap Hardware Product Support Customer Support Division email: dunlap@sgi.sgi.com Silicon Graphics Computer Systems   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02990; 13 Sep 89 23:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02574; 13 Sep 89 22:05 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02549; 13 Sep 89 21:57 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa04240; 13 Sep 89 21:36 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA16479; Wed, 13 Sep 89 18:29:10 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 01:13:27 GMT From: Jean-Francois Lamy Subject: Re: needed: working psview / dvi2ps Message-Id: <89Sep13.211218edt.2356@neat.cs.toronto.edu> References: <17158@pasteur.Berkeley.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL seth@miro.Berkeley.EDU (Seth Teller) writes: >i am using 'psview' on a silicon graphics box to preview the >output of the 'latex .. dvi2ps' process. although the dvi2ps output >prints perfectly to the laserwriter, it hangs the sgi previewer >software (for reasons unknown to me). LaserWriter have many extensions that are used by several drivers; common versions of dvi2ps (2.10 and 2.11) have that problem. >as a workaround, it would be great to have either A) a working >previewer Now, now. The previewer is likely doing just fine on real PostScript with no LaserWriter extensions. You can't even throw the book at the people who wrote your dvi2ps, it was likely written before the Red Book came out... > or B) a dvi2ps which produces 'better behaved' postscript. >(i don't know a whole lot about it, but from the looks of dvi2ps's >output, there seem to be a lot of printer-specific commands >generated; binary font specs and the like. these are apparently >the cause of the hangs.) But Glenn Reid from Adobe posted some code a while back (after someonw whined about Display Postscript not accepting LaserWriter PostScript code) that could alleviate the problem. See official party line from Adobe and the code enclosed at the bottom Having said that, I think that trying to preview PostScript generated from a TeX document that uses the Computer Modern or other bitmapped fonts is at best a good way to spend a lot of time waiting. The "printer-specific" fonts you allude to aren't really: they are the only easy way to encode the btmaps for the characters in your paper. They take a lot of time to process (the Hexadecimal encoding used by PostScript to remain 7-bit-ascii sure doesn't help). I haven't seen it, but the previewer by Gigante et al. advertized in this forum a while back should have no problem doing better, even if psview worked on phoney PostScript. Any "direct" solution will likely be better than PosScript. TeX and PostScript just aren't a good match. (before any PostScript bigot roasts me, I should add that the PostScript translator in use here has been heavily beaten on by yours truly, and I wear the battle scars of my encouters with PostScript trying to get it to do things right on various printers and phototypesetters. I even used to like PostScript :-). It might even work with an R3000 in every printer :-). Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4 ------------------------------------------------------------------------------- Here is the code and comment, which recently surfaced again when people here complained about Imagen's UltraScript and whatever runs in Dec LN03s Article 3846 of comp.windows.x: Path: jarvis.csri.toronto.edu!mailrus!purdue!decwrl!adobe!greid From: greid@adobe.com (Glenn Reid) Newsgroups: comp.sys.mac,comp.windows.x Subject: Re: PostScript previewer to view Mac PostScript files. Message-ID: <514@adobe.UUCP> Date: 22 Feb 89 18:30:11 GMT Sender: news@adobe.COM Organization: Adobe Systems Incorporated, Mountain View In message <35953@bbn.COM>, franco@bbn.com (Frank A. Lonigro) writes: > Hi: > I need a PostScript previewer to view the PostScript files produced > on the Mac with the "clover-f or clover-k" command keys. I need a > PostScript previewer that works on a VaxStation2000 running X11R3 and > hopefully supports 4 planes of color. > PS. I'm running Ultrix3.0 on my VaxStation2000 with DECWindows included and > the "dxpsview" program complains that it doesn't know about the command > "serverdict" which is in the converted PostScript file produced by MacPS, so > "dxpsview" won't work. What I don't understand is that the printer can print > the file and understand all the PostScript commands that are in the file, but > the dxpsview'er doesn't understand all the commands. Isn't the pspreviewer > suposed to be a complete PostScript interpreter? Just curious! Here is an explanation of why PostScript(r) programs generated by existing Macintosh and PC applications may not work immediately on Display PostScript(tm) systems, including the DEC previewer, dxpsview. Some PostScript language code to work around the common problems is appended to this message. PostScript language programs that are written according to the PostScript Language Reference Manual are guaranteed to be portable across all Adobe PostScript interpreters for both printers and displays. Period. In practice, it is desirable to be able to change certain aspects of a printer's behavior under program control, and this means using PostScript language programs. An example of such printer specific behaviour is the use of a specific paper tray if it is available on the particular PostScript printer. To accomodate this requirement, the PostScript interpreter in each printer may have system-specific operators that are defined in special dictionaries. Applications that can take advantage of special features of a printer, or that just want to avoid the overhead of sending their particular library of procedures to the printer before every document, can use the system-specific operators to do so. However, application writers must take great care when using operators that are defined outside the PostScript Language Reference Manual. To avoid writing custom drivers for specific printers and thereby losing all portability of the PostScript programs they generate, applications typically include a prolog of PostScript language code at the beginning of a document description both to test for special printer features and to store a library of procedures semi-permanently in the printer (they are stored until the printer is powered off). The problem that is encountered when giving a PostScript program generated by the popular applications to a Display PostScript system, is that the PostScript prologs that are prepended to the document descriptions often use some system-specific operators without first testing whether they are defined in the interpreter. The most obvious situation arises when an application tries to store its library of procedures so that they are available to subsequent jobs: In printers, document descriptions are executed one at a time in sequence by a PostScript program referred to as the "server loop". The server loop executes the PostScript operator save before starting each job and executes the restore operator at the end of the job. Any definitions made by a document description are discarded by the restore operator. To keep a library of procedures for subsequent jobs, the procedures must be defined outside the server loop's save/restore protection. This is accomplished by sending a special job to the printer that executes a system-specific operator, "exitserver", which is defined in a system-specific dictionary, "serverdict", and then executing the procedure definitions. After the job completes, the server loop is restarted and the definitions are available to the next job to arrive at the printer. The Display PostScript System has no notion of a sequence of jobs. It simply provides the PostScript imaging model to applications that want to draw on displays. Therefore it has no server loop and none of the system-specific operators and dictionaries to support the server loop. All Adobe PostScript printers to date have had a server loop and so it is understandable that the authors of PostScript drivers for applications have overlooked the fact that serverdict and its operators are system-specific. This is why the PostScript drivers in the most popular applications simply try to execute the "exitserver" operator from "serverdict" without checking first that the dictionary and operator are both defined by the interpreter. Consequently the PostScript programs generated by these applications encounter an error when executed by the interpreter in a Display PostScript System. Because it is impractical to expect application vendors to issue corrected, system independent drivers, the appended PostScript language procedures may be prepended to documents before giving them to a Display PostScript system, including DEC's dxpsview. These procedures make documents that use Apple's Laser Prep prolog and the Microsoft Word prolog work on DEC's previewer. Just concatenate these procedures, the application's prolog, and the document description (in order) to the previewer as a single file. The same file, including the appended prolog, may be sent to a PostScript printer, of course. The prolog provided here contains a minimal set of definitions. Other definitions may be needed by drivers used by other applications. There are sufficient examples in the appended prolog to show how to add definitions as necessary. For further advice on writing system independent PostScript device drivers, please refer to the book "PostScript Language Program Design" by Adobe Systems, published by Addison-Wesley. -------------------------------- Cut Here -------------------------------- %! %%Title: dpsdummyprinter.ps -- DPS prolog to emulate some printer features. % % Copyright (c) 1989 Adobe Systems Incorporated. All rights reserved. % % This file makes a number of definitions that are technically system specific % but are used by many existing PostScript language drivers that were written % without sufficient attention to the specification. % % This prolog ensures that serverdict, exitserver, and assorted statusdict % operators are defined as expected. The flushfile operator is also redefined % to allow Macintosh files with a prepended Laser Prep file to work properly. % % There is one special "feature" definition. The ASCII character \004 % (CTRL-D) is defined as a no-op operator in case the prolog contains % one to indicate end-of-file in some contexts. % %%BeginProcSet: DPSDummyPrinter 1 0 /serverdict where {%if pop } {%else /serverdict 1 dict def } ifelse serverdict /exitserver known not { % NOTE: We let the usual invalidaccess error occur if serverdict is not % writeable and exitserver is not known. This is unlikely because % either serverdict was just created (above) or it already existed % in which case exitserver should have been defined. serverdict /exitserver % int exitserver -- { 0 ne { /exitserver errordict /invalidaccess get exec } if {{end} loop} stopped pop % Clear dictstack clear } bind put } if statusdict /execjob known not { statusdict /execjob {exec} bind put } if statusdict /legal known not { statusdict /legal {} put } if statusdict /letter known not { statusdict /letter {} put } if statusdict /pagecount known not { statusdict /pagecount 0 put } if statusdict /printername known not { statusdict /printername (DPS) put } if statusdict /setjobtimeout known not { statusdict /setjobtimeout {pop} bind put } if statusdict /setrealdevice known not { statusdict /setrealdevice {} put } if statusdict /waittimeout known not { statusdict /waittimeout 600 put } if % The Mac Laser Prep file executes the flushfile operator to get to the end % of the prolog. When documents are saved with the prolog attached, the % flushfile consumes the document and nothing is printed. To get around this % problem the definition of flushfile is changed below to consume bytes of % input until a PostScript language comment (%) character is found. The % rest of the line is then consumed before the revised flushfile terminates. % This only works correctly when there is a PostScript language comment % where an end-of-file would be expected, which is usually true, luckily. /*flushfile /flushfile load def /flushfile % file flushfile -- {%def {%loop -- search for next percent character in file dup % Copy file parameter read { % Consume character 8#045 eq { % Check for ASCII percent character exit % Leave loop } if } if } loop {%loop -- search for newline character at end of comment dup % Copy file parameter read { % Consume character 8#012 eq { % Check for ASCII newline character exit % Leave loop } if } if } loop pop % Discard file parameterp } bind def (\004) cvn {} def % To ignore ^D at the end of prologs. %%EndProcSet   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03435; 14 Sep 89 0:45 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03057; 14 Sep 89 0:03 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab03051; 13 Sep 89 23:56 EDT Received: from [128.32.133.1] by SMOKE.BRL.MIL id aa04938; 13 Sep 89 23:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA23592; Wed, 13 Sep 89 20:31:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 03:19:46 GMT From: Timothy Hall Organization: Boston Univ. Subject: Error 15 and a new question... Message-Id: <38099@bu-cs.BU.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have had this error for several different reasons. If I remember correctly, one of my bugs that caused this to happen was when a transformation or loadmatrix resulted with NaN as an element of the top matrix in the matrix stack. I think a second bug was pushing the matrix stack too many times. Good luck, it's tough to debug when you keep ending up at the login prompt and no corefile has been left! (I did this on a 240 with 3.1F) While I'm here.....I have this bizarre bug that causes the lighting on our SGI to go into twinkie zone. Under a few certain transformations my light source shows up in the wrong place and shades p-gons with an "all or nothing" effect - either pure white or ambient grey at the verticies. Even more bizarre is that with shademodel( FLAT ) I will still get color interpolation across a surface. I must say that I've been talking to someone at the hotline about this and he has been most helpful. -Tim tjh@bu-pub.bu.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22502; 15 Sep 89 20:30 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab21925; 15 Sep 89 19:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab21915; 15 Sep 89 19:10 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa14002; 15 Sep 89 19:04 EDT Received: Wed, 13 Sep 89 13:52:21 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Wed, 13 Sep 89 13:52:21 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8909132052.AA08773@aero4.larc.nasa.gov> To: sgi!jmb%patton.sgi.com@ucbvax.berkeley.edu Subject: Re: various boot-related questions. Cc: info-iris@BRL.MIL I know of one case in which I said 'no' to fsck (on our 3130). We had a bad storager board and it said that the disk was bad and I KNEW it wasn't bad, so I stop fsck. But like you said, I almost always say 'yes'. -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03968; 14 Sep 89 2:01 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03917; 14 Sep 89 1:50 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03891; 14 Sep 89 1:37 EDT Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa06173; 14 Sep 89 0:59 EDT Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 9827; Thu, 14 Sep 89 01:02:14 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 14 Sep 89 07:01:31 Date: Thu, 14 Sep 89 07:01:36 +0200 (Central European Summer Time) From: Knobi der Rechnerschrat Subject: Signal 15 and Lighting To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8909140059.aa06173@SMOKE.BRL.MIL> Hallo everybody, we have seen the 'killed by signal 15' problem several times on a 70/GT running 3.1D. It can usually be tracked down to a severe corruption of the Matrix stack (doing 500 pushmatrix calls without popmatrix and vice versa). I can understand that the window system gets problems in this cases, but probably an error message at user level would be more appropriate than 'flatening' the graphics systems. Tim Hall wrote something about a lighting problem he has. We see a similar problem. We have an application with two light sources positioned roughly at the z-axis at +/- infinity. The whole application runs in MVIEWING mode, and I'm loading identity matrices hen it is neccessary. Usually we have coordinates that fit into ortho(-30.,30.,-30.,30.,-30.,30.). For one reason we change the ortho to 'screen coordinates' using ortho2(0,(float)XMAXSCREEN, 0.,(float)YMAXSCREEN). When resetting the ortho to our 'normal' values, the light sources have changed from z-direction to x-direction and the shading appears to be some kind of 'dirty'. The ortho change is accompanied by a mode change to and from OVERDRAW mode. Unfortunatelly the sequence in question is called from several places, but the error occurs only on half of the occasions. I know this description is not sufficient to describe the problem fully, but perhaps somebody has a hint. Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET:   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03348; 14 Sep 89 12:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02689; 14 Sep 89 11:37 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa02347; 14 Sep 89 11:19 EDT Received: from [128.32.133.1] by ADM.BRL.MIL id aa28172; 14 Sep 89 11:06 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA27030; Thu, 14 Sep 89 07:53:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 14:18:04 GMT From: "ROBERT E. MINSK" Organization: Georgia Institute of Technology Subject: Signal 15 Message-Id: <9169@pyr.gatech.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I work with ccsupos who brought the problem up. Signal 15 happens with several tried a tested programs (i.e. some wavefront software) When we log back in after the window server crash it does not seem to happen for quite a while. We have two 120GTX machines and one seems to crash the window server about twice as often as the other. It does seem silly that the whole window server crashes. 8-( -- ROBERT E. MINSK Georgia Insitute of Technology, Atlanta Georgia, 30332 uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!ccoprrm ARPA: ccoprrm@pyr.gatech.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03494; 14 Sep 89 12:50 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03135; 14 Sep 89 12:25 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03120; 14 Sep 89 12:17 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16584; 14 Sep 89 11:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA29672; Thu, 14 Sep 89 08:42:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 15:31:39 GMT From: Pablo Fernicola Organization: UF Machine Intelligence Laboratory. Subject: Plea for X windows source/help Message-Id: <20886@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A while ago I posted a message on the problems that we are having in compiling X Windows programs (ie we can't compile any). If you have the source code for a X Windows program that you _HAVE_ compiled, please E-mail it to me. Also, include the command that you used to compile it. We are gradually approaching a Big deadline, so please be quick. Thank you very much! Pablo -- pff@beach.cis.ufl.edu Pablo Fernicola - Machine Intelligence Laboratory - UF "If we knew how it works, it wouldn't be called research."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03718; 14 Sep 89 13:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03494; 14 Sep 89 12:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03443; 14 Sep 89 12:46 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17227; 14 Sep 89 12:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA01631; Thu, 14 Sep 89 09:17:32 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 15:33:46 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: NFS on PI Message-Id: <41738@sgi.sgi.com> References: Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article , mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) writes: > I am having terrible trouble with NFS between a PI and several other > machines. The PI hangs (completely dead) randomly when transferring > large files via NFS. The problem almost always occurs when I am > reading and writing large files on NFS-mounted disks. This happens > every few days when the input and output files are on the same > (remote) machine, and every few hours when the input and output files > are on different machines. > > The worst problems are with the NeXT machine (O/S 0.9), but I also get > failures with SGI 3000's (O/S 3.6). The PI is running a recent version > of the O/S also, 3.14711181642.... > > Changing things like hard vs soft mount does not help.... > > Is this just another SGI trick to get us to buy more disk drives for > the PI? > -- > John D. McCalpin - mccalpin@masig1.ocean.fsu.edu > mccalpin@scri1.scri.fsu.edu > mccalpin@delocn.udel.edu Better get the latest OS release. The 3.147... version is the original OS release for the PI, and is quite out of date by now. And we really aren't trying to trick you into buying more disk drives ... -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab03718; 14 Sep 89 13:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac03494; 14 Sep 89 12:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03451; 14 Sep 89 12:46 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17250; 14 Sep 89 12:18 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA01618; Thu, 14 Sep 89 09:17:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 15:31:37 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: various boot-related questions. Message-Id: <41737@sgi.sgi.com> References: <89Sep12.214425edt.2245@neat.cs.toronto.edu>, <1989Sep13.183918.8050@helios.physics.utoronto.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Sep13.183918.8050@helios.physics.utoronto.ca>, sysruth@helios.physics.utoronto.ca (Ruth Milner) writes: > I have also suggested that there should be a way for it to i) automatically > reboot after a crash, without depressing its belly button :-), and ii) have > it actually HALT after the shutdown sequence has completed, rather than > rebooting if you aren't there in time to press . I often initiate > shutdowns from my desk, and then go to the machine room a minute or two > later. In the IRIS' case, it had cleverly rebooted by this time and I had to > shut it down again. There have been some hints that new PROMs might fix at > least one of these problems, but it has been like pulling teeth to get any > concrete information. The system will halt after the shutdown sequence if you shut down to init state 0, for instance 'shutdown -i0', or 'init 0'. This works, I've done it alot. We don't autoreboot after an OS crash because there may be important data sitting on the screen that would be lost in this case - like the error message which tells you what happened. There aren't any 'bugs' to be fixed here, although we can argue about reboot after crash ... > While I can live without ii), part i) is absolutely vital. If it crashes > due to power problems or greedy people filling up swap or something, there > is no reason why it shouldn't go ahead and reboot. And in other situations, > I can get the information from /usr/adm/SYSLOG (or from the console if it > can't reboot). You can't get the final crash messages from SYSLOG! The kernel just crashed, how can it write reliably to the filesystem? If you have the PROM environment variable 'bootmode=c', the machine will reboot after a power fail. And filling up swap won't crash the machine, the OS will instead start gunning down processes. This would seem to answer most of your concerns. > -- > Ruth Milner UUCP - {uunet,pyramid}!utai!helios.physics!sysruth > Systems Manager BITNET - sysruth@utorphys > U. of Toronto INTERNET - sysruth@helios.physics.toronto.edu > Physics/Astronomy/CITA Computing Consortium -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06741; 14 Sep 89 16:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06343; 14 Sep 89 16:28 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06291; 14 Sep 89 16:21 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22565; 14 Sep 89 15:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA12925; Thu, 14 Sep 89 12:20:07 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 18:05:44 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: NFS on PI Message-Id: <41751@sgi.sgi.com> References: , <41738@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <41738@sgi.sgi.com>, jmb@patton.sgi.com (Jim Barton) writes: > In article , mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) writes: > > I am having terrible trouble with NFS between a PI and several other > > machines. The PI hangs (completely dead) randomly when transferring > > large files via NFS. > > Better get the latest OS release. The 3.147... version is the original > OS release for the PI, and is quite out of date by now. Seconded. The first PI release had bugs not only to do with Ethernet (which showed up best under NFS stress), but also with interrupted level management (for kernel heads, spl was busted). Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07345; 14 Sep 89 17:00 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06343; 14 Sep 89 16:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab06291; 14 Sep 89 16:21 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22574; 14 Sep 89 15:17 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA12939; Thu, 14 Sep 89 12:20:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 18:09:17 GMT From: Brendan Eich Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: various boot-related questions. Message-Id: <41752@sgi.sgi.com> References: <89Sep12.214425edt.2245@neat.cs.toronto.edu>, <41737@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <41737@sgi.sgi.com>, jmb@patton.sgi.com (Jim Barton) writes: > In article <1989Sep13.183918.8050@helios.physics.utoronto.ca>, sysruth@helios.physics.utoronto.ca (Ruth Milner) writes: > > I have also suggested that there should be a way for it to i) automatically > > reboot after a crash, without depressing its belly button :-), and ii) have > > it actually HALT after the shutdown sequence has completed, rather than > > rebooting if you aren't there in time to press . > > The system will halt after the shutdown sequence if you shut down to init > state 0, for instance 'shutdown -i0', or 'init 0'. We ship BSD-like reboot(1M) and halt(1M) scripts that call shutdown with enough arguments to get it to bounce the system and take it to the ground, respectively. Brendan Eich Silicon Graphics, Inc. brendan@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07896; 14 Sep 89 19:29 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07850; 14 Sep 89 19:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07827; 14 Sep 89 19:05 EDT Received: from HAC2ARPA.HAC.COM by SMOKE.BRL.MIL id aa03030; 14 Sep 89 18:25 EDT Received: from [128.152.60.1] by hac2arpa.hac.com (5.59/SMI-DDN) id AA14947; Thu, 14 Sep 89 15:28:27 PDT Received: by rsgate id <000000C3061@rsgate.RSG.HAC.COM> ; Thu, 14 Sep 89 15:27:06 PDT Date: Thu, 14 Sep 89 15:26:36 PDT From: "Kevin R. Martin" (213)-578-4316 <"SCCR50::DSLKRM"@rsgate.rsg.hac.com> Subject: Re: real-time and 3D workstations. To: info-iris%brl.arpa@hac2arpa.hac.com X-Vms-Mail-To: RSGATE::EXOS%"info-iris%brl.arpa@hac2arpa" Message-Id: <890914152636.000000C3061@rsgate.RSG.HAC.COM> Please excuse my delay in accessing and contributing to the engaging discussion on realtime unix/graphics. All the comments were great. I couldn't resist but to add a thing or two. First, on the discussion on realtime. Realtime is what you need it to be, no more or no less. From James Martin, Design of Real-Time Computer Systems: "A real-time computer system may be defined as one which controls an environment by receiving data, processing them, and taking action or returning results **sufficiently** quickly to affect the functioning of the environment at that time." Milliseconds and microseconds are interesting, but they don't define realtime. They just define our current limits at quantizing time and reacting with it via computers. (Of course the existance of "real-time features" makes the job easier and helps to "classify" an operating system). Let's not forget that the Voyager sent back 'realtime' video, traveling at the speed of light, which was received several hours after it encountered its subjects :-)! Second, out of interest in the subject of realtime workstations, let me refer to a case involving realtime unix/graphics and the measurement of time. In any discussion on measuring time we usually refer to these terms (among others): Resolution: Minimum time interval that can be measured. Accuracy: The degree of conformity of the measure to a true value. Precision: The degree of refinement with which a measurement is stated. Now let's say the unix/graphics task is to measure the amount of time it takes for an observer to react to an event (stimulus) in the graphics. Ignoring the speed of light (a valid assumption this time :-)), we would want to measure the time from when the event occurs on the screen, until the observer taps a response button. To get a feeling for the time and distances involved-- imagine a car appearing out of the fog, in your lane, heading in your direction. If your both traveling at about 35 mph, ten milliseconds represents about one foot of closing distance. Lets assume the event (say a traffic light changing this time) takes place in the middle of a non-interlaced display. Since I presume I can't call gettimeofday() at the exact point in time on the display when the event becomes visible (say when half the pixels representing the event are turned on, or even when the middle scan line of those representing the event comes on), I'll end up calling it some time nearby. The value I read may very well have microsecond resolution, and accuracy of 1 millisecond compared to a 'real' world clock. However, because of the latency (I couldn't access the clock at the desired point in time), the value I have to work may need to be stated with a precision somewhere around a half a frame time (+/- 16.667 msec on a 30Hz noninterlaced monitor). And this is just the time measurement needed to represent the start of the interval being measured! Similar difficulties result in measuring the end of this interval (and any interim points), and only compound the precision loss. Despite these limitations, we ARE measuring these intervals with significantly better precision, WITH Silicon Graphics machines, and some custom hardware. And yes it is true that human machine interaction can be considered on the order of tenths of seconds. But we would like to know just how good we humans are and how much time we're losing. Perhaps we can't always rely on humans to be our only interface to machines... Kevin R. Martin Internet: dslkrm@sccr50.dnet.hac.com Radar Systems Group U.S. Mail: Hughes Aircraft Company Loc: RC, Bldg: R50, M/S: 2723 GM Hughes Electronics Corp. P.O. Box 92426 General Motors Corp. Los Angeles, CA 90009   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07957; 14 Sep 89 19:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07896; 14 Sep 89 19:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07859; 14 Sep 89 19:06 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03144; 14 Sep 89 18:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA25799; Thu, 14 Sep 89 15:45:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 22:27:04 GMT From: "Scott R. Presnell" Subject: 4D and NeWS-emacs Message-Id: <11831@cgl.ucsf.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Hi all, I'm having a heck of a time getting emacs to run with the NeWS patches on the 4D/20G (Personal Iris). Note: these are the same patches that work great under the Sun version of NeWS. I'm can apply the patches and compile an emacs which uses the NeWS software (from columbia.edu). That emacs binary is functional in the sense that it wil execute and run and I can edit files for a while. However... There are two main problems. One is that the cursor does not seem to be tracking the characters on the screen correctly: as though the emacs cursor does not move the correct distance on the screen. This does not inhibit file editing, but sometimes I can't tell exactly which character I'm over. A ctrl-L will clean up the garbage that is generated from editing the characters, but the cursor is always mispositioned - the farther from the left margin the worse it gets. The bigger problem is that what eventually happens is the emacs process and the NeWS server "miscommunicate" and the emacs process reports: "emacs: received invalid message from NeWS server." in an infinite loop. Usually this happens when I cause a repaint of the screen due to moving a window. I can see where and why this is going on in the emacs code, but I'm at a loss as to how attack fixing it... Has anyone had any experience with this situation? Anyone sucessfully using NeWS-emacs on a 4D/20? Thanks for your help. Scott   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08267; 14 Sep 89 20:31 EDT Received: by VMB.BRL.MIL id bm08161; 14 Sep 89 20:25 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03852; 14 Sep 89 13:26 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03822; 14 Sep 89 13:15 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17916; 14 Sep 89 12:49 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA02956; Thu, 14 Sep 89 09:39:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 16:30:44 GMT From: George Drettakis Organization: University of Toronto, CSRI Subject: Re: various boot-related questions. Message-Id: <1989Sep14.123044.916@jarvis.csri.toronto.edu> References: <41737@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <41737@sgi.sgi.com> jmb@patton.sgi.com (Jim Barton) writes: >filling up swap won't crash the machine, the OS will instead start gunning >down processes. This would seem to answer most of your concerns. > This maybe true. However a I have probably witnessed more swap space filling than any other person around (we did it 2-3 times a day at one point), and what happens is that the machine goes into a very confused state, and yet again, the belly button is the only solution (NOTHING responds, no rlogins, not the console). This resulted in us writing a checkpointing mechanism so we could save the most recent data before the crash. > >-- Jim Barton >Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" >jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb -- George Drettakis (416) 978 5473 Dynamic Graphics Project UUCP: ..!uunet!dgp.toronto.edu!dret Computer Systems Research Institute Bitnet: dret@dgp.utoronto University of Toronto Internet: dret@dgp.toronto.edu Toronto, Ontario M5S 1A4, CANADA EAN: dret@dgp.utoronto.cdn -- Live where it's never below 20 deg. C.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09559; 15 Sep 89 0:40 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab09533; 15 Sep 89 0:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab09521; 15 Sep 89 0:16 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05367; 14 Sep 89 23:47 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA12019; Thu, 14 Sep 89 20:38:13 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 21:44:58 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Need LPD code for SGIs Message-Id: <544@odin.SGI.COM> References: <8909122300.AA17305@prism.gatech.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909122300.AA17305@prism.gatech.edu>, ccsupos%prism@GATECH.EDU ("SCHREIBER, O. A.") writes: > > What are the lpd codes please? > We have been having a lot of shut downs of the window server > due to > signal 15 > I do not know what causes that to happen. > Olivier Schreiber (404)894 6147, Office of Computing Services lpd codes? What's that got to do with the signal 15? signal 15 is SIGTERM. Something has sent a SIGTERM to the window server UNIX kills the process. The only reason I know of why this signal would be sent is that something happened to the graphics subsystem such that it needed to be reset. When this happens the kernel sends a SIGTERM to all graphics processes to remove them prior to resetting the graphics. You are probably running some program that does bad things to the graphics pipeline. There should be some other message in your syslog file such as "fifo timeout". -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09672; 15 Sep 89 1:06 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09533; 15 Sep 89 0:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09521; 15 Sep 89 0:16 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05365; 14 Sep 89 23:46 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA11967; Thu, 14 Sep 89 20:37:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 14 Sep 89 21:07:41 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: User Dialog Message-Id: <538@odin.SGI.COM> References: <20862@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL My guess is that you are overflowing your input buffer because qread is returning more than just keystrokes. For example, there will be an INPUTCHANGE event. Also qread returns shorts not chars so you definitely overrun it on the 15th character you type. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab09672; 15 Sep 89 1:06 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09594; 15 Sep 89 0:56 EDT Received: from KAOS.Stanford.EDU by VMB.BRL.MIL id aa09584; 15 Sep 89 0:43 EDT Received: by kaos.Stanford.EDU (4.0/MasterMail-1.0) id AA29598; Thu, 14 Sep 89 21:43:36 PDT From: paul@kaos.Stanford.EDU (Paul Ning) Message-Id: <8909150443.AA29598@kaos.Stanford.EDU> To: info-iris@vmb.brl.mil Cc: paul@kaos.Stanford.EDU Subject: dog Date: Thu, 14 Sep 89 21:43:36 PDT Anyone out there have a version of /usr/demos/dog which sends out "broadcast" packets to only one (or a select few) machines ? We were running dog on two Irises until we found out that the broadcast packets and subsequent responses slowed down the entire network. Now we can only run flight *sigh*. (We thought about just disconnecting the Irises from the rest of the network, but we need to access their disks via NFS.) - Paul Ning   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22048; 15 Sep 89 19:32 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21925; 15 Sep 89 19:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21915; 15 Sep 89 19:10 EDT Received: from AERO4.LARC.NASA.GOV by SMOKE.BRL.MIL id aa14000; 15 Sep 89 19:03 EDT Received: Fri, 15 Sep 89 07:38:31 EDT by aero4.larc.nasa.gov (5.52/5.6) Date: Fri, 15 Sep 89 07:38:31 EDT From: "Brent L. Bates AAD/TAB MS294 x42854" Message-Id: <8909151438.AA14117@aero4.larc.nasa.gov> To: paul@kaos.stanford.edu Subject: Re: dog Cc: info-iris@BRL.MIL I have posed that question before, so far I haven't heard of any. Has anyone done that yet? -- Brent L. Bates NASA-Langley Research Center M.S. 294 Hampton, Virginia 23665-5225 (804) 864-2854 E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.gov   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac22502; 15 Sep 89 20:30 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab22403; 15 Sep 89 20:19 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab22286; 15 Sep 89 20:04 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14123; 15 Sep 89 19:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA13527; Fri, 15 Sep 89 16:25:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 89 15:58:00 GMT From: ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!swanson@uxc.cso.uiuc.edu Subject: su modifier Message-Id: <223000002@uxe.cso.uiuc.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone implemented some sort of "su to root" modifier that only allows people in a certain group to su to root? Our Alliants (running Concentrix 5.5, which as I understand it, is of a BSD origin) have a great su utility that lets only the users listed in a certain group have access to the "su root" stuff. Since the SGIs are System V, and System V is suppose to be more secure than BSD, is this sort of thing in the works (maybe in 3.2?) or does it already exist? Thanks, Amy Swanson SGI Systems Administrator amys@ncsa.uiuc.edu NCSA - National Center for Supercomputing Applications University of Illinois, Champaign-Urbana   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab23242; 15 Sep 89 22:05 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23136; 15 Sep 89 21:50 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23065; 15 Sep 89 21:31 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14546; 15 Sep 89 20:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA16899; Fri, 15 Sep 89 17:28:43 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 89 15:15:19 GMT From: Gary Klaassen Organization: York U. Computing Services Subject: Any pd versions of emacs running on SGI 4D boxes? Message-Id: <3802@yunexus.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone have a version of GNU Emacs or Jove or microemacs running on a SGI 4D/20? If so could you please point me to an ftp site or send a diff file or other pointers on how to go about this. I have been told that getting GNU Emacs running on an SG 4D box is a big job. G. Klaassen York University   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23364; 15 Sep 89 22:15 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23242; 15 Sep 89 22:05 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23186; 15 Sep 89 21:49 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16020; 15 Sep 89 21:34 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA19635; Fri, 15 Sep 89 18:20:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Sep 89 01:03:35 GMT From: Geoff Collyer Organization: Statistics, U. of Toronto Subject: Re: swap space exhaustion Message-Id: <1989Sep16.010335.9619@utstat.uucp> References: <1989Sep13.183918.8050@helios.physics.utoronto.ca>, <41737@sgi.sgi.com>, <1989Sep15.162116.29789@utzoo.uucp> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Jim Barton: >>filling up swap won't crash the machine, the OS will instead start gunning >>down processes... Henry Spencer: >Would it be too much to ask that this be made a configuration option? >Some of us think that it is much better for a machine to crash cleanly >than to try to keep running with crucial processes (Murphy's Law says that >the gunned-down processes will be important daemons) dying randomly and >disrupting operations in bizarre ways. I would like to amplify Henry's comment. Why strafe innocent processes? When possible, I think returning ENOMEM from fork, exec, sbrk and the like is preferable; when that is not possible, given that sensible modern Unixes can be made to autoboot after a panic (ahem!), a panic("out of swap space") will cause a brief interruption and a clean start. Strafing processes (on our SunOS 3.x systems) has usually resulted in the deaths of inetd and sometimes ypbind or ypserv. After killing such critical daemons, the system was dead in the water and had to be manually crashed (L1-A key) and booted. This is not what you want from a timesharing system (pardon my heresy) that is meant to run unattended much of the time. -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23581; 15 Sep 89 22:51 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23435; 15 Sep 89 22:30 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23428; 15 Sep 89 22:24 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16179; 15 Sep 89 22:01 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA21591; Fri, 15 Sep 89 18:57:38 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Sep 89 01:46:33 GMT From: Jean-Francois Lamy Subject: Re: Any pd versions of emacs running on SGI 4D boxes? Message-Id: <89Sep15.214545edt.2165@neat.cs.toronto.edu> References: <3802@yunexus.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL gklaass@yunexus.UUCP (Gary Klaassen) writes: >Does anyone have a version of GNU Emacs or Jove or microemacs running >on a SGI 4D/20? If so could you please point me to an ftp site or send >a diff file or other pointers on how to go about this. There is a version of jove available for anonymous FTP on neat.cs.toronto.edu (128.100.1.65, across town). That version does run on 4d machines. > I have been told >that getting GNU Emacs running on an SG 4D box is a big job. I looked around in our source directory; we are running essentially what the etc/MACHINES file recommends, but additional changes have been made in config.h and sysdep.c to enable job control (a BSD_JOBCTRL define was added). temacs was dumping core in index() but a 10 line version in C was added which fixed the problem. Making sure that was all would require more careful scrutiny. Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23705; 15 Sep 89 23:06 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab23581; 15 Sep 89 22:55 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23541; 15 Sep 89 22:43 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16337; 15 Sep 89 22:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA23423; Fri, 15 Sep 89 19:31:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Sep 89 01:09:42 GMT From: Jack Weldon Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: NFS on PI Message-Id: <41826@sgi.sgi.com> References: , <41738@sgi.sgi.com>, <41751@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <41751@sgi.sgi.com> brendan@illyria.wpd.sgi.com (Brendan Eich) writes: >> > I am having terrible trouble with NFS between a PI and several other >> > machines. The PI hangs (completely dead) randomly when transferring >> > large files via NFS. > >Seconded. The first PI release had bugs not only to do with Ethernet >(which showed up best under NFS stress), but also with interrupted level >management (for kernel heads, spl was busted). > >Brendan Eich >Silicon Graphics, Inc. > I agree heartily with both Jim and Brendan's assesment of the problem. Since the 3.2 Release of IRIX is around the corner, you may want to wait until then. If not, feel free to call the Hotline and ask for a maintenence tape to bring you up above Rev C (3.147XXX). The bug was fixed in Rev D, but a Rev G is also available that has the NFS patch and other patches as well. If this is your only problem, I'd stick with Rev D. Let us know if we can assist. Jack Weldon Product Support System Engineer SGI Geometry Hotline -- Cheers, Jack   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24753; 16 Sep 89 1:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24409; 16 Sep 89 0:25 EDT Received: by VMB.BRL.MIL id aa24349; 16 Sep 89 0:12 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa18851; 15 Sep 89 14:38 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07953; 15 Sep 89 14:18 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA25277; Fri, 15 Sep 89 11:09:41 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 89 16:21:16 GMT From: Henry Spencer Organization: U of Toronto Zoology Subject: swap space exhaustion Message-Id: <1989Sep15.162116.29789@utzoo.uucp> References: <89Sep12.214425edt.2245@neat.cs.toronto.edu>, <1989Sep13.183918.8050@helios.physics.utoronto.ca>, <41737@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <41737@sgi.sgi.com> jmb@patton.sgi.com (Jim Barton) writes: >filling up swap won't crash the machine, the OS will instead start gunning >down processes... Would it be too much to ask that this be made a configuration option? Some of us think that it is much better for a machine to crash cleanly than to try to keep running with crucial processes (Murphy's Law says that the gunned-down processes will be important daemons) dying randomly and disrupting operations in bizarre ways. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10771; 18 Sep 89 7:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10405; 18 Sep 89 6:52 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10397; 18 Sep 89 6:45 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa17722; 18 Sep 89 6:36 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA21401; Mon, 18 Sep 89 03:26:04 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 15 Sep 89 21:28:52 GMT From: Dana Batali Organization: Pixar -- Marin County, California Subject: gnu g++ and gnu c Message-Id: <6757@pixar.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has anyone successfully ported gnu's c++ (g++) and gnu c to the 4d? Any pointers, recommendations, warnings, war stories, etc., are much appreciated. Thanks in advance! Dana Batali UUCP: ..!{sun,ucbvax}!pixar!dana   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06320; 17 Sep 89 16:34 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06044; 17 Sep 89 16:13 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa06042; 17 Sep 89 16:06 EDT Received: from phvax.smithkline.com by ADM.BRL.MIL id aa05470; 16 Sep 89 20:57 EDT Received: from PHVAX.DECnet MAIL11D_V3 by smithkline.com (5.57/Ultrix2.4-C) id AA14230; Sat, 16 Sep 89 20:49:46 EDT Date: Sat, 16 Sep 89 20:49:45 EDT Message-Id: <8909170049.AA14230@smithkline.com> From: dixons%phvax.dnet@smithkline.com To: "info-iris@brl.mil %INET.dnet"@smithkline.com Subject: converting Utah raster files Can anyone tell me how to convert back and forth between the Utah raster toolkit RLE image format and the standard SGI image format used by ipaste etc? Have I missed a tool in 4Dgifts? Or does someone have a tool they can send me? Thanks. Scott Dixon (dixons@smithkline.com)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa06909; 17 Sep 89 17:42 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab06320; 17 Sep 89 16:40 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa06200; 17 Sep 89 16:29 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa04589; 16 Sep 89 19:08 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA19398; Sat, 16 Sep 89 16:07:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 16 Sep 89 22:48:51 GMT From: Andrew Cherenson Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: dog Message-Id: <41831@sgi.sgi.com> References: <8909150443.AA29598@kaos.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909150443.AA29598@kaos.Stanford.EDU> paul@KAOS.STANFORD.EDU (Paul Ning) writes: > >Anyone out there have a version of /usr/demos/dog which sends out >"broadcast" packets to only one (or a select few) machines ? We were >running dog on two Irises until we found out that the broadcast >packets and subsequent responses slowed down the entire network. >Now we can only run flight *sigh*. > >(We thought about just disconnecting the Irises from the rest of >the network, but we need to access their disks via NFS.) > >- Paul Ning In the IRIX 3.3 release for the IRIS-4D, "dog" will send multicast packets by default. For backward compatibility with 3000's and 4D's running older releases, "dog" can use broadcasting. Multicasting has two benefits: 1) it will not affect machines that aren't listening to the "dog" multicast address, and 2) "dog" packets can be forwarded between networks. (BTW, we're using the IP multicast/IGMP/DVMRP software written by Steve Deering of Stanford.)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09665; 18 Sep 89 3:50 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09449; 18 Sep 89 2:58 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa09419; 18 Sep 89 2:51 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15774; 18 Sep 89 2:36 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA11772; Sun, 17 Sep 89 23:38:03 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 89 06:11:26 GMT From: LTH network news server Organization: Dept. of Automatic Control, Lund Inst. of Technology, Sweden Subject: Re: dog Message-Id: <1989Sep18.061126.4590@lth.se> References: <8909150443.AA29598@kaos.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909150443.AA29598@kaos.Stanford.EDU> paul@KAOS.STANFORD.EDU (Paul Ning) writes: > >Anyone out there have a version of /usr/demos/dog which sends out >"broadcast" packets to only one (or a select few) machines ? Yes, we have modified one of the files in the `dog' source code so it sends packets to one machine; it reads the environment variable ENEMY, and then opens a conventional (non-broadcast) connection. I can mail or post a context diff of the changes needed. Dag Michael Bruck -- Department of Automatic Control Internet: dag@control.lth.se Lund Institute of Technology P. O. Box 118 Phone: +46 46-108779 S-221 00 Lund, SWEDEN Fax: +46 46-138118   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13476; 18 Sep 89 9:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13046; 18 Sep 89 9:12 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12954; 18 Sep 89 9:01 EDT Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa19284; 18 Sep 89 8:13 EDT Received: Mon, 18 Sep 89 04:27:30 pdt by prandtl.nas.nasa.gov (5.51/1.2) Received: Mon, 18 Sep 89 07:26:31 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Mon, 18 Sep 89 07:49:23 EDT by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Mon, 18 Sep 89 07:49:23 EDT From: Tony Facca Message-Id: <8909181149.AA06699@lerc08.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: IRIX 3.3? (was Re: dog) Andrew Cherenson writes: > In the IRIX 3.3 release for the IRIS-4D, "dog" will send multicast packets ^^^^^^^^ Is this for real? IRIX 3.3 already? What new things can we look forward to in 3.3 and how far off is it? -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17256; 18 Sep 89 11:56 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16876; 18 Sep 89 11:35 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa16593; 18 Sep 89 11:20 EDT Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa24360; 18 Sep 89 10:58 EDT Received: Mon, 18 Sep 89 07:57:23 pdt by prandtl.nas.nasa.gov (5.51/1.2) Received: Mon, 18 Sep 89 10:56:26 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Mon, 18 Sep 89 11:19:22 EDT by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Mon, 18 Sep 89 11:19:22 EDT From: Tony Facca Message-Id: <8909181519.AA07258@lerc08.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Scanner for PI ** This is a repost from a few weeks ago ** > We are looking for a 300 DPI scanner, which can be connected to a Personal > Iris. Does anyone have experience with this? It would be nice if the > vendor supplied both the hardware and a software driver which would enable > us to scan in color images, cut, paste, resize, them, etc. If the format > of the image file were compatible with SGI's image tools, so much the better. > > I'd appreciate any information, suggestions, etc. I know I have seen scan digitizers attached to Iris's, and at least one vendor at SIGGRAPH told me they had (will have) a driver for the Personal Iris's. I am collecting information for a procurement sometime in October/November -- any ideas? Thanks again, Tony -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20825; 18 Sep 89 15:55 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20135; 18 Sep 89 15:24 EDT Received: from KAOS.Stanford.EDU by VMB.BRL.MIL id aa19929; 18 Sep 89 15:06 EDT Received: by kaos.Stanford.EDU (4.0/MasterMail-1.0) id AA10108; Mon, 18 Sep 89 12:02:41 PDT From: paul@kaos.Stanford.EDU (Paul Ning) Message-Id: <8909181902.AA10108@kaos.Stanford.EDU> To: info-iris@vmb.brl.mil Cc: paul@kaos.Stanford.EDU Subject: Re: dog Date: Mon, 18 Sep 89 12:02:40 PDT In article <1989Sep18.061126.4590@lth.se> dag@control.lth.se (Dag Michael Bruck) writes: > Yes, we have modified one of the files in the `dog' source code so > it sends packets to one machine; it reads the environment variable > ENEMY, and then opens a conventional (non-broadcast) connection. > > I can mail or post a context diff of the changes needed. That would be great, but I can't find the source code on my machines. Was this an option you selected during installation or did you have to ask SGI for it? - Paul Ning   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21914; 18 Sep 89 17:25 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab21823; 18 Sep 89 17:14 EDT Received: from adm.brl.mil by VMB.BRL.MIL id ab21758; 18 Sep 89 17:05 EDT Received: from ew09.nas.nasa.gov by ADM.BRL.MIL id aa05407; 18 Sep 89 16:56 EDT Received: by ew09.nas.nasa.gov (5.61/1.34) id AA00859; Mon, 18 Sep 89 13:53:40 -0700 Date: Mon, 18 Sep 89 13:53:40 -0700 From: "Eric L. Raible" Message-Id: <8909182053.AA00859@ew09.nas.nasa.gov> To: info-iris@BRL.MIL In-Reply-To: Gary Klaassen's message of 15 Sep 89 15:15:19 GMT <3802@yunexus.UUCP> Subject: Yes, gnu emacs runs on 4D's Reply-To: raible@orville.nas.nasa.gov Date: 15 Sep 89 15:15:19 GMT From: Gary Klaassen I have been told that getting GNU Emacs running on an SG 4D box is a big job. This is not true. The 4D is fully supported in recent releases. The latest version (18.55) is from many places including prep.ai.mit.edu in the directory /u2/emacs. - Eric   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22060; 18 Sep 89 17:56 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21823; 18 Sep 89 17:14 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa21758; 18 Sep 89 17:05 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa05316; 18 Sep 89 16:51 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA23721; Mon, 18 Sep 89 13:44:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 89 20:22:16 GMT From: Ramani Pichumani Organization: Stanford University Computer Science Department Subject: meta key for X11 Message-Id: <11836@polya.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Has any gotten the meta key to work with X11 on a 4D machine. Apparently, the keyboard translation for NeWS windows doesn't apply to an X11 window so we are without a meta key when we run xemacs or tcsh. If I run xemacs remotely on my Sun, the xemacs on the Iris recognizes the 200 bit correctly so I suspect the problem is in the keyboard translation. Whatever the cause, the meta is never recognized on the Iris keyboard. Ramani Pichumani Tel: (415) 723-2902 or 723-2437 Department of Computer Science Fax: (415) 725-7411 Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22227; 18 Sep 89 18:21 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22205; 18 Sep 89 18:11 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa22089; 18 Sep 89 18:02 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa06542; 18 Sep 89 17:50 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA26608; Mon, 18 Sep 89 14:33:01 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 18 Sep 89 21:04:05 GMT From: EMD Organization: Control Data Corp., Arden Hills, MN Subject: Re: dog Message-Id: <14036@shamash.cdc.com> References: <8909181902.AA10108@kaos.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am wondering if one of the JOVE experts out there could help me with the problem I am having compiling JOVE. When I do a make (version 4.13 or 4.14) I get the following: **** make started at Mon Sep 18 16:03:48 CDT 1989 **** cc -O -I/usr/include/bsd -c keys.c cpp: warning ./jove.h:53: const redefined [This does NOT occur in V4.14] ccom: Warning: keys.c, line 16: illegal pointer combination "set-mark", -----------------^ ccom: Warning: keys.c, line 17: illegal pointer combination "beginning-of-line", --------------------------^ ccom: Warning: keys.c, line 18: illegal pointer combination "backward-character", ---------------------------^ ccom: Warning: keys.c, line 19: illegal pointer combination "unbound", ----------------^ . . . . and so on until it warns me about all 640 of them. Then when jove actualy runs I crashes code 11, when I try to type a control key sequence. Any hints on how to fix this up would be great, thanks. Brad Miller bmiller@shamash.cdc.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23859; 19 Sep 89 0:34 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23506; 18 Sep 89 23:42 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23455; 18 Sep 89 23:29 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03129; 18 Sep 89 23:09 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA15111; Mon, 18 Sep 89 19:58:20 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 89 02:11:46 GMT From: Steve Maurer Organization: Vicom Systems Inc. San Jose, Cal. Subject: Various SGI Questions (VME bus interface & other programming) Message-Id: <1989Sep19.021146.2609@vicom.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I am working on a project in which we are integrating a number of boards into an SGI 4D/70GT. The boards include a real-time "system-controller", which talks to the SGI via a simple message-passing scheme (through dual ported memory), and our own memory boards (VME A32/D16). I'm also porting software. Now for my questions: #1] Our upper level software gives a "warning" in the link stage about "jump relocation". The actual messages read: Warning: error: multiply defined Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x489dbc to 0x10066270 (asm) Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x489eac to 0x10066270 (asm) Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x489fc8 to 0x10066270 (asm) Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x48a0c8 to 0x10066270 (asm) What is causing this? #2] We need to reserve an entire interrupt priority level for communication between our various boards. This means that the SGI hardware must ignore an IPL (not just have a null interrupt vectors, but actually not respond to it). When we started the project, SGI told us this is possible, but not how it was done. How do you do this? #3] We need the SGI to talk to both our system controller and our memory as VME slaves. The document we were provided seems to be unclear in a number of areas, however. (We have: Guide To Writing Device Drivers For Silicon Graphics IRIS-4D Computer Systems, Revision 1.1, Dec 13 1988). The description under Simple Memory Mapped Device Driver in Chapter 3 strictly warns about using "kernel virtual addresses", not physical bus addresses in the mmmap_addrs array, and refers to the appendix entitled: VME slave addressing. In the appendix however, there is no mention of what the difference actually is between these two addressing schemes. It does have a chart (Table 7 for A32 VMEbus-Physical Address Mapping), with two columns entitled "VME Address" and "Physical Address". The numbers are exactly the same, except for one unique reference for the IP5/7, which appears incompatible with all the other. It isn't clear what is meant, but am I correct in my presumption that the "kernel virtual address" is the "VME address", and that except for the IP5/7, the two are basically the same? If not, assuming that my A32 memory starts at "physical location" 0x800000, and goes up for 32 MB, what is the corresponding "kernel virtual address" that I should enter into the mmmap_addrs array? #4] Chart A.8 in the same section, "VMEbus Space Reserved for Customer Drivers", also seems to be incomplete. SGI told us that their system could support our addressing requirements (which on our Sun version, runs contiguously from 0x200000 to 0x2800000 in A32). Yet the VME bus addresses reserved for customers by the chart A.8, gives only a pitiful 32 MB (0x1A000000 - 0x1BFFFFFF), barely enough to support our extra memory. Thus, the VME addressing the chart gives is insuffient to run the system. Presumably, SGI was just overly aggressive in reserving space for itself on the VME bus, as I have a hard time believing that they could be actually using all that address space. So does anybody have a more detailed copy of the SGI mem map, which says what is really REALLY off-limits to trash, rather than the "A.8" chart they have now? If necessary, I might even consider installing our VME boards over addresses reserved for SGI optional add-on boards, and just saying that our system won't work with them installed. This project is under extreme time pressure, so I am hoping not to have to relocate any boards at all if possible (or the absolute fewest necessary). Steve Maurer steve@vicom.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02848; 19 Sep 89 20:02 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02794; 19 Sep 89 19:51 EDT Received: by VMB.BRL.MIL id aa02792; 19 Sep 89 19:45 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab01429; 19 Sep 89 16:19 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08298; 19 Sep 89 15:54 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA07767; Tue, 19 Sep 89 12:49:30 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 89 01:07:30 GMT From: "Thomas P. Mitchell" Organization: Silicon Graphics Computer Systems, Mountain View CA. Subject: Re: Power Series Arch Description Request Message-Id: <584@odin.SGI.COM> References: <89Sep6.182533edt.4956@jarvis.csri.toronto.edu>, <473@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <473@odin.SGI.COM> mitch@rock.sgi.com (Thomas P. Mitchell) writes: >>I am interested in getting my hands on a document that will describe >>the Power Series parallel architecture. > >Here are some pointers: I forgot to mention that Jim Barton and Chris Wagner are two key engineers in the design and implementation of the SGI multi-processing solution. Their papers give much insight into their thoughts and the reasons behind SGI's choices. >1) "UNIX Papers for UNIX Developers and Power Users" see: >Article 14 Multiprocessor UNIX by Tom Jermoluk (Tom is here >at SGI.) Edited by Mitchell Waite Howard W. Sams and >Company ISBN 0-672-22578-6 >2) Wagner, J.C., and Barton, J.M., "Threads in System V: >Letting UNIX parallel Process", a work-in-progress paper >presented in ;login:, USENIX Association, Vol. 12, No. 5, >September/October 1987. >4) Barton, J.M., Wagner, J.C. "Beyond Threads: Resource >Sharing in UNIX," USENIX Procedings, 1987. >Eindhoven, The Netherlands, 1965. Thomas P. Mitchell (ARPA:mitch@csd.sgi.com, UUCP: {decwrl,ucbvax}!sgi!mitch ) Rainbows -- The best (well second best) reason for windows.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24286; 19 Sep 89 2:25 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa23982; 19 Sep 89 1:12 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa23969; 19 Sep 89 1:05 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id ab04935; 19 Sep 89 0:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA21167; Mon, 18 Sep 89 21:53:50 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 89 04:45:29 GMT From: Tom Stockfisch Organization: Chemistry Dept, UC San Diego Subject: Re: needed: working psview / dvi2ps Message-Id: <564@chem.ucsd.EDU> References: <17158@pasteur.Berkeley.EDU>, <89Sep13.211218edt.2356@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Sep13.211218edt.2356@neat.cs.toronto.edu> lamy@AI.UTORONTO.CA (Jean-Francois Lamy) writes: >seth@miro.Berkeley.EDU (Seth Teller) writes: >>as a workaround, it would be great to have either A) a working >>previewer >Now, now. The previewer is likely doing just fine on real PostScript with >no LaserWriter extensions. Yes, the previewer does just fine with the postscript, but it does not have the features that are given in the man page. Specifically, it will not read input from stdin, regardless of whether you invoke it as "psview Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: IRIX 3.3? (was Re: dog) Message-Id: <41891@sgi.sgi.com> References: <8909181149.AA06699@lerc08.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909181149.AA06699@lerc08.lerc.nasa.gov>, fsfacca@LERC08.LERC.NASA.GOV (Tony Facca) writes: > Andrew Cherenson writes: > > > In the IRIX 3.3 release for the IRIS-4D, "dog" will send multicast packets > ^^^^^^^^ > > Is this for real? IRIX 3.3 already? What new things can we look forward to > in 3.3 and how far off is it? Look at it this way. It would be silly for us to think that with systems as complex as ours, we can finish a release (e.g. 3.2) and then just sit around for a while before starting another one -- there is too much to do. We're ALWAYS working on the "next release", and some are working on the one or two after that, or others that may be occuring in parallel for other reasons. We as an engineering department have to try and avoid talking about them in any specific terms, *especially* with respect to dates and schedules and stuff, because as we all know, those things are just management dreams until the reality of it all occurs. So unless something weird happens, there will be a 3.3 release, it is more or less the one after 3.2, and it will have some new, better software in it. If you want a *really good* release, though, you're going to have to wait for it. Also keep in mind that we know its a pain to update and convert, so we honestly try not to overwhelm our customer base with new releases too often. Maybe the slightly longer cycle means we generally put a larger collection of changes and features into each release. If there are serious issues that need to be addressed in the mean time, we can produce subset maintenance releases to take care of them, that have a much shorter development and release cycle, because they are deltas off of the base release. So just relax, and try not to get us in trouble! -- - donl mathis at Silicon Graphics Computer Systems, Mountain View, CA donl@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02393; 19 Sep 89 18:04 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02275; 19 Sep 89 17:53 EDT Received: by VMB.BRL.MIL id ac02197; 19 Sep 89 17:37 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01691; 19 Sep 89 13:31 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03404; 19 Sep 89 13:07 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA27804; Tue, 19 Sep 89 09:52:21 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 89 16:42:27 GMT From: Scott J Mark Organization: Department of Computer Science, Purdue University Subject: Re: DOG: diff for point-to-point communication Message-Id: <8020@medusa.cs.purdue.edu> References: <1989Sep19.151924.20792@lth.se> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Sep19.151924.20792@lth.se> dag@Control.LTH.Se (Dag Bruck) writes: > >Here is a context diff to convert at least one version of SGI `dog' >to use a point-to-point channel instead of broadcast messages. Just last night we got our version of dog to fake a multicast to each machine that is playing. If there's enough interest in it, I'll try to post a how-to. You'll have to have source code to do this. The reason I don't post a straight diff is that, from my understanding, there are more-recent versions of the source than the 2.3 version I got from SGI last month. That is, more-recent for those who aren't on PI machines. Currently, we keep a list of the connected machines, and then send a point-to-point to each machine. It doesn't seem to slow our game down at all, and I've, uh, "boosted" the packet size to allow multiple teams and multiple missiles. So if your network isn't saturated this may be a solution to the broadcast/interrupt problem. I haven't yet had time to add "defect" code, to stop sending packets to machines where people have stopped playing. So far throwing packets at the ethernet hasn't been a problem. Scott Mark PLEASE use E-Mail to express interest. -- sjm@cs.purdue.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02899; 19 Sep 89 20:12 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02608; 19 Sep 89 18:53 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02591; 19 Sep 89 18:44 EDT Received: from ugw.utcs.utoronto.ca by SMOKE.BRL.MIL id aa11846; 19 Sep 89 18:19 EDT Received: from uoguelph.netnorth (stdin) by ugw.utcs.utoronto.ca with BSMTP id 57392; Tue, 19 Sep 89 18:15:45 EDT Received: by UOGUELPH (Mailer R2.02A) id 5402; Tue, 19 Sep 89 18:15:00 EDT Date: Tue, 19 Sep 89 18:08:45 EDT From: "Len Zaifman UoGuelph (519)824-4120 xt 6566" Subject: Disappearing debug To: info-iris Message-Id: <89Sep19.181545edt.57392@ugw.utcs.utoronto.ca> Our operations group was running a backup recently, which crashed. The system was brought up again and much to my dismay(at a later date), there was no /debug file system(using df to show what was there). The processes seemed to be running normally, and using the command from /etc/init.d to mountfsys the /debug, it appeared. Can someone explain what was going on? In particular, how can processes run without swap space?? Are they all kept in memory?? What would have happened if we ran out of physical memory and had to swap ?? Thanks for any help in this matter. Regards Len Zaifman   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03340; 19 Sep 89 21:51 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03315; 19 Sep 89 21:40 EDT Received: from adm.brl.mil by VMB.BRL.MIL id aa03303; 19 Sep 89 21:28 EDT Received: from ucbvax.Berkeley.EDU by ADM.BRL.MIL id aa20331; 19 Sep 89 11:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA24289; Tue, 19 Sep 89 08:52:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 89 15:19:24 GMT From: LTH network news server Organization: Dept. of Automatic Control, Lund Inst. of Technology, Sweden Subject: DOG: diff for point-to-point communication Message-Id: <1989Sep19.151924.20792@lth.se> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here is a context diff to convert at least one version of SGI `dog' to use a point-to-point channel instead of broadcast messages. The file to update is called udpbrdcst.c. The job was done by Per Andersson at Computer Enginnering, Lund Institute of Technology, Lund, Sweden. We are all most grateful for his contribution to mankind. Dag Michael Bruck -- Department of Automatic Control Internet: dag@control.lth.se Lund Institute of Technology P. O. Box 118 Phone: +46 46-108779 S-221 00 Lund, SWEDEN Fax: +46 46-138118 ============================================================================== *** udpbrdcst.old Tue Sep 19 17:14:06 1989 --- udpbrdcst.c Tue Sep 19 17:14:08 1989 *************** *** 1,3 **** --- 1,9 ---- + /* + * Hacked May 19, 1989 by Per Andersson to use point to point communication + * between two specific hosts instead of broadcasts. This was done so that + * machines on different subnets may participate in a dogfight. + */ + #include #include #include *************** *** 22,27 **** --- 28,36 ---- struct sockaddr_in *addr; { struct servent *sp; + struct hostent *hp; /* Added (PA) */ + char *thehost; /* Added (PA) */ + int fd; int on = 1; int arg; *************** *** 36,49 **** perror("socket"); return (-1); } if (setsockopt(fd, SOL_SOCKET, SO_BROADCAST, &on, sizeof (on)) < 0) { ! perror("setsockopt"); ! close(fd); ! return (-1); } bzero(addr, sizeof(addr)); addr->sin_family = AF_INET; addr->sin_port = sp->s_port; if (bind(fd, addr, sizeof(*addr)) < 0) { perror("bind"); close(fd); --- 45,81 ---- perror("socket"); return (-1); } + /********************************** Removed (PA) *** if (setsockopt(fd, SOL_SOCKET, SO_BROADCAST, &on, sizeof (on)) < 0) { ! perror("setsockopt"); ! close(fd); ! return (-1); } bzero(addr, sizeof(addr)); addr->sin_family = AF_INET; addr->sin_port = sp->s_port; + ******************************************************/ + + /* New stuff here (PA) */ + + bzero(addr, sizeof(addr)); + thehost = getenv("ENEMY"); + if (!thehost) { + printf("Environment variable ENEMY not set\n"); + close(fd); + return(-1); + } + hp = gethostbyname(thehost); + if (!hp) { + printf("Can't find host to connect to %s\n", thehost); + close(fd); + return(-1); + } + addr->sin_family = AF_INET; + addr->sin_port = sp->s_port; + + /* End of new stuff (PA) */ + if (bind(fd, addr, sizeof(*addr)) < 0) { perror("bind"); close(fd); *************** *** 50,56 **** return (-1); } ! addr->sin_addr.s_addr = INADDR_BROADCAST; if (ioctl(fd, FIONBIO, &on) < 0) { /* Turn on non-blocking I/O */ perror("ioctl"); --- 82,89 ---- return (-1); } ! /* addr->sin_addr.s_addr = INADDR_BROADCAST; *** Removed (PA) */ ! bcopy(hp->h_addr, &addr->sin_addr, sizeof(addr->sin_addr)); /* New (PA) */ if (ioctl(fd, FIONBIO, &on) < 0) { /* Turn on non-blocking I/O */ perror("ioctl"); -- Department of Automatic Control Internet: dag@control.lth.se Lund Institute of Technology P. O. Box 118 Phone: +46 46-108779 S-221 00 Lund, SWEDEN Fax: +46 46-138118   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03937; 20 Sep 89 0:52 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03602; 19 Sep 89 23:29 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa03586; 19 Sep 89 23:17 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14808; 19 Sep 89 23:06 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA02105; Tue, 19 Sep 89 19:59:31 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 89 02:49:27 GMT From: Pablo Fernicola Organization: UF CIS Department Subject: /debug after backup Message-Id: <20902@uflorida.cis.ufl.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I just finished doing a total backup on our Personal Iris and when I do a df I don't see /debug listed there anymore. Does anybody know why, or even if it has any significance? Also, in which FM does SGI shows how to repartition the hard disk. The admistrator manual stops mid way through the explanation. Thanks Pablo pff@beach.cis.ufl.edu -- pff@beach.cis.ufl.edu Pablo Fernicola - Machine Intelligence Laboratory - UF "If we knew how it works, it wouldn't be called research."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04221; 20 Sep 89 1:50 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04182; 20 Sep 89 1:40 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04169; 20 Sep 89 1:31 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16448; 20 Sep 89 1:23 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09235; Tue, 19 Sep 89 22:16:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 89 20:50:47 GMT From: "Thomas P. Mitchell" Organization: Silicon Graphics Computer Systems, Mountain View CA. Subject: More parallel architecture papers. Message-Id: <595@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Here is one more paper by a key engineer here at SGI. It may sound as if they are all key engineers but they are: Kurt Akeley, "Superworkstation" in IEEE Computer Graphics and Applications. July 1989. Vol 9, number 4. Page 71. Starting at page 76 he talks about the hardware architecture of the Power Series. Thomas P. Mitchell (ARPA:mitch@csd.sgi.com, UUCP: {decwrl,ucbvax}!sgi!mitch ) Rainbows -- The best (well second best) reason for windows.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab04221; 20 Sep 89 1:50 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab04182; 20 Sep 89 1:40 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab04169; 20 Sep 89 1:31 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16450; 20 Sep 89 1:24 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09253; Tue, 19 Sep 89 22:16:48 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 89 21:47:48 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Scanner for PI Message-Id: <597@odin.SGI.COM> References: <8909181519.AA07258@lerc08.lerc.nasa.gov> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL IRIX release 3.2 includes a driver for a Sharp FX-450 color scanner which has a GPIB interface. It also drives a Ricoh IS11 grey-scale scanner which has a SCSI interface. "man scanner" for details. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac04221; 20 Sep 89 1:50 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac04182; 20 Sep 89 1:40 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ac04169; 20 Sep 89 1:31 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16452; 20 Sep 89 1:24 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09261; Tue, 19 Sep 89 22:16:59 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 89 22:08:16 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: needed: working psview / dvi2ps Message-Id: <599@odin.SGI.COM> References: <564@chem.ucsd.EDU>, <17158@pasteur.Berkeley.EDU>, <89Sep13.211218edt.2356@neat.cs.toronto.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <564@chem.ucsd.EDU>, tps@chem.ucsd.edu (Tom Stockfisch) writes: > Yes, the previewer does just fine with the postscript, but it does not have > the features that are given in the man page. Specifically, it will > not read input from stdin, regardless of whether you invoke it as > "psview work on stdin as well when invoked as "say -P": it doesn't. In IRIX 3.2, psview reads from stdin if no file is specified. I frequently use the command line psroff -me xyz.me | psview -F to preview documents. (-F gives me a page sized window so I don't have to stretch it out). say does work on standard input. You have to have a null string at the end as indicated in the man page. > > Is there any way to get a postscript file to be executed in a window? > "psh" works on stdin (thankfully), but it just writes on the background -- > you have to move all your other windows out of the way and damage is > not repaired. psview is your best bet. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04320; 20 Sep 89 2:01 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ad04182; 20 Sep 89 1:40 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ad04169; 20 Sep 89 1:31 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16454; 20 Sep 89 1:24 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09149; Tue, 19 Sep 89 22:14:47 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Sep 89 08:05:19 GMT From: Scott Henry Organization: Silicon Graphics Inc, Mountain View, CA Subject: Re: meta key for X11 Message-Id: References: <11836@polya.Stanford.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <11836@polya.Stanford.EDU> ramani@charity.Stanford.EDU (Ramani Pichumani) writes: r> Has any gotten the meta key to work with X11 on a 4D machine. r> Apparently, the keyboard translation for NeWS windows doesn't apply to r> an X11 window so we are without a meta key when we run xemacs or tcsh. r> If I run xemacs remotely on my Sun, the xemacs on the Iris recognizes r> the 200 bit correctly so I suspect the problem is in the keyboard r> translation. Whatever the cause, the meta is never recognized on the r> Iris keyboard. I just figured this out myself a couple of days ago: The patch to UI.ps that maps the Alt-keys to be Meta-keys under NeWS/4Sight BREAKS (under 3.2, anyway) the X-server's mapping of the Alt-keys to be Meta-keys. So, to have working Meta-keys under X is and XOR with working Meta-keys under 4Sight/NeWS at this time. Since you should have put the patched copy of /usr/NeWS/lib/NeWS/UI.ps into ~/NeWS/UI.ps (you don't really want to step on your original source, now, do you?), just rename ~/NeWS/UI.ps to something else when you would rather use the X-Meta-keys, and rename it back to ~/NeWS/UI.ps when you want to use the 4Sight/NeWS-Meta-keys. I know it's a pain (since you have to logout and login again to make the change happen), but until we can get WPD to fix this is the best workaround I know of at the moment. Since I'm in I/S, not engineering, I don't have any more control over this stuff than you do (maybe less, as I'm not a paying customer). r> Ramani Pichumani Tel: (415) 723-2902 or 723-2437 r> Department of Computer Science Fax: (415) 725-7411 r> Margaret Jacks Hall, Room 308 email: ramani@patience.stanford.edu r> Stanford, CA 94305 USA uunet!patience.stanford.edu!ramani Disclaimer: even though I work at SGI, I'm just another user. I just happen to get the stuff sooner... -- Scott Henry Information Services, Silicon Graphics, Inc   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04735; 20 Sep 89 4:11 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04571; 20 Sep 89 3:19 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa04569; 20 Sep 89 3:14 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa16906; 20 Sep 89 3:07 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA14320; Tue, 19 Sep 89 23:58:33 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 89 00:18:23 GMT From: Ted Wilcox Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Various SGI Questions (VME bus interface & other programming) Message-Id: <600@odin.SGI.COM> References: <1989Sep19.021146.2609@vicom.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I will just answer the parts of Steve's posting. As to the questions he asks that I am leaving out, I just don't know the answer. In article <1989Sep19.021146.2609@vicom.com> steve@vicom.COM (Steve Maurer) writes: > > I am working on a project in which we are integrating a number >of boards into an SGI 4D/70GT. The boards include a real-time >"system-controller", which talks to the SGI via a simple message-passing >scheme (through dual ported memory), and our own memory boards (VME >A32/D16). I'm also porting software. > > Now for my questions: > > #1] Our upper level software gives a "warning" in the link > stage about "jump relocation". The actual messages read: > > What is causing this? I Dunno. > > #2] We need to reserve an entire interrupt priority level for > communication between our various boards. This means that the > How do you do this? I Dunno. > > #3] We need the SGI to talk to both our system controller and our > memory as VME slaves. The document we were provided seems to > be unclear in a number of areas, however. (We have: Guide To > Writing Device Drivers For Silicon Graphics IRIS-4D Computer > Systems, Revision 1.1, Dec 13 1988). This manual is fairly good, but not as complete as a newer version due out "Real Soon Now." Actually, this supposedly means at the end of this month. The document number for the new manual is: 007-0911-010. You should be able to order it from you friendly neighborhood sales rep. > The description under Simple Memory Mapped Device Driver in > Chapter 3 strictly warns about using "kernel virtual addresses", > not physical bus addresses in the mmmap_addrs array, and refers > to the appendix entitled: VME slave addressing. In the appendix > however, there is no mention of what the difference actually is > between these two addressing schemes. It does have a chart (Table > 7 for A32 VMEbus-Physical Address Mapping), with two columns > entitled "VME Address" and "Physical Address". The numbers are > exactly the same, except for one unique reference for the IP5/7, > which appears incompatible with all the other. It isn't clear > what is meant, but am I correct in my presumption that the "kernel > virtual address" is the "VME address", and that except for the > IP5/7, the two are basically the same? If not, assuming that my > A32 memory starts at "physical location" 0x800000, and goes up > for 32 MB, what is the corresponding "kernel virtual address" that > I should enter into the mmmap_addrs array? Ok, there are a few issues here. 1) The table you are looking at is for a VME device doing DMA to/from the IRIS' main memory. The table you are really interested in is the one labled "A32 Kernel-VMEbus Mapping". (Table 5) This table says that "Kernel Addresses" 0xB0000000 - 0xBBFFFFFF map into VME addresses 0x10000000 to 0x1BFFFFFF. (This is all unprivileged data access --VME address modifier 0x09.) So, if you wanted to assert VME address 0x1000A000 you would use the Kernel address 0xB000A000. 2) The reason that the manual emphasizes the use of the "Kernel Virtual" address is that up through rev. 3.1C of our operating system, we expected "physical" addresses in the mmmap_addrs array. A physical address is NOT a VMEbus address, but is a "K1" address with the top 3 bits stripped off. (A K1 address is an address in which the top 3 bits are 101.) K1 addresses are not cached, and do not go through the TLB. > > #4] Chart A.8 in the same section, "VMEbus Space Reserved for Customer > Drivers", also seems to be incomplete. SGI told us that their > system could support our addressing requirements (which on our > Sun version, runs contiguously from 0x200000 to 0x2800000 in A32). > Yet the VME bus addresses reserved for customers by the chart A.8, > gives only a pitiful 32 MB (0x1A000000 - 0x1BFFFFFF), barely enough > to support our extra memory. Thus, the VME addressing the chart > gives is insuffient to run the system. > > Presumably, SGI was just overly aggressive in reserving space for > itself on the VME bus, as I have a hard time believing that they > could be actually using all that address space. So does anybody > have a more detailed copy of the SGI mem map, which says what is > really REALLY off-limits to trash, rather than the "A.8" chart > they have now? If necessary, I might even consider installing > our VME boards over addresses reserved for SGI optional add-on > boards, and just saying that our system won't work with them > installed. Actually, YOU have a more detailed copy of what space SGI uses for what boards. It's in the file /usr/sysgen/system on your system. (Assuming that you have 3.1D or later. In addition, this file has a better table of what spaces we reserve for customer use. Just in case the one you have is not as complete as mine, mine says that any A32 VME address in the following two ranges 0001 01xx xxxx xxxx xxxx xxxx xxxx xxxx np (All but R2300) -Should be OK, since 4D70s use IP4s. 0001 11xx xxxx xxxx xxxx xxxx xxxx xxxx np (where each digit represents a bit) is reserved for customer use. So this gives you two 64M spaces to use. Additionally, this file tells you specifically what SGI boards use what spaces. > This project is under extreme time pressure, so I am > hoping not to have to relocate any boards at all if possible (or > the absolute fewest necessary). Well, from the info I have, it looks bad for our heros. The addresses you want (0x00200000 - 0x02800000) are not in the VMEbus ranges which the driver guide and the system file state are accessable. If there's a way to get to those addresses, it's a deep dark secret. > > > Steve Maurer > steve@vicom.com I'm not one of the SGI kernel hackers, so I don't know every in and out of our memory mapping scheme. However, I have written a couple of drivers for 4D70 systems, and have been through the memory mapping stuff a jillion times, so I do have a pretty good idea of what can be done, and what problems often occur when writing drivers for our systems. Good Luck. P.S. If you have more questions, I'd be glad to help you out any way I can via e-mail. Ted. ted@sgi.com {sun|decwrl|pyramid|ucbvax}!sgi!ted   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07246; 20 Sep 89 9:13 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07039; 20 Sep 89 9:03 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa06934; 20 Sep 89 8:42 EDT Received: from prandtl.nas.nasa.gov by SMOKE.BRL.MIL id aa20375; 20 Sep 89 8:24 EDT Received: Wed, 20 Sep 89 05:23:51 pdt by prandtl.nas.nasa.gov (5.51/1.2) Received: Wed, 20 Sep 89 08:22:56 EDT by csduts1.lerc.nasa.gov (5.51/LeRC(1.0)) Received: Wed, 20 Sep 89 08:38:17 EDT by lerc08.lerc.nasa.gov (5.52/LeRC(1.0)) Date: Wed, 20 Sep 89 08:38:17 EDT From: Tony Facca Message-Id: <8909201238.AA09420@lerc08.lerc.nasa.gov> To: info-iris%brl.mil@prandtl.nas.nasa.gov Subject: Re: Power Series Arch Description Another good article was "Superworkstation" in the July CG&A. I don't have the magazine handy, and I don't remember who it was written by, but it was very well done. -- ----------------------------------------------------------------------------- Tony Facca | phone: 216-433-8318 NASA Lewis Research Center | Cleveland, Ohio 44135 | email: fsfacca@lerc08.lerc.nasa.gov -----------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15815; 20 Sep 89 16:06 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab15422; 20 Sep 89 15:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab15340; 20 Sep 89 15:39 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03796; 20 Sep 89 15:26 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA21667; Wed, 20 Sep 89 12:19:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 89 18:10:41 GMT From: Mark T Vandewettering Organization: Princeton Univ. Computing and Information Technology Subject: Wanted: Key to Speedy Particle Rendering... Message-Id: <10533@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have a new application that requires eeking out the highest performance possible from our 4D/220. My current application requires the capability to draw filtered spheres (possibly transparent) as fast as possible. Each point will be relatively small (< 10 pixels) but it is important that they be drawn with relatively sophisticated filtering in order to prevent aliasing in the final image. The current method that I have requires transforming the point into screen space by hand, and then using a table indexed by fractional pixel coordinates to filter the particle and zot it into the frame buffer. I use the blendfunction() call to composite the points, and draw them in back to front order. The main problem is the transform: translating the point by hand is tedious and slow. I have heard that the graphics pipeline of the 4/D is microcoded, and may be dynamically changed. Is this true? If so, is there documentation on coding applications which might take advantage of this? Is there anyway to code the transform and filter operations in microcode? Thanks for your help Mark VandeWettering (markv@acm.princeton.edu)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16006; 20 Sep 89 16:17 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15422; 20 Sep 89 15:55 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa15340; 20 Sep 89 15:39 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03735; 20 Sep 89 15:24 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA21683; Wed, 20 Sep 89 12:19:54 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 89 18:14:13 GMT From: Mark T Vandewettering Organization: Princeton Univ. Computing and Information Technology Subject: Wanted: Better Shadow for 4D Message-Id: <10534@phoenix.Princeton.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I was playing around with the ability of dog to record flights, creating an elaborate F-14 sequence with all sorts of diving and looping shots, follow the leader and landing sequences. Imagine my dismay to find that after I recorded 4 planes into a sequence, "shadow" would give me a segmentation violation. I have since found out that it dumps on 3 planes as well. Is this a well known or documented bug? Is there a fixed version to shadow that will enable me to replay this? Any ideas? Thanks again. Mark VandeWettering (markv@acm.princeton.edu)   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa16430; 20 Sep 89 16:38 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15049; 20 Sep 89 15:27 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa15007; 20 Sep 89 15:17 EDT Received: from nrtc.northrop.com by SMOKE.BRL.MIL id aa02331; 20 Sep 89 14:44 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa06818; 20 Sep 89 11:42 PDT Date: Wed, 20 Sep 89 11:39:51 PDT From: Fletcher Robinson To: info-iris@BRL.MIL Subject: kill kill ... Message-ID: <8909201444.aa02331@SMOKE.BRL.MIL> I have a communications program running in the background on a 4D70GT 3.1G. It performs DMA transferes through a device driver written by SGI for a VMIC VME-HSD board. The SGI is MASTER; a VME based 1750 is the slave. During a I/O operation, if I attempt to EXAMINE global ram through a 1750 debugger, my communications program HANGS. It won't dump core and it will not catch any interupt SIGNALS(such as a ^c). The only way I can recover is to REBOOT the SGI. I can not even use KILL <###>; I suppose this is because UNIX will not allow removal of a process doing I/O. Does anyone know how I might prevent this from occurring OR at least find a mechanism to "kill" the process when it hangs without rebooting?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17283; 20 Sep 89 19:33 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17235; 20 Sep 89 19:23 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa17226; 20 Sep 89 19:13 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa08255; 20 Sep 89 18:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA04283; Wed, 20 Sep 89 15:52:22 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 89 21:15:53 GMT From: Ruth Milner Organization: University of Toronto Physics/Astronomy/CITA Subject: Re: various boot-related questions. Message-Id: <1989Sep20.211553.17404@helios.physics.utoronto.ca> References: <89Sep12.214425edt.2245@neat.cs.toronto.edu>, <1989Sep13.183918.8050@helios.physics.utoronto.ca>, <41737@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <41737@sgi.sgi.com> jmb@patton.sgi.com (Jim Barton) writes: >We don't autoreboot after an OS crash because there may be >important data sitting on the screen that would be lost in this case - like >the error message which tells you what happened. I have been using this argument to justify hardcopy consoles since the day we set up our first UNIX system. Why do none (as far as I know, anyway) of the UNIX-box vendors suggest or sell a hardcopy console for just this reason? It's so much more useful than a 24-line screen. >You can't get the final crash messages from SYSLOG! The kernel just crashed, From /usr/adm/oSYSLOG: Sep 11 08:06:32 irides.physics PANIC: CPU 0: assertion failure! Granted, this is put there by savecore, but it is still available. There was not much more than that on the screen. Really serious crashes will mean the system can't reboot anyway, and there will still be information on the screen about why. >filling up swap won't crash the machine, the OS will instead start gunning >down processes. I've seen it with my own eyes. It can happen. I don't know whether it was because the kernel needed to run something and couldn't get the swap, or whether it "gunned down" a process it probably shouldn't have and got a panic, but it has happened to us. Further to this subject, I'd be interested to know how it decides which processes to destroy. The biggest ones? The newest ones? The lowest-priority ones ... ? -- Ruth Milner UUCP - {uunet,pyramid}!utai!helios.physics!sysruth Systems Manager BITNET - sysruth@utorphys U. of Toronto INTERNET - sysruth@helios.physics.toronto.edu Physics/Astronomy/CITA Computing Consortium   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17461; 20 Sep 89 20:55 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17395; 20 Sep 89 20:34 EDT Received: from sem.brl.mil by VMB.BRL.MIL id aa17385; 20 Sep 89 20:18 EDT Received: from umrvma.umr.edu by SEM.BRL.MIL id aa10161; 20 Sep 89 20:17 EDT Received: from UMRVMA.BITNET by UMRVMA.UMR.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 3567; Wed, 20 Sep 89 18:39:32 CDT Received: by UMRVMA (Mailer R2.03B) id 3566; Wed, 20 Sep 89 18:39:29 CDT Date: Wed, 20 Sep 89 18:36:43 CDT From: "Bob B. Funchess" Subject: GIF files To: info-iris@sem.brl.mil Message-ID: <8909202017.aa10161@SEM.BRL.MIL> I need a utility to translate files created by ICUT to GIF format for display on a PC. I could write one, BUT we have a time constraint. Does anyone have such a beast they're willing to share? Please reply DIRECTLY to me; probably not everyone is interested in this... < Bob S090726@UMRVMA.UMR.EDU Funchess >   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21628; 21 Sep 89 7:58 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20042; 21 Sep 89 7:06 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa19910; 21 Sep 89 6:50 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15090; 21 Sep 89 6:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA11270; Thu, 21 Sep 89 03:36:45 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 20 Sep 89 23:42:44 GMT From: Dave Olson Subject: Re: Scanner for PI Message-Id: <631@odin.SGI.COM> References: <8909181519.AA07258@lerc08.lerc.nasa.gov>, <597@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL msc@ramoth.esd.sgi.com (Mark Callow) writes: >IRIX release 3.2 includes a driver for a Sharp FX-450 color scanner >which has a GPIB interface. It also >drives a Ricoh IS11 grey-scale scanner which has a SCSI interface. "man >scanner" for details. Well, almost. Due to a lack of time/resources to make it work correctly, the IS11 support was removed at the last moment before 3.2 shipped. IS11 and a color Ricoh SCSI scanner will be supported in a future release. Unfortunately, the man page didn't get updated to reflect this... Dave Olson It's important to keep an open mind, but not so open that your brains fall out. -- Stephen A. Kallis, Jr.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02504; 22 Sep 89 4:44 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02437; 22 Sep 89 4:23 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02430; 22 Sep 89 4:08 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07462; 22 Sep 89 3:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA21305; Fri, 22 Sep 89 00:46:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 89 01:07:14 GMT From: Daniel McCoy Organization: Pixar -- Marin County, California Subject: mips symbol table stripping Message-Id: <6833@pixar.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Is there a tool around for manipulating the mips object file symbol table? (SGI 4D, DEC 3100, etc.) I have created an object file which contains a large package linked together with the relocation preserved. (ld -r) The idea is that customers will be able to link this package into their application as a major subsystem. (They also have the option of running it as a separate program.) That works fine, but all of the global symbols that link the guts of the package together are still present in the symbol table. I want to preserve the set of symbols that define the interface to the package as well as undefined references to system libraries. I would like to either remove or remap any other symbols, so as to avoid accidental symbol collisions with applications. Changing the source of the package is not an option. There is a set of functions for reading mips coff files, (sgi: ldfcn(4), dec ldfcn(5)), but they make no provisions for writing things back out. strip(1) is pretty much all or nothing. I'm in the process of rolling my own, but I would appreciate anything that might be of help. Thanks, Dan McCoy pixar!mccoy (415) 258-8195 Pixar, San Rafael, Ca   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27969; 21 Sep 89 11:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa27314; 21 Sep 89 11:18 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa27312; 21 Sep 89 11:06 EDT Received: from gatech.edu by SMOKE.BRL.MIL id aa20497; 21 Sep 89 10:44 EDT Received: from hydra.gatech.edu by gatech.edu (5.58/GATECH-8.6) id AA00100 for ; Thu, 21 Sep 89 10:25:05 EDT Received: by hydra.gatech.edu (4.12/2.5) id AA06605; Thu, 21 Sep 89 10:23:54 edt Date: Thu, 21 Sep 89 10:23:54 edt From: "SCHREIBER, O. A." Message-Id: <8909211423.AA06605@prism.gatech.edu> To: info-iris@BRL.MIL Subject: Hi, I would like to time a benchmarking FORTRAN program. Cc: ccsupos@prism.gatech.edu I would like to time a FORTRAN program. Would anybody tell me how to do it on an IRIS4D120GTX and IRIS4D50GT. I have tried call time(t) without luck. Thanks in advance. Olivier Schreiber (404)894 6147, Office of Computing Services Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccsupos ARPA: ccsupos@prism.gatech.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00546; 21 Sep 89 13:23 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28539; 21 Sep 89 12:10 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa28409; 21 Sep 89 11:56 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa22110; 21 Sep 89 11:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA25942; Thu, 21 Sep 89 08:32:25 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 89 14:54:01 GMT From: HOUFAC Organization: Control Data Corp., Houston, Texas Subject: What's and "Extent File System"? Message-Id: <14062@shamash.cdc.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Can anyone tell me what an "Extent File System" is (compared to a "normal" Unix System V file system). I see it mentioned in nearly every SGI document but I haven't been able to find and explaination of what the benefits are. Thanks! --Pete Poorman   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00519; 21 Sep 89 19:47 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00447; 21 Sep 89 19:26 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab00402; 21 Sep 89 19:16 EDT Received: from nrtc.northrop.com by SMOKE.BRL.MIL id aa02920; 21 Sep 89 18:25 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id aa12124; 21 Sep 89 15:23 PDT Date: Thu, 21 Sep 89 15:22:47 PDT From: Fletcher Robinson To: info-iris@BRL.MIL Subject: Why my display won't fit RS343 ? Message-ID: <8909211825.aa02920@SMOKE.BRL.MIL> I developed a display which uses full screen coordinates on a 4D70GT.(i.e 0,XMAXSCREEN 0,YMAXSCREEN) Program requirements called for SGI to provide a RS-343 video modification for my machines. I am utilizing a 25" color monitor from SRL to play my display program. This monitor's specifications for display format and sync timing requirements are delineated as follows : sync format composite sync verticle field rate 60.0 hz , 2:1 interlace horizontal line rate 30.69 khz horizontal sync 2.82 microsec horizontal blanking 6.75 microsec horizontal front porch 0.75 microsec displayed lines 959 total lines 1023 verticle sync 3h (97.75 microsec) verticle blanking 32h (1043 microsec) verticle front porch 3h (97.75 microsec) aspect ratio 4:3 video input level 0.7v peak to peak active pixels 1280 My problem is that my display program 'falls off' the screen on the bottom and to the left of the 30hz monitor while not on the 60hz monitor it was originally developed on. I do not think I should have to rework the display software to fit the 30hz monitor; and making adjustments such as verticle/horizontal sizing, etc. does not help to show more of the display. There should be adjustments to be made on the RS-343 video boards themselves, but I do not know where to look. I welcome comments from anyone having any experience with this type of problem. Thanx ...   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00593; 21 Sep 89 20:17 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00564; 21 Sep 89 20:06 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00562; 21 Sep 89 20:01 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03475; 21 Sep 89 19:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA23240; Thu, 21 Sep 89 16:26:27 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 89 22:47:44 GMT From: David A Higgen Organization: Silicon Graphics, Inc., Mountain View, CA Subject: efs Message-Id: <42041@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL > Can anyone tell me what an "Extent File System" is (compared to a "normal" > Unix System V file system). I see it mentioned in nearly every SGI document > but I haven't been able to find and explaination of what the benefits are. > > Thanks! --Pete Poorman 'man fs' will give you some basic information. There are also extensive explanatory comments in several of the include/sys/fs header files. Particularly efs_fs.h and efs_sb.h. The main benefit over a sysV filesystem is speed: space for files is allocated not on a one-by-one block basis but in chunks ("extents") of contiguous blocks which may be up to 248 blocks in size. So I/O happens in larger, faster, units. Dave Higgen   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00687; 21 Sep 89 20:48 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00519; 21 Sep 89 19:52 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00492; 21 Sep 89 19:40 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa03344; 21 Sep 89 19:22 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA23148; Thu, 21 Sep 89 16:24:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 89 21:28:11 GMT From: "Calvin H. Vu" Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Hi, I would like to time a benchmarking FORTRAN program. Message-Id: <42033@sgi.sgi.com> References: <8909211423.AA06605@prism.gatech.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909211423.AA06605@prism.gatech.edu>, ccsupos%prism@GATECH.EDU ("SCHREIBER, O. A.") writes: > I would like to time a FORTRAN program. > Would anybody tell me how to do it on an > IRIS4D120GTX and IRIS4D50GT. > I have tried call time(t) without luck. > Thanks in advance. > If you don't need better resolution than seconds, you can use time(). The way to use it is: integer t1, t2, time external time t1 = time() ......................... do something here t2 = time() - t1 ! t2 should be the elapsed time The reason for the EXTERNAL statement is that there are two versions of time(): an intrinsic VMS-compatible version, and a library version. Using time() without the EXTERNAL statement will default to the intrinsic version and give you an error message if you don't provide an argument. This is documented in the 3.1 release notes. If you want microsecond resolution you will have to use C and call gettimeofday(). You can look up in the manual to find out how to call a C subroutine from Fortran. > Olivier Schreiber (404)894 6147, Office of Computing Services > Georgia Institute of Technology, Atlanta Georgia, 30332 > uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ccsupos > ARPA: ccsupos@prism.gatech.edu Hope it helps, Calvin Vu Silicon Graphics Computer Systems calvin@sgi.sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01655; 22 Sep 89 0:45 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01464; 22 Sep 89 0:04 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01454; 21 Sep 89 23:54 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05449; 21 Sep 89 23:37 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA06939; Thu, 21 Sep 89 20:26:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 21 Sep 89 18:04:59 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: What's and "Extent File System"? Message-Id: <643@odin.SGI.COM> References: <14062@shamash.cdc.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The Extent File System is SGI's high performance filesystem running under system V. It is faster than the BSD filesystem, and tends to provide contiguous files (up to a certain point). There are man pages that describe it at a certain level...The main thing to know is that it is not the AT&T slow filesystem. kipp hickman silicon graphics inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02550; 22 Sep 89 5:11 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02534; 22 Sep 89 5:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02531; 22 Sep 89 4:53 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07732; 22 Sep 89 4:23 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22706; Fri, 22 Sep 89 01:14:34 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Sep 89 06:49:43 GMT From: Len Lattanzi Organization: Synthesis Software Solutions Inc, Sunnyvale, CA Subject: Re: Various SGI Questions (VME bus interface & other programming) Message-Id: <28025@mips.mips.COM> References: <1989Sep19.021146.2609@vicom.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1989Sep19.021146.2609@vicom.com> steve@vicom.COM (Steve Maurer) writes: : : I am working on a project in which we are integrating a number :of boards into an SGI 4D/70GT. The boards include a real-time :"system-controller", which talks to the SGI via a simple message-passing :scheme (through dual ported memory), and our own memory boards (VME :A32/D16). I'm also porting software. : : Now for my questions: : : #1] Our upper level software gives a "warning" in the link : stage about "jump relocation". The actual messages read: : : Warning: error: multiply defined : Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x489dbc to 0x10066270 (asm) : Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x489eac to 0x10066270 (asm) : Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x489fc8 to 0x10066270 (asm) : Warning: jump relocation out-of-range, bad object file produced, can't jump from 0x48a0c8 to 0x10066270 (asm) : : What is causing this? Typically this is caused by one importing module referencing a symbol as text and trying to jump to it. And the exporting module defining the symbol to be data. Text and Data are normally too far apart to jump between. You could use -Wl,-yerror,-yasm on the link command to indicate all modules referencing error and asm and make sure the uses are consistent. : : #2] We need to reserve an entire interrupt priority level for : communication between our various boards. This means that the : SGI hardware must ignore an IPL (not just have a null interrupt : vectors, but actually not respond to it). When we started the : project, SGI told us this is possible, but not how it was done. : How do you do this? : : #3] We need the SGI to talk to both our system controller and our : memory as VME slaves. The document we were provided seems to : be unclear in a number of areas, however. (We have: Guide To : Writing Device Drivers For Silicon Graphics IRIS-4D Computer : Systems, Revision 1.1, Dec 13 1988). : : The description under Simple Memory Mapped Device Driver in : Chapter 3 strictly warns about using "kernel virtual addresses", : not physical bus addresses in the mmmap_addrs array, and refers : to the appendix entitled: VME slave addressing. In the appendix : however, there is no mention of what the difference actually is : between these two addressing schemes. It does have a chart (Table : 7 for A32 VMEbus-Physical Address Mapping), with two columns : entitled "VME Address" and "Physical Address". The numbers are : exactly the same, except for one unique reference for the IP5/7, : which appears incompatible with all the other. It isn't clear : what is meant, but am I correct in my presumption that the "kernel : virtual address" is the "VME address", and that except for the : IP5/7, the two are basically the same? If not, assuming that my : A32 memory starts at "physical location" 0x800000, and goes up : for 32 MB, what is the corresponding "kernel virtual address" that : I should enter into the mmmap_addrs array? : : #4] Chart A.8 in the same section, "VMEbus Space Reserved for Customer : Drivers", also seems to be incomplete. SGI told us that their : system could support our addressing requirements (which on our : Sun version, runs contiguously from 0x200000 to 0x2800000 in A32). : Yet the VME bus addresses reserved for customers by the chart A.8, : gives only a pitiful 32 MB (0x1A000000 - 0x1BFFFFFF), barely enough : to support our extra memory. Thus, the VME addressing the chart : gives is insuffient to run the system. : : Presumably, SGI was just overly aggressive in reserving space for : itself on the VME bus, as I have a hard time believing that they : could be actually using all that address space. So does anybody : have a more detailed copy of the SGI mem map, which says what is : really REALLY off-limits to trash, rather than the "A.8" chart : they have now? If necessary, I might even consider installing : our VME boards over addresses reserved for SGI optional add-on : boards, and just saying that our system won't work with them : installed. This project is under extreme time pressure, so I am : hoping not to have to relocate any boards at all if possible (or : the absolute fewest necessary). : : : Steve Maurer : steve@vicom.com \ Len Lattanzi ({ames,pyramid,decwrl}!mips!synthesis!len) Synthesis Software Solutions, Inc. The RISC Software Company I would have put a disclaimer here but I already posted the article.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04850; 22 Sep 89 9:48 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa04652; 22 Sep 89 9:37 EDT Received: from tbd.brl.mil by VMB.BRL.MIL id aa04545; 22 Sep 89 9:24 EDT Date: Fri, 22 Sep 89 9:05:41 EDT From: Glenn Randers-Pehrson (WMB) To: ccsupos%prism@gatech.edu cc: info-iris@BRL.MIL Subject: Re: Hi, I would like to time a benchmarking FORTRAN program. Organization: U.S. Army Ballistic Research Laboratory, APG, MD Message-ID: <8909220905.aa22118@TBD.BRL.MIL> Here's what I use for timing Fortran programs. The Fortran program contains CALL CPUSEC(TIME) to get the elapsed user+system time, in seconds. I wouldn't mind having a version that properly reports total cpu time for multiprocessor jobs on the Power Series. ----cpusec.f----- subroutine cpusec (time) c c Glenn Randers-Pehrson, US Army Ballistic Research Laboratory c 11 Jan 89 c c Silicon Graphics IRIS version, works on 4D's and 3xxx's c Returns elapsed system+user cpu time in seconds, accurate to c 1/60th second. If more than 4295 seconds elapse between calls c to cpusec, n*4295 seconds will not be recorded. c 4295 (actually 4294.967296) is (2**32)/1000000. c With mp jobs on Power series 4D's, may only report elapsed c time for one of the cpu's. c real lasttime,thistime iris save lasttime, s4295 iris data lasttime /0.0/, s4295 /0.0/ iris call ccpusec(now) iris thistime=now/1 000 000. iris if(thistime.lt.lasttime) s4295 = s4295 + 4294.967296 iris lasttime=thistime iris time = s4295 + thistime iris c c Cray version C call ccpusec(time) cray c C Alliant version C dimension ait(2) alliant C xxx=etime(ait) alliant C time = ait(1)+ait(2) alliant c return end ----ccpusec.c----- #ifdef sgi /* * get cpu + system time for f77 program on IRIS * Glenn Randers-Pehrson, BRL, September 87 */ #ifdef mips fortran ccpusec_(thistime) #else fortran ccpusec(thistime) #endif /* returns unsigned integer, counting from 0 to (2**32 - 1) * in 16666 microsecond steps, representing elapsed system+user * time. If more than 4295 seconds elapse between calls to clockf, * n*4295 seconds will not be recorded. */ long *thistime; { long clock(); *thistime = clock(); } #endif #ifdef cray /* * get cpu + system time for CFT & CFT77 program * Gary Kuehl, BRL, 11 Jan 89 */ #include #include #ifdef CRAY2 #define CYCLE_TIME 4.1E-9 #else #define CYCLE_TIME 8.5E-9 #endif int CCPUSEC(sec) float *sec; { struct tms *t; times(t); *sec=(float)(t->tms_utime+t->tms_stime)*CYCLE_TIME; return; } #endif ------ Glenn Randers-Pehrson US Army Ballistic Laboratory Aberdeen Proving Ground, MD 21005-5066   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09393; 22 Sep 89 14:24 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08965; 22 Sep 89 14:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa08868; 22 Sep 89 14:00 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19146; 22 Sep 89 13:11 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA18793; Fri, 22 Sep 89 10:08:35 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Sep 89 16:43:01 GMT From: John Sahr Organization: Cornell Space Plasma Physics Group Subject: bug in ds3100 cc? Message-Id: <1333@calvin.EE.CORNELL.EDU> References: <6833@pixar.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL I have run across a bug in the MIPS cc C compiler (or in my understanding). Consider the following. #include int test(void *b) { printf("%d\n", *((int *) b)); return 0; } int main() { int four = 4; return test((void *) &four); } On a microvax (2000, ultrix) vcc and gcc (1.34) compile this and the result runs fine. vax cc objects, though (not surprising to me). On a DS3100, cc objects to the printf("%d\n", *((int *) b)), saying that b is undefined. Putting a prototype before test() does not help, and making typedef void *anonymous; to replace the void * doesn't help either. Any comments? The MIPS cc seems to handle the new style declarations pretty well, except for this. int test(b) void *b; { .... } Neither uvax lint nor MIPS lint approve of this declaration "b may be used before set..." among other things. Does this all mean that the "MIPS cc does not know about `void *' as `anonymous ptr'?" -john -- John Sahr, Dept. of Electrical Eng., Cornell University, Ithaca, NY 14853 johns@{alfven,calvin}.ee.cornell.edu, {rochester,cmcl2}!cornell!calvin!johns --When the dust settles, each B2 bomber will fund NSF for more than a year--   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09913; 22 Sep 89 14:45 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07918; 22 Sep 89 13:05 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa07684; 22 Sep 89 12:50 EDT Received: from uxc.cso.uiuc.edu by SMOKE.BRL.MIL id aa17857; 22 Sep 89 12:11 EDT Received: from kailand.UUCP by uxc.cso.uiuc.edu with UUCP (5.61+/IDA-1.2.8) id AA00436; Fri, 22 Sep 89 10:25:23 -0500 Received: from horizon.kai.com (horizon) by kailand.kai.com (4.12/kai2.5c/09-20-88) id AA21786; Fri, 22 Sep 89 09:50:03 cdt Received: by horizon.kai.com (4.12/kai2.5c/09-20-88) id AA24839; Fri, 22 Sep 89 09:50:01 cdt Date: Fri, 22 Sep 89 09:50:01 cdt Message-Id: <8909221450.AA24839@horizon.kai.com> Organization: KAI, 1906 Fox Drive, Champaign, IL 61820, (217-356-2288) From: David Nelson To: info-iris@BRL.MIL Subject: mips symbol table stripping >From: Daniel McCoy >There is a set of functions for reading mips coff files, >(sgi: ldfcn(4), dec ldfcn(5)), >but they make no provisions for writing things back out. Don't forget staux(3X), stcu(3X), stfd(3X), stfe(3X), stio(3X) and finally stprint(3X) in the IRIS-4D Programmer's Reference Manual Volumn II, Section 3. My favorite was the section on the symbol table in the Assembler manual. Just enough of a description to make you think you might be able to do the task, but not enough to make it even close to being easy. I spent a weekend trying to get a handle on the 'correct' way of reading and recreating a symbol table. We needed to get rid of declared but unreferenced global symbols (about 19Mb worth). Monday I found out that "ld -r" would do the trick and also using the "-x" option to strip local symbols helped even more. The result of the weekend was an ugly bit of code to print out the contents of the symbol table. (I wonder how long it took to implement odump... ) I'll include it here just in case it can be of use. David Nelson UUCP: ...!uunet!uiucuxc!kailand!dnelson Kuck and Associates, Inc. Internet: dnelson@kai.com 1906 Fox Drive Arpanet: dnelson%kai.com@uxc.cso.uiuc.edu Champaign, Ill. 61820 Optimizing software for supercomputers ---------- cut here ------------ cut here ------------ cut here --------- /* * First hack at a program to muck around the mips symbol table. * odump will do a better job, but here you get the source. * * Written by: * David Nelson UUCP: ...!uunet!uiucuxc!kailand!dnelson * Kuck and Associates, Inc. Internet: dnelson@kai.com * 1906 Fox Drive * Champaign, Illinois 61820 Optimizing software for supercomputers * */ #include #include #include #include int verbose = 1; LDFILE *infile = NULL; print_st(int st) { switch (st) { case stNil: printf("stNil "); break; case stGlobal: printf("stGlobal"); break; case stStatic: printf("stStatic"); break; case stParam: printf("stParam "); break; case stLocal: printf("stLocal "); break; case stLabel: printf("stLabel "); break; case stProc: printf("stProc "); break; case stBlock: printf("stBlock "); break; case stEnd: printf("stEnd "); break; case stMember: printf("stMember"); break; case stTypedef: printf("stTypedef"); break; case stFile: printf("stFile "); break; case stRegReloc: printf("stRegReloc"); break; case stForward: printf("stForward"); break; case stStaticProc: printf("stStaticProc"); break; case stConstant: printf("stConstant"); break; } } void print_sc(int sc) { switch (sc) { case scNil: printf("scNil"); break; case scText: printf("scText"); break; case scData: printf("scData"); break; case scBss: printf("scBss"); break; case scRegister: printf("scRegister"); break; case scAbs: printf("scAbs"); break; case scUndefined: printf("scUndefined"); break; case scCdbLocal: printf("scCdbLocal"); break; case scBits: printf("scBits"); break; case scCdbSystem: printf("scCdbSystem"); break; case scRegImage: printf("scRegImage"); break; case scInfo: printf("scInfo"); break; case scUserStruct: printf("scUserStruct"); break; case scSData: printf("scSData"); break; case scSBss: printf("scSBss"); break; case scRData: printf("scRData"); break; case scVar: printf("scVar"); break; case scCommon: printf("scCommon"); break; case scSCommon: printf("scSCommon"); break; case scVarRegister: printf("scVarRegister"); break; case scVariant: printf("scVariant"); break; case scSUndefined: printf("scSUndefined"); break; case scInit: printf("scInit"); break; case scMax: printf("scMax"); break; } } void print_sym(pSYMR sym) { printf("%20s\tvalue = %#8x\t", ((sym->iss) ? (char *)st_str_iss(sym->iss) : ""), sym->value); print_sc(sym->sc); printf("\t"); print_st(sym->st); printf("\tindex = %#6x\n", sym->index); } void print_ext(pEXTR extr) { pSYMR sym = &(extr->asym); printf("%20s\tvalue = %#8x\t", ((sym->iss) ? (char *)st_str_extiss(sym->iss) : ""), sym->value); print_sc(sym->sc); printf("\t"); print_st(sym->st); printf("\tindex = %#6x\n", sym->index); } void get_sym_info( ) { int num_extern; int num_local; int num_dense; pCHDRR cur_pCHDR; int syms_in_file; int i; if (FSEEK(infile,HEADER(infile).f_symptr,BEGINNING) != 0) { perror("seeking to the symbol table"); exit(1); } if (st_readst(fileno(IOPTR(infile)), 'r', 0, (pCHDRR)0, -1) != 0) { perror("reading the symbol table"); exit(1); } st_setfd(0); /* we will start with the first 'file' when printing local syms */ cur_pCHDR = (pCHDRR) st_currentpchdr(); num_local = cur_pCHDR->hdr.isymMax; num_extern = cur_pCHDR->cext; num_dense = cur_pCHDR->cdn; if (verbose) { printf(" pdn = %#x\n", cur_pCHDR->pdn); printf(" cdn = %d\n", num_dense); printf(" cdnMax = %d\n", cur_pCHDR->cdnMax); printf("num_local = %d\n", num_local); printf("num_extern = %d\n", num_extern); } /* print local symbols */ syms_in_file = PFD(infile)[st_currentifd()].csym; /* how many syms in this 'file' */ for (i=0; ipsym[i]) ); } /* external symbols (not arranged by 'file') */ for (i=0; ipext[i]) ); } } void get_info(char *filename) { printf("filename = \"%s\"\n", filename); if ((infile = ldopen(filename,infile)) == NULL) { perror("opening input file"); exit(1); } if (ISARCHIVE(TYPE(infile))) printf("it looks like an archive\n"); if (verbose) { printf("f_magic = %#06x\n", HEADER(infile).f_magic); /* magic number */ printf("f_nscns = %d\n", HEADER(infile).f_nscns); /* number of sections */ printf("f_timdat = %d\n", HEADER(infile).f_timdat); /* time & date stamp */ printf("f_symptr = %d\n", HEADER(infile).f_symptr); /* file pointer to symbolic header */ printf("f_nsyms = %d\n", HEADER(infile).f_nsyms); /* sizeof(symbolic hdr) */ printf("f_opthdr = %d\n", HEADER(infile).f_opthdr); /* sizeof(optional hdr) */ printf("f_flags = 0x%04x\n", HEADER(infile).f_flags); /* flags */ } if (HEADER(infile).f_flags != 0) { printf("I cannot work with this file"); if ((HEADER(infile).f_flags & F_RELFLG) == F_RELFLG) printf(", the relocation entries have been stripped"); if ((HEADER(infile).f_flags & F_EXEC) == F_EXEC) printf(", it is an executable"); if ((HEADER(infile).f_flags & F_LNNO) == F_LNNO) printf(", there are no line number entries"); if ((HEADER(infile).f_flags & F_LSYMS) == F_LSYMS) printf(", the local symbols have been stripped"); printf(".\n"); exit(1); } get_sym_info( ); } int main(int argc, char *argv[]) { char *filename = NULL; if (argc != 2) { fprintf( stderr, "Usage: %s file.o\n", argv[0]); exit(1); } filename = argv[argc-1]; /* now collect info on the named file. */ get_info(filename); return 0; } ---------- cut here ------------ cut here ------------ cut here --------- David Nelson UUCP: ...!uunet!uiucuxc!kailand!dnelson Kuck and Associates, Inc. Internet: dnelson@kai.com 1906 Fox Drive Arpanet: dnelson%kai.com@uxc.cso.uiuc.edu Champaign, Ill. 61820 Optimizing software for supercomputers   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00744; 23 Sep 89 17:25 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00684; 23 Sep 89 17:14 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id af00176; 23 Sep 89 16:57 EDT Received: from nrtc.northrop.com by SMOKE.BRL.MIL id aa00254; 22 Sep 89 18:04 EDT Received: from cirm.northrop.com by nrtc.nrtc.northrop.com id ab16636; 22 Sep 89 15:02 PDT Date: Fri, 22 Sep 89 15:04:30 PDT From: Fletcher Robinson To: info-iris@BRL.MIL Subject: 2000/3000 series reconfigurable kernel Message-ID: <8909221804.aa00254@SMOKE.BRL.MIL> Has anyone obtained and made use of the SPECIAL RECONFIGURABLE KERNEL OPTION for the SGI 2400T/3130 series machines. I just received a tape and no documentation. It is not put together like the sysgen stuff on the 4D's. I need information on including my own device drivers; and I need to 'tune' a parameter similar to the SHMSEG in the file /usr/ sysgen/master.d/shm on the 4D to allow more shared memory for IPC. I have not been able to locate it, and I do not know how to put the new kernel together.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00913; 23 Sep 89 17:57 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00090; 23 Sep 89 17:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12503; 22 Sep 89 17:46 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa25192; 22 Sep 89 17:08 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA03299; Fri, 22 Sep 89 14:04:23 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Sep 89 17:14:45 GMT From: "Michael L. Johnson" Organization: University of Va. Subject: Re: What's and "Extent File System"? Message-Id: <685@galen.acc.virginia.edu> References: <14062@shamash.cdc.com>, <643@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <643@odin.SGI.COM> kipp@warp.sgi.com (Kipp Hickman) writes: > >The Extent File System is SGI's high performance filesystem running under >system V. > kipp hickman > silicon graphics inc. Actually, didn't the extent file system come from SUN? (804)-924-8607 Michael L. Johnson mlj8e@virginia.EDU Pharmacology Dept. uunet!virginia!mlj8e Box 448; Univ. of Va. mlj8e@virginia.BITNET Charlottesville, Va. 22908   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02524; 24 Sep 89 0:58 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02493; 24 Sep 89 0:37 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02455; 24 Sep 89 0:23 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa11749; 23 Sep 89 23:53 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA04131; Sat, 23 Sep 89 20:42:49 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 22 Sep 89 20:31:35 GMT From: Chris Siebenmann Organization: Ziebmef home away from home Subject: Re: bug in ds3100 cc? Message-Id: <89Sep22.163043edt.30812@snow.white.toronto.edu> References: <6833@pixar.UUCP>, <1333@calvin.EE.CORNELL.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL "Losing" variables declared void * appears to be a problem generic to pcc-derived compilers; if you try it with Ultrix /bin/cc, you will get the same error message. Right now, the only solution I know of is to compile with "-Dvoid=int"; you could also try bringing gcc up on the DS3100. -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann ...!utgpu!{ncrcan,ontmoh!moore}!ziebmef!cks cks@white.toronto.edu or ...!utgpu!{,csri!}cks   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00744; 23 Sep 89 17:26 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00684; 23 Sep 89 17:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id bz00176; 23 Sep 89 17:01 EDT Received: from shadooby.cc.umich.edu by SMOKE.BRL.MIL id aa07321; 23 Sep 89 12:40 EDT Received: from ummts.cc.umich.edu by shadooby.cc.umich.edu (5.61/1.0) id AA20514; Sat, 23 Sep 89 12:38:54 -0400 Date: Sat, 23 Sep 89 12:39:16 EDT From: Tim_Buxton@um.cc.umich.edu To: info-IRIS@BRL.MIL Message-Id: <4931133@um.cc.umich.edu> Subject: Demos and Tutorials using Journal For anyone who has to do a "demo" of anything on an IRIS, there is now a really great tool for recording a whole demonstration once, including all keystrokes and mouse movements at the speed you want, then playing it back any number of times, at selectable faster or slower speeds. It is called the "journal" facility and just came out with 3.1g, I believe. "Journalrecord filename.jou" begins the recording, and "journalend" stops it. "Journalplay filename.jou" begins playback. Or, "journalchest" can show a panel with record, stop, and playback buttons to do all of the preceeding. If you aren't using this feature yet, I recommend trying it. We plan to use it to distribute some tutorials along with a new facetizer for BRL-CAD MGED files called FRED. Now to mention a few problems I have found: 1. There are problems going from one machine (4D/70) to the other (4D/50). The commands seem to get given before the machine is ready for them. There is a speed adjustment - will this help, or is there a difference in the keyboard signals between machines? I notice that keyboard entry is stored not by ASCII code, but by keyboard code, twice per keystroke. If a speed adjustment does not slow it down enough, would it make sense to multiply all the numbers in the first field, which seems to be an "event time" field, by some factor to slow it down more? 2. Stopping the journal playback can be done by pressing any key or moving the mouse yourself. You are then totally out of the playback, however; it will not start up again from that point. For new users watching a tutorial, the ability to stop, then resume would be invaluable. For giving presentations to groups (SGI salespersons are you listening?) it would be very helpful to be able to stop to answer questions or make a point, then continue. The SGI Hotline person I asked about this concluded after some thorough checking that "Pause" is not supported, although they might try to support it at a later time. Has anyone come up with a "Pause" feature on their own? I would like to hear about possible solutions to the above problems, as well as kinds of demos/tutorials/presentations that are being done by various users that could help all of us respond the the perennial question "Could you show me what it can do?" Thanks. Tim Buxton OptiMetrics, Inc. Tim_Buxton@um.cc.umich.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00826; 23 Sep 89 17:36 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00684; 23 Sep 89 17:15 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id bj00176; 23 Sep 89 17:01 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06009; 23 Sep 89 7:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA19287; Sat, 23 Sep 89 04:49:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 23 Sep 89 08:12:16 GMT From: "Roger B.A. Klorese" Organization: MIPS Computer Systems, Sunnyvale, CA Subject: Re: bug in ds3100 cc? Message-Id: <28082@abbott.mips.COM> References: <6833@pixar.UUCP>, <1333@calvin.EE.CORNELL.EDU> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <1333@calvin.EE.CORNELL.EDU> johns@calvin.spp.cornell.edu.UUCP (John Sahr) writes: >Does this all mean that the >"MIPS cc does not know about `void *' as `anonymous ptr'?" That's precisely what it means. Our release 2.10, coming early next year on our systems and I-don't-know-when from our licensees, will handle this. -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I want to live where it's always Saturday." -- Guadalcanal Diary   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02908; 24 Sep 89 2:47 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02733; 24 Sep 89 1:55 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa02729; 24 Sep 89 1:49 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa12892; 24 Sep 89 1:39 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA08846; Sat, 23 Sep 89 22:34:16 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 89 05:11:09 GMT From: Vernon Schryver Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: What's and "Extent File System"? Message-Id: <42100@sgi.sgi.com> References: <14062@shamash.cdc.com>, <643@odin.SGI.COM>, <685@galen.acc.virginia.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <685@galen.acc.virginia.edu>, mlj8e@dale.acc.Virginia.EDU (Michael L. Johnson) writes: > > Actually, didn't the extent file system come from SUN? > > (804)-924-8607 Michael L. Johnson > mlj8e@virginia.EDU Pharmacology Dept. > uunet!virginia!mlj8e Box 448; Univ. of Va. > mlj8e@virginia.BITNET Charlottesville, Va. 22908 Such statements as the preceding should not be made over a real return address. You are in danger of receiving a visit from Jack "The Knife", of the Usenet Department of Permanent Corrections for Base Calumnies. Sun had nothing to do with the Silicon Graphics EFS. The file system Sun pushed was NFS, Network File System. Sun runs the Berkeley FFS, or Fast File System, which as Kipp (who should know) says, is somewhat slower than EFS. Of course, anything is faster than the unspeakable, tiny-block-with- jumbled-free-list SV BFS. Vernon Schryver Silicon Graphics vjs@sgi.com   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05649; 24 Sep 89 23:46 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa05587; 24 Sep 89 23:05 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa05574; 24 Sep 89 22:59 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa19292; 24 Sep 89 22:38 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA03473; Sun, 24 Sep 89 19:30:17 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 24 Sep 89 21:08:23 GMT From: "Gavin A. Bell" Subject: Re: Demos and Tutorials using Journal Message-Id: <675@odin.SGI.COM> References: <4931133@um.cc.umich.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Tim_Buxton@UM.CC.UMICH.EDU writes: >For anyone who has to do a "demo" of anything on an IRIS, there is >now a really great tool for recording a whole demonstration once, >including all keystrokes and mouse movements at the speed you want, >then playing it back any number of times, at selectable faster >or slower speeds. It is called the "journal" >facility and just came out with 3.1g, I believe. ... goes on to mention two problems with journalling: playback on different machines, and not being able to pause the playback. The real problem with journalling is synchronization; playing back a journal recording of 'dog' twice in a row, you will end up in two different places, since small changes in when the program gets mouse events have large effects later. If this isn't critical (in demos where you won't crash if the 'bank left 20 degrees' is interpreted as 'bank left 18 degrees'), it can work fairly well. Having different scripts for different machines is one solution to the speed problem; recording on the slowest machine often works, too. However, a lot of different things can affect machine speed-- how loaded it is, if disk files have to be accessed over NFS, etc. The pause problem is much easier. You have the journalling code on your system; look in the files /usr/NeWS/lib/NeWS/journal.ps and /usr/NeWS/lib/NeWS/journalUI.ps. I've often considered adding a few options to the journalling stuff, including a pause feature (I've just never had the time to do it). There is one bug you should know about: If a GL program does a setvaluator() call, it will cause the journal file to stop. The journal playback gets confused, and thinks that the user has done something to stop the journalling. --gavin   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13073; 25 Sep 89 12:48 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12759; 25 Sep 89 12:37 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12685; 25 Sep 89 12:18 EDT Received: from cunyvm.cuny.edu by SMOKE.BRL.MIL id aa29106; 25 Sep 89 11:57 EDT Received: from DDATHD21.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 3510; Mon, 25 Sep 89 11:56:26 EDT Received: from BR2.THD.DA.D.EUROPE by DDATHD21.BITNET via GNET with RJE ; 25 Sep 89 16:55:21 Date: Mon, 25 Sep 89 16:53:09 +0200 (Central European Summer Time) From: Knobi der Rechnerschrat Subject: The big Memory-Eater strikes back To: info-iris@BRL.MIL X-VMS-To: X%"info-iris@brl.mil" Message-ID: <8909251157.aa29106@SMOKE.BRL.MIL> Hallo, we have discorvered a memory-eating bug when using 'malloc(3x)' instead of 'malloc(3m)'. The bug occurs under 3.1D when using '-lmalloc' in the LIBR symbol of the following sample code. the questions is: a) is it a bug? -if 'yes', is it known? b) do we use '-lmalloc' at an improper place? c) what else? It follows the sample code. 'make mem' gives the correct behaviour, 'make meml' gives you the memory eater. The code just runs a loop, where some amount of memory is allocated and deallocated. Regards Martin Knoblauch TH-Darmstadt Physical Chemistry 1 Petersenstrasse 20 D-6100 Darmstadt, FRG BITNET: -------------------------------makefile--------------------------------- # # make - directives # CFLAGS = -g -I/usr/include/bsd # # Library Selection # LIBRL = -lgl_s -lmalloc -lbsd -lfastm -lm -lc_s LIBR = -lgl_s -lbsd -lfastm -lm -lc_s # # # mem: mem.c cc mem.c $(CFLAGS) -o mem $(LIBR) # meml: mem.c cc mem.c $(CFLAGS) -o meml $(LIBRL) # -------------------------------mem.c------------------------------------ /* ** MOLCAD Version 4.1 ** ** COPYRIGHT AND ALL OTHER RIGHTS RESERVED ** ** Contact: ** ** Prof. Dr. J. Brickmann ** c/o TH - Darmstadt ** Dept. for Physical Chemistry ** Petersenstr. 20 ** D-6100 Darmstadt, FRG ** ** BITNET : ** ** ** file : mem.c ** author : Martin Knoblauch + Michael Teschner ** date : ** purpose : memory allocation test ** comment : ** ** ** ** */ #include #include int acount,dcount; struct Dot { struct Dot *next; float arr[4]; }; extern struct Dot *mk_Newdot(); main() { struct Dot *first,*dot; int i,j,count; first = NULL; for(j=0;j<1000;j++){ mk_Deldots(first); dot = first = NULL; count = 0; for(i=0;i<5000;i++){ dot = mk_Newdot(dot); count++; if( first == NULL ) first = dot; } printf(" loop %d count %d \n",j,count); } } /* end main */ struct Dot *mk_Newdot(prev) struct Dot *prev; { struct Dot *help; if ((help = (struct Dot *)malloc(sizeof(struct Dot))) == NULL) return(NULL); if (prev != NULL) prev->next = help; help->next = NULL; return(help); } mk_Deldots(start) struct Dot *start; { struct Dot *help; while (start != NULL) { help = start->next; free(start); start = help; } }   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13304; 25 Sep 89 12:58 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab12661; 25 Sep 89 12:22 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab12646; 25 Sep 89 12:16 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28565; 25 Sep 89 11:32 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09616; Mon, 25 Sep 89 08:19:46 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 89 14:47:22 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Hi, I would like to time a benchmarking FORTRAN program. Message-Id: <42134@sgi.sgi.com> References: <8909220905.aa22118@TBD.BRL.MIL> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909220905.aa22118@TBD.BRL.MIL>, glennrp@BRL.MIL (Glenn Randers-Pehrson, WMB) writes: > > > Here's what I use for timing Fortran programs. The Fortran program > contains > CALL CPUSEC(TIME) > to get the elapsed user+system time, in seconds. > > I wouldn't mind having a version that properly reports total cpu time > for multiprocessor jobs on the Power Series. ... > Glenn Randers-Pehrson > US Army Ballistic Laboratory > Aberdeen Proving Ground, MD 21005-5066 > If you are willing to do a little work, you can get the sum of all CPU time used by calling the 'times()' system call yourself from the the initial process of the share group (i.e., the parent). Then sum in the child user+sys times to the current process times. You can see how this might work by timing a parallel command: $ time command [args] ... You'll notice that the real time is usually less than the user+sys time used, if the threads were computing for a significant amount of time. I suspect that the CPUSEC call in Fortran just calls 'times()' and returns the current process user+sys. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa14042; 25 Sep 89 13:40 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12661; 25 Sep 89 12:21 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12646; 25 Sep 89 12:16 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28519; 25 Sep 89 11:31 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09625; Mon, 25 Sep 89 08:19:56 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 89 14:49:40 GMT From: Jim Barton Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: What's and "Extent File System"? Message-Id: <42135@sgi.sgi.com> References: <14062@shamash.cdc.com>, <643@odin.SGI.COM>, <685@galen.acc.virginia.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <685@galen.acc.virginia.edu>, mlj8e@dale.acc.Virginia.EDU (Michael L. Johnson) writes: > In article <643@odin.SGI.COM> kipp@warp.sgi.com (Kipp Hickman) writes: > > > >The Extent File System is SGI's high performance filesystem running under > >system V. > > kipp hickman > > silicon graphics inc. > Actually, didn't the extent file system come from SUN? > > > > (804)-924-8607 Michael L. Johnson > mlj8e@virginia.EDU Pharmacology Dept. > uunet!virginia!mlj8e Box 448; Univ. of Va. > mlj8e@virginia.BITNET Charlottesville, Va. 22908 Aw, c'mon, don't insult us. Sun hasn't invented a production filesystem that I know of at anytime - they use the fairly standard BSD FFS code. Mr. Hickman actually invented and wrote the code for the Extent File System himself - I'm sure he would resent the slur. -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa15091; 25 Sep 89 14:44 EDT Received: from VMB.BRL.MIL by VMB.brl.MIL id aa14410; 25 Sep 89 14:13 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa14392; 25 Sep 89 14:00 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02863; 25 Sep 89 13:38 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA17058; Mon, 25 Sep 89 10:30:14 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 89 17:22:45 GMT From: Scott J Mark Organization: Department of Computer Science, Purdue University Subject: lampon/off Message-Id: <8081@medusa.cs.purdue.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Can anyone explain why on earth the calls to lampon() and lampoff() take such a significant portion of a second on a Personal IRIS? Thanks in advance. Scott Mark -- sjm@cs.purdue.edu   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa18029; 25 Sep 89 18:42 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa17995; 25 Sep 89 18:32 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa17969; 25 Sep 89 18:21 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa09900; 25 Sep 89 17:41 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA00950; Mon, 25 Sep 89 14:14:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 89 20:36:27 GMT From: Dave Ciemiewicz Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: Demos and Tutorials using Journal Message-Id: <42154@sgi.sgi.com> References: <4931133@um.cc.umich.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <4931133@um.cc.umich.edu>, Tim_Buxton@UM.CC.UMICH.EDU writes: > For anyone who has to do a "demo" of anything on an IRIS, there is > now a really great tool for recording a whole demonstration once, > including all keystrokes and mouse movements at the speed you want, > then playing it back any number of times, at selectable faster > or slower speeds. It is called the "journal" > facility and just came out with 3.1g, I believe. "Journalrecord > filename.jou" begins the recording, and "journalend" stops it. > "Journalplay filename.jou" begins playback. Or, "journalchest" can > show a panel with record, stop, and playback buttons to do all > of the preceeding. If you aren't using this feature yet, I > recommend trying it. We plan to use it to distribute some > tutorials along with a new facetizer for BRL-CAD MGED files > called FRED. > > Now to mention a few problems I have found: > > 1. There are problems going from one machine (4D/70) to the > other (4D/50). The commands seem to get given before the machine > is ready for them. There is a speed adjustment - will this help, > or is there a difference in the keyboard signals between machines? > I notice that keyboard entry is stored not by ASCII code, but > by keyboard code, twice per keystroke. If a speed adjustment > does not slow it down enough, would it make sense to multiply > all the numbers in the first field, which seems to be an > "event time" field, by some factor to slow it down more? The journalling mechanism is based on the NeWS journalling capabilities with some convenient scripts -- journalrecord, journalend, and journalplay -- used as wrappers for driving a remote machine or terminal, or from within a shell script. The journalchest is also a wrapper for simple driving of the recording, stopping, and playback mechanisms. Mouse and keyboard events are recorded in a journal file simplay as an event and a timestamp for when the event occured. Upon playback, events are played back with the same timing as they were recorded. Since there is variance in the amount of time it takes for the system to react to events such as starting applications, it is very possible for the playback mechanism to get ahead of the system. We humans can adjust for these variations but the playback mechanism only has a gross playback speed adjustment. Using the playback speed adjustment (journalplay -p ) should help to some degree. The keyboard does not come into play as all of the mouse and keyboard events are simulated in 4Sight and never actually use the keyboard or mouse. In my experience with the journalling, I recommend you do make all of your mouse actions while recording slow and deliberate. It is very easy to go zipping through a menu while recording and end up with the wrong menu selection during playback. Also, when starting applications with the mouse wait 5-10 seconds after you see the window outline before manipulating the window outline to place the window. This will allow for variance in the amount of time required to launch an application on a 4D/70 versus a slower 4D/50. Because of system speed variations, don't try to use journalling for recording real-time interactive applications like "flight". However, it is quite satisfactory to use journalling for recording non-real-time demos. I used it to record a fairly sophisticated "live" demo we did for the Personal Iris unveiling a year ago. > > 2. Stopping the journal playback can be done by pressing any > key or moving the mouse yourself. You are then totally out > of the playback, however; it will not start up again from that > point. For new users watching a tutorial, the ability to stop, > then resume would be invaluable. For giving presentations to > groups (SGI salespersons are you listening?) it would be > very helpful to be able to stop to answer questions or make > a point, then continue. The SGI Hotline person I asked about > this concluded after some thorough checking that "Pause" is > not supported, although they might try to support it at a > later time. Has anyone come up with a "Pause" feature on > their own? > I cannot comment on implementing Pause, you could try modifying: /usr/NeWS/lib/NeWS/journal.ps if you are up to a challenge. > > I would like to hear about possible solutions to the above > problems, as well as kinds of demos/tutorials/presentations that > are being done by various users that could help all of us respond > the the perennial question "Could you show me what it can do?" > Thanks. > > > Tim Buxton > OptiMetrics, Inc. > Tim_Buxton@um.cc.umich.edu > --- Dave -- ------------------------------------------------------------------------------- Cosmo Ciemo, Silicon Valley Dude I was traipsing through the fields of my mind when I stepped in something that smelled rather ripe. -------------------------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01328; 26 Sep 89 2:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00931; 26 Sep 89 0:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00901; 26 Sep 89 0:40 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa14980; 25 Sep 89 23:53 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22082; Mon, 25 Sep 89 20:42:42 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 89 16:34:15 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: What's and "Extent File System"? Message-Id: <678@odin.SGI.COM> References: <685@galen.acc.virginia.edu>, <14062@shamash.cdc.com>, <643@odin.SGI.COM> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL The extent filesystem was written by myself and Don Fong, an ex sgi employee. It has nothing whatsoever to do with SUN, except that it is faster than the filesystem they use. kipp hickman silicon graphics inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab01328; 26 Sep 89 2:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab00931; 26 Sep 89 0:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id ab00901; 26 Sep 89 0:40 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa15000; 25 Sep 89 23:55 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA22188; Mon, 25 Sep 89 20:44:36 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 25 Sep 89 22:16:20 GMT From: Mark Callow Organization: Silicon Graphics Inc., Entry Systems Division Subject: Re: Demos and Tutorials using Journal Message-Id: <688@odin.SGI.COM> References: <4931133@um.cc.umich.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <4931133@um.cc.umich.edu>, Tim_Buxton@UM.CC.UMICH.EDU writes: > > For anyone who has to do a "demo" of anything on an IRIS, there is > now a really great tool for recording a whole demonstration once, > including all keystrokes and mouse movements at the speed you want, I'm glad you like it. I put in a lot of unscheduled time to make the journalling package usable with GL clients as well as NeWS clients. Please note the caveats on the man page (journalchest(1w)). Due to the nature of the package these are largely unavoidable. The package is very useful as it stands which is why I released it. > > Now to mention a few problems I have found: > > 1. There are problems going from one machine (4D/70) to the > other (4D/50). The commands seem to get given before the machine > is ready for them. There is a speed adjustment - will this help, > or is there a difference in the keyboard signals between machines? > I notice that keyboard entry is stored not by ASCII code, but > by keyboard code, twice per keystroke. If a speed adjustment > does not slow it down enough, would it make sense to multiply > all the numbers in the first field, which seems to be an > "event time" field, by some factor to slow it down more? There is no difference in keyboard signals. Journalling records the keyboard scan codes. Translation happens during playback. What kind of keyboard problems are you seeing? The speed adjustment will help with things like windows not being up before button clicks are delivered. The first field is a timestamp so that the events can be played back at exactly the same relative times as they were recorded. When you adjust the speed control guess what it does - yes it multiples the time stamps by a factor. > > 2. Stopping the journal playback can be done by pressing any > key or moving the mouse yourself. You are then totally out > of the playback, however; it will not start up again from that > point. For new users watching a tutorial, the ability to stop, > then resume would be invaluable. For giving presentations to > groups (SGI salespersons are you listening?) it would be > very helpful to be able to stop to answer questions or make I would love to add a pause feature. Unfortunately I haven't been able to think of a way of doing so that wouldn't rob useful keys or key combinations from clients. If anyone has any ideas, please let me know. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl,sun}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12430; 26 Sep 89 16:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11849; 26 Sep 89 15:25 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa11813; 26 Sep 89 15:10 EDT Received: from CS.NPS.NAVY.MIL by SMOKE.BRL.MIL id aa29189; 26 Sep 89 14:30 EDT Received: by cs.nps.navy.mil (5.51/1.26) id AA07872; Tue, 26 Sep 89 11:25:56 PDT Date: Tue, 26 Sep 89 11:25:56 PDT From: "m. j. cloutier x2772" Message-Id: <8909261825.AA07872@cs.nps.navy.mil> To: info-iris@BRL.MIL Subject: I/O CARDS We are attempting to connect an 80386 laptop to an IRIS workstation (which will emulate control signal inputs) in an effort to simulate inputs to an adaptive control sytem. Does anyone know of I/O cards for the IRIS that will meet (or exceed) the following requirements: 16 12-bit D/A channels 10 A/D channels (selectable bipolar(+/- 5v)/unipolar(0-5v) 1 16-bit digital channel 50kHz data throughput Thanks in advance for any suggestions!   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13486; 26 Sep 89 18:08 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa13372; 26 Sep 89 17:58 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa13345; 26 Sep 89 17:48 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa02849; 26 Sep 89 17:09 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA12999; Tue, 26 Sep 89 13:58:28 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 26 Sep 89 19:31:03 GMT From: "George Baciu [CGL]" Organization: U of Waterloo, Ontario Subject: limiting user process resources on 4D/120 running 3.1G Message-Id: <11636@watcgl.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Other than "ulimit", is there a way to limit a user process cpu usage, memory usage, etc. on a 4D/120GTX running 3.1G? --- George Baciu --- ----------------------------------------------------------------- | GBaciu@watcgl.Waterloo.edu GBaciu@watcgl.UWaterloo.CA | | * Computer Graphics Lab * | | University of Waterloo - Waterloo, Ontario, Canada - N2L 3B5 | -----------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00961; 27 Sep 89 3:21 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00646; 27 Sep 89 2:08 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa00627; 27 Sep 89 1:57 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07655; 27 Sep 89 1:23 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA07949; Tue, 26 Sep 89 22:18:19 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Sep 89 04:06:50 GMT From: "Roger B.A. Klorese" Organization: MIPS Computer Systems, Sunnyvale, CA Subject: Re: Disappearing debug Message-Id: <28319@abbott.mips.COM> References: <89Sep19.181545edt.57392@ugw.utcs.utoronto.ca> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <89Sep19.181545edt.57392@ugw.utcs.utoronto.ca> LEONARDZ@UOGUELPH.BITNET ("Len Zaifman UoGuelph 824-4120 xt 6566", 519) writes: > Our operations group was running a backup recently, which crashed. >The system was brought up again and much to my dismay(at a later date), there >was no /debug file system(using df to show what was there). The processes >seemed to be running normally, and using the command from /etc/init.d >to mountfsys the /debug, it appeared. Can someone explain what was going on? >In particular, how can processes run without swap space?? Are they all kept >in memory?? What would have happened if we ran out of physical memory and >had to swap ?? /debug (or, in RISC/os, /proc) is *NOT* your swap space. It's a special type of virtual filesystem which presents a view of your running processes accessible through the file namespace. If it's not mounted, you just can't use programs (like some debuggers and other tools) that access processes by opening them like files. This has *nothing* to do with your swap space. -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 928 E. Arques Ave. Sunnyvale, CA 94086 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I want to live where it's always Saturday." -- Guadalcanal Diary   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03419; 27 Sep 89 8:40 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa01739; 27 Sep 89 7:38 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa01726; 27 Sep 89 7:29 EDT Received: from inria.inria.fr by SMOKE.BRL.MIL id aa09602; 27 Sep 89 6:30 EDT Received: from kwai.inria.fr by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA12021; Wed, 27 Sep 89 11:28:40 +0100 (MET) Received: by inria.fr with X.400; 27 Sep 89 10:27:15+0100 Received: by ch; 27 Sep 89 11:28:16+0200 Date: 27 Sep 89 11:28:16+0200 From: Reinhard Doelz To: info-iris@BRL.MIL MMDF-Warning: Parse error in original version of preceding line at BRL.MIL Subject: RE:limiting resources Message-Id: <50*doelz@urz.unibas.ch> There is nothing on IRIX which could be called reasonable management... To be serious: 1) disk space of users might be limited by setting more than the default partitions, e.g., create new partitions and put each group of users on one of them. Once a device is full, there is no way to write on the device any longer. I did that , and esp. the /tmp device proved to be useful. Once /tmp is on the normal file system (/), it is easy to hang the entire system by calling vi on a 40 MByte ascii fie etc. 2) Memory allocation: There is the hint in USERS GUIDE pg. 10-10 that the MAXUMEM poarameter is tunable thus giving the user only a predefined memory page number which might be smaller than the available one. Sounds great but never worked in my hands (tried it at 3.1C last time). Maybe I'll try it on 3.1G now. (also running a 120GTX). 3) CPU time consumption - no way to get a limitation on the smart way. I use a process prioritizer which sets processes running longer than a particular time on a non-ageing priority using the npri command in a crontabs file. I'd *really* like to get information whether the tools needed are available in 3.2 such as * disk quota * CPU quota * accounting which does work (and not just reports garbage). (SGI do you hear me?) - Reinhard   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10823; 27 Sep 89 17:07 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10730; 27 Sep 89 16:56 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10697; 27 Sep 89 16:43 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07656; 27 Sep 89 15:58 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA09513; Wed, 27 Sep 89 09:48:15 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Sep 89 13:42:05 GMT From: "George Baciu [CGL]" Organization: U of Waterloo, Ontario Subject: iris C and C++ problem Message-Id: <11651@watcgl.waterloo.edu> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL A check for the context of keywords in the IRIS C compiler does not allow sometimes C++ code to be compiled. The environment is 4D/120GTX running 3.1G. Is there a fix to this? Or are we using a faulty C++ frontend? Here's a sample C program that generates the syntax error: Script started on Thu Sep 21 17:26:03 1989 % % cat foo.c typedef (*bar)(int); foo (bar,int); main() {} % cc foo.c ccom: Error: foo.c, line 2: syntax error foo (bar,int); -----------^ % exit % script done on Thu Sep 21 17:26:15 1989 --- George Baciu --- ----------------------------------------------------------------- | GBaciu@watcgl.Waterloo.edu GBaciu@watcgl.UWaterloo.CA | | * Computer Graphics Lab * | | University of Waterloo - Waterloo, Ontario, Canada - N2L 3B5 | -----------------------------------------------------------------   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10905; 27 Sep 89 17:28 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab10730; 27 Sep 89 16:57 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10712; 27 Sep 89 16:46 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa07829; 27 Sep 89 16:08 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA15934; Wed, 27 Sep 89 12:04:24 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Sep 89 18:13:52 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Big Iron I/O Message-Id: <42244@sgi.sgi.com> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL This was a posting from comp.arch that seems like it is relevant to recent postings in this group as well. Sorry if you already saw this. In article <32512@ames.arc.nasa.gov>, lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: > > However, I think you are painting with too broad a brush to include Sun, MIPSCo, > etc. in your list. Remember that the controllers you have been using for > your comparisons to get ~1 MB/sec. through a filesystem are relatively new. > Most of these controllers have been thoroughly *debugged* and in volume > production (two prerequisites for full service companies to buy) for 6 mos. > to one year. Sun now sells faster controllers that will do almost 1 MB/sec. > on SMD disks through a Unix filesystem. I haven't had a chance to measure > any IPI or synchronous SCSI disks. But it is unfair to use today's controllers > to criticize systems shipped 1-2 years ago. I can't yet publish our IPI numbers due to signed non-disclosure, but suffice it to say that it would not make sense to go to a completely different controller and drive technology for anything less than VERY LARGE performance wins or phenomenal cost savings.... On the other hand, using a controller from the same company, SGI gets over 2 MB/sec. on SMD *through* the filesystem. See comp.sys.sgi for discussions on the Extent File System designed by our own Kipp Hickman and Donovan Fong (who is no longer with SGI). However it is also true that a decent job on drivers, caching, selection of the right technology, both in terms of con- trollers and disk drives, and actually marrying these all together will yield a more coherent disk subsystem that is capable of providing nearly theoretical maximum throughput. This is something many companies seem to miss the boat in doing. Clearly I am somewhat biased, but the numbers don't lie (see below for our mid-range ESDI numbers, which are handy in my current directory). > > The other thing that would probably help would be if more people said to > salesrep from company X: "I am buying the system from company Y. Even > though the CPU is only 10 MIPS instead of 20, it can stream data from 4 > controllers simultaneously at 2.5MB/sec. each, with negligible CPU overhead." This is reasonable. Even more so if there is negligible CPU overhead. 2.5 on 4 controllers seems low and/or expensive, however. > > Hugh LaMaster, m/s 233-9, UUCP ames!lamaster > NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov > Moffett Field, CA 94035 > Phone: (415)694-6117 IP9,nfs,bbs Sequential write test total 33554432 time 19.910 ms/IO 9 Kb/S 1685 Sequential read test total 33554432 time 22.420 ms/IO 10 Kb/S 1496 Random read test total 8388608 time 14.990 ms/IO 29 Kb/S 559 Multiple processes writing separate files simultaneously total 268435456 time 187.660 ms/IO 11 Kb/S 1430 Multiple processes reading the intermixed files total 268435456 time 216.950 ms/IO 13 Kb/S 1237 Multiple processes reading randomly from the intermixed files total 67108864 time 128.580 ms/IO 31 Kb/S 521 Write 8 files, one at a time total 33554432 time 20.140 ms/IO 9 Kb/S 1666 total 33554432 time 20.110 ms/IO 9 Kb/S 1668 total 33554432 time 20.570 ms/IO 10 Kb/S 1631 total 33554432 time 20.230 ms/IO 9 Kb/S 1658 total 33554432 time 20.870 ms/IO 10 Kb/S 1607 total 33554432 time 19.930 ms/IO 9 Kb/S 1683 total 33554432 time 20.290 ms/IO 9 Kb/S 1653 total 33554432 time 20.510 ms/IO 10 Kb/S 1636 Multiple processes reading the sequentially laid-out files total 268435456 time 202.900 ms/IO 12 Kb/S 1322 Multiple processes reading randomly from the sequentially laid-out files total 67108864 time 123.270 ms/IO 30 Kb/S 544 Disclaimer: This is my opinion. But in this case, it might just be that of my employer as well. markb -- Mark Bradley "Faster, faster, until the thrill of IO Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA ---Hunter S. Thompson   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10939; 27 Sep 89 17:39 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa10571; 27 Sep 89 16:28 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa10523; 27 Sep 89 16:11 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa06886; 27 Sep 89 15:29 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA13579; Wed, 27 Sep 89 11:16:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 27 Sep 89 17:03:35 GMT From: Mark Bradley Organization: Silicon Graphics, Inc., Mountain View, CA Subject: Re: I/O CARDS Message-Id: <42240@sgi.sgi.com> References: <8909261825.AA07872@cs.nps.navy.mil> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL In article <8909261825.AA07872@cs.nps.navy.mil>, cloutier@CS.NPS.NAVY.MIL ("m. j. cloutier x2772") writes: > > We are attempting to connect an 80386 laptop to an IRIS workstation (which > will emulate control signal inputs) in an effort to simulate inputs to an > adaptive control sytem. > Does anyone know of I/O cards for the IRIS that will meet (or exceed) the > following requirements: > > 16 12-bit D/A channels > 10 A/D channels (selectable bipolar(+/- 5v)/unipolar(0-5v) > 1 16-bit digital channel > 50kHz data throughput > > Thanks in advance for any suggestions! I received at tip that a company called Data Translation has a board for $1595 that may fit your needs. I have no other info, nor do I know if it even works, but you may want to call them at (508)481-3700. markb -- Mark Bradley "Faster, faster, until the thrill of IO Subsystems speed overcomes the fear of death." Silicon Graphics Computer Systems Mountain View, CA ---Hunter S. Thompson   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12159; 28 Sep 89 1:10 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa12037; 28 Sep 89 0:49 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa12032; 28 Sep 89 0:38 EDT Received: from RUTGERS.EDU by SMOKE.BRL.MIL id aa13121; 28 Sep 89 0:14 EDT Received: from cmcl2.UUCP by rutgers.edu (5.59/SMI4.0/RU1.2/3.04) with UUCP id AA06602; Thu, 28 Sep 89 00:12:40 EDT Received: by cmcl2.NYU.EDU (5.61/1.34) id AA27364; Wed, 27 Sep 89 23:29:46 -0400 Received: by dasys1.UUCP (anilla/UUCP-Project/rel-1.0/11-05-86) id AA22035; Wed, 27 Sep 89 21:13:08 EDT Date: Wed, 27 Sep 89 21:13:08 EDT From: Rod Paul Message-Id: <8909280113.AA22035@dasys1.UUCP> To: Info-Iris@BRL.MIL Subject: /usr/etc/toolkitBus O.K. can anyone tell me what the "sgi-toolkit" (/usr/sgi/toolkitBus) is? I've just upgraded from 3.1C to 3.1G and didn't notice this baby before, but I do notice it realy sucks cpu, so I've excluded it in /etc/services and /usr/etc/inetd.conf. A mistake?   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22787; 28 Sep 89 17:44 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21532; 28 Sep 89 16:00 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa21419; 28 Sep 89 15:46 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa28130; 28 Sep 89 15:19 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA26153; Thu, 28 Sep 89 12:06:53 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Sep 89 18:42:09 GMT From: Bill Lasher Organization: Penn State University Subject: Device drivers for HP printers Message-Id: <89271.144209W0L@PSUVM.BITNET> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Does anyone know if device drivers are available for the HP Inkjet or Deskjet p rinters? We would like to be able to print both text files and do screen dumps to these devices (from a 4D). SG hotline says they don't know of any.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24442; 29 Sep 89 2:56 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24379; 29 Sep 89 2:45 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24369; 29 Sep 89 2:36 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05086; 29 Sep 89 1:52 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA01518; Thu, 28 Sep 89 22:30:18 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Sep 89 22:04:00 GMT From: Kipp Hickman Organization: Silicon Graphics, Entry Systems Division Subject: Re: /usr/etc/toolkitBus Message-Id: <725@odin.SGI.COM> References: <8909280113.AA22035@dasys1.UUCP> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL If you have 3.1G and /usr/etc/toolkitbus, get rid of it! Its not needed until 3.2, and it doesn't go crazy under 3.2. Simply removing the file should do the trick (it might be called /usr/etc/rpc.toolkitbus or something like that). kipp hickman silicon graphics inc.   Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24708; 29 Sep 89 5:09 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24594; 29 Sep 89 4:27 EDT Received: from smoke.brl.mil by VMB.BRL.MIL id aa24572; 29 Sep 89 4:09 EDT Received: from ucbvax.Berkeley.EDU by SMOKE.BRL.MIL id aa05564; 29 Sep 89 3:20 EDT Received: by ucbvax.Berkeley.EDU (5.61/1.37) id AA06648; Fri, 29 Sep 89 00:08:29 -0700 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-iris@brl.mil (info-iris@brl.mil) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 28 Sep 89 21:08:10 GMT From: Tom Haapanen Organization: WATMIMS Research Group, University of Waterloo Subject: Re: limiting resources Message-Id: <3302@watale.waterloo.edu> References: <50*doelz@urz.unibas.ch> Sender: info-iris-request@BRL.MIL To: info-iris@BRL.MIL Reinhard Doelz writes: > 1) disk space of users might be limited by setting more than the default > partitions, e.g., create new partitions and put each group of users on > one of them. Once a device is full, there is no way to write on the device > any longer. I did that , and esp. the /tmp device proved to be useful. > Once /tmp is on the normal file system (/), it is easy to hang the entire > system by calling vi on a 40 MByte ascii fie etc. Well, we have /tmp on a separate partition (the root partition) with normally about 8.5 MB of free space. But the downside of this is that I can not vi a one-megabyte ascii file! The temp file would be about 9 MB, I think! Does anyone know why vi creates such monster temp files? Can't this be fixed (by someone who has source)? \tom haapanen "now, you didn't really expect tom@mims-iris.waterloo.edu my views to have anything to do watmims research group with my employer's, did you?" university of waterloo