lkml.org 
[lkml]   [2000]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.135 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site