On 12 Jan 2013, at 15:48, Cory Smelosky <b4 at gewt.net> wrote:
Hello!
I'm working on getting this online and working right now:
https://lh5.googleusercontent.com/~vJZ5Y3ZWJMk/UPHKr_esrNI/AAAAAAAAA4Y/R0h_…
AlphaServer ES40: Dual 667MHz, 4G RAM, 18G 5.25" IBM SCSI drive I had laying around that I don't have a caddy for so it's just staying in by sheer dumb luck. (I have a second but it seems to be dead..)
Update on current hardware config:
4x 500MHz
4G RAM
2xl 18G full-height drives
2 DE500s (disconnected)
2 FibreChannel controllers (external, I have no FibreChannel hardware)
Several external SCSI ports
Here's the output of SHOW DEV/FULL: http://pastebin.com/KxKN6ETG
Node name is MISSY (9.3) (It's already in the node DB).
Accounts available upon request. Running OpenVMS 8.4 (Not set up as a galaxy)
Accounts /still/ more available and system is more configured now.
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
No I missed that one earlier, Brian.
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Brian Schenkenberger, VAXman-
Verzonden: zondag, januari 2013 21:18
Aan: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] My newest toy -SCSISE adapter
"H Vlems" <hvlems at zonnet.nl> writes:
Umm, I wasn't very clear there, was I ? :) Actually I was wondering how
Oleg had figured that out. That you'd be able to find the information
from the VMS source listings is no real surprise. Even though it implies
that formally unsupported hardware is documented in the sources. But
hypothetically, you have an Adaptec AHA2944UW controller how would an
ordinary VMS user figure that out? The hex id is vendor and model
related. But how to figure out what PK driver is required? Or is the PKA
driver a kind of catch all driver?
Did you read my follow-on?
$ HELP Sys_Files [SYS$LDR] SYS$PKADRIVER.EXE
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
"H Vlems" <hvlems at zonnet.nl> writes:
Brian, Speaking of source listings, VMS V4.<mumble> had a "secret" patch
for MONITOR.EXE. It enabled the monitor class Ethernet. Is that code
still hidden in MONITOR? The MONITOR utility was written in PL/I at the
time. Probably rewritten, right? Hans
There were only 3 or 4 modules written in PL/I. Those were rewritten in C.
Why not Bliss? Dunno.
I vaguely recall that "patch". I'll have to refresh my memory and then see
if somethign similar can be done to enable it in modern versions of MONITOR.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Brian,
Speaking of source listings, VMS V4.<mumble> had a "secret" patch for
MONITOR.EXE. It enabled the monitor class Ethernet. Is that code still
hidden in MONITOR?
The MONITOR utility was written in PL/I at the time. Probably rewritten,
right?
Hans
"H Vlems" <hvlems at zonnet.nl> writes:
Umm, I wasn't very clear there, was I ? :) Actually I was wondering how
Oleg had figured that out. That you'd be able to find the information
from the VMS source listings is no real surprise. Even though it implies
that formally unsupported hardware is documented in the sources. But
hypothetically, you have an Adaptec AHA2944UW controller how would an
ordinary VMS user figure that out? The hex id is vendor and model
related. But how to figure out what PK driver is required? Or is the PKA
driver a kind of catch all driver?
Did you read my follow-on?
$ HELP Sys_Files [SYS$LDR] SYS$PKADRIVER.EXE
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Umm, I wasn't very clear there, was I ? :)
Actually I was wondering how Oleg had figured that out.
That you'd be able to find the information from the VMS source listings is
no real surprise. Even though it implies that formally unsupported hardware
is documented in the sources.
But hypothetically, you have an Adaptec AHA2944UW controller how would an
ordinary VMS user figure that out? The hex id is vendor and model related.
But how to figure out what PK driver is required? Or is the PKA driver a
kind of catch all driver?
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Brian Schenkenberger, VAXman-
Verzonden: zondag, januari 2013 19:31
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] My newest toy -SCSISE adapter
hvlems at zonnet.nl writes:
OK, that I understand.
How do you know what PKx$DRIVER to select?
Me??? Because PKADRIVER.LIS says:
* ABSTRACT:
*
* PKADRIVER is a SCSI port driver for adapters based on the Adaptec
* AIC-78xx chipset.
*
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
OK, that I understand.
How do you know what PKx$DRIVER to select?
------Origineel bericht------
Van: Brian Schenkenberger, VAXman-
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] My newest toy -SCSISE adapter
Verzonden: 13 januari 2013 19:07
"H Vlems" <hvlems at zonnet.nl> writes:
Oleg,
a couple of questions: - how did you obtain/calculate the value for id?
- is MK a valid value for boot_class - is this file documented
somewhere? Hans
Google! :) I Googled "Adaptec AHA-2940UW hardware id" and found several
links that panned out... here's one:
http://www.driveridentifier.com/scan/download.php?item_id=174439555&scanid=…
In it it says:
Device Name:
Adaptec AHA-2940U/2940UW/2940D PCI SCSI Controller
Hardware ID
PCI\VEN_9004&DEV_8178&SUBSYS_00000000&REV_00
PCI\VEN_9004&DEV_8178&SUBSYS_00000000
--------^^^^-----^^^^
PCI\VEN_9004&DEV_8178&REV_00
PCI\VEN_9004&DEV_8178 <---- Device ID matches with our database
PCI\VEN_9004&DEV_8178&CC_010000
PCI\VEN_9004&DEV_8178&CC_0100
Hence, the "id = 0x81789004" in the SYS$USER_CONFIG.DAT.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 1/13/2013 5:08 PM, Peter Lothberg wrote:
On 1/12/2013 4:02 PM, Peter Lothberg wrote:
I'm concurrently attacking it from three different directions: ssh,
snmp and mop remote console.
First one done wins. :)
You only have one alternative that works across all the cisco boxes in
HECnet, SNMP.
As I made a a image that works on 2500 with 8M flash and 16M ram,
there is not room for SSH....
Can you try MOP RC?
How would you get on the local Ethnernet?
That will have to be worked out but shouldn't be too difficult.
-brian
"H Vlems" <hvlems at zonnet.nl> writes:
Oleg,
a couple of questions: - how did you obtain/calculate the value for id?
- is MK a valid value for boot_class - is this file documented
somewhere? Hans
Google! :) I Googled "Adaptec AHA-2940UW hardware id" and found several
links that panned out... here's one:
http://www.driveridentifier.com/scan/download.php?item_id=174439555&scanid=…
In it it says:
Device Name:
Adaptec AHA-2940U/2940UW/2940D PCI SCSI Controller
Hardware ID
PCI\VEN_9004&DEV_8178&SUBSYS_00000000&REV_00
PCI\VEN_9004&DEV_8178&SUBSYS_00000000
--------^^^^-----^^^^
PCI\VEN_9004&DEV_8178&REV_00
PCI\VEN_9004&DEV_8178 <---- Device ID matches with our database
PCI\VEN_9004&DEV_8178&CC_010000
PCI\VEN_9004&DEV_8178&CC_0100
Hence, the "id = 0x81789004" in the SYS$USER_CONFIG.DAT.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Mark Benson <md.benson at gmail.com> writes:
On 13 Jan 2013, at 16:04, Brian Schenkenberger, VAXman- wrote:
...but I don't BUY systems. ;)
You KNOW what I mean ;)
I have. There's quite an air volume but I would hessitate to call it
= a > toaster oven.=20
Okay try this comparison. Stick your hand behind a normal modern Intel =
PC. Now stick it behind a rx2600/zx6000. See what I mean. It's hot in =
comparison. It might be the flow is slower and hotter in a zx6000 but =
you can see where all that electrical energy is ending up :)
No "intel" PeeCees here as I do not do WEENDOZE. The only intel CPU h/w,
other than the Itaniums, are in the MacBookPros.
I'm not saying Itanium is inefficient as it has a LOT of raw CPU =
horsepower per Watt but I anm skeptical as to wether it's more efficient
= than a late Alpha on a per-MHz comparison. Both CPUs get very hot in =
operation. Both have a LOT of raw power for that draw and per MHz. It's
= not like comparing a Pentium 4 and an Alpha, for example.
Don't get me wrong. I loved Alpha and I believe that if it was permitted
to live beyond the late term abortion that HP gave it that it would be on
par with or have exceeded the Itaniums. Of course, that's fodder for one
of those time-travel into the past altered timeline theories where Brian
and Peter wind up with a chalkboard in their living room.
I'm not in Florida. ;)
No, I know, You're in NY/NJ, I know what 'Sandy' was, 2 of my best =
friends live in Hoboken. I was using Florida as a comparison as a 'it's
= hot there most of the year' place. If you'd prefer I use Texas or =
Louisiana I can do ;)
NJ shore area.
With regards to performance, the VUPS.COM benchmark (which is probably =
wildly inaccurate on fast non-VAX hardware) considers my zx6000 (472 =
VUPs) to be 3 times as fast as my 500Mhz PWS500au (161 VUPs). Even so, =
that's probably one CPU only on the zx6000 so it's probably 6x faster if
= you multi-thread. Like I said, though, it's not that accurate on a
fast = VAX, I doubt it's accurate at all on non-VAX CPUs ;)
What's in your VUPS.COM? The one I'm aware of is pure DCL and it's called
VUPOMETER.COM.
Running this VUPOMETER will not stress multiple CPUs as DCL is supervisor
mode single-threaded. Also, DCL was written in Macro-32 on VAX. On Alpha
and Itanium, it's also Macro-32. DCL's data structures were generally not
very well aligned for modern memory access systems like Alpha and Itanium.
Alignment faults abound. Alignment faults on Alphas could be tolerated but
on Itaniums it is a completely different story. I'd wager that your VUPS
determinations aren't accounting for alignment faults in DCL. In addition,
there are a number of things that were done in DCL macro that require some
more extensive handling on Alpha and Itanium. From the silly nonsense like
passing the CLI service block in R9 for CHMS handling to weird unwinds[*].
I believe that a new VUP meter -- one that's not pure DCL -- is needed to
better guage relative VUP performance.
[*] After development of the DCL debugger, I could elaborate for hours on
so much of the strangeness in DCL that makes it a less than ideal candidate
for being any sort of deterministic VUP indicator.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
