RE: grub2 code

[Roger Cruz]

This was a bug that was introduced into GRUB when the code to detect if the 
SHIFT key is being pressed was added.  The symptom was that customers were 
complaining that even though they had turn on NUMLOCK in the BIOS, once we 
booted our software, NUMLOCK was off.  It was easy to "see" when the bug was 
happening because the NUMLOCK LED would turn off sometime during GRUB running. 

I tracked it down to that one line which ANDs the BIOS state area and blows 
away the NUMLOCK state in it  (it stores the value in the address in BX via 
indirect addressing).  

Hope this helps.  If it is not clear, please feel free to ask for more details.

Roger R. Cruz


-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Ben Guthro
Sent: Monday, February 03, 2014 7:42 AM
To: Colin Watson
Cc: address@hidden; Roger Cruz
Subject: Re: grub2 code

On Mon, Feb 3, 2014 at 6:57 AM, Colin Watson <address@hidden> wrote:
> On Sun, Feb 02, 2014 at 07:25:51PM +0000, Robert Parnell wrote:
>> I was just looking at the grub2 source code and saw that 
>> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/grub2/tru
>> sty/view/head:/TODO 
>> <https://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/trusty/grub2/
>> trusty/view/head:/TODO>
>> says to contact with questions.
>> I was looking at the source because I encountered a bug on my machine 
>> that has been previously reported
>> (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1027694) and 
>> thought I'd have a look to see if I could find the problem.
>> So I have 2 questions:
>> 1. Is the code on launchpad the up to date code?
>
> It's an automatically-imported version of the Ubuntu packaging.  It's 
> up-to-date with what we're shipping, yes, but we do our work in git 
> these days.  The upstream code is here:
>
>   http://git.savannah.gnu.org/gitweb/?p=grub.git
>
> ... and the packaging used by both Debian and Ubuntu is here (the 
> "experimental" branch is most current):
>
>   http://anonscm.debian.org/gitweb/?p=pkg-grub/grub.git
>
>> 2. Line 177 of
>> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/grub2/tru
>> sty/view/head:/grub-core/boot/i386/pc/startup_raw.S
>> <https://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/trusty/grub2/
>> trusty/view/head:/grub-core/boot/i386/pc/startup_raw.S>
>> is a function that flushes the keyboard buffer, could this be what is 
>> causing the bug?
>
> That seems unrelated.
>
> Ben's patch referenced in https://savannah.gnu.org/bugs/?34547 touches 
> code that I wrote and that I maintain as a patch, so this would 
> presumably be my problem to fix.  But I don't understand why Ben's 
> patch fixes anything related to NumLock.  The code being commented out 
> is
> essentially:
>
>         movw    $(GRUB_MEMORY_MACHINE_BIOS_DATA_AREA_ADDR + 0x17), %bx
>         andb    $3, (%bx)
>
> ... followed by something that tests the condition flags.  But all 
> that does is test whether either Shift key is held down, not actually 
> set the NumLock state (see http://www.bioscentral.com/misc/bda.htm).  
> That is, it reads from the BIOS Data Area, but it doesn't write to it.
>
> Ben (CCed), could you shed some light on why your patch would fix this?

Adding Roger Cruz, as he was the original author of this fix, where I was just 
trying to get it upstreamed - though, this was quite some time since he 
developed it (Oct 2011), so I'm sure this isn't exactly fresh in his mind.

Roger, could you shed some light on  this?

Ben

>
> Thanks,
>
> --
> Colin Watson                                       address@hidden