Bug 13249 - Intel 945GM: Boot option`vga=0x31a' breaks display of TTYs
Intel 945GM: Boot option`vga=0x31a' breaks display of TTYs
Status: CLOSED OBSOLETE
Product: Other
Classification: Unclassified
Component: Other
All Linux
: P1 high
Assigned To: DRI developer's list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-05 09:24 UTC by Werner Lemberg
Modified: 2012-06-07 10:23 UTC (History)
7 users (show)

See Also:
Kernel Version: 2.6.30-rc5-git1-18-vanilla
Tree: Mainline
Regression: Yes


Attachments
boot log message from v2.6.27-0.1 (40.73 KB, text/plain)
2009-05-18 10:44 UTC, Werner Lemberg
Details
boot log message from v2.6.28-0.1 (40.77 KB, text/plain)
2009-05-18 10:45 UTC, Werner Lemberg
Details
config file for v2.6.27-0.1 (91.39 KB, text/plain)
2009-05-18 10:46 UTC, Werner Lemberg
Details
config file for v2.6.28-0.1 (95.65 KB, text/plain)
2009-05-18 10:48 UTC, Werner Lemberg
Details

Description Werner Lemberg 2009-05-05 09:24:16 UTC
[kernel 2.6.30-rc4-14-vanilla from openSuSE factory on top of
openSuSE 11.1]


With my 945GM intel graphics card, I don't get visible TTYs which I could
switch to with Ctrl-Alt-Shift-F1, for example, after X has started.
Only F7 to switch back to graphics mode works fine.  In particular, I
don't see any boot messages at start-up.  This has worked fine with a
previous kernel like 2.6.27.21.

It seems that `vga=0x31a' fails since without it I can see boot messages.

BTW, for `vga=0x31a' I get

  Console: colour dummy device 80x25

in the log file, while without this parameter I get

  Console: colour VGA+ 80x25


PS: It seems to me that graphic card problems at start-up are missing
    in the Linux bug categories...
Comment 1 Andrew Morton 2009-05-05 21:16:04 UTC
Reassigned to dri-devel.

Was 2.6.29 OK?
Comment 2 Werner Lemberg 2009-05-05 21:56:47 UTC
I don't know.  I've never tried the 2.6.29 series.
Comment 3 Werner Lemberg 2009-05-15 06:05:21 UTC
On the opensuse-kernel mailing list the following has been reported a few
days ago:

> Since KOTD 20090406183001_398542cc booting with vga=0x31a results in
> black and [un]usable textconsoles. on my system.  KOTD
> 20090331140119_768f098d still works fine. Looking in boot.msg shows
> that vesafb doesn't load anymore.  Any ideas what change may have
> broken vga=0x31a ?

I suspect that this is exactly the same problem I have; perhaps this
helps in identification of the problem (which is still present in
2.6.30-rc5, BTW).
Comment 4 Florian Mickler 2009-05-15 07:35:50 UTC
Do you have CONFIG_DRM_I915_KMS set in your kernel config or are using i915.modeset=1 on the kernel cmdline? 

KMS (kernel modesetting) is known to not work with other graphics-hardware-accessing things.
Comment 5 Florian Mickler 2009-05-15 07:37:05 UTC
(on the other hand, you don't need other 'graphics-hardware-accessing' things with kms. just disable intelfb or vesafb in the kernel)
Comment 6 Werner Lemberg 2009-05-15 08:17:16 UTC
> Do you have CONFIG_DRM_I915_KMS set in your kernel config

No.

> or are using i915.modeset=1 on the kernel cmdline? 

No.
Comment 7 Florian Mickler 2009-05-15 09:44:42 UTC
well, i think if you want to know what change (and thus who is responsible) introduced this breakage for you, you could try to bisect it down.
there are 34495 changesets since v2.6.27, so this means you are going to have to only try 15 kernels to identify the offending change.

(see under "bisect" here: http://www.kernel.org/doc/local/git-quick.html)


an other approach is cc'ing more people :
$ scripts/get_maintainer.pl -f drivers/video/uvesafb.c 
linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
Michal Januszewski <spock@gentoo.org>
Andrew Morton <akpm@linux-foundation.org>
Roel Kluin <roel.kluin@gmail.com>
Pablo Neira Ayuso <pablo@netfilter.org>
Michal Januszewski <michalj@gmail.com>
Comment 8 Werner Lemberg 2009-05-18 10:42:33 UTC
I've now downloaded the git archive of the kernel.  The above assumption
unfortunately is incorrect; the break for my video card happens between
2.6.27 (which is OK) and 2.6.28 (which is broken).  I really wonder that
noone has noticed this earlier.

BTW, the bisect link given in comment #7 is no longer valid.

Will now try to start bisecting.  Sigh.

From `make mrproper' to `make install' it takes an hour on my system –
I suppose that I have to do `make mrproper' each time, right?

Just to reassure:

  . 2.6.27 has these options:

      CONFIG_FB_UVESA=m
      CONFIG_FB_VESA=y
      CONFIG_FB_INTEL=m

  . 2.6.28 and newer has this:

      CONFIG_FB_BOOT_VESA_SUPPORT=y
      CONFIG_FB_UVESA=m
      # CONFIG_FB_VESA is not set
      CONFIG_FB_INTEL=m

    According to the docs this should be sufficient to make the `vga=...'
    boot option work.
Comment 9 Werner Lemberg 2009-05-18 10:44:11 UTC
Created attachment 21402 [details]
boot log message from v2.6.27-0.1
Comment 10 Werner Lemberg 2009-05-18 10:45:03 UTC
Created attachment 21403 [details]
boot log message from v2.6.28-0.1
Comment 11 Werner Lemberg 2009-05-18 10:46:55 UTC
Created attachment 21404 [details]
config file for v2.6.27-0.1

derived from openSuSE's config option for 2.6.27.21-0.1.pae
Comment 12 Werner Lemberg 2009-05-18 10:48:13 UTC
Created attachment 21405 [details]
config file for v2.6.28-0.1

derived from openSuSE's config file for 2.6.27.21-0.1.pae
Comment 13 Werner Lemberg 2009-05-19 22:02:28 UTC
OK, I did bisecting as follows:

  git bisect start v2.6.28 v2.6.27 -- drivers/video

and I found that this is good (this is, no black screen):

  5ab4840968cd094586f65fce978e35c66d25ac78 vgacon: vgacon_scrolldelta simplification

and this is bad, using the configuration as described above:

  4d31a2b74c6d063362ae10ce3be3e80d8713bf23 fbdev: ignore VESA modes if framebuffer does not support them
Comment 14 Michal Januszewski 2009-05-19 22:19:27 UTC
(In reply to comment #13)

> and this is bad, using the configuration as described above:
> 
>   4d31a2b74c6d063362ae10ce3be3e80d8713bf23 fbdev: ignore VESA modes if
> framebuffer does not support them

That's weird, with CONFIG_FB_BOOT_VESA_SUPPORT=y this commit shouldn't change anything.  Do you get any VESA modes if you boot with vga=ask?
Comment 15 Werner Lemberg 2009-05-20 05:51:28 UTC
Yes, plenty of them, like 0x307, 0x31B, or 0x305.  None of them work.

However, I've now analyzed the situation more closely, and the change from good to bad bisect just hides the real problem: I've configured the `good' kernel to use

  CONFIG_FB_VESA=y

(as the openSuSE 2.6.27 kernel is configured by default) while the bad kernel uses

  CONFIG_FB_BOOT_VESA_SUPPORT=y
  # CONFIG_FB_VESA is not set

(as the openSuSE 2.6.30 is configured by default).  In other words, the intel FB driver doesn't support VESA modes properly for my graphics card.  Is this a known problem?  What do you recommend for further debugging?
Comment 16 Michal Januszewski 2009-05-20 18:28:08 UTC
(In reply to comment #15)

> (as the openSuSE 2.6.30 is configured by default).  In other words, the intel
> FB driver doesn't support VESA modes properly for my graphics card.  Is this a
> known problem?  What do you recommend for further debugging?

I'm not familiar with the intel FB driver, but don't you need something along the lines of video=intelfb:mode=1024x768-32 instead of vga=xxx on the kernel command line?
Comment 17 Werner Lemberg 2009-05-21 05:06:10 UTC
I have no idea :-)  Krzysztof Helt has sent a patch to the linux-fbdev-devel list already.  In my case, I have no VESA driver selected at all, so it's no wonder that I get an empty screen.

On the other hand, if intelfb is the compiled-in VESA driver, it should IMHO accept the `vga=...' parameter too.

To really test his patch I would need to say CONFIG_FB_INTEL=y, but I can't manage to do this.  `make gconfig', for example, only allows values `m' or `n' for reasons I don't understand.  A manual change gets undone too by the control call to `scripts/kconfig/conf'...
Comment 18 Michal Januszewski 2009-05-21 08:39:57 UTC
(In reply to comment #17)

> To really test his patch I would need to say CONFIG_FB_INTEL=y, but I can't
> manage to do this.  `make gconfig', for example, only allows values `m' or `n'
> for reasons I don't understand.  A manual change gets undone too by the control
> call to `scripts/kconfig/conf'...

I had a look at your config file and this might be caused by CONFIG_AGP_INTEL being set to 'm'.  If you configure your kernel so that the AGP drivers are built into the kernel, you should be able to set CONFIG_FB_INTEL to 'y'.
Comment 19 Werner Lemberg 2009-05-21 21:34:38 UTC
Alas, it still fails.  After compiling the current git kernel with AGP_INTEL=Y and FB_INTEL=Y, I booted with

  vga=0x31a video=intelfb:mode=1280x1024

which spits out the following in the boot.msg file:

  Linux agpgart interface v0.103
  agpgart-intel 0000:00:00.0: Intel 945GM Chipset
  agpgart-intel 0000:00:00.0: detected 7932K stolen memory
  agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
  intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/945GME/965G/965GM chipsets
  intelfb: Version 0.9.6
  intelfb 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
  intelfb: 00:02.0: Intel(R) 945GM, aperture size 256MB, stolen memory 7932kB
  intelfb: Non-CRT device is enabled ( LVDS port ).  Disabling mode switching.
  intelfb: Initial video mode is 1280x1024-16@60.

This looks promising.  However, I still get a black screen.  I also tried only the `video' or the `vga' option, but both failed.

Am I doing something wrong?
Comment 20 Michal Januszewski 2009-05-21 21:39:38 UTC
(In reply to comment #19)

>   intelfb: 00:02.0: Intel(R) 945GM, aperture size 256MB, stolen memory 7932kB
>   intelfb: Non-CRT device is enabled ( LVDS port ).  Disabling mode switching.
>   intelfb: Initial video mode is 1280x1024-16@60.
> 
> This looks promising.  However, I still get a black screen.  I also tried only
> the `video' or the `vga' option, but both failed.
> 
> Am I doing something wrong?

Have you tried to set other video modes (i.e. vga= values other than 0x31a or mode= values other than 1280x1024)?  Do the intelfb messages in the kernel log change when you boot with vga= only?
Comment 21 Werner Lemberg 2009-05-22 06:03:50 UTC
Yes, the messages change correctly.  For example, booting with `vga=0x318' only correctly gives

  intelfb: Initial video mode is 1024x768-32@60.

However, the screen stays blank.
Comment 22 Michal Januszewski 2009-05-22 09:57:14 UTC
(In reply to comment #21)
> Yes, the messages change correctly.  For example, booting with `vga=0x318' only
> correctly gives
> 
>   intelfb: Initial video mode is 1024x768-32@60.
> 
> However, the screen stays blank.

Could you please do a bisection while using only the intelfb driver in all kernels, in order to find the commit that really introduced the problem?
Comment 23 Werner Lemberg 2009-05-24 06:22:50 UTC
Just to be sure: I really have to compile in intelfb, right?  It's not possible to load the intelfb module with, say initrd?

Sigh.  This means *a lot* of bisecting.  Is there any kernel version which is confirmed to run with my graphics card (in LCD mode) so that I have at least a starting point?
Comment 24 Michal Januszewski 2009-05-24 13:00:12 UTC
(In reply to comment #23)
> Just to be sure: I really have to compile in intelfb, right?  It's not possible
> to load the intelfb module with, say initrd?

It is, but then you'd have to use the mode= parameter instead of vga= on the kernel command line.  I don't think this would help you in any way though -- after each bisection, you still need to rebuild both the kernel and the module.  Otherwise the module will not load.  It's also possible that this was broken by a commit changing code outside of intelfb, and you would not detect this if you were only rebuilding and reloading the module.

> Sigh.  This means *a lot* of bisecting.  Is there any kernel version which is
> confirmed to run with my graphics card (in LCD mode) so that I have at least a
> starting point?

I'm not sure.  I think you should just pick a reasonably old kernel, such as 2.6.26 or 2.6.27 and try with that.  If that version doesn't work, at least you will establish a tighter upper boundary for the bisection.

Note You need to log in before you can comment on or make changes to this bug.