HDTenEightyP/NetNews huggingface dataset:
From: chris@suite.sw.oz.au (Chris Maltby)
Subject: Re: Problems with root passwd!!!!
Organization: Softway Pty Ltd
Date: 20 Nov 92 06:14:07 GMT

In <1992Nov18.083608.15657@cxbne.cx.OZ.AU> brett@cxbne.cx.OZ.AU (Brett Worth) writes:

>chopper@gumbytsg.tandem.com (Michael Chop) writes:
>>One of our mips machines is experiencing the following problem
>
>>The user(also a super user) couldnt log in as root as his root passwd was
>>not being accepted.  He tried su but that was of no help.
>
>>So I went down to single user and removed the root passwd. I then tried to
>>set a new root passwd. 
>
>>Everytime I did a 
>># passwd 
>
>>I would get,
>
>>New passwd:
>>Re-enter new passwd:
>
>I have seen a similar problem to this a long time ago on an RSX system.
>
>The problem turned out to be that the console terminal was in a mode
>there it was doing a LF and a CR when the RETURN key was hit.  Enter
>icrnl and you get two NLs.

It can also be because the passwd (and su) command opens /dev/tty
to read the passwd. If some other process pgrp matches the controlling
pgrp of the terminal you are on, the open of /dev/tty will fail. It
can then read EBADFs until satisfied, but no banana.
-- 
Chris Maltby - Softway Pty Ltd		Internet: chris@softway.sw.oz.au

PHONE:	+61-2-698-2322	"I'm waiting for X-Windows to become just that;
FAX:	+61-2-699-9174	 Ex-Windows" - A McGrath.
Newsgroups: comp.sys.mips
From: utama@ee.tamu.edu (Peter Utama)
Subject: uugetty and LCK..tty file
Organization: Texas A&M University
Date: Fri, 20 Nov 1992 21:34:00 GMT

Hi !

I am trying to use a faxmodem that can have modem dial-in (for login)
and fax dial-out. I use mips RS3230 with RISC os 4.52.

I use uugetty on the tty line to get the login.
my entry at /etc/inittab looks like:

dw:234:respawn:/usr/lib/uucp/uugetty -r -t 60 ttydm0 du_38400 none LDISC0

the fax process will create a LCK..tty file with its pid in it
in /usr/spool/locks whenever it wants to send a fax and 
the line is free (no LCK..tty created by uugetty) 

the problem is that when the Carrier Dettect goes high (when fax process
dials out and gets connected) uugetty will still try to take control of
the line even though there is a LCK file created by fax process
(uugetty first remove the LCK file then created its own).
According to the manual it shouldn't do that if the pid inside the LCK file 
is a valid one.

What am I doing wrong? is there a special way in creating the LCK file
so uugetty will recognize it and not try to take control of the line
when other process is using the line?
How exactly cu, ct, and uucico use the LCK feature to cooperate with uugetty?

Any comments and helps would be greatly appreciated

thanks,

-peter
---------------------------------------------------------------------------
Peter Utama				utama@ee.tamu.edu
Dept. of Electrical Eng.		voice:(409)845-2362
Texas A&M Univ. 			fax:(409)845-6259
---------------------------------------------------------------------------
Newsgroups: comp.sys.mips,comp.windows.x
From: berstel@mipsmath.math.uqam.ca (Bruno Berstel)
Subject: Kind of bug in xfig on Mips
Reply-To: berstel@lacim.uqam.ca (Bruno Berstel)
Organization: Universite du Quebec a Montreal
Date: Thu, 19 Nov 1992 19:35:02 GMT

Hi,

I have downloaded xfig 2.1.6 yesterday and compiled in on a Mips running
RISC/os 5.0 and on a Sparc 2 running SunOS 4.1.2. It works fine on the Sun
but only almost fine on the Mips.

The thing appears when I want to save into an already existing file (but
the same problem may well arise elsewhere). In the confirmation dialog ("Do
you want to overwrite it ?") the label of the Cancel button seems to be taken
from the bit box. Often this results into garbage being displayed in lieu of
"Cancel". But when (for example) I quit without saving and I click Yes in the
"Do you want to save before quitting ?" dialog, it causes a segmentation
violation.

Does anybody have any clue, suggestion, comment, patch ?
Thanks in advance,
	Bruno.
-----     -----     -----     -----     -----     -----     -----     -----
Bruno Berstel                                         berstel@lacim.uqam.ca
Laboratoire de Combinatoire et d'Informatique Mathematique       L.A.C.I.M.
Universite du Quebec a Montreal                                    U.Q.A.M.
(Tele)phone : (514) 987-8495                           Fax : (514) 987-8477
---------------     ---------------     ---------------     ---------------
                    Noel en hiver, Paques au printemps.
Newsgroups: comp.sys.mips,comp.sys.sgi
From: awolfe@moo.Princeton.EDU (Andrew Wolfe)
Subject: Need pixie documentation
Originator: news@nimaster
Organization: Princeton University
Date: Wed, 18 Nov 1992 18:46:28 GMT


I hope this isn't a FAQ - but I've checked our archives and exhausted local resources.


I need documentation for pixie and pixstats.  I have the man pages, of course, but I need something that documents the format of pixstats reports in more detail.  The subtleties of some of the count categories are important.

Any pointers are appreciated.

-- 
--------------------------------------
Andrew Wolfe
Assistant Professor
Department of Electrical Engineering
Princeton University
From: daryl@zaphod.uchicago.edu (Daryl McLaurine)
Newsgroups: comp.sys.mips
Subject: Dumb Question - How to correctly install an external SCSI disk...
Summary: Need help...PLEASE!
Date: 19 Nov 92 15:11:17 GMT
Article-I.D.: midway.1992Nov19.151117.20999
Organization: Dept. of Mathematics, Univ. of Chicago

Hi all...
Having been spoiled on the SUN auto-SCSI-init, I purchased a Wren7 1.2gb
SCSI disk & inclosure for my M/120...SASH keeps choking on boot...
HOW do I properly install & format the device for use?
	-Daryl, the mystified...

====================== Standard Disclaimers apply ======================
 Daryl McLaurine,     Systems Consultant / Systems Administrator 
 University of Chicago Mathematics Dept. / Cummings Computing Facility 
 daryl@zaphod.UChicago.EDU(128.135.72.61)/ system@biovax.uchicago.edu
From: hennie@datatek.csir.co.za (Hennie Rautenbach)
Newsgroups: comp.sys.mips
Subject: Looking for "npasswd" or "passwd+" for mips.
Date: 18 Nov 92 13:32:50 GMT
Article-I.D.: datatek.hennie.26.0
Organization: CSIR Information Services
NNTP-Posting-Host: valiant.csir.co.za

Hi

I'm looking for a version of "npasswd" or "passwd+" that successfully 
compiles under Risc-Os or EP/IX.

Much appreciated

Hennie Rautenbach
=============================================================================
Hennie Rautenbach                   E-Mail: hennie@nuustak.csir.co.za
Computing Services                  Voice:  +27 +12 841-4222 
CSIR Pretoria 
South Africa
=============================================================================
Newsgroups: comp.sys.mips
From: utama@ee.tamu.edu (Peter Utama)
Subject: uugetty and LCK..tty file
Organization: Texas A&M University
Date: Fri, 20 Nov 1992 21:19:12 GMT

Hi !

I am trying to use a faxmodem that can have modem dial-in (for login)
and fax dial-out. I use mips RS3230 with RISC os 4.52.

I use uugetty on the tty line to get the login.
my entry at /etc/inittab looks like:

dw:234:respawn:/usr/lib/uucp/uugetty -r -t 60 ttydm0 du_38400 none LDISC0

the fax process will create a LCK..tty file with its pid in it
in /usr/spool/locks whenever it wants to send a fax and 
the line is free (no LCK..tty created by uugetty) 

the problem is that when the Carrier Dettect goes high (when fax process
dials out and gets connected) uugetty will still try to take control of
the line even though there is a LCK file created by fax process
(uugetty first remove the LCK file then created its own).
According to the manual it shouldn't do that if the pid inside the LCK file 
is a valid one.

What am I doing wrong? is there a special way in creating the LCK file
so uugetty will recognize it and not try to take control of the line
when other process is using the line?
How exactly cu, ct, and uucico use the LCK feature to cooperate with uugetty?

Any comments and helps would be greatly appreciated

thanks,

peter

utama@ee.tamu.edu
Dept of Electrical Eng
Texas A&M Univ
Newsgroups: comp.sys.mips
From: milton@teal.csn.org (Milton Scritsmier)
Subject: Re: Serial Communication on RS2030
Organization: Colorado SuperNet, Inc.
Date: Thu, 19 Nov 1992 04:24:27 GMT

In article <1e9kdlINN275@fido.asd.sgi.com> beacker@babylon.wpd.sgi.com (Brad Eacker) writes:
>In response to the bantering that has been going on regarding the
>Mips RS2030 box and modems, there are a number of points to remember
>in all this.
>
>	1) The RTS/CTS lines along with the DTR line are used and
>	   listened to when ttym1 is used.

This is interesting. On page 16 of the RISCos 4.50 Software Binary
Release Notes it says

   "The tty1 port on the RC2030, and all tty0 and tty2 ports, except
    for the tty0 port on the Rx3230, have no modem control signals
    (DTR, DCD, DSR, RTS, and CTS) at all. Therefore, these are not
    suitable for use with dial-in or dial-out modems."

If I'm reading that correctly, then both serial ports on the 2030
are not capable of being used with modems. If tty1 does use the
RTS/CTS lines, then why was the above printed in the release notes?
Was there a subsequent hardware change?


Newsgroups: comp.sys.mips
From: neil@uninet.cpd.com (Neil Gorsuch)
Subject: Re: Serial Communication on RS2030
Organization: Uninet Peripherals, Inc.
Date: Wed, 18 Nov 1992 23:19:54 GMT

In article <1e9kdlINN275@fido.asd.sgi.com> beacker@babylon.wpd.sgi.com (Brad Eacker) writes:
>In response to the bantering that has been going on regarding the
>Mips RS2030 box and modems, there are a number of points to remember
>in all this.

I just happened to notice this message, all the previous bantering
messages have been expired from the news spool.  But you might want to
be aware that the SCSI connected Uninet SLAT serial ports will work
with modems on the MIPS, and support dial-in/dial-out and higher baud
rates.


--
Neil Gorsuch  INTERNET: zardoz!uninet!neil@ics.uci.edu  UUCP: uunet!uninet!neil
MAIL: 17981 Sky Park Blvd., Suite O, Irvine, CA, 92714  PHONE: +1 714 263 4222
Uninet Peripherals, Inc.                                FAX: +1 714 263 4299
Xref: sparky comp.sys.mips:1065 comp.std.c++:1614
From: ko@degas.cs.unc.edu (Pat Ko)
Newsgroups: comp.sys.mips,comp.std.c++
Subject: Arbitrary Length Integer Arithmetic Routine?
Keywords: computer arithmetic, arbitrary length
Date: 24 Nov 92 04:01:19 GMT
Followup-To: poster


Does anyone have a C or C++ routine that implements integer add and subtract
(both signed and unsigned) for arbitrary length (multiple of 32 bits)
integers?

Thanks in advance

pat
 
Newsgroups: comp.sys.mips
From: chris@suite.sw.oz.au (Chris Maltby)
Subject: Select snafu on Riscos 4.52 - a fix?
Organization: Softway Pty Ltd
Date: 23 Nov 92 00:51:44 GMT

We have an interesting problem with select and stream events on
our 4.52 3230 system(s). Strangely, one exhibits the problem worse
than the other, though we haven't yet worked out why. The problem
is this: sometimes select will return EAGAIN (though this is not
a documented return). Programs like xterm will consider this to
be a fatal error and exit.

We have tracked the problem to be excessive consumption of stream
event structures, but worse, the consumption is mostly redundant.
Here is a piece of crash output:

: :q29; crash
dumpfile = /dev/mem, namelist = /unix, outfile = stdout
reading symboltable................................................................................
> stream -ef !uniq -c
   1 ADDR      WRQ     IOCB VNODE     PGRP    IOCID   IOCWT WOFF ERR FLAG
   1 c019f000 c01a13f4    - c01a0744 17572      32710     0    0   0 nbio 
   1 	 STRTAB  RCNT
   1 	801085f4    0
   1 	SIGFLAGS:  
   1 	SIGLIST:
   1 	POLLFLAGS:   in
   1 	POLLIST:
 135 		PROC:  190    in
   1 
...

and there are lots more streams in similar states. The processes seem
to be selecting without timeouts, and they accumulate stream events as
time goes by. In fact, we believe that each such stream acquires a new
event structure every time nselcoll occurs, though nselcoll may occur
as a result of the bogus event list. The structures are eventually freed
when the select returns.

This problem exposed another in the way stream events are handled. The
kernel initially allocates 2000 of them, and sets aside MAXSEPGCNT "pages"
for allocation of more. It allocates precisely 20 new 12 byte event
structures for each "page" of allocation. Given that the default
MAXSEPGCNT is 1, and that the kernel actually seems to set aside a
real 4Kb page for each request, we patched (the binary) to change that
20 to be 348, and set MAXSEPGCNT to be 8. We still run out occasionally,
but only after long weekends...

So, the workaround is to include timeouts in your selects, and hope that
someone at mti.sgi.com starts responding to the bugs list...

Chris
-- 
Chris Maltby - Softway Pty Ltd		Internet: chris@softway.sw.oz.au

PHONE:	+61-2-698-2322	"I'm waiting for X-Windows to become just that;
FAX:	+61-2-699-9174	 Ex-Windows" - A McGrath.
Newsgroups: comp.sys.mips
Subject: MIPS R3000 unknown opcodes
From: najmi@ece.ucdavis.edu (Azfar Najmi)
Date: 21 Nov 92 00:34:35 GMT
Distribution: usa
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
Originator: najmi@madrone.eecs.ucdavis.edu


  Hi. I'm working on a project where we need to analyze pixstats
output run on the MIPS R3000 architecture. There are a number of
opcodes in the output for which we cannot seem to find definitions.
(We've looked in the "MIPS RISC Architecture" by Gerry Kane). I 
would appreciate it GREATLY if anyone could explain what these 
MEAN, and/or where I might be able to find them: 

  1. cop1 
  2. spec - in particular, what do these include? (We have a separate
	    output for syscall, which are supposedly a part of these.)
  3. fadd, fmul - are these floating point operations?
		  if so, are they double precision or single
		  precision?
  4. bcond - if these are conditional branches, why are they separate
	     from all the other specific cond. branches (e.g., beq,
	     etc.)?
  5. bff, cff - for these and the following, we really have no clue 
  6. ctf, mtf
  7. c.lt, c.olt
  8. fcvtd, fcvtw
  9. b
 10. bcond - if these are conditional branches, why are they separate
	     from all the other specific cond. branches (e.g., beq,
	     etc.)?

  If you have ANY info. on any of the above, please mail responses to:

      najmi@eecs.ucdavis.edu

  Thanks!
From: beacker@babylon.wpd.sgi.com (Brad Eacker)
Newsgroups: comp.sys.mips
Subject: Re: Serial Communication on RS2030
Date: 17 Nov 1992 02:12:05 GMT
Organization: Silicon Graphics, Inc.
Distribution: world
NNTP-Posting-Host: fddi-babylon.wpd.sgi.com

In response to the bantering that has been going on regarding the
Mips RS2030 box and modems, there are a number of points to remember
in all this.

	1) The RTS/CTS lines along with the DTR line are used and
	   listened to when ttym1 is used.

	2) The pin out for the tty1 is essentially an IBM PC db9.

	3) The box is only capable of supporting 4800 baud due to
	   a design flaw caused by a 186 processor handling all io.

	4) You will need to train your modem to always deliver DTR
	   which most of them can be programmed to do with the S regs.

	5) You will need to verify that you have at least 4.31 proms
	   with most of the boxes having 4.32 proms in later life.

     You ask what are my credentials?  I was one of the SW folks that put
this puppy on the market.  Some of the short cuts that we had to take
to get it to market are not what I consider the best in the world.  But
I have at home a 2030 that I have connected to another unix box and
I do bi-directional rts/cts connection control into the 2030 and it
doesn't go into blabber mode.

     All in all I like the box, but then I am biased since this was the
first of all the workstations that Mips put out.  And yes, I lost a couple
of fingers to each of them.  I just wish that Mips had been able to
survive as a separate company.
                   Brad Eacker (beacker@sgi.com)
Newsgroups: comp.sys.mips
From: trevc@cix.compulink.co.uk (Trevor Cotton)
Subject: test (sorry)
Reply-To: trevc@cix.compulink.co.uk
Date: Sun, 22 Nov 1992 16:48:00 +0000


Just seeing if I can get through.
22 nov 92.
Sorry for the interuption.
Newsgroups: comp.sys.mips
From: brett@cxbne.cx.OZ.AU (Brett Worth)
Subject: Re: Problems with root passwd!!!!
Organization: Comperex Australia Pty Limited
Date: Wed, 18 Nov 1992 08:36:08 GMT

chopper@gumbytsg.tandem.com (Michael Chop) writes:


>One of our mips machines is experiencing the following problem

>The user(also a super user) couldnt log in as root as his root passwd was
>not being accepted.  He tried su but that was of no help.

>So I went down to single user and removed the root passwd. I then tried to
>set a new root passwd. 

>Everytime I did a 
># passwd 

>I would get,

>New passwd:
>Re-enter new passwd:

I have seen a similar problem to this a long time ago on an RSX system.

The problem turned out to be that the console terminal was in a mode
there it was doing a LF and a CR when the RETURN key was hit.  Enter
icrnl and you get two NLs.

>Thanks in advance...
>harini chandra
>tandem computers
>oltp unix-support. 

----------------------------------------------------------------------------
Brett Worth - Software Support Manager            ________ _        _ _ 
Comperex Unix Systems                           /  _______|\  \    /  /
Unit 2, 66 McLauchlan Street                   |  |          \  \/  /
Fortitude Valley QLD,  AUSTRALIA               |  |            >  <
Ph: (61) (7) 2523788                           |  |_______   /  /\  \
Fax: (61) (7) 2571480                           \ ________|/_ /    \_ \
Email: brett@cxbne.cx.oz.au
----------------------------------------------------------------------------
Newsgroups: comp.sys.mips
From: mjohnson@netcom2.Netcom.COM (Mark Johnson)
Subject: Re: MIPS R3000 unknown opcodes
Organization: Netcom Online Communications Service
Distribution: usa
Date: Sun, 22 Nov 1992 15:38:01 GMT


In article <19476@ucdavis.ucdavis.edu> najmi@ece.ucdavis.edu (Azfar Najmi) writes:
   > There are a number of opcodes in the output [of pixstats] for
   > which we cannot seem to find definitions.  (We've looked in
   > the "MIPS RISC Architecture" by Gerry Kane).



Indian proverb: Give a man a fish, and he eats for one day.
                Teach a man to fish, and he eats for a lifetime.

The thing to do is PERFORM EXPERIMENTS.  Be active.  Try stuff.
Force the answer out of the machine against its will.


Here is an algorithm that will solve your problem.

   1. Obtain a list of opcodes for the R2000/R3000.  Number
      them from 0 to n.  Since you have the Kane book, this
      step is Completed.

   2. Write the C program "helloworld.c":
         #include <stdio.h>
         main() { printf("Hello, world\n"); }

   3. Use the "-S" option of the C compiler to generate assembly
      language from the C code: cc -S helloworld.c .  Save
      the assembly sourcecode.

   4. Assemble the assembly sourcecode with "as" and pixify
      the binary with "pixie".  Run the pixified binary and
      generate the pixstats.

   5. These pixstats are the Control in your experiment.
      Save them.

   6. Let i = 0

   7. Copy the helloworld assembly sourcecode from step 3 and
      modify the copy by adding one instruction to the code.
      This instruction uses opcode number  i  .

   8. Run this new assemly sourcecode through the assembler,
      then pixify the binary, then execute the pixified binary,
      then generate the pixstats.

   9. Compare the pixstats from step 8 with the Control
      pixstats from step 5.  This tells you ALL of the
      pixstats categories that opcode number  i  is counted
      in.  Yes, some opcodes are counted in several
      pixstats categories.

  10. Increment  i  .  If i >= n , halt,  Otherwise go to step
      number 7.


When you do this, you will discover that "cop1" is a
category that counts instructions that are executed
by Coprocessor 1 -- which is the R3010 Floating Point
Coprocessor.  See Kane for details.

You'll discover that "spec" are special opcodes --
opcodes deemed by the author of pixstats to be
special.

You'll discover that the instructions "ctc1", "cfc1",
"mtc1", and "mfc1" (which operate upon the two sets
of registers within coprocessor 1) get counted in a
most unconventional and amusing way.


Have fun,

  Mark Johnson
From: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 
Newsgroups: comp.sys.unisys
Subject: Re: Burroughs B20
Date: 16 Nov 92 14:38:00 GMT
Distribution: world
Organization: Advanced Computer Concepts BBS, New Rochelle, NY 914-654-1981
Reply-To: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 

HK> .About software running on it, I cannot say much. I have only seen that wor
  > .processing program and MS-DOS emulator (it could not run Turbo Pascal v 3.
  > .I think that accounting program they had run under the emulator. If I reme
  > .correctly, there is at least Fortran for it too.

You must have been using old software.  Under the current emulator, TP
runs just fine.

Fortran, Cobol, Pascal, Basic, C, PL/M, and Assembler are available from
Unisys (which bought Convergent Technologies)

There are several thousand applications which run native under CTOS.

        D/

 * OLX 2.2 * Bring back A-N airways!!    Dick.Zeitlin%acc1bbs@ssr.com
From: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 
Newsgroups: comp.sys.unisys
Subject: Re: CTOS <-> DOS disk con
Date: 16 Nov 92 14:54:00 GMT
Distribution: world
Organization: Advanced Computer Concepts BBS, New Rochelle, NY 914-654-1981
Reply-To: dick.zeitlin%acc1bbs@ssr.com (Dick Zeitlin) 

  > .> Actually, given that mtool package as a starting point, it probably is
  > .> trivial.  But, since the utilities to read/write Dos floppies are part
  > .> of Ctos Standard Software, why bother??
  > .>
  > .> C'mon, Clarence...  You've been dealing with that **IX stuff too long!
  > .> You should get into CTOS!  <~>

CD> .But...
  > .I assumed that the original poster didn't have MREAD/MWRITE, or we wouldn'
  > .have this thread here.

That's like assuming that everyone Rs The FM!!  I never assume that.
Experience has proven otherwise!  <~>

  > .I am promoting the "CTOS open".  There should be PD software in existence
  > .for a system with over a million users.  There certainly is for the
  > .Convergent/AT&T UNIX PC, with its measely 75,000 users.

But those 75,000 users are, for the most part, educated end users, while
most of the million CTOS users are dealing with a "black box" on the
job.

I did a few utilities that were supposed to be PD and released to the
world.  They disappeared into the CT/Unisys "black hole", so...  These
days I'd rather make money.  <~>  If I thought there was any real chance
of getting a return on shareware, I'd do some, but we both know how much
software was "appropriated" by customers without payment.  It soured me
on the prospects for doing shareware.

  > .                                             An hour of your time is
  > .probably more than they paid for the machine ;-).

Nah...  I'm not THAT expensive.  Two hours, maybe...  <~>

CD> .                Glad to see you back.
  > .You aren't actually using a **IX machine to post this, are you ?????

You jest, of course...  As you know, that **IX stuff doesn't turn me
on.  I still have a 7300 and Mini+ around, and even use them sometimes,
but rarely.  Actually, I'm using an NPC (remember that??) through a
local BBS.

        Best,
         D/

 * OLX 2.2 * Bring back A-N airways!!    Dick.Zeitlin%acc1bbs@ssr.com
                                                                                                           
Xref: sparky comp.sys.unisys:640 alt.folklore.computers:16271 comp.sys.misc:963