Bug 13249
| Summary: | Intel 945GM: Boot option`vga=0x31a' breaks display of TTYs | ||
|---|---|---|---|
| Product: | Other | Reporter: | Werner Lemberg (wl) |
| Component: | Other | Assignee: | DRI developer's list (dri-devel) |
| Status: | CLOSED OBSOLETE | ||
| Severity: | high | CC: | akpm, alan, florian, mrmazda, pablo, rjw, spock |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.30-rc5-git1-18-vanilla | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
boot log message from v2.6.27-0.1
boot log message from v2.6.28-0.1 config file for v2.6.27-0.1 config file for v2.6.28-0.1 |
||
Reassigned to dri-devel. Was 2.6.29 OK? I don't know. I've never tried the 2.6.29 series. 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).
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. (on the other hand, you don't need other 'graphics-hardware-accessing' things with kms. just disable intelfb or vesafb in the kernel) > Do you have CONFIG_DRM_I915_KMS set in your kernel config No. > or are using i915.modeset=1 on the kernel cmdline? No. 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> 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. Created attachment 21402 [details]
boot log message from v2.6.27-0.1
Created attachment 21403 [details]
boot log message from v2.6.28-0.1
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
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
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 (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? 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? (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? 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'... (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'. 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? (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? 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. (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? 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? (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. |
[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...