Sun-Spots Digest, v6n64
William LeFebvre
Sun-Spots-Request at RICE.EDU
Tue Apr 26 04:28:12 AEST 1988
SUN-SPOTS DIGEST Friday, 22 April 1988 Volume 6 : Issue 64
Today's Topics:
Re: Dialin/out on one port (possible SunOS 3.5 bug)
Re: fstab swap entries
Re: Problems configuring cua0 on a 3/160 zs0
Re: Conference room sized color displays?
Sun DecNet(5.1-Sun4) BIG BUG
Problems with rasfilter8to1 '-d'
wanted: gdbtool (windowing interface to gdb debugger)
Schematic capture & PC Design?
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Sat, 16 Apr 88 17:01:25 PDT
From: Brent Chapman <capmkt!brent at cogsci.berkeley.edu>
Subject: Re: Dialin/out on one port (possible SunOS 3.5 bug)
Reference: v6n53
In v6n53, Hilarie K. Orman talks about Sun's ttyd*/cua* capabilities to
allow both dial-in and dial-out on the same line, and says:
> ... The trick is the
> "flags" parameter in the kernel configuration for the device. This
> activates a mutual exclusion mechanism between devices with matching major
> device numbers and minor device numbers differing by 128 (just one bit).
> Init waits for activity on one device, dial-out uses the other. Now,
> there must be a little bit of magic going on here, because somehow init
> manages to get away with not doing an open on its device, merely getting
> notified when carrier is detected, then doing the open.
Close, but not quite, at least according to what I've been told (since
I've never looked at Sun's serial driver source, I can't say for sure).
The difference between tty device (major, minor) and tty device (major,
minor+128) when the 'flags' bit for that line of that device in the kernel
configuration file is '0' is that calls to open (major, minor+128)
(usually called the 'cua' device) can happen even if carrier detect is
absent, while calls to open (major, minor) (usually called the 'ttyd'
device) pause until carrier detect is asserted by the modem. So 'init'
just tries to open() the 'ttyd' device, and the open() hangs until carrier
detect on that line goes high; when CD goes high, the pending open() is
completed, and init forks a login [[ a "getty", actually --wnl ]] to
handle the (presumed) dialup on the line. Note that this is in _addition_
to the mutual exclusing mechanism mentioned above; if one of the devices
is open, and you try to open the other one, you get back a "no such
device" message from the kernel, so that if you open a cua, dial out (thus
causing CD to go high when you get a connection on the other end), that
_doesn't_ cause the open() pending in init to complete... Clear as mud
yet? It's actually a rather neat trick on Sun's (or whoever orginally
came up with it) part.
Now, for the problem... Things _used_ to work exactly as described above
for both zs0 (motherboard) serial ports and mti (16-port "Asynchronous
Line Multiplexor") boards. They still work just fine for mti ports, but I
can't seem to make them work for zs0 ports; I suspect something got broken
in 3.5, but can't prove it, as I didn't have anything trying to use zs0
before I installed 3.5, and now don't have access to anything _not_
running 3.5 to test my theory on... But if you're using zs0 ports and
3.5, it most definitely does _not_ work they way it is documented to...
Have all the other people who've been having problems with this lately
been running 3.5?
-Brent
Brent Chapman Capital Market Technology, Inc.
Senior Programmer/Analyst 1995 University Ave., Suite 390
{lll-tis,ucbvax!cogsci}!capmkt!brent Berkeley, CA 94704
capmkt!brent@{tis.llnl.gov,cogsci.berkeley.edu} Phone: 415/540-6400
------------------------------
Date: Fri, 15 Apr 88 22:31:21 PDT
From: cvbnet!cvedc!exc!markh at sun.com (Mark A. Holm)
Subject: Re: fstab swap entries
Reference: v6n43
We have been doing split swap since OS 3.0 on our systems here where I
work at Computervision. The first thing that is necessary is to regen your
kernal so that it says that swapping can be done on sd0 and sd1. The
original line should look something like:
config vmunix generic
Change it to read:
config vmunix root on sd0 swap on sd0 and sd1
After regenning your kernal and installing it, place an entry into the fstab
that looks like:
/dev/sd1b foo swap foo 0 0
The only field that count are 1 and 3 (device and type), so anything can
go in the others.
Without regenning the kernal, swapon says it adds the additional swap
space but the kernal doesn't seem to use it.
After doing all of the above and rebooting type /etc/pstat -s . The value
of the used field, the free field, the missing field, and the wasted field
should add up to the combined total of sd0b and sd1b. If not double check
everything and do it again.
Just as a note. Our OS is OEMed back from computervision and we had a
version somewhere between Sun's 3.2 and 3.5 that would only do split swap
using a generic kernal. It wasn't a bad bug or a normal customer
configuration (R&D is always doing something wierd;>) ), so I did not
track it back to find out which specific Sun OS it was derived from.
Therefore if you regenned the kernal and split swap doesn't work, try
going back to a generic kernal ( and let me know so I know it wasn't us).
Mark Holm ..tektronix!ogcvax!cvedc!exc!markh
Exceptions ..sun!cvbnet!cvedc!exc!markh
126 NE Grant Phone (503)648-8307
Hillsboro, Oregon 97124 Messages only until after 6:00 PM
------------------------------
Date: Fri, 15 Apr 88 23:09:53 PDT
From: cvbnet!cvedc!exc!markh at sun.com (Mark A. Holm)
Subject: Re: Problems configuring cua0 on a 3/160 zs0
Reference: v6n31
We have been using dialin/dialout on the same port on 2/120s since 3.0 and
have had no problems with it once we got the quirks worked out. We are
currently using a Hayes 2400 Baud Smartmodem, 2 Cat Novation 1200 Baud
modems, and a US Robotics 1200 Baud modem and have no problems. Here goes
a stab at the step by step procedure.
1. Regen your kernal for hardware hand shaking by setting the flags in the
config file for the zs0 line. An example for both ttya and ttyb to have
hardware handshaking:
device zs0 at obio 1 csr 0x2000 flags 0 priority 3
2. Install the new kernal and reboot the system.
3. cd /dev and make the cua0 device. For the cua0 device the commands are:
mknod cua0 c 12 128
chmod 777 cua0
mv ttya ttyd0 /* this will establish a dilaup port which
has special meaning to a Sun OS */
for additional devices use the major device number for the first numeric
parameter and 128 + the minor device number for the second one (ls -l).
4. edit the /etc/ttys file and add the appropriate getty type from your
gettytab to the device ttydo. We have modified our gettytab so it will
time out if it does not get a carrier or is argueing with a pseudo-carrier
(line noise that happens to sound like a carrier. Can happen with overseas
calls). An example is shown below:
z|d1200|Dial-1200:\
:hc#0:to#30:nx=d1200:fd#1:sp#1200:ig:
^^^^^^^^^^
5. SET THE MODEM SWITCHES CORRECTLY!! This is one of the most important steps!
Set the modem so that it DOES NOT give a constant DTR. When DTR goes active
it starts the getty that init will have waiting in the background. Also,
make sure auto-answer is on ;>).
6. Now do a kill -1 1 to start a getty against that port.
7. Do a ps -ax. You should only see two init processes running and NO getty
for ttyd0. If you see a getty for d0 then check your switch settings again.
If they appear ok, check your cable. It should pass RX, TX, RTS, CTS, DTR,
CD, and DSR (and ground of course ;>) ). Sorry I don't remember the pin
numbers, I'm doing this from memory.
8. Add cua0 to the dialers in the /etc/remote file.
That to the best of my memory is the step by step procedure for
dialin/dialout on a single port. I don't think I have missed any steps,
but anything is possible.
One other thing. Uucp thinks that a LCK file is stale after about 1 hour,
and will try to call out anyway, clobbering any (long) dialout call you
may still have in progress. Our cheap hack, so some of our engineers could
do long homework sessions, was to touch (via crontab) any existing LCK
file in /usr/spool/uucp every 20 minute. This just means that you have to
check your modems periodically, which you should be doing anyway ;>).
If you have problems you can give me a call or drop me some E-mail as this
is one of the areas that I do consulting in under the folowing name:
Mark Holm ..tektronix!ogcvax!cvedc!exc!markh
Exceptions ..sun!cvbnet!cvedc!exc!markh
126 NE Grant Phone (503)648-8307
Hillsboro, Oregon 97124 Messages only until after 6:00 PM
------------------------------
Date: Sun, 17 Apr 88 14:12:30 EDT
From: bob at allosaur.cis.ohio-state.edu (Bob Sutterfield)
Subject: Re: Conference room sized color displays?
Reference: v6n53
I've been pretty impressed with the Electrohome ECP Graphics projector.
It does color and handles scan rates of 15-80KHz, so you should be able to
get your PCs in there too. It's very smart and can be set up with several
switchable inputs with different configuration parameters for each
(convergence, brightness, pincushion, etc).
I have no connection with Electrohome other than as a wishful
budget-dollar-limited would-be customer.
Bob Sutterfield, Department of Computer and Information Science
The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
bob at cis.ohio-state.edu or ...!att!osu-cis!bob
------------------------------
Date: Wed, 20 Apr 88 07:49:39 PDT
From: Steve Blair <ascway.UUCP!scb at spar-20.spar.slb.com>
Subject: Sun DecNet(5.1-Sun4) BIG BUG
I just got finished with several hours of building NEW kernals for my
4/260 running Sys4-3.2 and 4/110's. I then proceeded to install the
incremental release of SunLink DNI-5.1(Sun 4 version). Having a sense of
humor during the following really helped. I followed the
instructions(what a fun time), added all necessary stuff to the system as
per their manuals. NOW THE FUN BEGINS: I rebooted with the new kernal(just
as in DNI5.0(Sun3)) and the following happens:
BAD TRAP
ncp:
trap: Memory address alignment
pid=114, pc=0xff0620a8, sp=0xff0b4d30, psr=0x4001c0, context=2
g1-g7: ff061c70, 4001e3, ffffffff, 0, 0, 0, 0
Begin traceback... sp = ff0b4d30
Called from ff06232c, fp=ff0b4db0, args=ff92db0f ff92db08 ff0cc000 ff0cc000 ff92db0e c
Called from ff061d54, fp=ff0b4e40, args=ff92da8c 1 0 ff452ea6 0 ff452ea8
Called from ff057c7c, fp=ff0b4ea8, args=ff92da8c 100 100 ff92da8c ff0c9400 0
Called from ff02c518, fp=ff0b4f40, args=ff0c9bd8 ff0cb508 ff0bacc4 ff0cb628 ff92da98 ff92da8c
Called from ff005a38, fp=ff0b4fc0, args=0 ff057b40 0 4001e5 ff0f1210 ff0c7060
Called from ff0400a0, fp=ffffe688, args=1 0 400 ffffede0 ff0f7e40 2f
End traceback...
panic: Memory address alignment
syncing disks... panic: cex_timeout
dumping to dev 301, offset 49324
Then my machine rebooted continously before my eyes. I then stopped this
fun and rebooted with the old kernal and it went away. I rebuilt 8-10 new
kernals and re-installed(x5) their DNI-5.1 product. The only change was
the macro which caused the panic/trap:
BAD TRAP
sh:
trap: Memory address alignment
pid=113, pc=0xff0620a8, sp=0xff0b4d30, psr=0x4001c4, context=9
g1-g7: ff061c70, 4001e0, ffffffff, 0, 0, ff0c5400, ff0c5000
Begin traceback... sp = ff0b4d30
Called from ff06232c, fp=ff0b4db0, args=ff92db8f ff92db88 ff0cc000 ff0cc000 ff92db8e c
Called from ff061d54, fp=ff0b4e40, args=ff92dc0c 1 0 ff3fdf0a 0 ff3fdf0c
Called from ff057c7c, fp=ff0b4ea8, args=ff92dc0c 100 100 ff92dc0c ff0c9400 0
Called from ff02c518, fp=ff0b4f40, args=ff0c96d8 ff0cb508 ff0bacc4 ff0cb628 ff92dc18 ff92dc0c
Called from ff005a38, fp=ff0b4fc0, args=0 ff057b40 0 1e2 ff0f1210 ff0c7060
Called from ff054474, fp=ffffea10, args=90 a0 b0 c0 d0 e0
End traceback...
panic: Memory address alignment
syncing disks... cex_sched: already running, must be sleeping
panic: cex_timeout
dumping to dev 301, offset 49324
I then later got a call from a VERY nice guy in their Software Support
group. He said " DEC Vaxes which are routers cause this, you must have
gotten the DNI-5.1 tape >BEFORE< the 'stop-ship'." It turns out from
further discussions with him that a small number of DNI5.1(Sun-4) tapes
got out before they discovered this fine problem. If your VAXES:
1) route
2) X.25
3) mail-relay
Then YOU'LL see this problem. Apparently DEC has a problem in some of
their routing usages. Luckily, SUN HAS A PATCH TAPE!!! If you experience
this problem, call Sun;they have a patch tape(mine is coming) and it'll
replace some of the library routines in '/usr/sys/sun4/OBJ' and end this
fun-time problem. Refer to my service order # 162625 if you're also having
fun with this one!!!
Steve Blair
Workstation Admin.
Schlumberger Technology Corp-Austin Texas
uucp: {backbone}!sun!decwrl!spar!ascway!blair
------------------------------
Date: Sun, 17 Apr 88 11:20:18 BST
From: Ida <ida at EAGLE.WARWICK.AC.UK>
Subject: Problems with rasfilter8to1 '-d'
Our version of rasfilter8to1 does not accept the '-d' (dither) option.
This option is documented but apparently not supported. The command
returns an error:
rasfilter8to1: Invlalid command line option
********
(sp)
Does anyone have a version which works properly? Thanks
Russ.
Russ Lomax. Department of Engineering
russ at uk.ac.warwick.eagle University of Warwick,
...!ukc!warwick!russ Coventry, CV4 7AL,
[+44|0]203 523523 ext 2115 England
------------------------------
Date: Sun, 17 Apr 88 20:13:52 EDT
From: jonathan at vax.cs.pittsburgh.edu (Jonathan S. Eunice)
Subject: wanted: gdbtool (windowing interface to gdb debugger)
I've been using gdb lately to debug a fairly large C program. It
understands complex structures which dbx chokes on, but I miss the
windowed environment of dbxtool (a Sun front-end for dbx). Has anyone
written a gdb interface for either the Sun envrionment or curses? I'd
sure like to get ahold of one.
Failing the ease of software acquisition through anonymous ftp, I've
considered rolling my own. That would give me both a gdbtool and
nitty-gritty experience with the Sun libraries. (My previous experience
was in the Macintosh Toolbox, whatever Masscomp calls their yuccky
library, and minor exposure to Apollo's system.) I've started to browse
the Sun manuals and code; they seem to have a reasonable programming
interface for their windows. If this is a wrong conclusion, or if there
are reasons the gdb interface would be hard to write, I'd appreciate
correction.
Please mail to me directly. I will post a summary. Thank you.
Jonathan S. Eunice ARPA: jonathan at vax.cs.pittsburgh.edu
University of Pittsburgh UUCP: jonathan at pitt
Computer Science BITNET: jonathan at pittvms
(412) 624-8843
------------------------------
Date: 17 Apr 88 01:18:09 GMT
From: vsi1!tim at uunet.uu.net (Tim Richardson )
Subject: Schematic capture & PC Design?
We are looking for some GOOD (!) schematic capture and PC design software
which will run on SUN3 workstations. Does anyone have any suggestions?
Tim Richardson VP Engineering
VICOM Systems Inc. sun!pyramid----\
2520 Junction Ave. uunet!ubvax-----!vsi1!tim
San Jose, CA 95134 ucbvax!tolerant/
+1-408-432-8660
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list