On Mon, 15 Sep 2008 20:52:24 +0100, you wrote:
Yeah, the EFI stuff is ACTUALLY quite self explanatory, I think I
should be able to get the Netboot working. Now I don't actually have
a SCSI drive to do the install onto, so will have fun seeing what USB
devices will work :)
Are you sure you do want to go with a USB disk? Reading around about either
VMS or EFI USB support, it appears that it could be a nightmare... Wouldn't be
better to spend your efforts looking for a SCSI disk instead? :)
G.
Yeah, the EFI stuff is ACTUALLY quite self explanatory, I think I should be able to get the Netboot working. Now I don't actually have a SCSI drive to do the install onto, so will have fun seeing what USB devices will work :)
Sampsa
On 15 Sep 2008, at 20:50, gerry77 at mail.com wrote:
On Mon, 15 Sep 2008 14:57:25 +0100, you wrote:
You seemed to know a bit about the integrity boxes, I've just got an
rx2600, but have NO idea what to do next.
I've hooked up the management processor to a DHCP-serving LAN, but
it's not picking up an IP address. Any idea how to reset it to factory
defaults?
I've seen on comp.os.vms that you've managed to resolve your problems and I'm
glad about that because I do not know anything about Itanium hardware: I'm an
Italian DECnet group member, that's true, and we do have an Itanium system on
our network, but... That system is in Rome and I'm in Bologna (about 500 km
north of Rome), so I've never put my hands on it! :-P
If I remember correctly you'll have to fiddle with EFI menus to start a PXE
network boot (a combination of bootp and tftp) and then using InfoServer you
should be able to start OpenVMS 8.x installation, then you'll have to fiddle
again with EFI to set back boot from a local disk or you can use the SETBOOT
command procedure (maybe in SYS$MANAGER or SYS$UPDATE) which should help you
in changing EFI setting quite easily...
Let me know!
G.
On Mon, 15 Sep 2008 14:57:25 +0100, you wrote:
You seemed to know a bit about the integrity boxes, I've just got an
rx2600, but have NO idea what to do next.
I've hooked up the management processor to a DHCP-serving LAN, but
it's not picking up an IP address. Any idea how to reset it to factory
defaults?
I've seen on comp.os.vms that you've managed to resolve your problems and I'm
glad about that because I do not know anything about Itanium hardware: I'm an
Italian DECnet group member, that's true, and we do have an Itanium system on
our network, but... That system is in Rome and I'm in Bologna (about 500 km
north of Rome), so I've never put my hands on it! :-P
If I remember correctly you'll have to fiddle with EFI menus to start a PXE
network boot (a combination of bootp and tftp) and then using InfoServer you
should be able to start OpenVMS 8.x installation, then you'll have to fiddle
again with EFI to set back boot from a local disk or you can use the SETBOOT
command procedure (maybe in SYS$MANAGER or SYS$UPDATE) which should help you
in changing EFI setting quite easily...
Let me know!
G.
"Zane" == Zane H Healy <healyzh at aracnet.com> writes:
Zane> Stupid question, is it possible the SET HOST is connecting via
Zane> LAT rather than DECnet?
I wouldn't think so.
paul
Gerry,
You seemed to know a bit about the integrity boxes, I've just got an rx2600, but have NO idea what to do next.
I've hooked up the management processor to a DHCP-serving LAN, but it's not picking up an IP address. Any idea how to reset it to factory defaults?
Sampsa
On 15 Sep 2008, at 01:25, gerry77 at mail.com wrote:
On Sun, 14 Sep 2008 21:17:06 +0100, you wrote:
Anyone know where I could borrow this, I'm picking up an rx2600
tomorrow?
There are two somewhat "secret" URLs from which you can download BACKUP/IMAGE
copies of the original installation DVDs for V8.3 and V8.3-1H1.
The most curious thing is that they're directly from HP, obviously not as an
official distribution, but maybe to informally spread new Itanium releases
among Hobbyists. Anyway, no one really knows why those files are there, so
it's better to keep their URLs reserved and not so publicly available.
ftp://ftp.hp.com/pub/openvms/private/I640831H1.BCK-GZ (1.8GB)
ftp://ftp.hp.com/pub/openvms/private/I64083.BCK-GZ (1.6GB)
They were made with BACKUP/IMAGE (and not BACKUP/PHYSICAL), so they're not
directly bootable from EFI because they lack the FAT partition which is
present in the original DVD outside the ODS-2 volume. The easiest way to boot
and install from those images is to use an Alpha system with OpenVMS V8.3 to
serve them using the new InfoServer function. You'll need GZIP too.
http://docs.hp.com/en/BA322-90077/apb.html
We [1] used the InfoServer method and were up'n'running in a matter of
minutes. If you'll need further assistance (except on EFI) I'm here! :-)
If someone else offers you off-list something like Layered Products for
OpenVMS on Itanium, we'll be very grateful if you'll share with us! :-)
HTH,
G.
[1] http://decnet.ipv7.net
On Sun, 14 Sep 2008 21:17:06 +0100, you wrote:
Anyone know where I could borrow this, I'm picking up an rx2600
tomorrow?
There are two somewhat "secret" URLs from which you can download BACKUP/IMAGE
copies of the original installation DVDs for V8.3 and V8.3-1H1.
The most curious thing is that they're directly from HP, obviously not as an
official distribution, but maybe to informally spread new Itanium releases
among Hobbyists. Anyway, no one really knows why those files are there, so
it's better to keep their URLs reserved and not so publicly available.
ftp://ftp.hp.com/pub/openvms/private/I640831H1.BCK-GZ (1.8GB)
ftp://ftp.hp.com/pub/openvms/private/I64083.BCK-GZ (1.6GB)
They were made with BACKUP/IMAGE (and not BACKUP/PHYSICAL), so they're not
directly bootable from EFI because they lack the FAT partition which is
present in the original DVD outside the ODS-2 volume. The easiest way to boot
and install from those images is to use an Alpha system with OpenVMS V8.3 to
serve them using the new InfoServer function. You'll need GZIP too.
http://docs.hp.com/en/BA322-90077/apb.html
We [1] used the InfoServer method and were up'n'running in a matter of
minutes. If you'll need further assistance (except on EFI) I'm here! :-)
If someone else offers you off-list something like Layered Products for
OpenVMS on Itanium, we'll be very grateful if you'll share with us! :-)
HTH,
G.
[1] http://decnet.ipv7.net
Stupid question, is it possible the SET HOST is connecting via LAT rather than DECnet?
Zane
At 10:02 PM +0200 9/13/08, Johnny Billquist wrote:
Which all, in my eye, points to that klh10 decides to drop DECnet packets.
Johnny
Mark Abene wrote:
I admit, the fact that LAT "just works" is very puzzling to me.
Enabling debugging on dpni20 isn't very helpful, as I don't see evidence
of anything failing. The thing just doesn't transmit any DECnet traffic
over ethernet. I can SET HOST to my own machine, so I know at least in
principle the protocol is up, however only locally.
Johnny Billquist wrote:
One important detail you left out Mark, is that LAT traffic is working
fine from your klh10 machine.
Do you see any of those multicast addresses? Otherwise I think that's a
red herring.
Since LAT works, we can really narrow things down quite a lot.
Johnny
Mark Abene skrev:
So, as for my problem with Johnny's bridge, I discovered the write(2) to
bridge 0 was failing because I was compiling and linking to an outdated
libpcap. That was easily remedied and now I have DECnet traffic on my
bridged-tap. Yay. However, the problem I detailed below is still
plaguing me, and still after digging through klh10 source it remains a
mystery. Apparently the DECnet multicast addresses are maintained in
the emulated pdp10's memory, in a table called MCAT. This occurs in the
dpni20's function eth_mcatset() which calls osn_ifmcset() in osdnet.c.
Strangely, it thinks it's succeeding, and though the multicast addresses
don't appear in "netstat -ani", a "vmstat -m | grep ether_multi" shows
the in-use counter is incrementing each time, including when I add them
manually with mtest. I highly suspect that the dpni20 driver is getting
confused somewhere, since with the bridged-tap setup it maintains an
internal "10-side" IP and MAC address which is not visible to the OS's
interface table, and only manifests in the ARP table. Presently,
klh10's "enaddr" command-line utility stopped giving errors on adding
the requisite multicast addresses, but ether_multi is *not* incremented,
and the warning enaddr: No EN addr in iftab for "tap0" is given, telling
me that nothing is really happening. This is telling, since enaddr
exercises the same functions in osdnet.c that the emulator itself uses.
As a test I think I may try setting the dedicated interface to a real
ethernet instead of the virtual tap, to see if I can resolve the
multicast issues. At the moment this seems to be the show stopper.
Mark
Mark Abene wrote:
I wanted to be doing a netstat -ani, (-g only shows multicast for
ipv4/6), but the result is the same. None of the DECnet multicast
addresses are being added, most notably (and absolutely necessary) are:
ab:0:0:3:0:0 - type 6003 - for DECnet Phase IV end node Hello packets
from each host, and
ab:0:0:4:0:0 - type 6003 - for DECnet Phase IV router Hello packets from
the router.
I've tried adding these with both enaddr from KLH10 and FreeBSD's
built-in "mtest", but both return errors. This seems to be a
FreeBSD-specific problem which so far I'm unable to find the reason for.
Mark
Mark Abene wrote:
Mark Abene wrote:
I've actually made a new discovery... looking at "netstat -g", I'm
seeing that none of the multicast addresses exist that DECnet uses and
requires! This would explain why I don't see any DECnet traffic at
all.
I compiled KLH10's enaddr utility in an attempt to add the multicast
addresses manually, and I get failures for all attempts...
"SIOCADDMULTI failed - Can't assign requested address". My server's
kernel wasn't built with multicast routing enabled, which is not a
default. I'm wondering if this is the cause of the error. I'm
going to
do some further testing.
Regards
Mark
Well I was mistaken about the multicast routing, that's only for doing
DVMRP with mrouted (MBONE, etc). Local LAN multicast should work "out
of the box" on FreeBSD. Still trying to track down why this is
failing,
since it's my primary candidate for DECnet not working...
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| MONK::HEALYZH (DECnet) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
Which all, in my eye, points to that klh10 decides to drop DECnet packets.
Johnny
Mark Abene wrote:
I admit, the fact that LAT "just works" is very puzzling to me.
Enabling debugging on dpni20 isn't very helpful, as I don't see evidence
of anything failing. The thing just doesn't transmit any DECnet traffic
over ethernet. I can SET HOST to my own machine, so I know at least in
principle the protocol is up, however only locally.
Johnny Billquist wrote:
One important detail you left out Mark, is that LAT traffic is working
fine from your klh10 machine.
Do you see any of those multicast addresses? Otherwise I think that's a
red herring.
Since LAT works, we can really narrow things down quite a lot.
Johnny
Mark Abene skrev:
So, as for my problem with Johnny's bridge, I discovered the write(2) to
bridge 0 was failing because I was compiling and linking to an outdated
libpcap. That was easily remedied and now I have DECnet traffic on my
bridged-tap. Yay. However, the problem I detailed below is still
plaguing me, and still after digging through klh10 source it remains a
mystery. Apparently the DECnet multicast addresses are maintained in
the emulated pdp10's memory, in a table called MCAT. This occurs in the
dpni20's function eth_mcatset() which calls osn_ifmcset() in osdnet.c.
Strangely, it thinks it's succeeding, and though the multicast addresses
don't appear in "netstat -ani", a "vmstat -m | grep ether_multi" shows
the in-use counter is incrementing each time, including when I add them
manually with mtest. I highly suspect that the dpni20 driver is getting
confused somewhere, since with the bridged-tap setup it maintains an
internal "10-side" IP and MAC address which is not visible to the OS's
interface table, and only manifests in the ARP table. Presently,
klh10's "enaddr" command-line utility stopped giving errors on adding
the requisite multicast addresses, but ether_multi is *not* incremented,
and the warning enaddr: No EN addr in iftab for "tap0" is given, telling
me that nothing is really happening. This is telling, since enaddr
exercises the same functions in osdnet.c that the emulator itself uses.
As a test I think I may try setting the dedicated interface to a real
ethernet instead of the virtual tap, to see if I can resolve the
multicast issues. At the moment this seems to be the show stopper.
Mark
Mark Abene wrote:
I wanted to be doing a netstat -ani, (-g only shows multicast for
ipv4/6), but the result is the same. None of the DECnet multicast
addresses are being added, most notably (and absolutely necessary) are:
ab:0:0:3:0:0 - type 6003 - for DECnet Phase IV end node Hello packets
from each host, and
ab:0:0:4:0:0 - type 6003 - for DECnet Phase IV router Hello packets from
the router.
I've tried adding these with both enaddr from KLH10 and FreeBSD's
built-in "mtest", but both return errors. This seems to be a
FreeBSD-specific problem which so far I'm unable to find the reason for.
Mark
Mark Abene wrote:
Mark Abene wrote:
I've actually made a new discovery... looking at "netstat -g", I'm
seeing that none of the multicast addresses exist that DECnet uses and
requires! This would explain why I don't see any DECnet traffic at
all.
I compiled KLH10's enaddr utility in an attempt to add the multicast
addresses manually, and I get failures for all attempts...
"SIOCADDMULTI failed - Can't assign requested address". My server's
kernel wasn't built with multicast routing enabled, which is not a
default. I'm wondering if this is the cause of the error. I'm
going to
do some further testing.
Regards
Mark
Well I was mistaken about the multicast routing, that's only for doing
DVMRP with mrouted (MBONE, etc). Local LAN multicast should work "out
of the box" on FreeBSD. Still trying to track down why this is
failing,
since it's my primary candidate for DECnet not working...
