roskos@csed-1.UUCP (Eric Roskos) (01/08/88)
In article <921@polyslo.UUCP>, mpatnode@polyslo.UUCP (Mike Patnode) writes: > In article <82@ucrmath.UUCP> baumann@hope.UUCP (Michael Baumann) writes: > > a "trap > 16" message > occurs with Logitech mouse This problem also occurs* with the Microsoft Mouse, iff the mouse driver is actually loaded (via config.sys) before you do a keyboard reboot. I traced this a good bit a few months ago before giving up to concentrate on more pressing things; the easiest interim solution seems to be to not load the mouse driver unless you need it (e.g., use the .COM version). Since I've taken this approach (I almost never use the mouse) I haven't gotten any more spurious interrupts. But it would be better to figure out what the problem is; if only the mouse's control registers, etc. were documented, it would be much easier. The strange thing was, I got these trap messages even if I turned off the PICs altogether (so no interrupts should have gotten through at all). They looked almost as if the mouse card was sometimes driving the bus when it should have been inactive, since they seemed to be random branches (that happened to hit the > 16 message) rather than real interrupts. However, this was just a guess on my part since I didn't have the hardware to look at what was really going on. I also posted a query on it, and also got only one (alas, incorrect) response that it was a spurious serial interrupt. (This is for the bus mouse.) *on an AT