30 Jul
2016
30 Jul
'16
10:51 a.m.
Hi
I'm trying to revive and old unix machine. A Concurrent Computer
Corporation series 8000. This seems to be a later version of Masscomp
MC5600/MC5700 which has a manual in bitsavers. The system runs RTU
(which I assumes means Real Time Unix).
My machine is in great condition and both SCSI disks (Seagate ST516)
seems to work fine and I've made images. But the machine panics at boot:
---
panic: Unauthorized use of RTU
For further assistance, contact Concurrent's
Customer Service Technical Support Group
---
The NVRAM battery is long dead and upon entering the console I get a
complaint regarding the TOD clock, but I see no way of setting it.
I can boot into a "stand alone mode" but not single user. In the SAM I
can poke arround the filesystem and use "date" to set a date, but the
clock appears not to be running.
Does anyone have experience with this type of machine, either CCC or
masscomp and can offer assistance?
It's a dual MIPS machine with 16MB of memory.
/P
30 Jul
30 Jul
10:58 a.m.
On 2016-07-30 13:51, Pontus Pihlgren wrote:
Hi
I'm trying to revive and old unix machine. A Concurrent Computer
Corporation series 8000. This seems to be a later version of Masscomp
MC5600/MC5700 which has a manual in bitsavers. The system runs RTU
(which I assumes means Real Time Unix).
My machine is in great condition and both SCSI disks (Seagate ST516)
seems to work fine and I've made images. But the machine panics at
boot:
---
panic: Unauthorized use of RTU
For further assistance, contact Concurrent's
Customer Service Technical Support Group
---
The NVRAM battery is long dead and upon entering the console I get a
complaint regarding the TOD clock, but I see no way of setting it.
I can boot into a "stand alone mode" but not single user. In the SAM I
can poke arround the filesystem and use "date" to set a date, but the
clock appears not to be running.
Does anyone have experience with this type of machine, either CCC or
masscomp and can offer assistance?
It's a dual MIPS machine with 16MB of memory.
/P
I know nothing about this machine in particular, but i know a decent
amount about other unix machines of the era. Chances are that the copy
of RTU on that box is licensed to the serial / id number programmed in
nvram. Because the nvram is dead, those numbers no longer match and the
OS panics from an invalid license. The TOD clock typically part of the
nvram chip and loses it's value after every reset. If i had to guess, i
would say replace the battery / nvram chip (if it's a self contained
chip like the old sun boxes) and see if you can get enough data together
to reprogram it. Whether or not the machine in question has a facility
to do that like the old sun's do i am not sure.
11:35 a.m.
On Sat, Jul 30, 2016 at 01:58:49PM -0400, alexmcwhirter at triadic.us wrote:
I know nothing about this machine in particular, but i
know a decent amount
about other unix machines of the era. Chances are that the copy of RTU on
that box is licensed to the serial / id number programmed in nvram. Because
the nvram is dead, those numbers no longer match and the OS panics from an
invalid license.
I think you may very well be right. I noticed that the "show" command in
the console displays the serial number. I went back and compared it with
the serial number printed on the back of the machine. Well, it doesn't
match one bit. So.. I either need to figure out to reprogram the NVRAM
(simply set serial_number doesn't work and the manual lists the
environment variable as "permanent") or I suppose I could figure out
where on disk the serial number is.. but it doesn't sound easy.
The TOD clock typically part of the nvram chip and
loses
it's value after every reset. If i had to guess, i would say replace the
battery / nvram chip (if it's a self contained chip like the old sun boxes)
and see if you can get enough data together to reprogram it. Whether or not
the machine in question has a facility to do that like the old sun's do i am
not sure.
I've battled the NVRAM death and corresponding TOD problems in SGI, SUN
and DEC machines before but only succeded because the "set"
functionality of the console was enough... this time I'm not so sure.
/P
11:54 a.m.
Remove the part and set it in a device programmer ?
On Sat, Jul 30, 2016 at 11:35 AM, Pontus Pihlgren <pontus at update.uu.se>
wrote:
On Sat, Jul 30, 2016 at 01:58:49PM -0400,
alexmcwhirter at triadic.us wrote:
I know nothing about this machine in particular,
but i know a decent
amount
about other unix machines of the era. Chances are
that the copy of RTU on
that box is licensed to the serial / id number programmed in nvram.
Because
the nvram is dead, those numbers no longer match
and the OS panics from
an
invalid license.
I think you may very well be right. I noticed that the "show" command in
the console displays the serial number. I went back and compared it with
the serial number printed on the back of the machine. Well, it doesn't
match one bit. So.. I either need to figure out to reprogram the NVRAM
(simply set serial_number doesn't work and the manual lists the
environment variable as "permanent") or I suppose I could figure out
where on disk the serial number is.. but it doesn't sound easy.
The TOD clock typically part of the nvram chip
and loses
it's value after every reset. If i had to guess, i would say replace the
battery / nvram chip (if it's a self contained chip like the old sun
boxes)
and see if you can get enough data together to
reprogram it. Whether or
not
the machine in question has a facility to do that
like the old sun's do
i am
not sure.
I've battled the NVRAM death and corresponding TOD problems in SGI, SUN
and DEC machines before but only succeded because the "set"
functionality of the console was enough... this time I'm not so sure.
/P
2 Aug
2 Aug
1:48 a.m.
On Sat, Jul 30, 2016 at 11:54:03AM -0700, Pete Lancashire wrote:
Remove the part and set it in a device programmer ?
Well yes :) In theory it's simple. In practice, we'll see. I suppose I
must figure out what the device is, how to program it, find out which
adress to write to, figure out what to write.
I've never done it before either, it will be fun.
/P
On Sat, Jul 30, 2016 at 11:35 AM, Pontus Pihlgren <pontus at update.uu.se>
wrote:
> On Sat, Jul 30, 2016 at 01:58:49PM -0400, alexmcwhirter at triadic.us wrote:
> > I know nothing about this machine in particular, but i know a decent
> amount
> > about other unix machines of the era. Chances are that the copy of RTU on
> > that box is licensed to the serial / id number programmed in nvram.
> Because
> > the nvram is dead, those numbers no longer match and the OS panics from
> an
> > invalid license.
>
> I think you may very well be right. I noticed that the "show" command in
> the console displays the serial number. I went back and compared it with
> the serial number printed on the back of the machine. Well, it doesn't
> match one bit. So.. I either need to figure out to reprogram the NVRAM
> (simply set serial_number doesn't work and the manual lists the
> environment variable as "permanent") or I suppose I could figure out
> where on disk the serial number is.. but it doesn't sound easy.
>
> > The TOD clock typically part of the nvram chip and loses
> > it's value after every reset. If i had to guess, i would say replace the
> > battery / nvram chip (if it's a self contained chip like the old sun
> boxes)
> > and see if you can get enough data together to reprogram it. Whether or
> not
> > the machine in question has a facility to do that like the old sun's do
> i am
> > not sure.
>
> I've battled the NVRAM death and corresponding TOD problems in SGI, SUN
> and DEC machines before but only succeded because the "set"
> functionality of the console was enough... this time I'm not so sure.
>
> /P
>
>
30 Jul
30 Jul
11:19 a.m.
Have u tried replacing said dead battery would start there
On Jul 30, 2016 12:51 PM, "Pontus Pihlgren" <pontus at update.uu.se>
wrote:
Hi
I'm trying to revive and old unix machine. A Concurrent Computer
Corporation series 8000. This seems to be a later version of Masscomp
MC5600/MC5700 which has a manual in bitsavers. The system runs RTU
(which I assumes means Real Time Unix).
My machine is in great condition and both SCSI disks (Seagate ST516)
seems to work fine and I've made images. But the machine panics at boot:
---
panic: Unauthorized use of RTU
For further assistance, contact Concurrent's
Customer Service Technical Support Group
---
The NVRAM battery is long dead and upon entering the console I get a
complaint regarding the TOD clock, but I see no way of setting it.
I can boot into a "stand alone mode" but not single user. In the SAM I
can poke arround the filesystem and use "date" to set a date, but the
clock appears not to be running.
Does anyone have experience with this type of machine, either CCC or
masscomp and can offer assistance?
It's a dual MIPS machine with 16MB of memory.
/P
3064
days inactive
3067
days old
5 comments
4 participants
participants (4)
-
alexmcwhirter＠triadic.us -
pete＠petelancashire.com -
pontus＠Update.UU.SE -
tdk.knight＠gmail.com