Oooohhh, awesome, thanks!
Now to get to grinding. :-D
-brian
On 3/28/2012 5:38 AM, Pontus Pihlgren wrote:
On Wed, Mar 28, 2012 at 05:34:07AM -0400, Brian Hechinger wrote:
I'm working with getting the 4000/90 up and running and I was
wondering if anyone had seen this behavior before.
Upon initial power up all the diag lights are lit and nothing ever
happens. If I quickly flip the power switch off and on it then comes
up normally.
This happens every time it's powered on cold. Once it's on as long
as I only ever quickly flick the power switch off and on it works
fine.
Thoughts?
Incidentally, Holm Tilfe over att cctech@ had a similar problem.
His problem description:
The Machine doesn't start properly if it is switched on, the LEDs are
all stuck on (0xff). If I switch it off then and on again in a short
time, it starts up properly, is doing the diagnostics and tries to
boot an (defective?) NetBSD 1.1 that is loading the kernel but is
getting then in a ?54 RETRY loop.
His solution was as follows:
Ok, answering myself: Yes this error is already known, found a thread
in comp.sys.dec. The cause ist an empty lithium cell in the DS1287A
RTC. Used a proxxon grindng tool and grinded the IC housing of,
replaced the empty cell (1,07V) with an soldered on CR2016. Works now.
The RTC was unable to remember the "set bootdev dka0" over a
powercycle.
Hope it helps,
Pontus
On Wed, Mar 28, 2012 at 05:34:07AM -0400, Brian Hechinger wrote:
I'm working with getting the 4000/90 up and running and I was
wondering if anyone had seen this behavior before.
Upon initial power up all the diag lights are lit and nothing ever
happens. If I quickly flip the power switch off and on it then comes
up normally.
This happens every time it's powered on cold. Once it's on as long
as I only ever quickly flick the power switch off and on it works
fine.
Thoughts?
Incidentally, Holm Tilfe over att cctech@ had a similar problem.
His problem description:
The Machine doesn't start properly if it is switched on, the LEDs are
all stuck on (0xff). If I switch it off then and on again in a short
time, it starts up properly, is doing the diagnostics and tries to
boot an (defective?) NetBSD 1.1 that is loading the kernel but is
getting then in a ?54 RETRY loop.
His solution was as follows:
Ok, answering myself: Yes this error is already known, found a thread
in comp.sys.dec. The cause ist an empty lithium cell in the DS1287A
RTC. Used a proxxon grindng tool and grinded the IC housing of,
replaced the empty cell (1,07V) with an soldered on CR2016. Works now.
The RTC was unable to remember the "set bootdev dka0" over a
powercycle.
Hope it helps,
Pontus
I'm working with getting the 4000/90 up and running and I was wondering if anyone had seen this behavior before.
Upon initial power up all the diag lights are lit and nothing ever happens. If I quickly flip the power switch off and on it then comes up normally.
This happens every time it's powered on cold. Once it's on as long as I only ever quickly flick the power switch off and on it works fine.
Thoughts?
-brian
You should NEVER edit those files directly. That
can screw the system in a most unpleasant way.
Looks like you couldn't make a decent backup copy
of those files ...
--
Regards, Rok
On 21/03/12 22:09, Steve Davidson wrote:
You should NEVER edit those files directly. That can screw the system in a most unpleasant way.
-Steve
I resemble that comment!
Mark.
You should NEVER edit those files directly. That can screw the system in a most unpleasant way.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Rok Vidmar
Sent: Wednesday, March 21, 2012 17:38
To: hecnet at update.uu.se
Subject: Re: [HECnet] Eastern US HECnet hub will be down this Friday
FWIW, you cannot actually enter "bridge.declab.net" into
Multinet -
it only accepts a dotted IP address.
Not in mul conf/decnet/connect, but you can in multinet
set/decnet command in MULTINET:DECNET-CIRCUITS.COM. It will
stay there unles you touch the interface again.
--
Regards, Rok
I figured that most would figure that out. Also, I'm not sure what the
actual address will be until sometime Friday, so the name was the
easiest to use.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Bob Armstrong
Sent: Wednesday, March 21, 2012 15:27
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Eastern US HECnet hub will be down this Friday
Select port tcp-0-19 and modify the address.
FWIW, you cannot actually enter "bridge.declab.net" into
Multinet - it only accepts a dotted IP address.
Bob
FWIW, you cannot actually enter "bridge.declab.net" into Multinet - it
only accepts a dotted IP address.
Not in mul conf/decnet/connect, but you can in multinet set/decnet
command in MULTINET:DECNET-CIRCUITS.COM. It will stay there
unles you touch the interface again.
--
Regards, Rok
Select port tcp-0-19 and modify the address.
FWIW, you cannot actually enter "bridge.declab.net" into Multinet - it
only accepts a dotted IP address.
Bob
Mark,
$multinet configure/menu
Select DECnet over IP, or something like that. Select port tcp-0-19
and modify the address. Save and exit. This will fix the "permanent"
database, but not the the in-memory copy. You can either fix that
manually, or reboot. It has been a while since I've done the manual
mode, so I would have to look that up myself, but rebooting will check
to see that everything works for startup. This should be done
periodically anyway.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Benson
Sent: Wednesday, March 21, 2012 10:11
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Eastern US HECnet hub will be down this Friday
Can you give me some idea how to check Multinet? I let you
set it up remotely and I don't know what/how to check it >.<
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
On 21 Mar 2012, at 14:04, "Steve Davidson" <jeep at scshome.net> wrote:
The Eastern US HECnet hub will be down this Friday due to static IP
address reassignment and bandwidth increases. Any systems that
currently connect to IP address 69.21.253.230 should change to
bridge.declab.net. This includes bridge and Multinet Tunnel
connections as well as UUHEC (UUCP port 540) connections.
Regards,
-Steve
