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

[terry-...@glaver.org]

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]

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.]

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]

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]

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]

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]

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]

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]

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]

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?

[Dylan McNamee]

Today I decided to revisit my "ancient" PiDP-11 build, and it still seems the current release doesn't have these fixes (front-panel lights freeze, odd behavior of rotary encoder). Oddly, the version of historybuffer.c installed by pidp11/install/install.sh doesn't any calls to mutex functions, so the patches provided in other threads don't even apply. I started from scratch "Option 2" approach at the 2024 site: https://obsolescence.dev/pidp-11-building-instructions.html so I thought I'd be good. I'm using Option 2 so I could apply the mutex fixes.

I feel like I've fallen off the intended tracks, but don't know where I went wrong.

I'm running a fresh install of Debian Bookworm on a RPi 3B.

[terry-...@glaver.org]

On Thursday, November 7, 2024 at 1:09:49 PM UTC-8 dylan....@gmail.com wrote:

I feel like I've fallen off the intended tracks, but don't know where I went wrong.

The 32-bit binaries in the 2004 kit have the ""fix", but the 64-bit binaries don't. The

correct source files are there. I forget what you have to do to compile / installl

them, and I'm 3000 miles away from those systems now.

I put "fix" in quotes because it is a band-aid on a cast over a festering wound. The

whole front panel code is crying out for a total rewrite using the newest simh and

its API.

[Flavio Villanustre]

Compiling from source is very simple: just run the installer again and tell it to compile from source (you can tell it to not do anything else, so it doesn't overwrite your existing Operating System images). It should take just a few minutes on a Raspberry Pi 5. After that, just restart the system and the new binary should be running.

HTH,

Flavio

[mike.ni...@gmail.com]

Flavio,

        You're making the assumption that the source contains all of the patches. Oscar, has this been determined to be the case, or is the source lagging behind the patched binaries?

        -- Mike 

[Flavio Villanustre]

Good point! It would be great to have a public repository in a version control system (github, fossil, whatever). That way it would be easy to pull the right branch. The pidp-8 code is exactly like that.

Flavio

--

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 visit https://groups.google.com/d/msgid/pidp-11/f417f433-bd26-414c-a10c-61f4d6425cc6n%40googlegroups.com.

[oscarv]

The suspicion is correct.

and I just posted the fix here: https://groups.google.com/g/pidp-11/c/sviHgH1-OZU/m/BbMMDBr5CQAJ

In the Brain Fog I've been blessed with for the past two years, this old bug re-emerged. And Terri, I think we emailed some time ago about it. The recipe for the fix is now correct. (Famous last words but, yes)

Please let me know if this ends your suffering - if it does, I'll amend the install package.

Yes - I should move it all to github. But in this Fog of mine, every little step is a big one. Very annoying to me, and I know, also for others sometimes :-)

Kind regards,

Oscar.

[Mike Niswonger]

Thanks Oscar!

--
You received this message because you are subscribed to a topic in the Google Groups "[PiDP-11]" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-11/TwxVXFV3ut8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/59906d59-c62c-49cb-856a-5f635ef7b3c3n%40googlegroups.com.

[oscarv]

Eager to hear if this solves the problem.

In another thread, Johnny warned that it might mitigate but not eliminate the problem. But the fix of yesterday was part 2 of two fixes, the other was already in the code. So I'm hopeful that this makes for all PiDP-11s to run stable over long times.

The odd thing of this bug is, it seems to strike some people but most others, not. I ran my PiDP-11 without ever noticing the issue.

Anyway, eager to hear feedback on the fix. I've put it into the test Github repository that I will soon transfer the PiDP-11 in to. After some long test runs, and multiple install tests. With all the changes in Raspbian OS, it's time consuming to test on 3 or 4 Pis with 3 or 4 OS versions.

Kind regards,

Oscar.