microp@b-tech.UUCP (08/23/87)
Subject: Microp mailing list #32 (22-Aug-87)
This message is being mailed to you as part of a mailing list.
This list is targeted towards technical discussions of Microport's Sys
V/AT Unix for the IBM PC-AT. It not officially related to Microport
Systems Inc.
Any input you have should be sent to:
seismo!umix!b-tech!microp
microp%b-tech.uucp@umix.cc.umich.edu
To be added to this list, contact one of the following sites:
seismo!scubed!sdcsvax!amos.ling.LOCAL!sdeggo!dave (southern CA area)
tektronix!reed!percival!nerd
rutgers!umnd-cs!umn-cs!rosevax!herman!k0jfv!alan (Minneapolis/St. Paul area)
seismo!mcvax!trevan!trevor
nessus!info-uport
genrad!mrst!sdti!mjy
gargoyle.uchicago.edu!vijit!madsen
-------------------------------------------------------------------------
From: b-tech!zeeff
Subject: uusub -u
It appears that "uusub -u24" incorrectly collects statistics for all
the data in SYSLOG instead of just the last 24 hours. Has anyone
had it work correctly?
----------------------------------------------------------------------------
From: umix!seismo!hplabs!bnrmtv!mdc!blob (Brian Bechtel)
Subject: Performance under 2.2 U
We're running 2.2 U (unlimited users, version 2.2 L otherwise) on a
Compaq 386 with 10Mb of memory, but it doesn't *feel* like we're
using up all that memory. Compiles still seem to do a lot of disk
i/o, our Unify database doesn't run as fast as it seems it ought,
etc. Anybody have any ideas what might be wrong? Anybody have any
ideas how we can even measure if we *are* doing anything wrong? Our
results on the IOCALL benchmark recently posted to comp.arch were in
the 50 second range.
Thanks for any suggestions.
{hplabs,amdahl}!bnrmtv!\
--Brian Bechtel mdc!blob
{sun,oliveb}!3comvax!/
----------------------------------------------------------------------------
From: itivax!umix!seismo!xios!dont (Don Taylor)
Subject: MicroPort Sys V/AT Mailing List
We have been spending QUITE a lot of time trying to resolve a
problem that results in a "double panic: TSS fault". I believe that a
number of sites have reported this problem. It occurs for us when we use
telnet on our own implementation of TCP/IP SLIP links. Other people have
reported the problem with uucp and cat. In all cases that we know of, the
problem manifests itself on 9600 baud lines. We feel that the problem
derives from the fact that V/AT uses 1kb. of the u-area for the kernel
stack, and that simply is not big enough to handle nested interrupts of any
number. We have a kludge that seems to get around the problem - we switch
stacks to a dedicated interrupt service stack on the first interrupt.
Unfortunately, the 286 prevents us from doing this atomically with respect
to 287 co-processor interrupts (and NMI and bus errors), so the solution
only works reliably if you do not have a co-processor. The correct solution
appears to be the use of another 286 priviledge level by the kernel,
unfortunately that would require changes throughout the kernel, which is
something that we do not want to do.
Has anybody else experienced this problem? MicroPort say that they
cannot reproduce it. (We have been unable to reproduce other sites version
of the problem, and I do not want to ship all of our software to MicroPort
so that they can try to reproduce the problem). Has anybody managed to find
a sure-fire way to reproduce this problem on several different flavours of AT
using readily available software? (preferably MicroPort's own software). If
so, then please let me know how you do it and I will try to reproduce it
here, and test it against our 'fixed' kernel.
Thx. Don
Don Taylor,
XIOS Systems Corporation, ...seismo!mnetor!dciem!nrcaer!xios!dont
1600 Carling Avenue, Suite 150,
Ottawa, Ontario.
K1Z 8R8 613-725-5411
Canada.
---------------------------------------------------------------------------
From: umix!seismo!cmcl2!manhat!samperi
Subject: talk & Microport floppy backups
Here is another write-like talk for System V, with immediate character
echo/send, and with shell escapes for which the ouput of a shelled command
goes to both parties. This program is not Microport-specific. I was going
to send along a Microport-specific floppy backup program that users on this
mailing list might find useful, but it is about 1000 lines long, and I
don't know what length limits you impose on submissions. The latter program
essentially provides a more user friendly interface to cpio, permitting
backups to multi-floppy sets, without those "errno: 6" cpio messages
appearing. (Actually, the program is quite short, but there is much
documentation.) BTW, would somebody on the list please add me to the
list? My UUCP address is shown below.
Thanks.
If 1000 lines is not too long, I'll send the backup program along.
Dominick Samperi
Dept. of Math. & Computer Science
Manhattan College
Riverdale, NY 10471
UUCP: ...{ihnp4|seismo|rutgers|philabs}!cmcl2!manhat!samperi
[ed: source for this is a available from the author]
----------------------------------------------------------------------------
From: umix!seismo!cmcl2!manhat!samperi
Subject: vi tags bug?
I keep getting the vi error message "no such tag in tags file" with
the version of vi that is shipped with System V/AT, while the same
tags file works fine with a Berkeley vi that I tested. Sometimes if
I rearrange the lines in the tags file vi is able to find the tag,
but the results are unpredictable in general (as far as I can tell).
Does anyone have a fix for this problem?
I also tested by using PC/VI with the same tags file, and there were
no problems.
Dominick Samperi
Manhattan College
{seismo|ihnp4|rutgers|philabs}!cmcl2!manhat!samperi
-----------------------------------------------------------------------------
From: umix!seismo!ce.okstate.edu!walters
First off, let me thank all of you who responded to my plea for help
about EGA graphics and Microport UNIX. Almost all replys were helpfull.
Following are two sets of routines, one for doing graphics on the EGA
under Microport System V/AT and the other to save the text screen.
There are several prerequisites to using these routines. Some obvious
and some not so obvious.
An EGA card and a version of Microport that supports shared memory
(for most people thats > 2.2.0).
Shared memory segments are created are bootup with a file in /etc/rc.d
like /etc/rc.d/shm.rc with the following lines.
/etc/shmcreate 0xa0000 a0000 65535 # ega high res
/etc/shmcreate 0xb8000 b8000 32768 # cga
A working version of /etc/shmcreate. The version that came with
2.2.0L didn't work but there was a patch posted in the microp newsletter.
Write access to /dev/mem. A potential security hole.
The routines are pretty obvious and are commented. They must be compiled
with the large memory model. A small demo is given below. Compile
with
cc -Ml mtest.c mega.c mcgasr.c -o mtest
Now I understand why most people don't submit code they have written,
it takes forever to make it presentable. The *best* way to do all of
this non-sense would be to put it in a device driver to make 'em fast.
Oh well, a project for the future. Please send bug reports to
me and flames to /dev/null. Enjoy.
--
Harold G. Walters Internet: walters@ce.okstate.edu
School of Civil Engineering Uucp: {cbosgd, ihnp4, rutgers, ?seismo?,
Oklahoma State University uiucdcs}!okstate!osubem!walters
Stillwater, OK 74078
[ed: source for this is available from the author]
-----------------------------------------------------------------------------
From: umix!seismo!scubed!sdcsvax!ucrmath!soft21!root
Subject: Line printer graphics routines
Enclosed find the shar file which allows Microport to print graphics
(lines, dots, text) on an Epson/Epson Like printer (960x792 dots).
True, it's not stunning, but someone might enjoy it. I did learn how
certain MP problems. For example, we can't seem to create a 96k malloc,
even 64k causes trouble. I page a 32k array in 3 sections from disk.
Table.c is a program which converts hercules 8x8 fonts (see Byte) to
fonts for Epson. Hanve fun and give away freely -- it might improve.
[ed: source for this is available from the author]
-----------------------------------------------------------------------------
From: umix!seismo!scubed!sdcsvax!ucrmath!soft21!root
Subject: ELM?
Aren't you running the ELM mailer? How much memory/disk do I need for this?
I finally have the sources and Iam considering compiling it.
-----------------------------------------------------------------------------
From: b-tech!zeeff
Subject: ELM?
I run the Elm mailer here and I know some other sites do also. It
took alot of work to get it running on Microport and still has a few
bugs. The author (Dave Taylor) is supposed to be working on a new
version, hopefully he will try this on 16 bit systems before he
releases it. It takes about 200K for elm itself + some utilities that
I don't use here.
-----------------------------------------------------------------------------
Subject: serial mouse routines
Enclosed is a shell archive containing my modifications to the serial mouse
routines written by John Chapman (john@bby-bc.UUCP)
I added error checking along with some modularization and efficiency
changes. Also included is a small program called "track" to test these
routines.
These routines were tested with a Microsoft compatible PC mouse and
Microport UNIX 2.2.
-----
Anthony J. Starks ...{ihnp4 | seismo}!iuvax!hpuinda!mdri!ajs
Merrell Dow Research Institute
P.O. Box 68470
Indianapolis, IN 46268
#------------------cut here------------------------------------------------
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# Makefile
# smouse.h
# smouse.c
# track.c
# This archive created: Fri Aug 7 13:13:33 1987
export PATH; PATH=/bin:$PATH
if test -f 'Makefile'
then
echo shar: will not over-write existing file "'Makefile'"
else
cat << \SHAR_EOF > 'Makefile'
#
# Makefile for smouse routines
#
track: track.o smouse.o
cc $(CFLAGS) track.o smouse.o -o track
track.o: track.c smouse.h
cc $(CFLAGS) -c track.c
smouse.o: smouse.c smouse.h
cc $(CFLAGS) -c smouse.c
shar:
shar Makefile smouse.h smouse.c track.c >smouse.shar
clean:
rm -f track.o
SHAR_EOF
fi # end of overwriting check
if test -f 'smouse.h'
then
echo shar: will not over-write existing file "'smouse.h'"
else
cat << \SHAR_EOF > 'smouse.h'
/*
* Constants and definitions for the Microsoft serial mouse routines
*/
#define MOUSE_DEV "/dev/tty1"
#define NCOORD 4
#define NBUTTON 3
#define SYSERR (-1)
#define SUCCESS (0)
typedef struct {
int dx;
int dy;
int button[NBUTTON];
} Mouse;
SHAR_EOF
fi # end of overwriting check
if test -f 'smouse.c'
then
echo shar: will not over-write existing file "'smouse.c'"
else
cat << \SHAR_EOF > 'smouse.c'
/*
* Mouse routines for the Microsoft serial mouse and compatibles.
*
* Adapted from routines posted by john@bby-bc.UUCP in <146@bby-bc.UUCP>.
*
* Anthony J. Starks (ajs@mdri)
*/
#include <fcntl.h>
#include <errno.h>
#include <termio.h>
#include "smouse.h"
static int mfd;
MouseInit()
{
struct termio t;
errno = 0;
if ((mfd = open(MOUSE_DEV, O_RDONLY)) < 0)
{
perror("mouse open");
return SYSERR;
}
if (ioctl(mfd,TCGETA, &t) < 0)
{
perror("mouse get parameter");
return SYSERR;
}
t.c_iflag &= ~(IXON|IXOFF|ISTRIP|INLCR|IGNCR|ICRNL|IUCLC|INPCK);
t.c_cflag = B1200 | CS8 | CLOCAL | CREAD ;
t.c_lflag = 0;
if (ioctl(mfd,TCSETA, &t) < 0)
{
perror("mouse set parameter");
return SYSERR;
}
return SUCCESS;
}
MouseRead(m)
Mouse *m;
{
unsigned char b;
char coord[NCOORD];
/*
* Synchronize on a button byte
*/
for (b=0; (b&0370) != 0200 ; )
if (read(mfd, &b, 1) < 0) return SYSERR;
/*
* Read the coordinates
*/
if (read(mfd, coord, NCOORD) < 0) return SYSERR;
/*
* Read button bits
*/
m->button[2] = (~b) & 1;
m->button[1] = (~(b>>1)) & 1;
m->button[0] = (~(b>>2)) & 1;
/*
* Pack up the coordinate half-words
*/
m->dx = (int)(coord[0] + coord[2]);
m->dy = (int)(coord[1] + coord[3]);
return SUCCESS;
}
MouseClose()
{
close(mfd);
}
SHAR_EOF
fi # end of overwriting check
if test -f 'track.c'
then
echo shar: will not over-write existing file "'track.c'"
else
cat << \SHAR_EOF > 'track.c'
/*
* track -- track the mouse using the serial mouse routines.
*/
#include "smouse.h"
main()
{
Mouse m;
if (MouseInit() < 0) exit(1);
while (!m.button[2])
{
if (MouseRead(&m) < 0) break;
printf("dx = %4d dy = %4d b1 = %1d b2 = %1d b3 = %1d\n",
m.dx, m.dy, m.button[0], m.button[1], m.button[2]);
}
MouseClose();
}
SHAR_EOF
fi # end of overwriting check
# End of shell archive
exit 0
--------------------------------------------------------------------------