There's probably not many programs that can do this, otherwise it wouldn't have been such a pain at the time to solve the types of problems you're having.

You can't "probe" an IRQ to know what device is using it, you can only identify a device and then via some proprietary mechanism (maybe) figure out what settings it's using, or use PCI or ISA plug-n-play if the cards are new enough, which is just a standard way of doing the same thing.

Your best bet is to probably find some manufacturer configuration or setup program for both of your cards and run that to see if it will tell you the current configuration.

Otherwise you'll need a program that is aware of both those cards, so it knows how to query the resource info. Possibly the only one is an old version of Linux, if it includes drivers for both cards. If you can boot that and load the drivers, then you can query the kernel to see what hardware resources are in use. Note that 386 support was removed from Linux a while back, so it will have to be an older version.

I'm not aware of any DOS program that can do the same. There are a few that come close, like MSD (Microsoft Diagnostics) that came out with DOS 6, but like all programs it will only provide limited info, and possibly none at all about hardware it isn't specifically designed to detect.

I assume you've tried all the usual troubleshooting steps? Different slots, cards work fine one at a time, etc.

I'm using both SCSI cards you have in my 386 based systems:
- Adaptec AHA-1520B with Sound Blaster 16 CT1740
- Adaptec AHA-1540CP with Sound Blaster AWE32 PNP CT3670

In none-PNP systems, I generally disable the cards self-setup features and use jumpers, whenever possible. With 1520 and 1740 I did just this. And for the 1540 and 3670 couple, I configured AWE32 with its own utilities and again configured 1540 manually with jumpers. Both working correctly now (these machines also have 3com ISA NICs which also have been configured by their utilities, and their auto configure features disabled). I don't really remember at the moment if I used CTCM or Intel's PNP configuration utility in my autoexec.bat, though.

I remember about using some version of Check-It and MS System information tool (that came with DOS 6.22) for seeing the I/O address, memory ranges, DMA channels and interrupt usage during the times, but I believe there is some slightly modern software for doing this now, like DOS verisons of Aida, Astra and HWinfo.

By the way, you said IO addresses and interrupts are ok in your setup, but you need to check DMA configuration, too (considering DMA utilization is the only difference between 1520 and 1540).

For what it is worth.... Touchstone's Check'it Pro suite.

This download is the 1993 release 1.11:
Check'it Pro at REMOVED

The 7z package contains two diskette images that you can install to harddisk using registration key
[AS-171677]

As far as I know the 1.xx release versions are picky about the hardware they have to diagnose.
When running into unknown/later hardware they tend to hang easily.

I had already set the SCSI card to available IRQ, I/O, and DMA channel. I was able to solve my problem with the ESS sound card not working simply by putting the 1540CP SCSI card into a different ISA slot. I don't understand why the 1520B worked fine in a certain ISA slot, but not the 1540CP. The 1540CP card works fine now with one exception, when I exit Windows 3.11 (to go back into DOS), the system hangs at a blinking cursor. After a minute or so, a message is displayed about not finding COMMAND. The keyboard also doesn't work. A hard reset is the only way to get DOS functional again. Any ideas what is causing this? The 1520B does not have this problem.

After performing some disk bencharks, the 1520B is 10-50% faster than the 1540CP, depending on the benchmark. I have the 1540CP set at DMA 5.0 MB/s transfer speed.

Regarding performance: ISA DMA is slow.
http://wiki.osdev.org/ISA_DMA
"ISA DMA is slow - theoretically 4.77 MB/second, but more like 400 KB/second due to ISA bus protocols;"
https://en.wikipedia.org/wiki/Direct_memory_access#ISA
"Due to their lagging performance (2.5 Mbit/s[3]), these devices have been largely obsolete since the advent of the 80386 processor in 1985 and its capacity for 32-bit transfers."

The usefulness of ISA DMA is not throughput performance, but freeing the CPU of the task. As long as the throughput is adequate (floppy disk transfers, printing, wave sound) that's fine. (16-bit 44.1KHz stereo needs 176kB/sec, floppies are slower.)

MSD

is useful.

Speedsys indicated the linear read speed for the DMA-SCSI controller (1540CP) at 2120 KB/s, whereas the non-DMA SCSI controller (1520B) at 3040 KB/s. Makes me wonder the usefullness of less CPU overhead of the DMA controller.

The 1520B controller does have an area in its BIOS to select the DMA channel, however I do not know to what extent DMA is being used on that controller. There is no DMA transfer speed option to select.