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. 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: a. Do nothing. It's a Vmware bug, let the users bug Vmware and get an updated version. b. Detect Vmware versions that are affected (how?) and suppress output. c. Don't attempt to scroll in this code, and instead wrap around the screen (presumably clearing the rest of the line.) d. Blindly assume hardware scrolling works, instead of doing copy-to-scroll. Although I have seen craptops on which hardware scrolling is broken, it's hardly critical messages we're dealing with here. A bug for a bug... -hpa _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
