[PATCH] Workaround for the keyboard hang problem in intel mac

[PATCH] Workaround for the keyboard hang problem in intel mac

[Bean]

Hi,

This patch fix the keyboard hang problem when using boot camp to load
legacy system.

diff --git a/kern/i386/pc/startup.S b/kern/i386/pc/startup.S
index 5d4bbcb..455233a 100644
--- a/kern/i386/pc/startup.S
+++ b/kern/i386/pc/startup.S
@@ -1240,6 +1240,19 @@ FUNCTION(grub_console_getkey)
 	call	prot_to_real
 	.code16

+	pushfw
+	sti
+
+1:
+	movb	$1, %ah
+	int	$0x16
+	jnz	2f
+	hlt
+	jmp	1b
+
+2:
+	popfw
+	movb	$0, %ah
 	int	$0x16

 	movw	%ax, %dx		/* real_to_prot uses %eax */

-- 
Bean

Re: [PATCH] Workaround for the keyboard hang problem in intel mac

[Robert Millan]

On Wed, May 07, 2008 at 01:12:08AM +0800, Bean wrote:
> Hi,
> 
> This patch fix the keyboard hang problem when using boot camp to load
> legacy system.
> 
> diff --git a/kern/i386/pc/startup.S b/kern/i386/pc/startup.S
> index 5d4bbcb..455233a 100644
> --- a/kern/i386/pc/startup.S
> +++ b/kern/i386/pc/startup.S
> @@ -1240,6 +1240,19 @@ FUNCTION(grub_console_getkey)
>  	call	prot_to_real
>  	.code16
> 
> +	pushfw
> +	sti
> +
> +1:
> +	movb	$1, %ah
> +	int	$0x16
> +	jnz	2f
> +	hlt
> +	jmp	1b
> +
> +2:
> +	popfw
> +	movb	$0, %ah

I think it'd be nice to have a comment there explaining why this is done.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

Re: [PATCH] Workaround for the keyboard hang problem in intel mac

[Bean]

On Wed, May 7, 2008 at 8:55 PM, Robert Millan <rmh@aybabtu.com> wrote:
>  I think it'd be nice to have a comment there explaining why this is done.

Hi,

You're right, here is the patch with comment:

diff --git a/kern/i386/pc/startup.S b/kern/i386/pc/startup.S
index 5d4bbcb..a67bf6d 100644
--- a/kern/i386/pc/startup.S
+++ b/kern/i386/pc/startup.S
@@ -1240,6 +1240,26 @@ FUNCTION(grub_console_getkey)
 	call	prot_to_real
 	.code16

+	/*
+	 * Due to a bug in apple's bootcamp implementation, INT 16/AH = 0 would
+	 * cause the machine to hang at the second keystroke. However, we can
+	 * work around this problem by ensuring the presence of keystroke with
+	 * INT 16/AH = 1 before calling INT 16/AH = 0.
+	 */
+
+	pushfw
+	sti
+
+1:
+	movb	$1, %ah
+	int	$0x16
+	jnz	2f
+	hlt
+	jmp	1b
+
+2:
+	popfw
+	movb	$0, %ah
 	int	$0x16

 	movw	%ax, %dx		/* real_to_prot uses %eax */

-- 
Bean

Re: [PATCH] Workaround for the keyboard hang problem in intel mac

[Pavel Roskin]

On Wed, 2008-05-07 at 21:55 +0800, Bean wrote:

> +	/*
> +	 * Due to a bug in apple's bootcamp implementation, INT 16/AH = 0 would
> +	 * cause the machine to hang at the second keystroke. However, we can
> +	 * work around this problem by ensuring the presence of keystroke with
> +	 * INT 16/AH = 1 before calling INT 16/AH = 0.
> +	 */

Can it be because interrupts are not enabled during the call?

> +	pushfw
> +	sti
...
> +	popfw

I would prefer explicit sti and cli without saving flags on the stack,
unless we want the code work with both enabled and disabled interrupts.

Robustness is not always handling unexpected situations.  Sometimes it's
enforcing the rules and being clear about it.

It's just a suggestion, not an invitation for a long discussion about
three instructions :-)

-- 
Regards,
Pavel Roskin

Re: [PATCH] Workaround for the keyboard hang problem in intel mac

[Bean]

On Thu, May 8, 2008 at 1:09 AM, Pavel Roskin <proski@gnu.org> wrote:
> On Wed, 2008-05-07 at 21:55 +0800, Bean wrote:
>
>  > +     /*
>  > +      * Due to a bug in apple's bootcamp implementation, INT 16/AH = 0 would
>  > +      * cause the machine to hang at the second keystroke. However, we can
>  > +      * work around this problem by ensuring the presence of keystroke with
>  > +      * INT 16/AH = 1 before calling INT 16/AH = 0.
>  > +      */
>
>  Can it be because interrupts are not enabled during the call?

I just check, enabling interrupt alone doesn't solve the problem.
According to the discussion at:

https://www.opensolaris.org/jive/thread.jspa?threadID=7554&tstart=0

Some I/O port is not implemented, I guess this cause INT 16/AH = 0 to
wait forever.

>
>  > +     pushfw
>  > +     sti
>  ...
>  > +     popfw
>
>  I would prefer explicit sti and cli without saving flags on the stack,
>  unless we want the code work with both enabled and disabled interrupts.
>
>  Robustness is not always handling unexpected situations.  Sometimes it's
>  enforcing the rules and being clear about it.
>
>  It's just a suggestion, not an invitation for a long discussion about
>  three instructions :-)

Yep, actually, I think even the ending cli can be omitted, because it
will jump right back to protected mode after the keystroke is
received.

-- 
Bean