A Quality Assurance Engineer's perspective on Neo2 PS/2 Port Problems.

Question

I came here looking for some insight . . . . and while i got some confirmation that it's a common problem, I think some things need to be cleared up.
There's a mistake being made that disconnects cause and effect by lumping together effects that aren't necessarily from the same cause. Don't feel bad, everybody does it, I've just been trained to be critical about it.
I think there is more than one issue. Here's why.
1: I think the chipset or BIOS is cooking the ps/2 mouse data stream (and maybe USB HID data streams as well) when the "BIOS Support for USB Mouse" option is turned on. By this i mean that it's presenting the operating system with a virtual mouse device and working some behind-the-scenes magic on the data between computer and mouse.
My evidence:
With that option turned on, Linux kernel 2.6.12.2 (vanilla kernel.org sources) says this:
Jul 10 19:38:00 type kernel: input: PS/2 Generic Mouse on isa0060/serio1
Jul 10 19:38:00 type kernel: psmouse.c: Failed to enable mouse on isa0060/serio1
Jul 10 19:38:01 type kernel: psmouse.c: Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
And with that option turned off, the kernel says this:
Jul 11 21:58:48 type kernel: input: ImExPS/2 Generic Explorer Mouse on isa0060/serio1
I think this bios option prevents the linux kernel serio driver from allowing the psmouse driver to perform two-way communication with the mouse in the standard way.
Disabling this bios option also makes all my PS/2 mice and trackballs work on bootup, where all of them needed to be re-plugged or have the kvm switch to another port and back before they would work previously.
I think many people are having some of their problems purely because of this bios option.
I think this is very bad, and that the developers responsible for this bios feature should be subjected to a public flogging and sent to a reeducation camp where they might learn to respect the law that the quality of a piece of software is inversely proportional to the amount of magic performed within it.
I can't even think of what the advantage of a virtual PS/2 mouse would be. You want to run DOS with mouse.com driving your usb mouse or something? We're supporting Win95 OSR1 users? I guess it might make Partition Magic boot floppies a tiny bit easier to manage, but sheesh. The damage far outweighs the benefit.
Even when it works, it will only work for fairly plain mice that don't need special protocols to work.
I don't think MSI did this, I think the bios vendor did it, and MSI doesn't realize what's going on.
Yes, I know the Explorer is a USB mouse on a PS/2 adapter, but i started down this road because my Logitech trackball - which uses the MouseManPlus protocol - and it still didn't work right when i replaced the mouse. I have a PS/2 based KVM that I'd like to keep using. The KVM has been out of the loop for these diagnostics.
2: While i admit that it could very well be a PS/2 port power issue, I think it has nothing at all to do with system power supply problems, least of all the 12V rail.
Why? Why on earth would my 5V keyboard and mouse care what's happening on the 12V rail, what's why.
Furthermore, the same KB and mouse mostly kinda/sorta work on a USB to PS2 adapter cable, which is on the exact same 5V rail as the keyboard and mouse ports, and if anything should draw MORE power.
They are however probably on separate fuses.
If it's a power problem, I'm leaning toward it being a slow-blowing fuse on the PS/2 ports that is being pushed near it's limits and is thus rippling. This is conjecture, and only MSI's rework guys or someone with a lot of diagnostic gear can tell you for sure.
3: Having fixed the mouse initialization and synchronization problems, I still have a problem.
I replaced my Lexmark (IBM) PS/2 keyboard with a KeyTronic PS/2 keyboard, replaced my Logitech Trackman Marble FX with a Microsoft Trackball Explorer, and sometimes, I still get an input lockup.
The mouse will just stop tracking in mid-sweep and the keyboard will stop keying.
And then the kernel says this:
Jul 11 23:37:49 type kernel: atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
Jul 11 23:37:50 type last message repeated 54 times
Jul 11 23:37:50 type kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly
Jul 11 23:37:50 type kernel: input: AT Translated Set 2 keyboard on isa0060/serio0
Jul 11 23:37:50 type kernel: atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
Jul 11 23:38:18 type last message repeated 623 times
Jul 11 23:38:18 type kernel: atkbd.c: Unknown key released (translated set 2, code 0x7c on isa0060/serio0).
Jul 11 23:38:18 type kernel: atkbd.c: Use 'setkeycodes 7c <keycode>' to make it known.
Jul 11 23:38:18 type kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly
Jul 11 23:38:19 type kernel: atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
Jul 11 23:38:19 type last message repeated 10 times
Jul 11 23:38:19 type kernel: atkbd.c: Unknown key released (translated set 2, code 0x68 on isa0060/serio0).
Jul 11 23:38:19 type kernel: atkbd.c: Use 'setkeycodes 68 <keycode>' to make it known.
Jul 11 23:38:19 type kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly
Jul 11 23:38:21 type kernel: atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
Jul 11 23:38:21 type last message repeated 4 times
Jul 11 23:38:21 type kernel: atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly
Jul 11 23:38:46 type kernel: atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
Jul 11 23:39:16 type last message repeated 2439 times
Jul 11 23:40:16 type last message repeated 4986 times
Jul 11 23:41:16 type last message repeated 4988 times
Jul 11 23:42:16 type last message repeated 4987 times
Jul 11 23:43:16 type last message repeated 4987 times
Jul 11 23:44:16 type last message repeated 4987 times
Jul 11 23:45:16 type last message repeated 4986 times
Jul 11 23:46:16 type last message repeated 4944 times
Jul 11 23:46:24 type last message repeated 688 times
I wonder if the "AT Translated" designation that the atkbd driver gives the keyboard may indicate that the PS/2 keyboard is having it's data stream cooked as well?
Edit: (for geeks) - It turns out that bios can set up your keyboard as either "raw" or "translated". It's possible to switch a keyboard back into "raw" mode, but most operating systems don't do this because it can cause problems on laptops and other computers that don't have their keyboard on a normal ps/2 port.
I don't mind having a keyboard on a usb converter, but the usb converter translates the ps/2 mouse signals too poorly. My Trackman FX has no buttons on the usb converter, and the Explorer is missing two buttons on the usb converter.
4: I don't have the 'reboot' problem, but maybe that only happens in windows.
What i see sometimes is the above, and sometimes the keyboard starts responding slowly - like it takes 30 seconds per keypress. And sometimes by re-plugging the connectors i can get it to come back.
I'm CERTAIN that some of these problems - at least one of them - can be fixed in bios. If only by defaulting the mouse bios support to off. This won't keep you from being able to navigate in bios or use your USB mouse in any OS since Win95 OSR2.1.
For at least the mouse problems, it appears that many of the problems people have reported can be resolved merely by  disabling "BIOS Support for USB Mouse".

Answer 1

Quote from: d2thez on 13-July-05, 10:00:03
Ok, I am lost to be honest, but I just need to know if this applies to me.  Please help!
I have a K8N Neo Platinum for the socket 754, not a Neo2.  I use a USB mouse and a PS/2 keyboard.  I have both "USB keyboard/storage support" and "USB mouse support" enabled in my bios.
You have me scared from reading your post that having them enabled will short out my PS/2 or USB.  Will this happen?  And should I have these options enabled or not?
And finally, if I do disable them, do I lose and functionality??  Please help me out here!
Relax. You're not going to short out anything or lose any functionality.
The first one - USB Keyboard/Storage Support - this makes it possible for you to boot off of USB drives (like the flash drives) and makes USB keyboards work in DOS. It may be required to make USB keyboards work in bios setup, but i haven't tested that.
If you have a PS/2 keyboard and you don't intend to boot off of a USB drive, you can safely disable that option with no loss in functionality of any kind.
The second one - USB Mouse Support - This is a bit of software in BIOS that takes control of USB mice and makes them appear like PS/2 mice in order to provide easy mouse support for operating systmems that don't understand USB.
Specifically, DOS and Windows versions prior to Win95 OSR2.1.
Since Win95 probably won't boot at all on an Athlon64 - and in any case won't have the drivers you need for nearly anything - the only possible scenario where you might need this feature is if you were booting some old versions of Partition Magic or Norton Ghost or other utility floppy that runs on DOS, supports mouse navigation, and is old enough that it doesn't have a DOS USB mouse driver. Newer versions of pqmagic and ghost probably have usb mouse support on their boot floppies.
You can stop reading now if you just wanted to be reassured.
The reason it causes a problem is because mice are far more complex than keyboards. For some reason, even if you don't have a USB mouse installed, the signals from your PS/2 mouse are run through software in BIOS to make the signals from your mouse look like the signals from a generic PS/2 mouse - instead of a mouse that speaks the MouseMan protocol or the Intelimouse protocol or the Explorer protocol (or three or four other protocols).
This sounds like a strange way to do it, but it's actually easier in software to treat all inputs to the same logic and translate them to a virtual device than it is to detect whether translation is needed and then only translate the signals that need it.
This interferes with the mouse drivers. It also makes it impossible for some mice to 'wake up' properly when the computer is turned on.
It also doesn't work very well because it doesn't install all the myriad mouse protocols out there. KVM manufacturers have the same problem. If they fix the Intelimouse protocol they frequently break the MouseMan protocol.
If your mouse has only two or three buttons and no scroll wheel (which counts as two or three buttons), and your mouse was not made by Microsoft or Logitech, chances are your mouse only speaks the plain PS/2 Mouse protocol and you won't have problems with translation, but you might have some other symptoms. It appears that the BIOS may actually understand the Intelimouse protocol, so Microsoft mice may work anyway.