Now thats unexpected: The freeze was triggered by the bios "Turbo switch function". If that function is turned on, which is default, there is a ~200us burst of activity on the CPU M/IO# line every ~400ms. During that time, the 82C495SLC LMCS#/KBCS# line goes nuts. Those two lines are or'ed together to form the keyboard controllers CS# line. If both are low, then the keyboard controller is activated to read/write data from the ISA bus. And as I don't press any keys, that obviously should not happen. But it does, and so the keyboard controller gets activated a dozen times every ~400ms and apparently reads data from the bus thats not meant for it. This is more likely while a sound card is playing sound effects. And as far as I've learned, there are notifications caused by security related keyboard controller control commands that will trigger INT1.

Once the "Turbo switch function" is disabled in bios, the strange bursts on M/IO# are gone, and so are the frequent chip selects of the keyboard controller. No more INT1 and no more freeze. Most interestingly, even if the option is turned off, the turbo switch still works. So I suspect the bios I've installed somehow doesn't match the board/chipset, although it is clearly from an OPTi 82C495SLC board. I'll have to try the old bios.

I've attached a screenshot of such a "burst". The blue line is M/IO# and the yellow line 82C495SLC LMCS#/KBCS#. It seems to me that there is some low frequency noise in the 10khz range overlayed here. I have yet to figure out if thats caused by poor probe connections or a real problem. That noise might even be the root cause (and not the "burst" itself).

Some quick thoughts:

The keyboard controller has a long history of being used as a "miscellaneous control" device: A20 gate, fast reset, etc. It's not uncommon for the keyboard controller to also be involved in the turbo mode control logic.

I would place good odds that the periodic activity you're seeing is the BIOS SMM handler communicating with the chipset and/or keyboard controller. Probably to check either (1) for the turbo mode enable/disable hotkeys or (2) examine the I/O lines attached to the keyboard controller, one or more of which might be tied into the turbo mode functionality.

Since you have access to a logic analyzer / scope, try checking the SMIACT# pin of the CPU and see if it is active during these mysterious keyboard controller accesses.

That sounds like a reasonable explanation. It had to be BIOS code being executed by an interrupt every~400ms, as these accesses began right before booting DOS but not before POST had finished.

The AMI "Turbo Switch Function" is not as self explanatory it seems. In the book "The BIOS Companion", I found the attached excerpt that indicates that this function may actually be related to A20 gate switching and it has nothing to do with the turbo button. It wouldn't make sense on this board anyway, since according to the 82C495XLC datasheet, the turbo button input pin is ignored in 486 mode. And as far as I've been able to trace the actual turbo button, it seems to effectively disable the CPUs first level cache.

Meanwhile, I burned the attached Mr. BIOS. Its meant for a 82C495XLC, but seems to run perfectly fine on my 82C495SLC chipset. I haven't had any crashes or lockups since. Even though I can't run 0 RAM read waitstates anymore with this Bios (I have 8x1MB 70ns), benchmark performance is still noticeably better. And the Bios has native support for 32 bit IDE block transfers, which gives me even 1MB/s more IDE speed in DOS than the controller manufacturers tool "wbide.exe" tool/driver (4.7MB/s now, which I consider pretty good).

Oh, and since I've gotten rid of these keyboard controller accesses, it also runs way cooler. I bet these not only caused random controller functions being called that sporadically triggered INT1, but they also caused bus conflicts that lead to high sink currents in the controller.