Some information from a newsgroup post in regards to mice connected to KVM (Keyboard/Video/Mouse) switches (it provides a potential scenario when this event may occur):
"The PS/2 specification states that the mouse should not be connected or disconnected whilst the system is powered up. What happens is that shortly (500ms?) after system power-up or cold reboot, the 8042 port interface issues an initialisation command to the mouse. If the mouse is subsequently unplugged, it will obviously lose its current internal status information. When the mouse is re-connected, it gets powered up again. A lot of mice do not work correctly following power-up
until they receive the initialisation command, though the port won't send this as it only does so during reboot system initialisation. Many of those switch devices are nothing more than a basic switch, so the mouse does get disconnected during a switch-over, hence causing this problem.
Some mice, however, behave a bit better. One such example is the Microsoft "Mouse Port Compatible Mouse 2.0A" (or at least my particular one). This mouse issues a RESET command to the 8042 when it powers up on re-connection, then starts functioning using default tracking rates, etc. The result of this is an event log information entry "i8042prt: An unexpected RESET was detected from the mouse device" and a responsive mouse cursor. The tracking rate will probably be to cock though, and adjusting this under the "mouse" control panel icon will probably give inconsistent results which will then change upon the following reboot. The i8042prt driver probably negotiates the proper tracking rate with the mouse during initialisation at boot time. It is also probable that i8042prt sends an initialisation command to the mouse when it starts. Unfortunately, however, this driver does not support loading and unloading so you can't actually make it re-initialise without
rebooting. (Even if it did you would struggle, as unloading it would disable both the keyboard and mouse, rendering the console unusable)."