Apparently something was wrong with the configuration file for cde.
So I did a find / -name Xconfig
and that pointed me to /usr/dt/config/Xconfig, which in turn is a link to
/usr/var/dt/Xconfig.
The file contents told me not to modify that file, which probably happened.
So I copied it to /etc/dt/config, rebooted and all was well.
Why it went worng in the first place, no idea at all...
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Kari Uusim ki
Verzonden: vrijdag, februari 2013 7:15
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Tru64 question
Quite right, Hans. Finland is at UTC+2.
On 15.2.2013 0:15, hvlems at zonnet.nl wrote:
Same for me Kari, on both topics!
You're one hour ahead, right?
We're at UTC+1.
Hans
------Origineel bericht------
Van: Kari Uusim ki
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Tru64 question
Verzonden: 14 februari 2013 23:03
Well, have to test myself. It's so long a time since I've been working
with Tru64 that I've forgotten many details. It's late now so I have to
test tomorrow.
Kari
On 14.2.2013 23:58, H Vlems wrote:
The session options give me Failsafe and another one (name forgotten),
but that last one was selected.
I end up in a single xterm window whether logged on as root or as hans,
makes no difference.
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Kari Uusim ki
Verzonden: donderdag, februari 2013 22:54
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Tru64 question
There is probably the last used desktop selection "xterm".
Try to select from the session options the CDE desktop before you log in.
Kari
On 14.2.2013 19:27, H Vlems wrote:
Logging in on the console of a Tru64 V5.0 machine
I ended up in an xterm terminal and nothing else.
The usual "new DECwindows" desktop was gone.
Any ideas where to look for a fix?
The system is an AlphaServer 800 that had been power
off for a year now.
Hans
.
.
On 2013-02-16 03:03, Paul_Koning at Dell.com wrote:
The thing to do would be to see what happens if you load some multicast address (such as broadcast) into slot 0 of the 16-entry address match table, and the station address into slot 1. For a QNA, that's perfectly fine because all slots are equivalent and the device doesn't do any MOP. It may be that this was a later restriction that RSTS didn't obey. Or it may be a bad assumption in the real LQA that wasn't documented -- or maybe it's just a bad assumption in the SIMH emulation. I haven't yet looked for LQA manuals to give more clues.
Ah. I thought you had already checked documentation.
Well, I did now, and simh is right. Page 3-31 of the DELQA manual states that the first address is used as the source address for system ID messages.
So I guess RSTS/E just sets it up wrong.
Johnny
paul
On Feb 15, 2013, at 8:53 PM, Johnny Billquist wrote:
On 2013-01-24 20:29, Paul_Koning at Dell.com wrote:
I was watching the MOP Console system ID messages from DECnet/E on simh, with an emulated LQA. Noticed something odd: the source address was broadcast. That's not valid, of course. The question is why that happened.
The answer is that the emulation uses the address in slot 0 of the address filter as the source address. The hardware doesn't care what order the addresses go in as far as filtering is concerned; DECnet/E puts broadcast in slot 0 and the physical address in slot 1, followed by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an interesting DECnet/E bug if so... Or does a real LQA just use the physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I did mark this for some later investigation. However, I now realize that it's not trivial for me to test, as it would appear a RSTS/E system would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more, since he have been digging into these kind of questions way more than most people I know...
Or else if you have some realistic suggestion on how I would test this on my machine, as I do have a 11/93 with a real LQA here (although an LQA plus).
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
--
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
The thing to do would be to see what happens if you load some multicast address (such as broadcast) into slot 0 of the 16-entry address match table, and the station address into slot 1. For a QNA, that's perfectly fine because all slots are equivalent and the device doesn't do any MOP. It may be that this was a later restriction that RSTS didn't obey. Or it may be a bad assumption in the real LQA that wasn't documented -- or maybe it's just a bad assumption in the SIMH emulation. I haven't yet looked for LQA manuals to give more clues.
paul
On Feb 15, 2013, at 8:53 PM, Johnny Billquist wrote:
On 2013-01-24 20:29, Paul_Koning at Dell.com wrote:
I was watching the MOP Console system ID messages from DECnet/E on simh, with an emulated LQA. Noticed something odd: the source address was broadcast. That's not valid, of course. The question is why that happened.
The answer is that the emulation uses the address in slot 0 of the address filter as the source address. The hardware doesn't care what order the addresses go in as far as filtering is concerned; DECnet/E puts broadcast in slot 0 and the physical address in slot 1, followed by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an interesting DECnet/E bug if so... Or does a real LQA just use the physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I did mark this for some later investigation. However, I now realize that it's not trivial for me to test, as it would appear a RSTS/E system would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more, since he have been digging into these kind of questions way more than most people I know...
Or else if you have some realistic suggestion on how I would test this on my machine, as I do have a 11/93 with a real LQA here (although an LQA plus).
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
On 2013-01-24 20:29, Paul_Koning at Dell.com wrote:
I was watching the MOP Console system ID messages from DECnet/E on simh, with an emulated LQA. Noticed something odd: the source address was broadcast. That's not valid, of course. The question is why that happened.
The answer is that the emulation uses the address in slot 0 of the address filter as the source address. The hardware doesn't care what order the addresses go in as far as filtering is concerned; DECnet/E puts broadcast in slot 0 and the physical address in slot 1, followed by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an interesting DECnet/E bug if so... Or does a real LQA just use the physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I did mark this for some later investigation. However, I now realize that it's not trivial for me to test, as it would appear a RSTS/E system would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more, since he have been digging into these kind of questions way more than most people I know...
Or else if you have some realistic suggestion on how I would test this on my machine, as I do have a 11/93 with a real LQA here (although an LQA plus).
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
On 2013-02-16 02:15, John Wilson wrote:
From: Johnny Billquist <bqt at softjar.se>
But is there any sane reason
why Linux would SYN-ACK twice, and the second one more than a second
after the first.
Completely stupid theory: last time I did any testing with Linux, it seemed
that it would *always* lose the very first packet sent to a given local
IP address, because it would send an ARP request instead and then forget
why it asked (i.e. drop the outgoing frame since it depended, IMHO wrongly,
on the higher-level protocol to time out and resend). Maybe they fixed
that bug twice? I.e. did a workaround to send the SYN+ACK twice, and then
later did the *real* bug fix to maintain a queue of packets waiting for an
ARP reply, so now you get two? Seems silly but this would be the result.
Ha! Thanks for reminding me about that one. Many Unix systems have a variant of that bug. Many will only keep one packet around when they need to do an ARP request, so if you for example do a ping with a large packet size (that gets fragmented), the first packet always fail if there isn't an entry in the arp cache. (Only one fragment makes it across.)
(Of course my TCP/IP for RSX tries do to better than that... :-) )
But yeah, you could be right on that one. Ugly as hell if you are right, but I cannot rule it out. But it would be nice if someone had something more substantial than guesses as well. Anyone?
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
To continue my night ramblings about TCP/IP, I think I now have all aspect of my rewritten TCP/IP for RSX working right.
And to give you something of a live example from a real PDP-11/93, here is a tcpdump of a short session, which also gives you a little idea of response times for real hardware.
iMac is a pretty quick Mac. Pondus is my home 11/93. DELQA-YM, and also a VSV-21 which keeps the bus a little busy, but otherwise a farily idle machine when the test was run.
02:08:51.963513 IP iMac.61712 > Pondus.http: Flags [S], seq 1430632358, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 2339561691 ecr 0,sackOK,eol], length 0
02:08:52.041339 IP Pondus.http > iMac.61712: Flags [S.], seq 3396663417, ack 1430632359, win 5840, options [mss 1460], length 0
02:08:52.041397 IP iMac.61712 > Pondus.http: Flags [.], ack 1, win 65535, length 0
02:09:14.525188 IP iMac.61712 > Pondus.http: Flags [P.], seq 1:17, ack 1, win 65535, length 16
02:09:14.729046 IP Pondus.http > iMac.61712: Flags [.], ack 17, win 5840, length 0
02:09:14.964597 IP iMac.61712 > Pondus.http: Flags [P.], seq 17:19, ack 1, win 65535, length 2
02:09:15.169279 IP Pondus.http > iMac.61712: Flags [.], ack 19, win 5840, length 0
02:09:16.372880 IP Pondus.http > iMac.61712: Flags [F.], seq 1:1272, ack 19, win 5840, length 1271
02:09:16.372949 IP iMac.61712 > Pondus.http: Flags [.], ack 1273, win 65535, length 0
02:09:16.373569 IP iMac.61712 > Pondus.http: Flags [F.], seq 19, ack 1273, win 65535, length 0
02:09:16.389006 IP Pondus.http > iMac.61712: Flags [.], ack 20, win 5840, length 0
So, for the initial SYN-ACK response to the SYN is about 8/100s, which I think is pretty ok (that would include the startup of the web server task). It takes a little time to serve the data requested in the HTTP session. Not surprising since the web server needs to be started, it needs to read in the request from the net, parse it, log it to a couple of different logs, access the mapping between URL and filenames, access the mime content mapping, read the requested file, and send the stuff back over the network.
(And I typed in the http request by hand.)
All in all, the session took 25 seconds.
Time to maybe twiddle some HLL libraries a little more, and start thinking of getting this onto some more machines than mine...
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
From: Johnny Billquist <bqt at softjar.se>
But is there any sane reason
why Linux would SYN-ACK twice, and the second one more than a second
after the first.
Completely stupid theory: last time I did any testing with Linux, it seemed
that it would *always* lose the very first packet sent to a given local
IP address, because it would send an ARP request instead and then forget
why it asked (i.e. drop the outgoing frame since it depended, IMHO wrongly,
on the higher-level protocol to time out and resend). Maybe they fixed
that bug twice? I.e. did a workaround to send the SYN+ACK twice, and then
later did the *real* bug fix to maintain a queue of packets waiting for an
ARP reply, so now you get two? Seems silly but this would be the result.
John Wilson
D Bit
Hi. As I'm working on my TCP/IP for RSX, I just noticed something that I think looks funny in Linux. But right now my head is also spinning, so maybe there is something I've just forgotten, or don't know, which explains this. But if anyone can shed some light, I'd be interested.
Just for the record - I *think* that TCP/IP in Linux is misbehaving, but it's not really hurting anything, but I like my TCP/IP to really do things as right and optimal as possible.
So, I actually have two scenarios that I'm looking at. The first one is the initial setup. You know, the old three way handshake. Here is a tcpdump between a Linux box and my RSX. Psilo being Linux, and Madame being RSX, and connection initiated from RSX to Linux:
01:02:06.567423 IP Madame.Update.UU.SE.48001 > Psilocybe.Update.UU.SE.http: Flags [S], seq 2810750936, win 5840, options [mss 1460], length 0
01:02:06.567435 IP Psilocybe.Update.UU.SE.http > Madame.Update.UU.SE.48001: Flags [S.], seq 323429751, ack 2810750937, win 14600, options [mss 1460], length 0
01:02:06.569071 IP Madame.Update.UU.SE.48001 > Psilocybe.Update.UU.SE.http: Flags [.], ack 1, win 5840, length 0
01:02:07.966015 IP Psilocybe.Update.UU.SE.http > Madame.Update.UU.SE.48001: Flags [S.], seq 323429751, ack 2810750937, win 14600, options [mss 1460], length 0
01:02:07.967524 IP Madame.Update.UU.SE.48001 > Psilocybe.Update.UU.SE.http: Flags [.], ack 1, win 5840, length 0
Notice how I get two SYN-ACK packets in quick succession from Linux. I ack both, and connection is established. But is there any sane reason why Linux would SYN-ACK twice, and the second one more than a second after the first.
I should point out that the tcpdump is being run on Psilo (the Linux box in question), so the packet definitely found its way to Psilo, so I don't think lost packet is the answer. Also, it is very repeatable.
Second issue. During a session I see the following. Data transferred from RSX to Linux:
01:10:23.065711 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 17521:18981, ack 27, win 5840, length 1460
01:10:23.065715 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 18981, win 52560, length 0
01:10:23.106052 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 18981:20441, ack 27, win 5840, length 1460
01:10:23.106055 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 20441, win 55480, length 0
01:10:23.146201 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 20441:21901, ack 27, win 5840, length 1460
01:10:23.146205 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 21901, win 58400, length 0
01:10:23.181855 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 21901:23361, ack 27, win 5840, length 1460
01:10:23.181859 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 23361, win 61320, length 0
01:10:23.215162 IP Madame.Update.UU.SE.http > Psilocybe.Update.UU.SE.54009: Flags [.], seq 23361:24821, ack 27, win 5840, length 1460
01:10:23.215166 IP Psilocybe.Update.UU.SE.54009 > Madame.Update.UU.SE.http: Flags [.], ack 24821, win 62780, length 0
Notice how Psilo ACKs every fricking message immediately. No delayed ACKs at all. And the announced window is plenty larger. I could have sent another 30 messages before that window was exhausted.
I could possibly believe that in todays world a window of 50K could be considered "almost exhausted" and so immediate window updates when possible, but it do seem a bit silly, and spams the network with lots of unneccesary ACK packets here.
Any thoughts, opinions or knowledge always welcome.
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
I can not speak for VMS, but I can speak for NT and Tru64.
The official (standard) DEC SCSI (and Sun Solaris) controller was based on the QLogic device in ISP*40/50/60/80 boards. I do not remember why we picked them, there must have been features that Adaptec did not support that Qlogic did. My memory is they were "triple" board that supported Network, SCSI and something else -- ???floppy maybe??.
At the that time ( mid late 1990s ) NT did not work/support/was qualified with the Qlogic (NT only supported the NCR, LSI/Buslogic and Adaptec chips). Thus DEC had to ship the 2940 based in the Alpha/NT systems. This forced the boot ROMs from then on to have the code to deal with them. IIRC from Turbo lasers on that code to support Adaptec SCSI chips was "in there."
At the time, I do not believe the Tru64 SPD officially support them (I do not remember the details - there was some issues with fail-over on TruClusters), but the OS could recognize them, and even boot from them and a lot of smaller machines, particularly repurposed Alpha/NT systems ran that way (the Tru64 based Alpha on my own desk in MRO & ZK0 had one in it -- as did most if not all of them in our Lab).
When we trying to build the $1K Alpha (i.e. we replaced the Compaq based AMD K8 with and EV6 - long story), we used the Adaptec board so Tru64 could "just work" and I seem to remember there was an issue with Qlogic boards which was never solved. (Too many beers ago, but I know VMS would not boot but I've forgotten why. I think I remember that it was because VMS did not have the native support for the Adaptec chips).
Funny - years later, I do not think I have Qlogic boards in my "museum" - but I know I have 4 or 5 Adaptecs in box somewhere.
On Thu, Feb 14, 2013 at 11:16 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 02/14/2013 11:15 PM, Cory Smelosky wrote:
> Mine are pretty much like those, except the internal connector is
> parallel, they work with VMS, and they're not parallel SCSI inside.
If they're not parallel SCSI inside, then what are they?
The ISP1080 (I think you mentioned your board is ISP1080-based) is a
pretty common PCI to SCSI host adapter chip. Nearly all of the required
circuitry is on that chip.
What Gregg was looking for was, I think, something from the Adaptec
AHA2940 family. Different chip, same basic idea, just as common, but
incompatible at the register level.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
