Re: [rs] Re: [stable] [PATCH] x86, setup (2.6.30-stable) fix 80x34 and 80x60 console modes

[Greg KH <greg@kroah.com>]

On Tue, Jun 30, 2009 at 08:01:47AM -0600, Marc Aurele La France wrote:
> On Mon, 29 Jun 2009, H. Peter Anvin wrote:
> > Greg KH wrote:
> >> On Mon, Jun 29, 2009 at 06:27:40PM -0700, H. Peter Anvin wrote:
> >>> Marc Aurele La France wrote:
> >>>> As coded, most INT10 calls in video-vga.c allow the compiler to assume EAX
> >>>> remains unchanged across them, which is not always the case.  This
> >>>> triggers an optimisation issue that causes vga_set_vertical_end() to be
> >>>> called with an incorrect number of scanlines.  Fix this by beefing up the
> >>>> asm constraints on these calls.
> 
> >>>> Reported-by: Marc Aurele La France <tsi@xfree86.org>
> >>>> Signed-off-by: Marc Aurele La France <tsi@xfree86.org>
> >>>> Acked-by: H. Peter Anvin <hpa@zytor.com>
> 
> >>> Note: this is not in upstream since upstream is not affected due to the
> >>> new "BIOS glovebox" subsystem.
> 
> >> So it is a ".30 only" type patch?  Any older kernel versions affected?
> 
> > Yes, all the way back to .23 or something like that.
> 
> No.  The problem can only arise in 2.6.30 and is a consequence of commit 
> 5f641356127712fbdce0eee120e5ce115860c17f.  It disappears with subsequent 
> mainline commit cf06de7b9cdd3efee7a59dced1977b3c21d43732.
> 
> Prior to 2.6.30, vga_set_480_scanlines() was passed a byte-size value (as 
> an int), which means the compiler was forced to load EAX, instead of only 
> AL, even if it did assume AH still contained 0x01.  That 0x01 is what the 
> last INT10 call in the vga_set_{8,14}font() functions sets AH to.
> 
> In truth, only those two INT10's need beefing up.  But I did them all for 
> completeness.

Ah, thanks.  Next time, putting that information into the patch itself
would be most helpful :)

I'll go queue it up.

greg k-h