From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JtnAD-00053B-HZ for mharc-grub-devel@gnu.org; Wed, 07 May 2008 13:10:45 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JtnAB-00051q-Qq for grub-devel@gnu.org; Wed, 07 May 2008 13:10:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JtnAA-00050I-6S for grub-devel@gnu.org; Wed, 07 May 2008 13:10:42 -0400 Received: from [199.232.76.173] (port=40568 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JtnA9-00050F-W5 for grub-devel@gnu.org; Wed, 07 May 2008 13:10:42 -0400 Received: from c60.cesmail.net ([216.154.195.49]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1JtnA9-0001jy-Ni for grub-devel@gnu.org; Wed, 07 May 2008 13:10:41 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 07 May 2008 13:10:39 -0400 Received: from [192.168.1.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 8183A619058 for ; Wed, 7 May 2008 13:10:39 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: References: <20080507125554.GC16492@thorin> Content-Type: text/plain; charset=UTF-8 Date: Wed, 07 May 2008 13:09:30 -0400 Message-Id: <1210180170.2321.6.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 (2.22.1-2.fc9) Content-Transfer-Encoding: 8bit X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: [PATCH] Workaround for the keyboard hang problem in intel mac X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2008 17:10:44 -0000 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