[jan-jaap]

Good to see it's working.

Two quickies:
1. Memory testing takes several minutes. Once you're confident the hardware is OK, you can disable the full memory test by flipping one of the dip switches behind the MSC panel (where the key switch is). I can look up which one. That's how I run my Onyx2 (which has the full 4GB per nodeboard). Oh, what *really* takes forever to POST is nodes with RAM but no (enabled) CPUs. This can happen if you replace the PIMM on a node with a faster one. Then the other nodes have to run the memory test over the NUMA link and it takes half an hour or so. It's usually faster to just pull all but one bank of memory from the board until the CPUs work again.

2. Normally you should spread the memory over the nodes so all nodes have similar amounts of local memory. All CPUs can access all memory but non-local memory is slower (that's the NU in NUMA). So unless you have an extremely specific workload and pin processes to CPUs this is not a good idea.

There's a message about PROM rev mismatches and barrier sync warnings which usually means one of the IO6 or CPU PROMs is a different rev. Most common case is someone swapped out a part, which would also explain the RAM-less node. 'flash' will fix the PROM rev mismatch.

[uunix]

Thanks for this info Jan-Jaap.
<QUOTE author="jan-jaap" post_id="1083" time="1529307077" user_id="183">

Good to see it's working.

Well, getting there, I still have half the 10GB Memory to bring back to life and a nodeboard. It has nothing interesting installed, apart from MIPPSPro 7.4.3, the skins look OK, but also a bit flaky. Still, very interesting to play with.

<QUOTE author="jan-jaap" post_id="1083" time="1529307077" user_id="183">

Two quickies:
1. Memory testing takes several minutes. Once you're confident the hardware is OK, you can disable the full memory test by flipping one of the dip switches behind the MSC panel (where the key switch is). I can look up which one. That's how I run my Onyx2 (which has the full 4GB per nodeboard). Oh, what *really* takes forever to POST is nodes with RAM but no (enabled) CPUs. This can happen if you replace the PIMM on a node with a faster one. Then the other nodes have to run the memory test over the NUMA link and it takes half an hour or so. It's usually faster to just pull all but one bank of memory from the board until the CPUs work again.

Think therefore I may remove all memory from the none-working node and get as much working in the other ones to start with then.
<QUOTE author="jan-jaap" post_id="1083" time="1529307077" user_id="183">

2. Normally you should spread the memory over the nodes so all nodes have similar amounts of local memory. All CPUs can access all memory but non-local memory is slower (that's the NU in NUMA). So unless you have an extremely specific workload and pin processes to CPUs this is not a good idea.

Yes, spreading is what I would have thought.
<QUOTE author="jan-jaap" post_id="1083" time="1529307077" user_id="183">

There's a message about PROM rev mismatches and barrier sync warnings which usually means one of the IO6 or CPU PROMs is a different rev. Most common case is someone swapped out a part, which would also explain the RAM-less node. 'flash' will fix the PROM rev mismatch.

I carried out a flash this morning and the messages have gone. First pass updated one of the boards, and subsequent passes updated none, so they all match.
I wonder does anyone have the techpub on these machines, some things I would like to get straight is the fitting of memory. I have a mixture of Green and Red simms, I have taken to installing first the red, and then populating the remaing with green (I have more green than red), and unsure if this is correct.

Cheers for your help, maybe I should create a new thread on this.

[jan-jaap]

"red" memory is 512MB per kit (of 2 DIMMs)
"silver" memory is 256MB per kit (of 2 DIMMs)
everything else is ... not too interesting.

There's a monster PDF describing the O2K/Onyx2 series which probably has this info: <URL url="https://archive.org/details/Origin2k_Hardware_Guide">https://archive.org/details/Origin2k_Hardware_Guide
NB: if that's the "quick ref booklet" I'd like to know what the in-depth booklet looks like

[uunix]

<QUOTE author="jan-jaap" post_id="1091" time="1529328989" user_id="183">

"red" memory is 512MB per kit (of 2 DIMMs)
"silver" memory is 256MB per kit (of 2 DIMMs)
everything else is ... not too interesting.

There's a monster PDF describing the O2K/Onyx2 series which probably has this info: <URL url="https://archive.org/details/Origin2k_Hardware_Guide">https://archive.org/details/Origin2k_Hardware_Guide
NB: if that's the "quick ref booklet" I'd like to know what the in-depth booklet looks like

Thanks Jan, and yes.. rather in-depth book for a quick guide.

[jirka]

<URL url="https://www.indiegogo.com/projects/gemini-pda-android-linux-keyboard-mobile-device--2">Gemini PDA

[55cancri]

Since half a year I could not use a keyboard on my new DEC 3000/600. I tried two <B>LK401</B> keyboards, both only produced character garbage, could not type a single word, some keys printed the same character and so on ... I saw no reason why it should not work and even have thrown the first keyboard in the trash, because it seemed like every one on the world used their LK401s happily with their DEC 3000s and absolute no information about a problem like that could be found on the internet or the manual ...
... only a small hint in a OpenVMS FAQ ... some keyboards have problems with some DEC 3000 firmware (SRM?) versions. So I bought a third keyboard, a dirty old <B>LK201</B> from 1984 (!) and it finally finally worked. I am happy now!

[dexter1]

One of my companions for the upcoming holidays and holinights.
<ATTACHMENT filename="NatureTrek.jpg" index="0">     </ATTACHMENT>
10x50 BAK4 roofprism. The Manfrotto i bought earlier.
This should be lightweight enough, yet useful for day and night observations.

[55cancri]

<QUOTE author="55cancri" post_id="1203" time="1530046500" user_id="247">

Since half a year I could not use a keyboard on my new DEC 3000/600. I tried two <B>LK401</B> keyboards, both only produced character garbage, could not type a single word, some keys printed the same character and so on ... I saw no reason why it should not work and even have thrown the first keyboard in the trash, because it seemed like every one on the world used their LK401s happily with their DEC 3000s and absolute no information about a problem like that could be found on the internet or the manual ...
... only a small hint in a OpenVMS FAQ ... some keyboards have problems with some DEC 3000 firmware (SRM?) versions. So I bought a third keyboard, a dirty old <B>LK201</B> from 1984 (!) and it finally finally worked. I am happy now!

Now the new LK201 does the same error -__- it just worked the first time. Is there a SRM variable that causes this? can I somehow reset the NVRAM?

I remember that it failed the "NVR - CHECK_BATTERY TEST" at the boot screens that one time it worked. Then I pulled out the RTC-Chip from the board, turned on the machine and I could type again!!!
I could not get far, because of errors, but I could type ... like it is the most normal thing in the world! So, what can I do now? Buy a new DS1287?

[CB_HK]

<QUOTE author="55cancri" post_id="1238" time="1530182423" user_id="247">

<QUOTE author="55cancri" post_id="1203" time="1530046500" user_id="247">

Since half a year I could not use a keyboard on my new DEC 3000/600. I tried two <B>LK401</B> keyboards, both only produced character garbage, could not type a single word, some keys printed the same character and so on ... I saw no reason why it should not work and even have thrown the first keyboard in the trash, because it seemed like every one on the world used their LK401s happily with their DEC 3000s and absolute no information about a problem like that could be found on the internet or the manual ...
... only a small hint in a OpenVMS FAQ ... some keyboards have problems with some DEC 3000 firmware (SRM?) versions. So I bought a third keyboard, a dirty old <B>LK201</B> from 1984 (!) and it finally finally worked. I am happy now!

Now the new LK201 does the same error -__- it just worked the first time. Is there a SRM variable that causes this? can I somehow reset the NVRAM?

I remember that it failed the "NVR - CHECK_BATTERY TEST" at the boot screens that one time it worked. Then I pulled out the RTC-Chip from the board, turned on the machine and I could type again!!!
I could not get far, because of errors, but I could type ... like it is the most normal thing in the world! So, what can I do now? Buy a new DS1287?

If it is the Dallas chip you'll most likely need to mod the one you have to accept an external battery. The weakness of the chip is that not only is the battery sealed inside (as you already know), but it's next to impossible to find a new one. Even if you did, new is relative and the battery may already be depleted.

There are a number of guides posted on the internet about having to modify the chips. It's fairly straightforward and involves using a dremel to make a cut into two pin locations to separate the internal battery and then solder the connection to the external battery holder (CR2032) to those cut pin locations. Overall it's not terribly complex, just tedious. It's something that I've looked into for my GRiD 1520 since they also rely on Dallas RTC.

[55cancri]

<QUOTE author="CB_HK" post_id="1256" time="1530215073" user_id="159">

If it is the Dallas chip you'll most likely need to mod the one you have to accept an external battery. The weakness of the chip is that not only is the battery sealed inside (as you already know), but it's next to impossible to find a new one. Even if you did, new is relative and the battery may already be depleted.

There are a number of guides posted on the internet about having to modify the chips. It's fairly straightforward and involves using a dremel to make a cut into two pin locations to separate the internal battery and then solder the connection to the external battery holder (CR2032) to those cut pin locations. Overall it's not terribly complex, just tedious. It's something that I've looked into for my GRiD 1520 since they also rely on Dallas RTC.

Ok, but the problem is not that the Computer is forgetting its time and ethernet-adress. Everytime the computer thinks the NVRAM is okay, my keyboard refuses to work and when it is complaining or I just pull the RTC out of the socket it works. What is this? I am so frustrated ...
... I just don't see the connection, but soldering a new battery in is the last thing I can do ... but how can that fix the keyboard problem?