HECnet

hecnet@lists.dfupdate.se

15562 discussions

by mcguire＠neurotica.com

On 09/15/2014 09:35 PM, Johnny Billquist wrote: Ok. Does anyone remember for sure. Is the BA123 3 or 4 slots of Q-CD? If the DHV11 sits in a Q-CD slot, I seem to remember that there are a couple of jumpers that should be different than if it sits in a Q-Q slot. The error you got from moving the DELQA, in combination with how I think I should read your illustration of card locations would suggest that it's 4 Q-CD slots. The BA123 does have 4 Q-CD slots, starting from the right. At slot 5, the serpentine pattern begins, the first dual-width Qbus slot is at the top, and the second is at the bottom. -Dave -- Dave McGuire, AK4HZ/3 New Kensington, PA

10 years, 9 months

ULTRIX on VAX

by bqt＠softjar.se

By the way, Cory. The clock on your system seems to be 3 hours into the future... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

10 years, 9 months

ULTRIX on VAX

by bqt＠softjar.se

On 2014-09-16 07:17, Cory Smelosky wrote: On Tue, 16 Sep 2014, Johnny Billquist wrote: BA123. 5 4 3 2 1 N D R R P 5 4 3 2 1 E D R R P N = NIC, D = DHV11, R = RAM, P = Processor, E = Emprt. All slots after are empty Hum. Hard to say for sure, but this might be a classical case of you having the NIC in the wrong place. Move it over to the "E" side... That resulted in: -XQA0 ?4B CTRLERR, XQA0 ?06 HLT INST PC = 00000C1A Failure. Kept NIC in previously-E slot and put a TQK50 in the former-NIC slot. Loading operating system image ... ************************************ ULTRIX V4.0 (Rev. 158) System #2: Sat Mar 31 03:23:27 EST 1990 real mem = 16723968 avail mem = 11991040 Buffer configuration adjusted to run with small system page table using 239 buffers containing 1672192 bytes of memory KA650 processor with an FPU CPU microcode rev = 4, processor firmware rev = 83 Q22 bus klesiu0 at uba0 uq16 at klesiu0 csr 174500 vec 774, ipl 17 qe0 at uba0 csr 174440 vec 770, ipl 17 qe0: DEC DELQA Ethernet Interface DEQNA-lock Mode, hardware address 08:00:2b:18:ba:b4 root on bonerhitler:/dlclient0/lolwat.root swap on bonerhitler:/dlclient0/lolwat.root/dev/swap swap size - 131072 blocks WARNING: todr too small -- CHECK AND RESET THE DATE! Sat Sep 15 18:56:18 EDT 1990 Automatic reboot in progress... Time set to Sat Sep 15 20:57:40 1990 /etc/nfsstat does not show increasing values. Using OpenBSD 4.4's boot.mop with no bootparams gives me: stray interrupt: vector 0x18, ipl 31 stray interrupt: vector 0x18, ipl 31 stray interrupt: vector 0x18, ipl 31 stray interrupt: vector 0x18, ipl 31 spammed but that could simply be a bootblock bug. Ok. Does anyone remember for sure. Is the BA123 3 or 4 slots of Q-CD? If the DHV11 sits in a Q-CD slot, I seem to remember that there are a couple of jumpers that should be different than if it sits in a Q-Q slot. The error you got from moving the DELQA, in combination with how I think I should read your illustration of card locations would suggest that it's 4 Q-CD slots. But all this is very hard to debug remotely like this. I would try removing the DHV11 in order to minimize the components in the system that can create problems. That also means moving the DELQA up to the DHV11 location. It should definitely be on the left side in that case. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

10 years, 9 months

ULTRIX on VAX

by bqt＠softjar.se

On 2014-09-16 06:56, Cory Smelosky wrote: On Mon, 15 Sep 2014, Mark Pizzolato - Info Comm wrote: On Monday, September 15, 2014 8:18 PM, Cory Smelosky wrote: Evening, I've been trying to netboot ULTRIX today and I have gotten nowhere. Works fine in SIMH! The kernel output says my DELQA is in DEQNA-LOCK mode despite any changes made to the switches...is this Ultrix behaviour or do I have 2 bum DELQAs? I wouldn't be too concerned about this detail, but if you want to worry about it, see if you can get a different output when running under SIMH. Alright. FYI: This is Ultrix 4.0. It appears to stop at printing what the time has been set to. I don't recall what the sequence of output produced at boot time is (maybe you capture that and tell us), but one thing to look at would be proper sequencing of the Qbus bus grants. What type of chassis/backplane are you using and what devices are plugged into the bus and what slots are they in?? BA123. 5 4 3 2 1 N D R R P 5 4 3 2 1 E D R R P N = NIC, D = DHV11, R = RAM, P = Processor, E = Emprt. All slots after are empty Hum. Hard to say for sure, but this might be a classical case of you having the NIC in the wrong place. Move it over to the "E" side... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

10 years, 9 months

ULTRIX on VAX

by Mark＠infocomm.com

On Monday, September 15, 2014 8:18 PM, Cory Smelosky wrote: Evening, I've been trying to netboot ULTRIX today and I have gotten nowhere. Works fine in SIMH! The kernel output says my DELQA is in DEQNA-LOCK mode despite any changes made to the switches...is this Ultrix behaviour or do I have 2 bum DELQAs? I wouldn't be too concerned about this detail, but if you want to worry about it, see if you can get a different output when running under SIMH. FYI: This is Ultrix 4.0. It appears to stop at printing what the time has been set to. I don't recall what the sequence of output produced at boot time is (maybe you capture that and tell us), but one thing to look at would be proper sequencing of the Qbus bus grants. What type of chassis/backplane are you using and what devices are plugged into the bus and what slots are they in?? - Mark

10 years, 9 months

FYI - Guys, I'm back from the desert, areas 8 and 47 are alive again...

by jg＠jordi.guillaumes.name

El 08/09/2014, a les 23.20, Sampsa Laine <sampsa at mac.com> va escriure: Just thought I'd let you know that CHIMPY:: and HILANT:: are finally back up again, had some hardware trouble with my hosting box, but was stuck in the Sinai desert... All is well now, and CHIMPY, GORVAX and HILANT are back online.. sampsa Hello, desert man! Hve you changed your IP addresses? My multinet links to GORVAX and SG1 are both down at this moment. Jordi Guillaumes i Pons jg at jordi.guillaumes.name HECnet: BITXOV::JGUILLAUMES

10 years, 10 months

FYI - Guys, I'm back from the desert, areas 8 and 47 are alive again...

by mark＠wickensonline.co.uk

Well done Sampsa. Your life is still an enigma to me - but it sounds fun (for the most part!) M. On 08/09/14 22:20, Sampsa Laine wrote: Just thought I'd let you know that CHIMPY:: and HILANT:: are finally back up again, had some hardware trouble with my hosting box, but was stuck in the Sinai desert... All is well now, and CHIMPY, GORVAX and HILANT are back online.. sampsa

10 years, 10 months

FYI - Guys, I'm back from the desert, areas 8 and 47 are alive again...

by sampsa＠mac.com

Just thought I'd let you know that CHIMPY:: and HILANT:: are finally back up again, had some hardware trouble with my hosting box, but was stuck in the Sinai desert... All is well now, and CHIMPY, GORVAX and HILANT are back online.. sampsa

10 years, 10 months

Network change stuff

by b4＠gewt.net

Hello all, Hey Brian...in the next week or so I'll be simplifying the tunnel and moving to a (mostly) static IP through cable. I will also be replacing the current DECnet router (a Cisco 2524) with a much more recent 1841 running IOS 15.1. ;) Maybe tftp will work now? ;););) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

10 years, 11 months

Adjacencies Keep Bouncing

by robert.jarratt＠ntlworld.com

Ah, the changes once per second would explain those sequences one second apart coming from 8.400. I had not noticed that in the specs. I guess those updates could be coming because 8.400 is not seeing some packets (or they are being delayed), so it is changing its mind about the liveness of some adjacencies and so sending out updates. My router does not send updates as they change, it waits for the hello timer. As for my pacing of the Level 1 Router updates, the spec does anticipate some issues because it wants you to stagger the starting point (para 6 of section 4.8.1). My pacing should not affect other nodes, the problem seems to occur when I *send* a lot of packets all at once, it seems to affect the receive side. If other nodes send me lots of updates in a burst, that seems to be OK. Regards Rob From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 30 June 2014 21:56 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Adjacencies Keep Bouncing A few notes below paul On Jun 29, 2014, at 5:04 AM, Robert Jarratt <robert.jarratt at ntlworld.com> wrote: I think this was discussed not too long ago, but I can t find the email thread. Sorry, this is quite a long email. ... So here are some interesting things about the above information. 1. I am supposed to send out the Ethernet Router Hello every 15 seconds. From my router log, that is exactly what happens (at :18, :33, :48 etc). However the packet sniffer sees extra packets inserted. I have no idea where these packets are coming from (although my suspicion is winpcap, see later). 2. 8.400 seems to send its Ethernet Router Hello every 15 seconds, but repeats them several times at 1-second intervals. In the extract above it is repeated 3 times, then 3 times, then 5 times. The rule is that router hellos are sent every hello time, or whenever the content of the message changes (different DR, different router list, change in router priority, etc.). Hellos sent when a change occurs are limited to one per second. 3. For a node to decide to drop an adjacency (ie to exclude it from the Ethernet Router Hello message), it must fail to see an Ethernet Router Hello for 3xHello Timer (Hello Timer is 15 seconds by default, so 45 seconds). Clearly my side has sent several Ethernet Router Hello messages in that time. If this was UDP dropping packets, then I would have hoped that it would not drop my particular ones 3 times in a row over a period of 45 seconds. So, somehow, my Ethernet Router Hello messages are being dropped on their way to 8.400. However, this can t be outbound from 5.1023, because if that was the case then all my adjacencies would all go down at the same time. At any one time, only adjacency goes down. This suggests that the packet is somehow getting lost towards the end of its journey to 8.400. What kind of node is 8.400? 47.556 is another one that appears to have this problem, I see that one is SIMH. I am wondering if pcap/winpcap might be implicated here. The reason is that I noticed winpcap seems to drop incoming packets if you have sent a burst of outbound packets. In my router I was sending all the DECnet Level 1 Routing messages, all at the same time and getting some problems similar to this with a node local to my network, because my router did not see the packets coming from the other node, even though the sniffer could see them. I changed my router code to send the Level 1 Routing messages with a 1-second delay between them, and that problem went away. So, I am wondering if the remote nodes I have this problem with are SIMH nodes? Yikes. DECnet assumes that data links don t have defects like that. If you need a workaround like that, chances are things won t work anyway, because the nodes you re talking to will not do packet pacing like that. paul

11 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet