Bug#741464: grub-pc-bin: hangs after displaying boot menu

[Jeroen Dekkers]

Control: tag -1 +patch

On Mon, 29 Oct 2018 00:36:00 +0100,
Colin Watson wrote:
> 
> On Sun, Feb 01, 2015 at 11:16:59PM +0100, Marco Gamberoni wrote:
> > I see this same at_keyboard behaviour: working in VirtualBox, delivering garbage on this real hardware:
> >  - an HP Proliant DL380 Gen5 machine
> >  - with a Compaq PS/2 keyboard italian layout attached
> >  - booted from an iso image made with grub-mkrescue (GRUB) 2.02~beta2-15, containing a keyboard layout file made with
> >       ckbcomp -model pc105 -layout it | grub-mklayout -o pc105-it.gkb
> [...]
> > Having read
> >     http://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html
> > it is obvious what's going on: at_keyboard is using scankey set 1 but the keyboard is using set 2 and the keyboard controller is not translating.
> 
> Sorry for the long delay.  Are you still in a position to test this?
> 
> I just ran across this upstream commit:
> 
>   https://git.savannah.gnu.org/cgit/grub.git/commit/?id=c4b8bec5fee4e30a165fd14a188cf3ab8eccd095
> 
> Ignoring the specific hardware mentioned here, it seems like this could
> be a plausible cause: if GRUB manages to get out of sync with the
> keyboard controller on the command/data sequence, then it could easily
> end up confused about which is the current scan code set (see the
> changes to query_mode in particular) and so end up using the wrong set,
> or possibly even send a nonsense command somehow.  It seems worth
> testing if you can.

I cherry-picked that commit and tested it but it didn't fix the
problem.

The bug was introduced somewhere between GRUB 2.00 and 2.02 so I used
git bisect to find the commit that introduced the bug:

https://git.savannah.gnu.org/cgit/grub.git/commit/?id=0c62a5b28e2783d84d266341c4388b494e058114

As far as I understand the change it will no longer poll forever in
the module init when the keyboard controller isn't ready. The problem
seems to be that we used to initialize the keyboard controller in the
module init but now we always do it later when getkey is
called. Somehow this messes up things but I have no idea why.

I changed it so that it only initializes the keyboard controller when
it is ready and doesn't poll when it isn't. Here is the merge request:

https://salsa.debian.org/grub-team/grub/merge_requests/6

I've tested this on my old laptop (X200s thinkpad) and the problem
goes away with this patch.

Kind regards,

Jeroen Dekkers