Messages in this thread | | | Date | Sun, 30 Jan 2000 18:15:25 -0500 | From | Wakko Warner <> | Subject | Re: Keyboard is frozen on boot of 2.3.41 |
| |
> Basically, the mouse open routine does: > > kbd_write_command_w(KBD_CCMD_MOUSE_ENABLE); /* Enable the > auxiliary port on > controller. */ > aux_write_ack(AUX_ENABLE_DEV); /* Enable aux device */ > kbd_write_cmd(AUX_INTS_ON); /* Enable controller ints */ > > send_data(KBD_CMD_ENABLE); /* try to workaround toshiba4030cdt problem */ > > and nothing more. The "Timeout" message comes from the final > "send_data()", which seems to imply nothing more than the fact that the > keyboard has already locked up by that time.
Actually, on my NEC, it doesn't print any errors.
> Now why any other driver _could_ make a difference here is very very > unclear. It might be a subtle timing issue, and nothing more. Or it migth > be something truly subtle indeed. > > The fact that the keyboard does come back when the mouse is closed again > certainly implies that whatever the interaction is, it's not some other > driver (ie USB or PCMCIA) just stomping on the keyboard state by mistake. > It really is internal to the mouse/keyboard driver, and some other driver > just makes it show up.
Sounds interesting. I actually thought about trying to have one function in yenta just return and see which one does it. Or is this a waist of time?
> More suggestions, if you have the time and the energy: > > - try to use the "kbd-reset" kernel command line at bootup, see if that > makes any difference (it does a full keyboard init sequence at bootup, > and it has been known to matter on some machines).
Ok, I'll try it.
> - disable the keyboard before changing the controller mode in open_aux(), > and re-order the operations, ie make the init sequence look like this: > > kbd_write_command_w(KBD_CCMD_MOUSE_ENABLE); /* Enable mouse controller */ > > send_data(KBD_CMD_DISABLE); /* Disable keyboard during mode set */ > kbd_write_cmd(AUX_INTS_ON); /* Enable controller ints for both keyboard and mouse */ > send_data(KBD_CMD_ENABLE); /* Enable keyboard again */ > > aux_write_ack(AUX_ENABLE_DEV); /* Enable the mouse itself */ > > which actually makes a lot more sense than the current one (makes the > mouse and keyboard controller and device "enabledness" be more regular: > both controllers are enabled during the mode set, but both devices are > disabled until after the mode-set is complete.
I'll try this as well if I can figure out where to do it.
I do remember once on an old machine that I had (a 486 ps/2 kb/mouse) that if the I hit any button on the keyboard while the mouse was init'd (this was in my DOS days) it would lock the machine. But then again, I didn't know which it was because I only had that machine and no network. Not sure why I meantion this. When the keyboard locks on my laptop, all I do is touch the mouse, nothing more. But it's not the fact (or for me anyway) the keyboard/mouse locks up, it's the fact that the keyboard never locks up until the mouse is opened and a mouse even occurs.
To test this, what I do is login (w/o touching the mouse), run: sleep 5;killall gpm the keyboard works, touch the mouse, it quits, when gpm dies, every key I pressed shows up on the cmd line.
-- Lab tests show that use of micro$oft causes cancer in lab animals
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |