Very Computer

We are using sz 3.34 (dated 02-24-94) and it was working great until
we installed latest recommended patches (including 101318-50 with
utmpd disabled and -42's syslogd).  Now sz will time out after about
a minute (more or less) of data transfer and return to shell prompt.

Does anyone with latest recommended patches have problems with 'sz'?

Thanks in advance!

--

Dial-up shell, SLIP/PPP & UUCP, Modem (410) 730-9786, login guest | "Knowledge
is power; the ability to acquire knowledge at will is more powerful."  (Jamie)

: We are using sz 3.34 (dated 02-24-94) and it was working great until
: we installed latest recommended patches (including 101318-50 with
: utmpd disabled and -42's syslogd).  Now sz will time out after about
: a minute (more or less) of data transfer and return to shell prompt.

We tried 'sz' on two Sparc machines (SS10) with latest recommended
patches and it has same problem, then we tried 'sz' on SPARCclassic with
101318-42 and it works fine, so I guess -50 patch must have changed
the behavior of network that cause 'sz' to time-out.

Other problem with -50 (or one of the latest recommended patches)
is that 'w' and 'ps' stopped working, i.e. type 'w' and don't see
any output for long time so had to hit Ctrl-C to get out.  Same
problem with 'ps' ('ps -ef' would show partial output and then stopped
in the middle of output and had to hit Ctrl-C to get out).

We plan to backout the patch back to -42 in order to use 'sz' and
the 'w', 'ps' et al commands.  Let us know if there is any
workarounds.  (We was hoping that latest recommened patches will
solve the "rn, trn or strn: Data Fault" crashes/panic that happens
about 3 times or so a week).

Thanks in advance!

--

Dial-up shell, SLIP/PPP & UUCP, Modem (410) 730-9786, login guest | "Knowledge
is power; the ability to acquire knowledge at will is more powerful."  (Jamie)

: : We are using sz 3.34 (dated 02-24-94) and it was working great until
: : we installed latest recommended patches (including 101318-50 with
: : utmpd disabled and -42's syslogd).  Now sz will time out after about
: : a minute (more or less) of data transfer and return to shell prompt.

Here are the latest patches we installed here:
101317-09
101318-50
101327-06
101344-08
101615-02
101869-01

--

Dial-up shell, SLIP/PPP & UUCP, Modem (410) 730-9786, login guest | "Knowledge
is power; the ability to acquire knowledge at will is more powerful."  (Jamie)

The workaround is to use -w switch.  With -w 4096, it works with ISDN and
ordinary phone line.  I hate to do this but it beats to backout to -42.

--


|  |-|    |  | |     | Los Alamos National Laboratory|uucp: !cmcl2!lanl!jxc
\____|__|_|____|\__\_| Los Alamos, NM 87545          |fax: (505)665-6333

: > We tried 'sz' on two Sparc machines (SS10) with latest recommended
: > patches and it has same problem, then we tried 'sz' on SPARCclassic with
: > 101318-42 and it works fine, so I guess -50 patch must have changed
: > the behavior of network that cause 'sz' to time-out.

: The workaround is to use -w switch.  With -w 4096, it works with ISDN and
: ordinary phone line.  I hate to do this but it beats to backout to -42.

Many thanks.

I guess Sun has changed the settings in ip or tcp driver that might
affect 'sz'.  Will try comparing the ip and tcp driver settings
between two Sun, one with -50 and other with -42.

We still have problem with 'w' and 'ps' and trying using truss (Thanks
Casper) on ps -ef and the ps -ef stopped on

open("/proc/07738", O_RDONLY, 035777776372)     = 4
ioctl(4, PIOCPSINFO, 0x0002527C) (sleeping...)

and it just sits there.

The process 07738 belongs to one of our user, I dont know what name
of the program he run for this process.

Tried 'kill -9 7738' but process still sits in /proc.

Thanks for any help!

--

Dial-up shell, SLIP/PPP & UUCP, Modem (410) 730-9786, login guest | "Knowledge
is power; the ability to acquire knowledge at will is more powerful."  (Jamie)

Just saw in /var/adm/messages which I never saw before it is:

Jul 18 12:59:36 explorer talk: pts/12 in utmp is not a tty
Jul 18 12:59:51 explorer talk: pts/8 in utmp is not a tty
Jul 18 13:00:06 explorer talk: pts/12 in utmp is not a tty
Jul 18 13:00:21 explorer talk: pts/8 in utmp is not a tty
Jul 18 13:00:36 explorer talk: pts/12 in utmp is not a tty

Might has to do with process 7738*up.

--

Dial-up shell, SLIP/PPP & UUCP, Modem (410) 730-9786, login guest | "Knowledge
is power; the ability to acquire knowledge at will is more powerful."  (Jamie)

I've had two other problems after installing the latest recommended
patch set (including 101318-50):

 1) the serial ports are always busy when trying to start up tip, and
 2) tooltalk X authentication is screwed up.

Regarding 1, after using the serial port manager to set the serial ports
to template "Modem - Dial-Out Only", I can use tip to connect *once*.
After disconnecting, waiting a minute or so, and trying tip again, it
then reports "All ports busy", presumably since something (login?) has
grabbed /dev/cua/b.  Re-running the serial port manager will then allow
one more call.  Has anyone seen this?  I haven't tried to figure out
using saf by hand, but I guess it will now be necessary.

The other problem that appeared after patching was the following
console message:
  AUDIT: Fri Jul 22 17:37:05 1994: 1927 X: client 12 rejected from
      IP 127.0.0.1 port 32922
  Xlib:  connection to "127.0.0.1:0.0" refused by server
  Xlib:  Client is not authorized to connect to Server

when trying to start mailtool or the Answerbook viewer.  Mailtool will
go ahead and start after the message, but viewer will not, unless I
turn off authentication with "xhost".  Tooltalk is apparently the
culprit, since we learned that other deskset tools (calendar,
file manager, navigator, etc) didn't hang on startup when tooltalk
was issuing bogus DNS lookups (before some other patch).

  Configuration: SS-5, Solaris 2.3 Hardware 5/94, everything from
Maintenance Supplement 1, everything from 2.3_Recommended as of 20 July.

(I didn't use the save option, so backing out to 101318-42 isn't
possible.)

--

-----------------------------------------------------------------------------
"If it doesn't have an analogy, it isn't Usenet (tm)"