It is widely known that Microsoft Windows 95 had a problem with the K6 processor, because the K6 processor executed the LOOP instructions too fast. There is an official patch for Windows 95 OSR2.

I happened to find another affected tool: The Logitech mouse driver, e.g. version 6.02, as shipped with Microsoft Windows for Workgroups 3.11. The symptom is a failure to detect a Microsoft mouse (I don't have a logitech mouse at hand at the moment) connected to a serial port on a fast K6 processor (in my case: A K6-2+ at 400MHz). The root cause is another case of the "LOOP" instruction being fast. The logitech mouse driver calibrates a delay loop during start-up that counts how many loop iterations are performed per millisecond if a loop instruction points back to itself. On the processor I have at hand, that measurements yields a bit below 400.000. It should actually be exactly 400.000, but the measurement algorithm is generally returning low numbers because some measurement overhead is not compensaated for. The issue with the mouse drive is that this value is (as it is common on 16-bit software) truncated to 16 bits. The original measurement routine counts that around 180450 loops of 110 iterations can be executed in 55ms, so this means around 360900 iterations per ms. This value is truncated to 33220 iterations per ms, which is less then 10 times the correct amount.

The way to detect a MS mouse is to power up the mouse by asserting the modem control singal DTR (the mouse is powered from this line), then wait "a short amount of time" for the power and oscillator of the mouse, and then assert RTS to release the mouse processor out of reset, and wait for the mouse to send an "M" character, which is commonly understood to mean "Microsoft" or "Mouse". The logitech driver has a 50ms timeout while waiting for an "M". As the mouse is running at 1200Baud with 7-n-1, the time to transmit that character is around 8ms. So after releasing the mouse processor out of its reset mode, it takes some firmware-dependent time for initialization of the processor plus the transmission time of 8ms for the "M" to appear. As the loops per iteration are less than a tenth of what they are supposed to be, the 50ms timeout turns into a 5ms timeout, which has no chance of receiving a character.

So, moral of the story: Use a different mouse driver for serial (Microsoft-compatible) mice on K6 processors.