[tlinux-users:08724] Re: BIOS video bug - GRUB menu not displayed

Guess I spoke too soon ... the problem does still persist in the latest BIOS.

However, I managed to figure out that the behavior is related to the value of the most significant bit in the byte at offset 0x44 of /dev/nvram.  If this bit is 0, the splash screen works fine ... if it is 1, the splash screen does not go away when the GRUB menu is displayed.  I attached two files showing the difference between "good" behavior and "bad" behavior - these were generated using 'hexdump /dev/nvram'.

This bit is apparently set to 1 whenever entering any ACPI sleep modes (including S3, S4, and S5 - linux normally enters ACPI sleep mode S5 to turn the computer off), but it only appears to be unset in unusual circumstances (like when upgrading the BIOS), which is why it appeared that the problem went away when I upgraded my BIOS.  If I manually write a 0 to that bit, then disable the ACPI poweroff on halt and only ever turn the computer off using the power button, everything always works fine every time I boot.

I don't know what the intended purpose of this bit is, and I don't what (either in linux ACPI code or in BIOS code) might be triggering it to be written.  I hacked the toshset utility to print all of the Toshiba SCI and HCI values on my machine, but the value of that bit in nvram does not seem to have any effect on any of the SCI or HCI values.  I spent some time tracing out the ACPI routines in the linux kernel and reading through the firmware ACPI DSDT tables, but I didn't find anything there either (although, I may have simply missed something because I'm not familiar with enough of the low-level details of the kernel or ACPI subsystem).

I'm not sure how to continue debugging this without disassembling the BIOS code.  I've seen some references that describe the layout of firmware code and nvram storage for some of the generic BIOSs (Award, Phoenix, etc), but I haven't been able to find one describing the Toshiba BIOS...  If anyone knows anything about the low-level implementation details of ACPI or the Toshiba BIOS, or knows anything about BIOS disassembly, I'd appreciate any pointers you can give me.

On Tue, Nov 13, 2007 at 07:11:50PM -0500, Paul Donohue wrote:
> FYI, I upgraded to BIOS Version 3.50 (released 10/04/2007), and this problem seems to have gone away.
> 
> On Fri, Aug 03, 2007 at 03:07:34PM -0400, Paul Donohue wrote:
> > I own a Tecra M5, and am running Debian lenny.
> > 
> > I recently upgraded my BIOS from Version 1.50 to Version 3.40.
> > 
> > This fixed a lot of minor issues (including the 'APIC error' messages I used to get - http://linux.toshiba-dme.co.jp/ML/tlinux-users/8300/8321.html is a message from another user getting the same messages).  However, it introduced one new problem that is rather annoying.
> > 
> > Whenever the TOSHIBA "In Touch with Tomorrow" splash screen (with the boot device icons at the bottom of the screen) is displayed during boot, the splash screen continues to stay visible until after linux begins booting (GRUB does run, and you can blindly select a kernel to boot, but the menu is never actually visible), and when the splash screen does finally go away, the console is corrupted (it generally has a white or grey background with black text or text that flashes (alternates between black and white), sometimes with garbled characters).  After some time, the console generally seems to correct itself.  If it doesn't correct itself, starting xwindows fixes it, and everything works fine until it is rebooted again.
> > 
> > If the splash screen is not displayed, or if the BIOS switches back to text mode before booting the operating system (when rebooting instead of cold booting, when diagnostic mode is enabled, or when LAN booting is enabled before HDD booting), GRUB is displayed as usual, and the console looks fine.  Unfortunately, enabling diagnostic mode or LAN booting greatly increases the time it takes to boot the machine, so it isn't practical to leave those enabled all the time.  However, if you need to see the GRUB boot menu, you don't have many options.
> > 
> > I've seen a lot of complaints about this when searching for a fix (for example http://ubuntuforums.org/showthread.php?t=405515), and some people say the problem goes away for them if they enable diagnostic mode once then disable it for subsequent boots, but that didn't work for me.  I searched this mailing list for anything related, but it doesn't look like anything has been posted about this yet.
> > 
> > I assume the root of the problem is that most BIOS's set the video card to text mode before handing off to the operating system, and therefore GRUB does not explicitly set the video mode before displaying the menu.  The new BIOS probably does not set the video card back to text mode after the splash screen is displayed before handing off to the operating system, so the video card remains in a graphical mode, and text mode display data written to the card by GRUB is ignored or corrupted.  I assume the old BIOS did reset the video card, since I never noticed this problem with the old BIOS version.  I'm guessing noone at Toshiba noticed this bug since Microsoft products generally use text mode only for a short period of time (if at all) before switching to a graphical mode to display the 
 Windows splash screen during boot, so you wouldn't likely notice the missing text mode.
> > 
> > I called Toshiba Tech Support in hopes of filing a bug report.  They were very helpful and tried to find a work-around for the problem, but they apparently don't have any way to even internally file a bug report for something like this.  I'm willing to bet there's some engineer in Toshiba who could fix this very easily if made aware of the problem.  It is discouraging to be told that there is no way for that engineer to find out that people are having problems.
> > 
> > I'm posting this here incase someone else runs into this problem and wants to understand it a little better.  Maybe if I'm really lucky this will some day make it to the eyes of the person in Toshiba who can fix this...