> Roger Cornelius wrote:
> > We have been successfully running SCO Office Portfolio for the last
> > several years as we have upgraded UNIX/OpenServer from 3.2v4.2 to the
> > current OSR 5.0.7. Starting with about 5.0.2 (I think) OP would no
> > longer run if we had the SMP software installed. OP would fail with the
> > message:
> > MV wiockeys() failed! Can't register hotkeys
> > This is actually the message I get with 5.0.7 but it is the same or
> > similar as previous OS versions. Since sar reports didn't show any
> > performance bottleneck, I just uninstalled SMP and we ran without it and
> > OP works fine in that case. We're now in the process of upgrading an
> > aging server to a new one, which, though we didn't order it, was shipped
> > with a second processor installed. I tried installing SMP and, not
> > surprisingly, OP won't run. I know that OP hasn't been supported for
> > years, but I'd love to be able to use it and the second processor at the
> > same time. Is there any chance of making it work? On a side note, the
> > new server has XEON processors. If I can't run OP with SMP, will I be
> > able to run it with one XEON processor with the osr507up Hyper-Threading
> > update installed?
> > I've run truss against the OP pmiew.rts binary. It forks a new process
> > which ultimately dies with a segmentation fault. I can provide the
> > trace if needed.
> OSR5 `truss` is imperfect; one of its faults is that it sometimes causes
> a process to SIGSEGV when it would have been fine when run standalone.
> It's possible the process was going to SIGSEGV by itself, but that's
> probably an observation artifact.
> My desktop has a Pentium 4 "2.40C GHz", 800FSB, that supports
> hyperthreading. I installed OP on it and it fails with the "wiockeys"
> message on some runs. I actually see three different behaviors:
> sometimes it hangs, sometimes it fails with "wiockeys", sometimes it
> starts successfully (with a "Caldaemon process has stopped due to a
> fatal error\nF1 to clear reminder" complaint). BTW when I say
> "installed" I actually mean "copied files from a 3.2v4.2 system that
> once ran OP" -- I don't even know if it works correctly on the original
> system, and I don't know anything about running, installing or
> administrating the beast myself.
> When I `truss`, it usually does the third thing (seems to work).
> If I disable a CPU (`cpuonoff -i 2`), it usually seems to work (with or
> without `truss`).
> I'm doing the `truss` in the `op` shell script,
> runapp truss -o /tmp/op.truss $OALIB/mvw/pmview.rts -R "$OALIB/oadaemon"
> instead of:
> runapp $OALIB/mvw/pmview.rts -R "$OALIB/oadaemon"
> The variant behavior between truss/no-truss and SMP/disabled strongly
> implies that this is a timing problem. It's probably forking a child,
> then assuming some events will occur in a certain sequence which isn't
> true on an SMP system.
> Since you know how to install & use OP, you're in a better position to
> test this...
> Pathetic idea, but, what if you `cpuonoff -i 2` (etc.), disable all your
> extra processors; then start OP; then reenable them. Does OP continue
> to work? Obviously this isn't a viable way to run a system, I'm just
> trying to figure out if the problem is pervasive, or if there's just one
> small hump to get over.