On 21 Sep 2011, at 08:11, Mark Wickens wrote:
I'm yet to determine whether this is down to the LCD panel it is driving being at limits or whether there is a slight issue with the video generation circuit. Once in a while, every couple of minutes or so the LCD looses sync and the picture is dropped. This only happens for a fraction of a second, then the picture is restored as was.
If anyone has any ideas I'm all ears. For reference I'm using a Iiyama AS4637UT, an old but extremely capable 18.1" 1280x1024 native panel. If anyone is interested I can post the horizontal and vertical frequencies it is being driven at.
It's most likely the LCD panel. They are very funny about refresh rates a lot of the time. Some prefer 59.9Hz and some 60Hz and some won't drive at anything other than that, while others will but shut the signal off after a while (my Samsungs all do this - very annoying) or they just have a brain-fart and blink off, and in your case come back on again (some just crash totally).
It'd be interesting to see what the vertical and horizontal refresh rates are.
--
Mark Benson
My Blog:
<http://markbenson.org/blog>
Follow me on Twitter:
http://twitter.com/mdbenson
"Never send a human to do a machine's job..."
Folks,
Always nice when you've got a piece of good news ;)
I replaced all the mains filtering capacitors in the original DEC GIGI power supply when one blew only to find that the power supply lasted another 10 minutes before losing power completely. At this point I decided given the relatively standard power outputs (5V 3A, 12V 1A, -12V 0.3A) I would source a replacement power supply.
This arrived and was installed yesterday. It I guess unsurprisingly is substantially smaller and lighter than the original. The original cooling fan was removed as it was basically transformed directly from either the mains directly or one of the windings of the main transformer. I used the fan out of an external SCSI enclosure as a replacement, although I look to source a high quality brand new one. To me it looks like the fan primarily is for cooling the PSU only - given the fan location and the location of the plate that the PSU is mounted on it looks unlikely that the main circuit board would benefit much.
The machine now happily powers on and I had an hours playtime last night with the local BASIC monitor.
The GIGI now only exhibits one minor trait, and I'm yet to determine whether this is down to the LCD panel it is driving being at limits or whether there is a slight issue with the video generation circuit. Once in a while, every couple of minutes or so the LCD looses sync and the picture is dropped. This only happens for a fraction of a second, then the picture is restored as was.
If anyone has any ideas I'm all ears. For reference I'm using a Iiyama AS4637UT, an old but extremely capable 18.1" 1280x1024 native panel. If anyone is interested I can post the horizontal and vertical frequencies it is being driven at.
I plan on scanning the GIGI brochures I have for inclusion on bitsavers shortly.
Regards, Mark
No because it is a property of the hardware front-end.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Sampsa Laine
Sent: Tuesday, September 20, 2011 14:23
To: hecnet at Update.UU.SE
Subject: [HECnet] SRM stuff from VMS
Is there a way of setting the bootdev and bootflags from within VMS?
Walking to the next room and plugging in a serial cable is a pain?
Sampsa
boot -fl 0,1
SYSBOOT>set alloclass=<non-zero-value>
SYSBOOT>continue
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Sampsa Laine
Sent: Monday, September 19, 2011 21:16
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] I broke CHIMPY, again...
How do I get the system to boot again, easiest way?
Sampsa
On 20 Sep 2011, at 02:07, Steve Davidson wrote:
You will need to set ALLOCLASS (in MODPARAMS.DAT) to non-zero, autogen, and reboot. Do not use feedback unless the system had been up for at least 24 hours.
-Steve
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Sampsa Laine
Sent: Monday, September 19, 2011 18:05
To: hecnet at Update.UU.SE
Subject: [HECnet] I broke CHIMPY, again...
This time by adding volume shadowing:
I added the following to MODPARAMS.DAT:
! Volume Shadowing Parameters:
SHADOWING=2 ! Enables phase II shadowing
SHADOW_SYS_DISK=1 ! Enables system disk shadowing
SHADOW_SYS_UNIT=7 ! Specifies 7 as the virtual unit number
of the system disk
SHADOW_MAX_COPY=3 ! Specifies that 3 parallel copies can occur at one time
SHADOW_MBR_TMO=10 ! Allows 10 seconds for physical members to fail over
! before removal from the shadow set
Then ran:
@SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS FEEDBACK
Rebooted with save feedback, when it comes up, it fails:
**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
** Bugcheck code = 00000B14: SHDWREQALLOC, Allocation class is required for shadow set members
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: CHIMPY
** Supported CPU count: 00000001
** Active CPUs: 00000000.00000001
** Current Process: SYSINIT
** Current PSB ID: 00000001
** Image Name: SYSINIT.EXE
Easiest way to fix?
How do I get the system to boot again, easiest way?
Conversational, set SHADOW_SYS_DISK and
SHADOW_SYS_UNIT to zero. Then check the
documentation about SHADOW_SYS_UNIT.
--
Regards, Rok
You will need to set ALLOCLASS (in MODPARAMS.DAT) to non-zero, autogen, and reboot. Do not use feedback unless the system had been up for at least 24 hours.
-Steve
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Sampsa Laine
Sent: Monday, September 19, 2011 18:05
To: hecnet at Update.UU.SE
Subject: [HECnet] I broke CHIMPY, again...
This time by adding volume shadowing:
I added the following to MODPARAMS.DAT:
! Volume Shadowing Parameters:
SHADOWING=2 ! Enables phase II shadowing
SHADOW_SYS_DISK=1 ! Enables system disk shadowing
SHADOW_SYS_UNIT=7 ! Specifies 7 as the virtual unit number
of the system disk
SHADOW_MAX_COPY=3 ! Specifies that 3 parallel copies can occur at one time
SHADOW_MBR_TMO=10 ! Allows 10 seconds for physical members to fail over
! before removal from the shadow set
Then ran:
@SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS FEEDBACK
Rebooted with save feedback, when it comes up, it fails:
**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
** Bugcheck code = 00000B14: SHDWREQALLOC, Allocation class is required for shadow set members
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: CHIMPY
** Supported CPU count: 00000001
** Active CPUs: 00000000.00000001
** Current Process: SYSINIT
** Current PSB ID: 00000001
** Image Name: SYSINIT.EXE
Easiest way to fix?
Weird, however, that I can mount an ODS-5 drive on the VAX and indeed do
directory listings and the like. Wouldn't believe it if I hadn't seen
it. Is it some feature of 7.3.1 that I didn't know about? Or maybe
specific to mounting drives in a cluster?
Strange indeed. HELP INITIALIZE /STRUCTURE on Alpha VMS 7.3-1 says that VAX
deos not support Structure Level 5 disks, and specifying 5 on VAX results
in an error. I don't have a 7.3 VAX system to hand to check what that says.
The help for MOUNT is silent on the issue.
I wonder what happens if you try to access filenames with ODS-5 specific
features from the VAX side?
Regarding AUTOGEN - I tried what you suggested and there were no
differences between the before and after files. I can post them if you
like, but I'm not sure they are going to be much use.
Bother! I neglected to include "USE CURRENT" before the SHOW commands!
As result, both BEFORE.TXT and AFTER.TXT ended up listing the "active"
parameter set, ie what is in memory. AUTOGEN, on the other hand updates
the "current" parameter set which is the parameter set on the disk.
Assuming you have now rebooted after the AUTOGEN, if you now repeat:
$ DEFINE /USER SYS$OUTPUT AFTER.TXT
$ MCR SYSGEN
SHOW /ALL
SHOW /SPECIAL
^Z
You should get an updated AFTER.TXT suitable for comparison with BEFORE.TXT
which was generated before the AUTOGEN. This should then reveal the changes
AUTOGEN made.
(It would be unusual for AUTOGEN to result in no changes at all.)
Note that having manually changed the parameters with SYSGEN the system
should be in line with the MODPARAMS file which is what I saw.
But haven't you done an AUTOGEN already as part of the commands I suggested
for comparing the system parameters before and after it? If you have, AUTOGEN
will have set the system parameters taking account of what it found in
MODPARAMS.DAT.
I'm going to back up the ALPHASYSTEM disk when it's offline and then
I'll try an AUTOGEN and see what happens this time. Maybe it was
something else which is now working. With a backup it will be trivial to
revert.
A backup is always good to have.
The system disk move from ODS-5 to OSD-2 was uneventful. I created an
extra shadow member $4$DKC500: in shadowset DSA0: which was running on
$4$DKB0: and $4$DKB100:, then I dismounted the new member $4$DKC500: and
$4$DKB100:. I then followed the instructions here:
http://h71000.www7.hp.com/doc/73final/6536/6536pro_001.html
Which went something like this:
$ INITIALIZE /STRUCTURE_LEVEL=5 $4$DKB100: SLAVESYSTEM
Shouldn't that be /STRUCTURE_LEVEL=2 ? I guess that's what you did and 5 is
a typo?
$ MOUNT/FOREIGN $4$DKB100:
$ BACKUP/LOG/CONVERT/IMAGE $4$DKC500: $4$DKB100:/NOINIT
then shutdown the system, swapped $4$DKB0: and $4$DKB100: so the OSD-2
drive was now the single shadow set member, rebooted then issued a
$ MOUNT/SYSTEM DSA0: /SHADOW=($4$DKB0:, $4$DKB100:) SLAVESYSTEM SYSTEM$
to bring $4$DKB100: (the old ODS-5 drive) back into the shadowset via copy.
The ALPHA and VAX are now clustered nicely, including a common SYSAUTH
and RIGHTSLIST, so I can now login to my normal account hosted on the
ALPHA from the VAX. I've also pulled out common logicals and mounts into
a common file.
Good progress today.
Good news that everything is working now.
Regards,
Peter Coghlan.
On 19/09/11 23:04, Sampsa Laine wrote:
This time by adding volume shadowing:
I added the following to MODPARAMS.DAT:
! Volume Shadowing Parameters:
SHADOWING=2 ! Enables phase II shadowing
SHADOW_SYS_DISK=1 ! Enables system disk shadowing
SHADOW_SYS_UNIT=7 ! Specifies 7 as the virtual unit number
of the system disk
SHADOW_MAX_COPY=3 ! Specifies that 3 parallel copies can occur at one time
SHADOW_MBR_TMO=10 ! Allows 10 seconds for physical members to fail over
! before removal from the shadow set
Then ran:
@SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS FEEDBACK
Rebooted with save feedback, when it comes up, it fails:
**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
** Bugcheck code = 00000B14: SHDWREQALLOC, Allocation class is required for shadow set members
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: CHIMPY
** Supported CPU count: 00000001
** Active CPUs: 00000000.00000001
** Current Process: SYSINIT
** Current PSB ID: 00000001
** Image Name: SYSINIT.EXE
Easiest way to fix?
You need to add an ALLOCLASS definition to MODPARAMS.DAT, or use SYSGEN to define, for example:
$ MCR SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET ALLOCLASS 100
SYSGEN> WRITE CURRENT
Ctrl-Z
then reboot. If you use SYSGEN then make MODPARAMS.DAT match.
You'll probably need a conversational boot to get this point.
See here: http://lakesdev.blogspot.com/2009/09/volume-shadowing-system-disk-on-vax.ht…
Mark.
On 19/09/11 11:40, Peter Coghlan wrote:
Peter, I should be able to get round to testing this today.
Great stuff. Let me know how you get on and I will try to help if
necessary / possible.
Just currently moving the system disk on the alpha from ODS-5 to OSD-2 so
that we've got half a chance of clustering the VAX properly...
I don't think the alpha system disk being ODS-5 should cause any problems
clustering with a VAX. However, you would not be able to mount the ODS-5
disk from the VAX side of the cluster and from that point of view, it would
be better if it was ODS-2.
Regards,
Peter Coghlan.
Weird, however, that I can mount an ODS-5 drive on the VAX and indeed do directory listings and the like. Wouldn't believe it if I hadn't seen it. Is it some feature of 7.3.1 that I didn't know about? Or maybe specific to mounting drives in a cluster?
Regarding AUTOGEN - I tried what you suggested and there were no differences between the before and after files. I can post them if you like, but I'm not sure they are going to be much use.
Note that having manually changed the parameters with SYSGEN the system should be in line with the MODPARAMS file which is what I saw.
I'm going to back up the ALPHASYSTEM disk when it's offline and then I'll try an AUTOGEN and see what happens this time. Maybe it was something else which is now working. With a backup it will be trivial to revert.
The system disk move from ODS-5 to OSD-2 was uneventful. I created an extra shadow member $4$DKC500: in shadowset DSA0: which was running on $4$DKB0: and $4$DKB100:, then I dismounted the new member $4$DKC500: and $4$DKB100:. I then followed the instructions here: http://h71000.www7.hp.com/doc/73final/6536/6536pro_001.html
Which went something like this:
$ INITIALIZE /STRUCTURE_LEVEL=5 $4$DKB100: SLAVESYSTEM
$ MOUNT/FOREIGN $4$DKB100:
$ BACKUP/LOG/CONVERT/IMAGE $4$DKC500: $4$DKB100:/NOINIT
then shutdown the system, swapped $4$DKB0: and $4$DKB100: so the OSD-2 drive was now the single shadow set member, rebooted then issued a
$ MOUNT/SYSTEM DSA0: /SHADOW=($4$DKB0:, $4$DKB100:) SLAVESYSTEM SYSTEM$
to bring $4$DKB100: (the old ODS-5 drive) back into the shadowset via copy.
The ALPHA and VAX are now clustered nicely, including a common SYSAUTH and RIGHTSLIST, so I can now login to my normal account hosted on the ALPHA from the VAX. I've also pulled out common logicals and mounts into a common file.
Good progress today.
Regards, Mark
