SYSTEM logins weird

[Greg Wohletz]

In article <2877 at decuac.DEC.COM>, avolio at decuac.dec.com (Frederick M.
Avolio) writes:
> 
> Well, send me your two problems and/or repost them.  Yes, people from
> the ULTRIX group read this (and no, I am not in the ULTRIX group) but
> the best bet to get fixes is still through buying support.  I guess
> that sounds sort of capitalistic, eh? :-).

Sorry for the flame, I've had a bad week...  Anyway.  We actually
tried to order source code maintenance with our tape, but somehow the
order got screwed up.  Here is my last message again.


In article <1444 at jimi.cs.unlv.edu>, I write:

> We have three microvax  II's that we  use as fileservers.  Each has  3
> Wren V's and   an Exabyte hooked  into  a  Sigma  scsi  controller  (it
> emulates  a  uda  and  tms controller).   They    also  have a Dec  uda
> controller hooked to  an  rd52 and two rx50's  (yes  we've had  these
> machines for  a while...) on  them.   We have been  running with  this
> configuration under Ultrix  2.0 without  many problems (well a few nfs
> bugs, but nothing major).  Recently we got Ultrix 3.1.  I installed it
> on one of  our microvax's  and everything seemed  to be  going fine, I
> could use the disks, and read from the Exabyte.  However, when I tried
> to dump the root filesystem  to the Exabyte  I got a write error, then
> some message like ``mscp resynching controller uq2'' at that point the
> system locked up.

Well,  I've  investigated the situation   a bit further,   and  I have
discovered that (surprise, surprise)  one difference  between  2.0 and
3.1 is that  all of the disk and  tape drive stuff  appears to have be
re-written.   Now  everything  (except  for  non-uda   type drives and
non-tmscp tapes) goes through this new mscp code (or at least  that is
what it looks  like to me).  Anyway looking  at the code didn't reveal
anything obvious,  however  I have noticed  that I  can't  dump to the
trusty (?) old rx50's.   The first volume  of the dump works fine, but
if you so  much as open the  door to the floppy  when dump asks you to
insert the next volume all subsequent  attempts to write to the floppy
will fail (if you leave the same floppy in (without opening  the drive
door) for  ALL of the volumes it  will work...).   I suspect that this
problem is related to the same bug.  I think  at this point I'm almost
convinced that it is a software bug, and not  a problem with the Sigma
controller, but I could be wrong.

So  the question  is, will  someone  from DEC tell  me if  there  is a
known/fixable bug in 3.1 that would cause this behavior?

Would if be possible to graft in the old tmscp  code  from 2.0 without
an inordinate amount of pain?

ANY information would be greatly appreciated.

                                        --Greg
                                        greg at unlv.edu
                                        <@relay.cs.net:greg at unlv.edu>