From: Andrei Warkentin <awarkentin@vmware.com>
To: Jason Wessel <jason.wessel@windriver.com>
Cc: kgdb-bugreport@lists.sourceforge.net,
linux-kernel@vger.kernel.org,
Andrei Warkentin <andreiw@vmware.com>
Subject: Re: [PATCH] KDB: Fix usability issues relating to the 'enter' key.
Date: Sun, 26 Feb 2012 17:01:28 -0800 (PST) [thread overview]
Message-ID: <106764274.1567181.1330304488097.JavaMail.root@zimbra-prod-mbox-2.vmware.com> (raw)
In-Reply-To: <4F4A2F60.1060700@windriver.com>
Hi Jason,
Thank you for the review. Comments inline.
----- Original Message -----
> From: "Jason Wessel" <jason.wessel@windriver.com>
> To: "Andrei Warkentin" <andreiw@vmware.com>
> Cc: kgdb-bugreport@lists.sourceforge.net, linux-kernel@vger.kernel.org
> Sent: Sunday, February 26, 2012 8:10:56 AM
> Subject: Re: [PATCH] KDB: Fix usability issues relating to the 'enter' key.
>
> I did not write the original code, but I can explain why there was
> some special logic.
>
> When you restore the system back to the running state you do not want
> to send any other key scan codes back to the kernel. The idea being
> that you type "go" and press enter to resume kernel execution. At
> that point you do not want to send a random scan code back to the
> kernel, ideally you want to leave everything as it was. This also
> handled the case where there was a PS/2 style mouse attached.
The input device is already reset on kdb exit to a safe state, however, by the
code inside kgdboc_post_exp_handler, which calls kgdboc_restore_input().
The existing logic also already correctly will handle the case of a PS/2 mouse, i.e.:
/*
* Ignore mouse events.
*/
if (scanstatus & KBD_STAT_MOUSE_OBF)
return -1;
...so there is nothing that the non-ENTER-specific code already doesn't deal with.
That special ENTER code also doesn't correctly handle typematic repeat, nor does it handle
key-pad enter (as I mentioned before in the patch description, this has a different
make and break codes, prefixed with 0xe0).
>
> I do have a question about part of the section you deleted.
>
>
> > - if ((scancode & 0x7f) == 0x1c) {
> > - /*
> > - * enter key. All done. Absorb the release scancode.
> > - */
> > - while ((inb(KBD_STATUS_REG) & KBD_STAT_OBF) == 0)
> > - ;
>
> Seems there is a bug here. There is a cpu_relax() missing.
Right, that's exactly what I said in the patch :-).
>
> > -
> > - /*
> > - * Fetch the scancode
> > - */
> > - scancode = inb(KBD_DATA_REG);
> > - scanstatus = inb(KBD_STATUS_REG);
> > -
> > - while (scanstatus & KBD_STAT_MOUSE_OBF) {
>
> There should also be a cpu_relax() right here.
Correct.
>
> > - scancode = inb(KBD_DATA_REG);
> > - scanstatus = inb(KBD_STATUS_REG);
> > - }
> > -
>
>
> If you put the two cpu_relax() pieces in do you still end up with a
> problem? If this does not work for you the possibility to exists to
> clear the keyboard/mouse state on the kdb exit.
You will solve the multi-second hangs on ESX. However, this still doesn't fix the
bogus messages during typematic repeat (holding down ENTER) or keypad enter key use.
Basically, if you nuke the entire ENTER-key special case block, the existing key will
correctly handle both typematic, break codes, and KP ENTER key use (as well as any
mouse events). Cleanup of mouse/keyboard state is done already on kdb exit by kgdboc, which
is the only consumer of the kdb_keyboard code.
A
prev parent reply other threads:[~2012-02-27 1:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-17 23:52 Andrei Warkentin
2012-02-25 3:20 ` Andrei Warkentin
2012-02-26 13:10 ` Jason Wessel
2012-02-26 13:58 ` Jason Wessel
2012-02-27 1:04 ` Andrei Warkentin
2012-02-27 22:50 ` Jason Wessel
2012-02-27 23:18 ` Andrei Warkentin
2012-02-27 23:28 ` Jason Wessel
2012-02-27 23:35 ` Andrei Warkentin
2012-02-28 1:27 ` Andrei Warkentin
2012-02-28 4:26 ` Andrei Warkentin
2012-02-28 13:53 ` Jason Wessel
2012-02-28 17:24 ` Andrei Warkentin
2012-02-27 1:01 ` Andrei Warkentin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=106764274.1567181.1330304488097.JavaMail.root@zimbra-prod-mbox-2.vmware.com \
--to=awarkentin@vmware.com \
--cc=andreiw@vmware.com \
--cc=jason.wessel@windriver.com \
--cc=kgdb-bugreport@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome