[johnnym]

Got my first ambiguity here:

I consider it a good commit when:

• booting to the login prompt works
  
• login works
  
• uname, machine and sysctl hw work
  

Bad commits usually mount the NFS file systems but give bus errors, illegal instruction or segmentation faults when going through /etc/rc.

Now with a39c18f28d16b1a61658f6ce07a74bc58176db30 applied the Indigo² hangs after mounting the NFS root and the NFS swap (the NFS server logs it as "authenticated mount requests"). And I remember that I've seen something similar on my Octane when getting the commits together for the sgi-is-alive-at-7.2 branch, it didn't happen after applying a specific commit - of course I didn't log that one . So from that I can't really say if this "badness" is related to my actual issue for IP28 and OpenBSD 7.2.

In the end I decided to define it as bad commit - well, it didn't boot until the login prompt - but I now think that was wrong. That because:

• Nobody claims that a kernel will always work correctly for each and every commit
  
• That issue seems to have been solved later on, because although the bad commits so far are bad in the sense of the description, they all didn't hang after mounting the NFS shares
  

So making it a good commit would have set the "left" border ("good" commits) a little closer to the "right" border (bad commits). It could be that I am working now on the wrong half. Well, if it doesn't give a reasonable result, I can still start the bisecting with that ambiguous commit as good, but will cost me hours...