[bug #33318] Unknown process in grub 1.99~rc1 is setting and passing invalid graphics data to linux kernel and Xorg.

[Mike Ferreira]

URL:
  <http://savannah.gnu.org/bugs/?33318>

                 Summary: Unknown process in grub 1.99~rc1 is setting and
passing invalid graphics data to linux kernel and Xorg.
                 Project: GNU GRUB
            Submitted by: mafoelffen
            Submitted on: Sun 15 May 2011 06:56:16 PM GMT
                Category: Terminal
                Severity: Major
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: mafoelffen
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 
                 Release: other
         Reproducibility: Intermittent
         Planned Release: None

    _______________________________________________________

Details:

Reference:
Since implementation of KMS technologies at Ubuntu version 10.04, transitions
have occurred where the graphics is first set and how, via:
"Kernel mode-setting (KMS) shifts responsibility for selecting and setting up
the graphics mode from X.org to the kernel. When X.org is started, it then
detects and uses the mode without any further mode changes. This promises to
make booting faster, more graphical, and less flickery. "

>From what I can figure out, most of this started with Ubuntu 10.04 when they
started implementing KMS technology:
(Simplistic explanation of graphical changes)
- 9.10 graphics modes were dealt with in xorg and the video drivers. Grub2
introduced.
- 10.04 introduces KMS, (kernel mode switching) where graphics modes were set
in the kernel and passed to xorg. Default graphics mode in Grub and linux
kernel was 640x480.
- 10.10 has some more changes with this... Trying to find and set the graphics
modes and pass it to Xorg. Default graphics mode in Grub and linux kernel was
640x480.
- Natty and Grub 1.99!rc1 have ingrained changes tied to KMS. Grub tries to
find and set the graphics using __?__ from (Grub?), which it then passes that
mode to the kernel, which then passes in it to Xorg. That's why we now have
the graphics changes happening as soon as the Grub Menu...

Current: Ubuntu 11.04, Grub 1.99~rc1, Linux Kernel 2.6.38.8.xx and Xorg 1.7.6
(all using KMS technologies to pass a preset graphics mode to xorg)

Most of the people that I've helped (Ubuntu Support Forum- Installations and
Updates) correct their black or purple screen problems, by 1 of 4
workarounds:

1. Add "GRUB_GFXPAYLOAD_LINUX=text" to /etc/defualt/grub which tells the
kernel to boot in a text graphics mode and to ignore all other graphics calls
being passed to it from Grub.

2. Roll the linux kernel back from 2.6.38.x to 2.6.7.x. Which then ignores any
graphics modes/data passed by Grub.

3. Roll the grub version back from 1.99~rc1 to 1.98, which then does not pass
any mode or data to the kernel.

## // These 3 workarounds bypass and ignore the designed process of KMS, but
verifies that the graphics bypass switch of the kernel mode set does work. //
##

4. Manually set the default graphics mode in /etc/grub/default of
GRUB_GFXMODE=WIDTHxHEIGHTxDEPTH, which when manually set > verifies the the
process of KMS in the kernel and Xorg work, but identifies that there is a
problem in Grub, when GRUB_GFXMODE=auto...

//
Bypassing the GFXMODE=auto default setting, a process that starts and uses
data returned by __?__. The main fix explicitly sets the
GFXMODE=WIDTHxHEIGHTxDEPTH parameters of a mode that "their" graphics hardware
supports. This fix bypasses whatever grub is using and it's query/mode set
functions. Other fixes are via setting the scan rate of a monitor, which is
also supposed to be a a function of whatever utility or file it is using.
(ETC.)

There have been a few other "instances" where there was some other things
going on or the "current" kernel "did not support or lost" graphics support
for... (The kernel in proposed fixes a lot of those) But the majority was just
setting an initial mode.

I know that kernel boot parameters are a part of it. I know that Grub
1.99~rc1's GFXMODE and GFXTERM are a part of it. I know that HAL and
subsequently Xorg is a part of this.

What I put together so far is in this sticky, which is still evolving:
http://ubuntuforums.org/showthread.php?t=1743535

I know that the default of GFXMODE=auto is causing a lot of blank (flashing
cursor/black/purple/stuck at splash) screens as it tries modes until it lands
on one that deos not return an error code... even though that instance may be
invalid or out-of-range.

If you manually set the variable of GRUB_GFXPAYLOAD or GFXMODE and it works...
then it does not seem to be a kernel bug. Manually setting those variables and
passing to the kernel verifies that the process at the kernel is working as
designed.

What that does point out is that the process is broken before that... I don't
know the "exact: process in Grub that is failing.  I've spent enough time out
on IRC # grub to take their advice to file this bug.

Somewhere in GRUB, where it is either trying to query the hardware and then
passing invalid data to set a mode. Or possibly in the video.lst files that
are the video device files?

Manually setting that mode (GRUB_GFXMODE) bypasses that process, then things
are working fine.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?33318>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/