bugGNU GRUB - Bugs: bug #33318, Unknown process in grub 1.99~rc1...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitter:  Mike Ferreira <mafoelffen>
Submitted:  Sun 15 May 2011 06:56:16 PM UTC
   
 
Category:  Terminal Severity:  Major
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  None Originator Name:  mafoelffen
Open/Closed:  Closed Release:  other
Release:  Reproducibility:  Intermittent
Planned Release:  None

Thu 29 Sep 2011 02:42:39 PM UTC, comment #2: 

Now bzr version uses EDID which should solve the autodetecting issue. Also please avoid of plugging in the technical explanation if you have no idea of a subject. All your talk about "processes" which don't exist in GRUB only made your report longer and unreadable whereas concise and precise version would be simply "Video mode autodetected by GRUB isn't supported by monitor"

Vladimir Serbinenko <phcoder>
Group administrator
Sun 15 May 2011 07:25:54 PM UTC, comment #1: 

Most of the things you guessed are wrong. For once GRUB doesn't have any processes. "auto" just uses the highest resolution reported by BIOS. 2.6.37 uses the graphics data passed by GRUB (even 2.6.32 does). "auto" isn't perfected and although it will be made better (by using EDID if found) it will still sometimes fail. Right resolution is sometimes unsupported by BIOS and so gfxpayload with this resolution is equivalent to gfxpayload=text. Furthermore failure of kms to switch mode (and going to purple color) is outside of GRUB scope and indicates a problem with KMS which should be able to switch from any to any supported mode.

Vladimir Serbinenko <phcoder>
Group administrator
Sun 15 May 2011 06:56:16 PM UTC, original submission:  

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.

Mike Ferreira <mafoelffen>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by mafoelffen (Submitted the item)
  • -email is unavailable- added by mafoelffen
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-09-29 phcoder StatusNone Fixed
        Open/ClosedOpen Closed
    2011-05-15 mafoelffen Carbon-Copy- Added mafoelffen

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code