v0.9.9 takes very long to initialize I/O interrupts in SysCheck 2.45.

[TzOk83]

With the new release, it takes very long in CheckIt to "initialize" I/O interrupts, sometimes it hangs a step before, on checking modem on COM2. I'm running on Micro8088, with PT8010AF chipset and NEC V20 CPU.

---

Correction - SysCheck, not CheckIt

[skiselev]

I am unable to reproduce this issue on my system. Moreover, I don't remember touching anything related to serial ports in the BIOS, and it doesn't do much with serial ports anyway.

I don't have a modem connected to the serial port, but serial port tests work fine on my system - both with and without a loopback. I don't see any delays when initializing interrupts or anywhere in the test.

I recommend checking the following:

• Make sure that there are no I/O ports or interrupt conflicts between your modem/COM2 and other cards in the system
• Try removing and reseating all the cards into the backplane

[TzOk83]

I don't have a modem or nothing else connected to the MultiIO card, that's just the message is being displayed in CheckIt. I have 2 switchable BIOSes on my Micro8088, one is this, and the other is GLaBIOS, and on the latter one, CheckIt starts without problems. Furthermore, I don't think it is related to modem nor COM port, more to the next step, which is determining IRQ binding. If it reaches this phase it takes very long to complete, while normally you wouldn't be able to even see those messages. The problem was not occurring on the v0.9.8 BIOS.

---

Sorry, my mistake - it was SysChk, not CheckIt.

[skiselev]

I indeed can reproduce this issue on my system with both 0.9.9 and 0.9.8 BIOSes. So it doesn't seem to be related to any changes in 0.9.9. More work needed to understand what exactly SysChk is doing when it "initializes I/O interrupts"

[TzOk83]

As far as I understand, it tries to determine available IRQs and hardware associated with them.

[skiselev]

Yes. In SYSCHK.DOC, it actually says that "Detecting interrupt usage for the parallel and serial ports can often cause the system to hang under certain conditions". I was checking a few things, and here are some findings:

• The hang does not happen if the UART is disabled (or removed). So it definitely related to the SYSCHK trying to do something related to the UART
• The SYSCHK seems to probe various ports... This is probably not the safest thing to do. At least two side effects of that:
  1. The serial port detection in GLaBIOS will fail after running SYSCHK (run SYSCHK, warm reboot). To be more precise, the GLaBIOS serial port is not robust enough: https://github.com/640-KB/GLaBIOS/issues/28
  2. It breaks the NE2000 packet driver, at least it stops working until the system is rebooted
• It doesn't seem to be the PIC configuration the PIC interrupt mask or the UART configuration... At least the PIC configuration and mask seems to be the same between two BIOSes. The UART detection code is different, although I tried using one from GLaBIOS, and that didn't help
• I checked the UART service routine, UART initialization code (INT 14h, AH=00) that SYSCHK calls, and I can't find and significant differences in the behavior (same values are written to the UART)

[skiselev]

It took me a few hours to get to the bottom of it.

TL;DR: There is nothing wrong with 8088 BIOS or GlaBIOS. The problem is in the SysChk. As I mentioned in my previous comment, SysChk documentation specifically says that "Detecting interrupt usage for the parallel and serial ports can often cause the system to hang under certain conditions". Congratulations are in order, you've found these conditions! 😄

Long description:

• SysChk does not even attempt to run the "Initializing I/O Interrupts" function on a system with GlaBIOS
• The deciding condition seems to be the "feature information" byte from the "system descriptor table" returned by INT 15h, AH=0C0h. SysChk checks bit 1 from that byte, and if it is set (normally indicating that the system has a Micro Channel bus), it skips the "Initializing I/O Interrupts" function
• GlaBIOS does not implement that function, and it returns CF = 1, AH=86h, indicating that the function is not supported. SysChk does not care for that return code, and it appears to assume that function always succeeds. So SysChk goes ahead and checks the feature information byte located at ES:BX+5. But since the function is not implemented it does not change ES:BX. Therefore SysChk uses ES:BX = 0000:0000 at the system descriptor table address, apparently the value that it has there prior to calling the function, and by a random chance, the byte at the 0000:0005 address (a part of INT 1 interrupt vector) has bit 1 set... So SysChk assumes that it is an MCA system and skips the IRQ probe...
• Now, it is a good question why "Initializing I/O Interrupts" hangs. Two factors seem to contribute to this:
  1. The unused IRQ signals on ISA bus are floating, and are generating spurious interrupts. Normally unused IRQs are masked at the 8259 PIC, and in case if they are not, they will be masked by BIOS (see int_ignore subroutine in bios.asm)
  2. SysChk, as a part of the "Initializing I/O Interrupts" routine, replaces the default BIOS IRQ handler with its own, and unmasks IRQ3, IRQ4, IRQ5, and IRQ7, as the result the processor starts to get multiple spurious interrupts. Instead of masking these interrupts right away, SysChk leaves them unmasked, which at some point, seem to result in a stack overflow due to nested calls to the interrupt service routine...

What to do about it:

• Since it is not a bug in the BIOS, I will not fix it. (There is no good workaround in BIOS either. I can remove INT 15h 0C0h, but there are some good uses to it, so I don't want to do that. I also don't want the system to lie about being an MCA system)
• If you like to use SysChk, run it with /I option. It will disable the I/O IRQ detection
• You can try getting in contact with the SysChk author, causing him some nostalgic feelings, and asking to take a look at the issue... Maybe also he will open-source the code while he is at it 😉
• You can also modify your system and add weak pull-downs (say 10k) on IRQ lines, so that these lines will not float when they are not driven by any peripherals

[TzOk83]

I went for the last option and added 10k pullups on IRQ lines on the ISA backplane. It was a good choice. Not only SysCheck now works, but it also greatly improved overall system stability. The system boots every time (previously it was sometimes freezing without any bus activity), with any clock speed, and with any combination of ISA cards.