[johnnym]

Another update, two things this time:

1. I now also tested with a R10K equipped Octane (both dual 195 and single 250 MHz processors) and I didn't observe any problems there during bootup. So it could indeed be a problem specific for IP28 with 7.2 kernel (as said, with 7.1 bootup was fine, see this dmesg).
   
2. I did manage to get segfaults for the R10K Indigo² in single user mode, too, now, after some fiddling. I don't yet recognize a systematic here unfortunately. But my initial assumption, that this would only affect multi-user mode, hence was wrong.
   

You can also sign up for gitea and post patches there if you prefer to keep it within our community. It's entirely up to you

Actually I'd like to keep this on GitHub, also because my other stuff is all there. But if people want to fork it here, that's cool, too. Just make sure to create PRs on GitHub for any changes you want to be added there.

[Raion]

That's fine. GitHub is not my thing hence why I run my own gitea.

[johnnym]

That's fine. GitHub is not my thing hence why I run my own gitea.

Yeah, I understand. I'm just too lazy to run something like that myself and the time needed for it I can use for other stuff (same thing as for CVS versus git for me).

[Raion]

CVS and SVN are outdated, for sure. Fossil, Mercurial and Git are far better.

[johnnym]

Got a working reproducer that can be used in single user mode to trigger the issue:

Executing /usr/sbin/sshd seems to change something important, because afterwards executing binaries that ran perfectly well before leads to segfaults, bus errors or illegal instruction faults (depending on userland and boot from disk or network). Things that keep working afterwards are the running shell and commands like halt and reboot.

This is reproducible for both boot from disk and boot from network and for both OpenBSD/sgi 6.9 and /octeon 7.2 userlands. I've detailed things in this issue over at GitHub.

Not sure what to do next. I don't think I can bisect between two branches (sgi-is-alive-7.1 and sgi-is-alive-7.2), also because of the way I restored sgi functionality on top of the respective release commit. Unless I start from 7.1 and apply the patches in each bisect step - that could take a while...

[Raion]

Put dropbear SSH in and run it from inetd, see if that gets things going?

[johnnym]

Put dropbear SSH in and run it from inetd, see if that gets things going?

Please understand that I don't have an access problem - I always have access via serial console and both sshds (one time from an OpenBSD/sgi 6.9 userland, other times from OpenBSD/octeon 7.2 userlands) trigger the same issue for the same kernel and there are no such errors/faults for the 7.1 or 7.0 kernels - this leads me to believe the issue lies in the OpenBSD/sgi 7.2 IP28 kernel alone.

Executing sshd must touch something in the kernel (socket functionality maybe?) that makes it loose its ability to run (certain) binaries correctly.

This thread here describes something similar I think. IIUIC there the problem was a wrong assumption in the kernel code that lead to illegal instruction faults on perfectly normal binaries when the OP activated a specific option in the BIOS setup of the affected machines. It's not the same problem as I have at hand, but it's similar enough IMHO.

[Raion]

I'm afraid I don't have an understanding of what the problem is then.

OpenBSD is not something I run regularly, so I'm not familiar with the nuances of it because a lot of it feels really primitive but would it be out of the question to perhaps try to ask on their mailing list and see if they can advise further?

It's a shame there's no more bitrig or other OpenBSD forks worth a damn, maybe you could have found somebody willing to help you with the maintenance

[johnnym]

Made some progress since my last post:

Guess what: if you do not intend to build LLVM/clang for OpenBSD/sgi userlands, you can do the whole userland build on a dual 300 MHz R12K driven Octane with 2 GiB of RAM in just a little more than 12 hours! Much better than 110 hours plus extra (for the parts that were not build after I did not continue the build process).

It then took another 10 hours to make the actual release files (sets, kernels (needed to be made again, respective Makefile patched to make use of the second processor), RAMdisk kernels (repective Makefile unfortunately not yet patched, so needed extra time for this run because it was done in serial), boot loaders and CDROM ISO) out of the userland created earlier.

So I now have an OpenBSD/sgi 7.0 userland available which includes the usual files (minus X) that were available in the past, e.g. on https://ftp.eu.openbsd.org/pub/OpenBSD/6.9/sgi/

I still need to test this, but at least during compilation of the files for the userland and release LLVM/clang wasn't needed, so it might indeed be save to do without on OpenBSD/sgi.

---

I'm afraid I don't have an understanding of what the problem is then.

Oh, ok, I thought I did provide a good description on https://github.com/the-machine-hall/openbsd-src/issues. Well, it's not IRIX, of course and I might also be bad in explaining things. 

OpenBSD is not something I run regularly, so I'm not familiar with the nuances of it because a lot of it feels really primitive

This is actually what mainly adds to the charm of it. Its simpleness greatly helps to understand its workings. The complexity of common GNU/Linux distributions is no comparison in this regard.

but would it be out of the question to perhaps try to ask on their mailing list and see if they can advise further?

Well, in the end I might do that, but I don't expect to get too much - if any - support there, because they already have enough to do with the architecture ports they offer and support. And running a reinstated port based on reverts and adaptations voids their warranty at multiple places I think. 

It's a shame there's no more bitrig or other OpenBSD forks worth a damn, maybe you could have found somebody willing to help you with the maintenance

Indeed. Actually I also came here (and also to the sgi.sh forums) with this topic because I'm in need of testers for all the machinery I don't have available. Hence I'd be really grateful for people with the following machines:

• Tezro (uses the IP27 kernels)
  
• Fuel (dito)
  
• Origin 350 (dito)
  
• R12K O2 (uses the IP32 kernels)
  
• R4K Indigo² (uses the IP22 kernels)
  
• R8K Indigo² (uses the IP26 kernels)
  
• R5K Indy (uses the IP22 kernels)
  
• R4K Indigo (dito)
  

...to test the kernels (and in the future also userlands) I have available on GitHub (linked from the original post).

[Raion]

I admire this project because I know from experience how trying to support a single architecture in a niche project can be a challenge. I have my own pet OS that I am working on, off and on.

Honestly if the OpenBSD guys aren't willing to help at all I think the best opportunity would be to join forces with another project that has interest in maintaining an openbsd port and sharing resources between the two.

A tezro running an IP27 kernel? Interesting.