Re: Vmware crashes if compress/misc.c scrolls?

[Jeremy Fitzhardinge <jeremy@goop.org>]

H. Peter Anvin wrote:
> I just got the following message on the syslinux mailing list:
>
>   
>> 2. On some platforms (vmware for example :), READING from the video memory
>>    in the 32bit mode is impossible (causes an exeption). Taking in to account
>>    that the scroll function in ilinux/arch/i386/boot/compressed/misc.c
>>    works using a memcpy of the video memory, when the linux bootsector is given
>>    control and the cursor is at the end of the screen (-1-2 lines) an exception is
>>    arisen and in the presence of it's handler in the bootloader the system halts.
>>    Both lilo and grub handle this situation - the cursor is always somewhere at the
>>    middle of the screen when the control is given to the linux bootsector.
>>    When using pxelinux taking in to account that the PXE bios prints out the
>>    presence of the second initramfs which causes the screen to scroll and the bug
>>    to appear :)
>>    A very simple solution - the screen is cleared before giving control to the
>>    linux bootsector (in the patch).
>>     
>
> First of all, is this actually true?  This seems like a monumental screwup.
>   

Yes.  Is this a report of observed failure?  And how would VMWare even 
go about implementing this kind of misfeature?  Maybe it fails with 
particular instructions reading the framebuffer?

> Second, assuming it is true, what should be done about it?  The notion
> that the bootloader should erase the screen is ridiculous since we spend
> a lot of effort maintaining the screen context from 16-bit code.
>
> I see a couple of options:
>   

Maintain a shadow framebuffer, and copy it to the real framebuffer on 
update...

    J