I'd need the NVR folder as well.

OK, here you are.
nvr.zip

This looks like a bug with the IBM MCA ESDI controller.

I've tried to install AIX again on recent build, this time on SCSI. Result is "Error in obtating information on hard disk drives available" (this issue was on earlier builds also). NVR and configs included.

nvr+cfg.zip

I think AIX doesn't support the current emulated SCSI cards, iirc it only supports the IBM SCSI card, which is not emulated and also poorly documented.

Well, documentation for IBM SCSI adapters is harder to find, but at least that's not 8514 adapter. Here's technical reference for IBM PS/2 SCSI Adapter with Cache: http://www.mcamafia.de/pdf/ibm_scsiwc_trm.pdf

The IBM PS/2 SCSI Adapter is going to be implemented in v2.10 based ont he technical reference manual.

Well, I'm glad I made a contribution, but I'm going to return to question of ESDI: is it going to be fixed?

The IBM ESDI controller is going to be fixed at some point in the future.

I'm still getting the kernel trap bug with the IBM MCA SCSI controller selected...

Attempted to reproduce this bug but could not find a version of IBM AIX 1.3 that was bootable, with the one I found on WinWorld having "Non-system disk or disk error" for the ESDI boot disks and install disk.

Attempted to reproduce this bug but could not find a version of IBM AIX 1.3 that was bootable, with the one I found on WinWorld having "Non-system disk or disk error" for the ESDI boot disks and install disk.
https://mega.nz/file/FA9GRQLJ#Mg5p8O032DB7legV2rShvgjMAS0qkVyflDDLHWl6DNc

Thank you for the link! These disks are bootable this time. I think I'm getting the same issue with ESDI but I'm not sure to be honest, because it gets partway into the boot process and then immediately reboots before I can read what the error onscreen is. It at least gets to this point first:

Thank you for the link! These disks are bootable this time. I think I'm getting the same issue with ESDI but I'm not sure to be honest, because it gets partway into the boot process and then immediately reboots before I can read what the error onscreen is.

I had to use screen recorder, but here's that screen:

When using IDE configurations with the ISA support from PTF0024 which you have in your disk set there, many boards have a similar kernel trap at roughly the same point in the initial boot as this one for the ESDI PS/2 systems, and some work fine (e.g. socket 2 SiS 461 PS/ValuePoint, socket 7 single voltage hp vectra vl 5 series 4, slot 1 asus p3b-f, slot 2 supermicro s2dge). Is there some kind of difference anyone can spot between these boards that might explain this, maybe not in 86box as such but some kind of firmware/initialization difference? Anyway, I wonder if this is related to the kernel trap on these ESDI configs.

Note that AIX 1.3 with the PTF 0024 update supports some kind of Adaptec ISA SCSI (see the one line note to this effect in the PTF 0024 patch notes). And I can confirm this because it works with the BusLogic driver's AHA-154x compatibility in VirtualBox, but only if you put it in the special undocumented parameter AdapterType "AHA-1540B" mode

VBoxManage setextradata "your vm name here" VBoxInternal/Devices/buslogic/0/Config/AdapterType "AHA-1540B"

which enables a small set of differences -- basically a slightly different board ID and disabling a bunch of commands supported by the BT-958D that the AHA-1540 doesn't have. See the DEV_AHA_1540B cases in https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/Storage/DevBusLogic.cpp. This might be a small set of stuff to try in the 86box impl of AHA-154x's to see if it makes any difference.

No, i don't think any of those BT-958 vs AHA-1540 differences is it, there must be some more preliminary probe that isn't working on 86box, as enabling the ENABLE_AHA154X_LOG output it's not even getting hit at all as the AIX driver passes the point when it would detect the card.

What you need to enable is ENABLE_X54X_LOG instead.

Ah, sorry, I didn't notice your reply there originally; I just noticed now as you made this a discussion.

Ok, with ENABLE_X54X_LOG set, testing with the AHA-154xC:

Starting from the point in the log output where the accesses from the scsi bios are finished and now the kernel is loaded and the actual scsi driver would be accessing it, it sits there reading the signature register over and over for a bit and then gives up.

x54x_in(): 0337, 40
x54x_in(): 0337, 45
x54x_in(): 0337, 40
x54x_in(): 0337, 51
x54x_in(): 0337, 40
x54x_in(): 0337, 45
x54x_in(): 0337, 40
x54x_in(): 0337, 51
...

but these are... not the right values? we are expecting "ADAP", no?

After removing that xor fiddling with the low bits of the signature, we get a little farther: the driver reads the signature exactly once, then reads the status once, which has just the idle bit:

x54x_in(): 0334, 10

and then the driver throws up its Board not really there message and carries on as though it wasn't found and the install fails not finding any available HD.

From experience, this driver gives the Board not really there error when the driver does detect an AHA-154x, but it is not in the state the driver is expecting -- in VirtualBox's AHA-1540B mode the error happens if and only if it's a "warm boot" of the vm, so presumably the emulated reset behaviour over there is not quite right. Since I'm encountering the error here on a fresh start of 86Box my hunch was that the cause can only be the configured state the scsi bios has left the AHA-154x in, and from an absence of anything else this one status call could tell it, I conclude the driver is just expecting the card to be ready for initialization right away at this point and is not seeing that.

So I tried just doing x54x_device_reset() whenever a signature read finishes (rakslice@a05e336) -- and it works, the driver initializes the AHA-154x sees the scsi hd and installs normally.

(All of that is still an irrelevant side issue to the kernel trap that the original issue was about, unless you're looking for workaround options)