Is it possible the 2024 install is missing a number of fixes?

350 views
Skip to first unread message

terry-...@glaver.org

unread,
Apr 29, 2024, 2:04:43 PMApr 29
to [PiDP-11]
In my earlier "Re-visiting my PiDP-11 build" post I mentioned starting with a blank slate (actually, SD card) with the newest Raspberry Pi OS and a fresh install of Oscar's PiDP-11 using Option #2 from the "pidp-11-building-instructions" document.

I mentioned there that I was having even worse behavior with the rotary switches than with the original beta software. Back then, the only issue was the LEDs cycling in the reverse direction from the knob rotation. With the newest software, rotating the knob via a single detent will advance the LED 0, 1, or 2 positions in a random direction. At that point I asked if perhaps one of the fixes wasn't merged to the current install kit.

Today I came downstairs to my office and found the front panel completely off. I had been running RSTS/E DISPLY on the "console", so I don't have a clean error message. But there's enough there to show that indeed, the console process died:

RSTS V10.1-L RSTS/E V10.1    Status on 29-Apr-24 02:00 PM  Up: 18:08:33
   100.0%User,     .0%I/O,      .0%Exec,     .0%Idle,     .0%Lost
istorybuffer_idx2pos: Assertion `idx < _this->endpos' failed.es
localhost: RPC: Unable to  SR            = Connection refused (in .//../../../07.0_blinkenlight_api/blinkenlight_      .5nt.c, line 296)

Which sure looks like one of the old-time bugs. My original beta software usually made it several months between console crashes.

I don't know if enough people are doing new installs and/or running their PiDP-11's 24/7 to have noticed this.

Can someone "in the know" take a look and let me know what I should try or do?

Hopefully it is something simple like "just recompile everything - the binaries are out of date", but I don't want to get further away from a known state before getting expert advice.

oscarv

unread,
May 1, 2024, 10:40:02 AMMay 1
to [PiDP-11]
Terry,

On Monday, April 29, 2024 at 8:04:43 PM UTC+2 terry-...@glaver.org wrote:
Which sure looks like one of the old-time bugs. My original beta software usually made it several months between console crashes.

I don't know if enough people are doing new installs and/or running their PiDP-11's 24/7 to have noticed this.

Can someone "in the know" take a look and let me know what I should try or do?

That would be me! Hmm. I took the source code as it was , the fixes 'should' be in. There's only one way to be sure. Let me double check and report back!

Kind regards,

Oscar.

Neal G.

unread,
May 2, 2024, 1:39:19 PMMay 2
to [PiDP-11]
Terry,

The "Connection refused" seems like it is some new or different issue. It is not like the old front panel freeze issue.

My PiDP-11 runs 24/7 using the original 32bit distribution on a Pi-2. About every 45 days, I find the front panel frozen. When this happens some LEDs are on, some are off, in whatever state they happened to be in when the front panel froze. There's no error. If I stop and restart the "client11" by itself, it has no difficulty connecting to the "server11" process. Stopping and restarting the "server11" process cures the problem. It is not a huge problem, just an occasional annoyance, as I typically let IDLED have control of the front panel and use a separate "background" SimH instance to host RSX-11M. This allows me to restart the front panel as needed without disturbing RSX or anything else I have running on the Pi.

- Neal G.

Malcolm Ray

unread,
May 2, 2024, 5:35:18 PMMay 2
to Neal G., [PiDP-11]
It would be interesting to know what strace -p says about the server process when this freeze happens.
--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/a0ed1745-e004-47c0-80a4-e48e2f059314n%40googlegroups.com.

sydn...@gmail.com

unread,
May 5, 2024, 12:33:36 PMMay 5
to [PiDP-11]
Neal, I have the same issue. Consistently, about every 45ish days, the front panel freezes. I restart the PiDP-11 and the countdown to another freeze begins anew! 

Bob

terry-...@glaver.org

unread,
May 6, 2024, 8:38:09 PMMay 6
to [PiDP-11]
I just had another front panel crash. Since I intentionally wasn't running anything on the PDP-11 "console", I was able to obtain the full set of error messages:

server11: ../../07.0_blinkenlight_api/historybuffer.c:128: historybuffer_idx2pos: Assertion `idx < _this->endpos' failed.
localhost: RPC: Unable to receive; errno = Connection refused (in .//../../../07.0_blinkenlight_api/blinkenlight_api_client.c, line 296)

Presumably the fist line is the front panel process dying, and the second is the simulator noticing that the front panel disappeared.

This is on a clean install of Raspberry Pi OS (latest, 64-bit) on a fresh SD card on a 4GB Pi 3B+ with the PiDP-11 installation done with "Option #2" from the current version of the assembly instructions. This happened less than a week after the simulator was started. I don't know how much less as I was away picking up actual DEC hardware 8-}

terry-...@glaver.org

unread,
May 10, 2024, 11:15:01 PMMay 10
to [PiDP-11]
And it happened again today, with a Pi uptime of less than 24 hours.

Oscar, when you get a  chance can you grab the latest 64-bit Raspberry Pi OS, apply all updates, then use your "Option #2" installation script and see if it happens to you? It shouldn't take more than a few days.

Johnny Billquist

unread,
May 10, 2024, 11:39:49 PMMay 10
to pid...@googlegroups.com
I think it's a well known fact that the front panel sometimes crash out.
I haven't had the energy or time to look at it. Others have tried to fix
it, and improved things, but there are still some bugs in there...

Johnny
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/8590cab7-8bb8-4124-9707-fb5f9ae4293bn%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/8590cab7-8bb8-4124-9707-fb5f9ae4293bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

terry-...@glaver.org

unread,
May 11, 2024, 4:08:50 PMMay 11
to [PiDP-11]
True, but my 2018-era software installation (Raspbian + the beta version of the PiDP-11 software) regularly ran for 45-90 days between front panel crashes. It's now down to a week or less.

Also, the knob rotation was backwards but predictable on that beta version, but now one click of the knob produces a shift of 0, 1, or more LED positions in a random direction.

I'm wondering if something has just gone terribly wrong in the 2024-dated "Option #2" instructions or files.

I suppose if nobody else is seeing this, I can try recompiling the whole thing from scratch - perhaps linking with out-of-date libraries is causing an issue.

terry-...@glaver.org

unread,
May 13, 2024, 11:39:30 PMMay 13
to [PiDP-11]
and again:


server11: ../../07.0_blinkenlight_api/historybuffer.c:128: historybuffer_idx2pos: Assertion `idx < _this->endpos' failed.
localhost: RPC: Unable to receive; errno = Connection refused (in .//../../../07.0_blinkenlight_api/blinkenlight_api_client.c, line 296)

Would it be possible (until / unless this error is found and possibly fixed) to have the part that's dying (I think the front panel process) restart itself (maybe "respawn" - I'm not a Linux person) and the part that's then complaining about the missing process just retry the RPC until the part that died restarted?

OTOH, My PiDP-10 has been up longer than this and hasn't exhibited this problem (with the exact same Raspberry Pi OS version) so maybe it was fixed for the -10 but the fix didn't make it back to the -11? Or are the blinkenlight code bases so different that this isn't relevant?
Reply all
Reply to author
Forward
0 new messages