Sun-Spots-Request@RICE.EDU (William LeFebvre) (05/18/88)
SUN-SPOTS DIGEST Tuesday, 17 May 1988 Volume 6 : Issue 90
Today's Topics:
Re: Sun noise levels
Re: Need help with SLIP installation
Vax to SUN4 update
Csh bug
1/2" tape help
SUN monitors hardware problem
Problems with spurious level 2 interrupts
Sun/LISP/KEE/68881 problems
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@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@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Fri, 13 May 88 09:57:37 PDT
From: mordor!tolerant!versatc!aden@sally.utexas.edu (Michael Aden)
Subject: Re: Sun noise levels
I would think twice about EVER lowering my cooling capacity just to get
rid of a bit of noise.
By the way, how do you know you haven't had heat problems? Have you had
any problems at all with your machine?
If I might make a biological analogy, if you have a stroke (part of your
brain dies), you might lose control of one of your arms and legs. I've had
problems (heat? maybe) with my CPU board which exhibited symptoms which
looked like problems with my SCSI interface, the color board, graphics
processor, and a couple other boards. I must admit that I have 2 parallel
interfaces and a GPIB board in my system, too, but that is after all why
they put so many holes back there.
Much better than changing out the fans would be to put filters in front of
them to keep the machine from filling with dust (staticky little devils).
Who knows? It might even make the machine quieter... :-)
Michael Aden
{vsi1,pyramid,uunet}!versatc!aden
------------------------------
Date: Fri, 13 May 88 23:05:32 PDT
From: Brent Chapman <capmkt!brent@cogsci.berkeley.edu>
Subject: Re: Need help with SLIP installation
Reference: v6n83
> From: oravax!alex@cu-arpa.cs.cornell.edu (Alex Feldman)
>
> I tried to install the version of SLIP....when
> I try to run slattach I always get the error:
>
> ioctl(TIOCSETD): No such device or address
Did you add the "pseudo-device slN" (where N is the desired number of
possible SLIP attachments) to your kernel configuration file, then run
'config', then rebuild the kernel?
Are you sure you are telling slattach the correct tty device? The message
above is generated when slattach tries to change the line discipline
(basicly the "type" of the line) from "TTY" to "SLIP". It would seem to
indicate that the device argument getting passed to that ioctl() isn't a
real, open TTY device.
I know the package works fine, at least on my test configuration (between
a 3/50 and a 3/60, both diskful and running 3.5).
-Brent
Brent Chapman Capital Market Technology, Inc.
Senior Programmer/Analyst 1995 University Ave., Suite 390
brent@capmkt.com Berkeley, CA 94704
{lll-tis,uunet}!capmkt!brent Phone: 415/540-6400
------------------------------
Date: Fri, 13 May 88 13:48:14 EDT
From: weltyc@turing.cs.rpi.edu (Christopher A. Welty)
Subject: Vax to SUN4 update
For those of you who had been following the saga of our conversion from a
4.3BSD Vax to a SUN4 as a central machine, I thought I should post an
update, in all fairness to SUN. [For those of you just tuning in, we had
MANY problems making this a reality]
I think the conversion is complete. Our Vax is now off and we haven't had
to turn it on for a while. We had to disribute a lot of the functions the
Vax used to provide over several other machines until the mythical 4.0
comes around and fixes important little things like subnetting, but I
would say about 70% of the functionality we had with the Vax is now
handled by the SUN4.
Now that it's all over, I can say we are pleased. The sucker is fast,
especially when you were used to the poor old Vax with 32 users. It's
realiable, so far. It's cool, the Vax put such a load on our air
conditioner that it just plain broke. It's virtually maintenance
free...so far. It's realy nice to be able to reconfig a kernel and reboot
- all in about five minutes, too - especially in those first few hours of
bringing up the new system. An most importantly, the conversion went very
smoothly. i couldn't have wished for a smoother transition. Sure there
were little things here and there, but we had all the 4.3 src and managed
to port most things.
Another good thing to know is that sunspots works. After my first posting
I got about 10 different messages from people asking about the troubles we
had because they were thinking of doing the same thing. I recommend
anyone thinking of doing such a switchover ask someone who has done it
first. Also as a result of my posting, our local sun sales guy apparently
got a major league beating from higher up (they say sh-t travels down) -
I'm not sure the whole affair was his fault, but it's nice to know if you
get screwed there is a very influential forum to turn to. This power
opens up a dangerous possibility that people will start posting every
little dissapointment, or even lies, and I'd like to make it clear that in
general we are pleased with SUN and I never would have posted such a
flaming message unless I was REALLY frustrated. But let's not forget that
it DID happen.
[[ This is a powerful forum. Maybe even too powerful. I'm glad that it
worked to your advantage in this situation. But to comment further on
your statements about potential abuse: if I ever find out that someone
intentionally lied to this forum about a problem they have been having
with Sun employees, I will be *very* angry. I'm fairly confident that
those who participate in Sun-Spots have a sufficiently professional
attitute where something like that would never happen. And I don't want
to be disappointed! --wnl ]]
Christopher Welty --- Asst. Director, RPI CS Labs
weltyc@cs.rpi.edu ...!rutgers!nysernic!weltyc
------------------------------
Date: Fri, 13 May 88 16:51:52 BST
From: Aled Morris <aledm%cvaxa.sussex.ac.uk@nss.cs.ucl.ac.uk>
Subject: Csh bug
I think I've found a bug in the C-shell on SunOS 3.4 (Sun-3/160).
I tried to type "ls -lgd !$:h" ("why can't I copy to that directory?") but
mistyped it as "ls -lgd !#:h". You can reproduce the bug with any
command:
psune% set prompt="out% "
out% csh
psune% echo !#:h
Segmentation fault (core dumped)
out% file core
core: core file from 'csh'
out%
This bug does not manifest itself on our 4.2BSD Vax, instead it prints
"Modifier failed".
Any ideas?
Aled Morris
systems programmer
Janet/Arpa: aledm@uk.ac.sussex.cvaxa | School of Cognitive Science
uucp: ..!mcvax!ukc!cvaxa!aledm | University of Sussex
talk: +44-(0)273-606755 e2372 | Falmer, Brighton, England
------------------------------
Date: Fri, 13 May 88 18:17:58 CDT
From: natinst!brian@cs.utexas.edu (Brian H. Powell)
Subject: 1/2" tape help
Last night, I installed a Fujitsu M244X 1/2" Tape Drive with a Xylogics
472 controller in our Sun 3/160. It seems to work okay, but there are
some things that I just can't get to work right. Perhaps they're not
supposed to work right, since the man pages have lots of exceptions ("a"
doesn't work for "b" tape drives, for instance.)
In particular, I'm not able to use the "u" (append) option to tar. I can
use the "c" option to create an initial tar file, but I can't add any
files to it after that. Seems like a waste if we have to use a new tape
each time we want to tar something to archive it, or if we have to restore
everything from the tar file to immediately tar it to the tape again.
Something else I can't do are "mt bsf", "mt erase", "mt retension". Of
course, I don't expect retension to work, and perhaps you aren't supposed
to erase 1/2" tapes, but surely bsf should work. ("mt fsf" does work, as
does "mt rewind" and "mt offline".)
Typical errors are below:
natinst% tar u file
tar: tape backspace error: I/O error
natinst% mt retension
/dev/rmt12 retension 1 failed: No such device or address
natinst% mt fsf 2
natinst% mt bsf
/dev/rmt12 bsf 1 failed: I/O error
Any ideas? Like I said, some things work. I've tested all of the various
devices involved ([n][r]mt{0,4,8,12}), and the errors seem to occur
consistently. (And the things that work, work consistently.) Thanks for
any help.
Brian H. Powell National Instruments Corp.
brian@natinst.uucp 12109 Technology Blvd.
ut-sally!im4u!natinst!brian Austin, Texas 78727-6204
AppleLink:D0351 (512) 250-9119 x832
or if that doesn't work, you can use brian@sally.utexas.edu.
------------------------------
Date: Fri, 13 May 88 14:05:12 EDT
From: dean@wrath.cs.cornell.edu (Dean Krafft)
Subject: SUN monitors hardware problem
We have discovered a significant hardware problem with a number of SUN
monitors (ones manufactured by Phillips). The problem is that the flyback
transformer lead to the CRT is routed so that it presses against the power
supply cover. The insulation of this lead is supposed to be rated to
handle the 30KVolts necessary, but it appears to break down. The result
is arcing onto the power supply cover and burning out the flyback
transformer. In some cases, the problem can be identified by black marks
on the cable and the power supply cover.
Over the last two months we have had to replace four flyback transformers
in SUN-3/50s and 3/60s (out of a community of about 100 machines we
support). Now that our electronics technician, John Finley, has isolated
the problem, we are going through all our monitors insulating the cables
from the power supply covers. If you are maintaining your own equipment,
you probably want to do the same. MAKE SURE YOU KNOW WHAT YOU ARE DOING!
There are very dangerous voltages in this section of the monitor, and you
won't do anyone any good if you fry yourself. If Sun is maintaining your
equipment, you might want to ask them about the problem - they may be
interested in doing the preventive maintenance rather than just fixing it
when it breaks.
Dean Krafft
Computer Science Department
Cornell University
Internet: dean@gvax.cs.cornell.edu
uucp: dean@cornell.uucp
bitnet: dean@crnlcs
[[ Many people have complained about the Phillips monitors throughout
the years. --wnl ]]
------------------------------
Date: Fri, 13 May 88 18:26:18 CDT
From: natinst!brian@cs.utexas.edu (Brian H. Powell)
Subject: Problems with spurious level 2 interrupts
Last night, when I was installing our new tape drive, I decided to move
some cards around to conform to Sun's latest concept of "Cardcage Slot
Assignments and Backplane Configuration" for our 3/160. In particular, I
moved our 2nd ethernet card (from slot 6 to slot 3) and our extra memory
card (from slot 2 to slot 5).
When I did that and tried to boot, it would get through all the device
entries, then show "Using 95 buffers occupying using xxxxx bytes memory"
(where xxxxx was some number). Immediately after that, I got lots and
lots of "Spurious Level 2 Interrupt" lines until I shut the machine off.
(L1-a didn't work.)
I quintuple checked the backplane jumpers for all our cards, but it still
happened. I finally had to move the cards back to their original places,
and then it started working. Any idea what I did wrong? Sorry if this is
a dumb question; I'm new at this.
Brian H. Powell National Instruments Corp.
brian@natinst.uucp 12109 Technology Blvd.
ut-sally!im4u!natinst!brian Austin, Texas 78727-6204
AppleLink:D0351 (512) 250-9119 x832
or if that doesn't work, you can use brian@sally.utexas.edu.
[[ There has ben mention in sun-spots before of problems with spurious
level *3* interruputs, but not level 2. If you are interested, you can
check the following back issues: v6n10, v6n15, v6n19, v6n26. And v6n36
has an article about spurious interrupts on ie1. --wnl ]]
------------------------------
Date: Fri, 13 May 88 15:55:53 MDT
From: roberts%studguppy@lanl.gov (Doug Roberts @ Los Alamos National Laboratory)
Subject: Sun/LISP/KEE/68881 problems
There seems to be a problem with implementing calls to the 68881
co-processor when running KEE (V 3.1) on a Sun 3/260. The problem could be
best characterized as, well, NUMERIC GARBAGE being created by declaring
variables as single-float and compiling with the :target 68020/68881
compiler option. This only seems to be the case when attempting to compile
code (SCL 2.1) from within KEE.
In addition to numeric garbage (verrrry large or small numbers) being
created by the type declarations, inexplicable segmentation violations
occur at run time.
We have not seen this type of problem occur when we are just running LISP;
only when running LISP from within KEE. What follows is an example of some
code that causes segmentation violations when we try to run it. The
variables that have been declared single-float, by the way, all have
(should have had) numeric values in the range of 0.0 - 100.0.
Included is an example piece of code that causes problems. Anybody out
there have a clue?
(Angry aside: the Lucid debugger almost completely worthless at diagnosing
this problem.)
(Second angry aside: Why the hell can't the Lucid debugger give variable
NAMES, instead of asigning an arbitrary number: eg. Local 6:)
--Doug
;;; -*- Mode: LISP; Syntax: Common-lisp; Package: KEE; Base: 10; -*-
;;
(defun RFP-SHIP-TO-RL (self &optional fiscal-year)
(let*
((year (if fiscal-year fiscal-year (get.value
'(controller controller) 'a-year)))
(month (get.value '(controller controller) 'a-month))
(cal-month (get.value '(controller controller) 'a-cal-month))
(scrap-to-rl (list 0.0 0.0)) ;;(get.value self 'a-scrap-to-rl))
(rfp-fast-inv (max 0.0 (get.value '(fast-residue-inventory rocky)
'a-current-inventory)))
(rfp-slow-inv (get.value '(slow-residue-inventory rocky)
'a-current-inventory))
(rl-fast-inv (get.value '(RL-STORAGE RICHLAND) 'a-fast-scrap))
(rl-slow-inv (get.value '(RL-STORAGE RICHLAND) 'a-slow-scrap))
(fast-shipped (first scrap-to-rl))
(slow-shipped (second scrap-to-rl))
(rl-sched-fast 0.0)
(rl-sched-slow 0.0)
(rl-fast 0.0)
(rl-slow 0.0)
(return-list (if (or (< cal-month 9.0) (>= cal-month 10.0))
(list (list (+ month 1.0) self 'P-RFP-SHIP-TO-RL))
(list (list (+ month 2.0) self 'P-RFP-SHIP-TO-RL))))
)
(declare (type integer year))
(declare (type single-float scrap-to-rl rfp-fast-inv rfp-slow-inv
RL-FAST-inv RL-slow-inv fast-shipped slow-shipped))
;; slow-shipped)) <--- If this variable is added to
;; the declaration, a segmentation
;; violation occurs at run time!!!
(setq RL-sched-fast
(second (get-data2 year '(rfpsg rocky) 'a-RL-scrap-ship-schedule)))
(setq RL-fast (max 0.0 (min (- RL-sched-fast fast-shipped) rfp-fast-inv)))
(setq RL-sched-SLOW
(third (get-data2 year '(rfpsg rocky) 'a-RL-scrap-ship-schedule)))
(setq RL-SLOW (max 0.0 (min (- RL-sched-SLOW slow-shipped) rfp-slow-inv)))
(cond
((not (<= 0.0 (+ RL-fast RL-slow)))
(put.value '(fast-residue-inventory rocky)
'a-current-inventory (- rfp-fast-inv rl-fast))
(put.value '(rl-storage richland) 'a-fast-scrap
(+ rl-fast rl-fast-inv))
(put.value '(slow-residue-inventory rocky)
'a-current-inventory (- rfp-slow-inv rl-slow))
(put.value '(rl-storage richland) 'a-slow-scrap
(+ rl-slow rl-slow-inv))
(put.value self 'a-scrap-to-rl
(list (+ rl-fast fast-shipped)
(+ rl-slow slow-shipped)))
))
return-list
))
Douglas Roberts
Los Alamos National Laboratory
(505)667-4569
dzzr@lanl.gov
------------------------------
End of SUN-Spots Digest
***********************