# No console framebuffer with linux-3.12.x and i915

## pappy_mcfae

I have been looking, but I seem to be not looking in the right place.

I upgraded to 3.12.2 today, and thereafter, I lost my console framebuffer. The machine boots. If I allow it time to finish booting up to where I log in (about two minutes), I can log in, then start X. X comes up normally. When I exit X, my framebuffer is there. While X is running, I can use <ctl><alt><Fn>, and switch to other console sessions, and the console is there.

I have been searching and looking, but I'm not seeing anything. If anyone has a clue what the deal is, please let me know. I know that it is kernel related, as 3.11.10 boots just fine, and after installing 3.12.0, I found it has the same issue. I don't think it's a bug as much as someone changed up a few things with the intel driver code, and now, I can only get a frame buffer if I can hold on until I can log in, then hit the up arrow key once (startx).

Thanks in advance.

Cheers,

Pappy

----------

## chithanh

Maybe CONFIG_FRAMEBUFFER_CONSOLE is set to m and the module is not loaded until X starts? If you have enabled printk timestamps, dmesg might tell at which time the framebuffer console initialized.

----------

## pappy_mcfae

Nope. That's easy stuff. I think I may have an idea, though. 

Cheers,

Pappy

----------

## DepreTux

Ooops, I started another thread about the same issue:

https://forums.gentoo.org/viewtopic-t-977764.html

The last kernel update (3.12.4) doesn't seem to bring any fixes to i915, so I'm not compiling it.

----------

## wuzzerd

These are my settings under 3.12.3

```
CONFIG_X86_SYSFB=y

CONFIG_FB=y

CONFIG_FB_BOOT_VESA_SUPPORT=y

CONFIG_FB_CFB_FILLRECT=y

CONFIG_FB_CFB_COPYAREA=y

CONFIG_FB_CFB_IMAGEBLIT=y

CONFIG_FB_MODE_HELPERS=y

CONFIG_FB_TILEBLITTING=y

CONFIG_FB_VESA=y

CONFIG_DRM=y

CONFIG_DRM_KMS_HELPER=y

CONFIG_DRM_I915=y

CONFIG_DRM_I915_KMS=y

CONFIG_SND_HDA_I915=y

```

```
 x11-drivers/xf86-video-intel-2.99.903

```

Several times I had to block the later x11 drivers for various reasons.

Screen bleeding through.

X-server crashing on keyboard events/switching to virtual console.

And (forgot this one) xorg using my boot video size instead on size in xorg.conf.  648x480 Ha!

Hope this helps.

----------

## pappy_mcfae

nomodeset also works for me, unless I want to run X after booting. One of these days, I may understand why they have to break things so badly in the kernel, then take forever to give the actual working fix. I am still playing with it, but due to that reality, I can't recommend anyone use 3.12.x kernels until they fix this issue.

Cheers,

Pappy

----------

## pappy_mcfae

After checking the documentation that comes with the kernel, I can say that they obviously never tried it. 

Adding: 

```
append="video=intelfb:mode=1280x800-32@60.0,accel,hwcursor,vram=8"
```

, as recommended in the documentation, did nothing to mitigate the situation. 

If I use nomodeset, I can't start X. Not only that, I get default 640x480 (stretched to hell). If I use the above, or nothing appended, as long as I allow two minutes for full boot, I can log in and up-key my way to an X session. If I make a mistake, then it takes forever to get things back to right, and only a three finger salute gets me back to where I can boot to a kernel that, um, works.

I sometimes have to wonder about the minds of those who do kernel development. Do they harbor some strange sadistic streak, or what?

Cheers,

Pappy

----------

## DepreTux

I just upgraded to 3.12.5 and I'm still experiencing the same regression.

But my problem differs from yours in that if I do a startx on the blank screen, I only get a the pointer to show, but the rest of my wm doesn't display.

Maybe we should try the mailing list?

----------

## pappy_mcfae

I've started a bug report on this at kernel.org. I added a link to this thread.

Cheers,

Pappy

----------

## TheNiceGuy

Hi, first post here.

I have the same problem. I search everywhere and I couldn't find anything. Like OP, my computer boots up normally but there is no framebuffer. The strange thing is that it will happen sometimes, but most of the time. I can log in, and startx blindly. If I close the xserver the framebuffer is there. I tested a couple of boot kernel parameters, it didn't work. I tried playing with the brightness, it didn't do anything.

I noticed that you made a bug repport and the dev were asking for a kernel bisect. It seems that nobody did it yet. So I decided to give it a try, my first bisect. 

Gentoo's wiki had a great page on how to bisect the kernel: Kernel git-bisect I did the bisect from 3.11 to 3.12.

After a couple of kernel compilling and testing, git bisect gave me the following bad revision:27c053aa8d18d1fa7b83041e36bad20bcdf55514. Which didn't make any sens since it doesn't seems to touch the i915 driver, which is what I have. I tested the kernel, the problem was still there, as expected.

I checked the commit under it, a09e9a7a4b907f2dfa9bdb2b98a1828ab4b340b2, bingo, there were some pretty big changes on the i915 driver. I tested it, the problem was still there.

If that commit made the problem, the one under it should work, right? I tested the commit 9ab073bc45b8b523cc39658925bb44bef35ca657 and the problem wasn't there. There is most likely a problem in the commit above.

That was the kernel's config I use: .config. If you try both of these commit and tell us if it work that might help to fix this problem.

I hope it's been usefull.

EDIT: typos

----------

## DepreTux

Did you try with the more recent 3.13 kernels yet?

I actually went back to 3.2, since I was trying to upgrade from that version to the latest lts...

I will do the bisect and report back ASAP.

----------

## TheNiceGuy

Yes, I've been running on 3.13.5 even if the problem is there. I even tried the lastest git kernel.

----------

## ff11

One bug that crush my hope! I tried the 3.13.6, and it still there.

The 3.11.10 is in EOL, then it has removed from sys-kernel/gentoo-sources.

Maybe we have to go forever with the longterm 3.10.X

I have never felt so sad with linux before.

I think this is related with the "Splitting DRM and KMS device nodes" from the 3.12 (ref: https://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/ )

----------

## pappy_mcfae

Well, I'm glad someone is doing something with this bug. The bug at kernel-dot-org is going nowhere. I have not tried the latest 3.13.x, but I know that 3.13.0 is still a no go. I suppose I could mess around and see if the latest version, and see what happens. 

As for a sad state of affairs, yes. Because XP is about to die, the windows side of this machine is practically dead. I could set it back up for Vista, but I think I'd rather chew glass. Yeah, it has more memory and a bigger hard drive, but it's Vista. 

Now, even Linux is turning this machine obsolete. That totally sucks. I guess it's time to bite the bullet, and upgrade.

Bummer!

Cheers,

Pappy

----------

## Anon-E-moose

Is this what you're seeing? https://bbs.archlinux.org/viewtopic.php?id=173914

If so the last post is interesting. Not sure whether it will fix anything as I don't use intel graphics.

----------

## ff11

 *Anon-E-moose wrote:*   

> Is this what you're seeing? https://bbs.archlinux.org/viewtopic.php?id=173914
> 
> If so the last post is interesting. Not sure whether it will fix anything as I don't use intel graphics.

 

Yes and No! The result of black screen is kind the same and work on 3.11.X like this bug, but my hardware have just 1 GPU (intel gen3 onboard card only), then I don't have issue with radeon and I don't have "video.backlight=vendor" kernel parameter.

I'm searching for the bug, doing some tests. Thanks God, i have knowledge for do it. But I will have to spend a lot of time for what I have seen of this bug (Oh! My headache!).

----------

## Anon-E-moose

If it has to do with the backlight it may not have anything to do with the kernel parameters per se.

One way would be to take it out of config, recompile and see what happens.

I have these options on (don't know why, but they're on)

```
CONFIG_DRM_NOUVEAU_BACKLIGHT=y

CONFIG_FB_BACKLIGHT=y

CONFIG_BACKLIGHT_LCD_SUPPORT=y

CONFIG_BACKLIGHT_CLASS_DEVICE=y
```

Anyway, hope y'all solve it.

----------

## ff11

 *Anon-E-moose wrote:*   

> If it has to do with the backlight it may not have anything to do with the kernel parameters per se.
> 
> One way would be to take it out of config, recompile and see what happens.
> 
> I have these options on (don't know why, but they're on)
> ...

 

Well, it's not this kind of bug. I have spend my whole day rebuilding kernel, search logs, kernel codes, making tests...

After the system boot, if i type the login, pass and start the xorg (even without see the screen), I can see the pointer of the mouse very well and clear.

----------

## till

disabling CONFIG_X86_SYSFB did the trick for me.

----------

## ff11

 *till wrote:*   

> disabling CONFIG_X86_SYSFB did the trick for me.

 

"CONFIG_X86_SYSFB is not set" for me -_-"

By the way, if you are using the KMS you should disable all frame buffer devices drivers, including VGA, Intel, nVidia, and ATI. It's the normal.

----------

## ff11

Before anyone ask, I also tried force the brightness to the max using setpci direct on the hardware, but he result is just one high brightness black screen -_-"

----------

## DepreTux

The problem is gone for me with 3.12.14

I did turn on the PCI_QUIRKS option, so it might have been just that.

----------

## ff11

 *DepreTux wrote:*   

> The problem is gone for me with 3.12.14
> 
> I did turn on the PCI_QUIRKS option, so it might have been just that.

 

This bug is not about the PCI_QUIRKS option. PCI_QUIRKS is always on at my kernel's configs (even the older config I have, case the doc help have: "Disable this only if your target machine is unaffected by PCI quirks", then I never disable it)

Or the 3.12.14 fix, or is not the same bug.

Well, because be stuck on the 3.12.(14-X) isn't the end of the problem, I will test new codes only on the last stable releases (now is 3.13.6, and don't work). And I will be waiting for some more releases before came back to try solve this. In this time, I'm using the 3.10.33.

----------

## ff11

Because we don't have kernel > 3.13.6 yet, I have tested the 3.12.14:

1* After install and reboot, it's work! ^^

2* I reboot 1 more time to confirm, and it don't work anymore. I rebooted more times and keep don't working -_-"

3* I rebooted without boot splash, then worked! ^^

4* I rebooted without boot splash for confirm, and it don't work anymore. I rebooted more times without boot splash and keep don't working -_-" (sometimes, 10% of the tests, it's work in this case)

5* I removed all boot splash things from initramfs, and it keep don't working.

6* I don't know what to do using just the free little time, then I'm back to 3.10.33

I'm not sure, but I feel that this bug is happening just on gen3 intel GPU only (915G/GM, 945G/GM, G/Q33). The other generations seems just have other minor bugs reported (more easy to solve).

----------

## TheNiceGuy

This is pretty much the same here, it will work sometimes, but it mostly doesn't work.

----------

## ff11

More tests using 3.12.14:

* If I plug some monitor on the VGA-out, even if I not use it, the notebook i915 KMS work again (I think the hdmi or tv-out work the same for this bug). Then I just need plugin and remove for each boot. But at the moment, I don't have some light monitor to bring along with the notebook, then I will still using the 3.10.33.

I'm getting close to the responsible code (still having little time to spend on this).

Could you guys confirm if is the same for you?

----------

## ff11

By the way, if you don't have one extra VGA monitor for workaround the bug, then you can just force the kernel to enable it (even without it) with the kernel parameter "video=VGA-1:e" (or maybe "video=HDMI-1:e", if you have hdmi instead)

But I have to remember if you use it: The bug still there, you are just workaround it, not solving. And for this, you paid with the extra allocated VGA resource.

EDIT: By the way 2, just on case, I enabled the CONFIG_DRM_LOAD_EDID_FIRMWARE for possible futures workarounds. I'm not using this now, but after this bug i kinda feel that I will need it someday to force some firmware configs or create my own -_-"

EDIT2: I have make many tests using this workaround and it's work 100% of time for the 3.13.6 in my machine. But I still need of you guys to confirm that for me in another machines, and I will use this information for find the bug in a more proper way.

----------

## pappy_mcfae

I have sent along the commit in question to the open bug on this issue. Considering what I've seen, I find it rather annoying that I had to even pass on the commit to them. How could they NOT know the roots of the issues with that driver were in that commit? 

Cheers,

Pappy

----------

## ff11

 *pappy_mcfae wrote:*   

> I have sent along the commit in question to the open bug on this issue. Considering what I've seen, I find it rather annoying that I had to even pass on the commit to them. How could they NOT know the roots of the issues with that driver were in that commit? 
> 
> Cheers,
> 
> Pappy

 

Well, just stay calm. Let's join more valuable information:

Then:

* Adding the kernel parameter "video=VGA-1:e" (the same way you added the "drm.debug=0xe" or "i915.modeset=1"). Workaround this for you?

----------

## ff11

Seem that this kind of old hardware is not officially supported anymore. They (kernel dot org) can help with instruction, but can't help with make tests, debug...

They want a bisect into the bugged merge:

 *Quote:*   

> 
> 
> Yes, please bisect into the merge. That merge consists of 698 commits, of which 321 touch drivers/gpu/drm/i915, with a total diff stat of 440 files changed, 50821 insertions(+), 18085 deletions(-).
> 
> $ git bisect good a09e9a7a4b907f2dfa9bdb2b98a1828ab4b340b2^
> ...

 

Well, if I had time to do it in the first place, probably, I already had the solution patch make by myself.

I have the workaround until I build some "life time" to spend enough to fix it. If someone of you guys want more speed, just make the bisect and post the result here, I will see the code. I will report back to kernel_dot_org too without much hope, but I will try fix by myself and post some patch (it's not the first time I have to fix intel kernel bug on old hardware by myself anyway).

----------

## M i M

Bug founded.

Gentoo Bugzilla:

https://bugs.gentoo.org/show_bug.cgi?id=508082

Kernel Bug Tracker:

https://bugzilla.kernel.org/show_bug.cgi?id=67191#c43

----------

## ff11

 *M i M wrote:*   

> Bug founded.
> 
> Gentoo Bugzilla:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=508082
> ...

 

I tested the patch (on 3.14.0) and work very well! 7 reboot times without force VGA and no blank screen. Thanks

----------

## ff11

Now, that the "M i M" found the regression, we can try something else:

The Bob Raitz (pappy_mcfae) said: "Version 3.14.1 doesn't work. Version 3.15-rc2 does."

Then, if someone can make the bisect for this, to find what commit that "or fix" "or hide it again", it will be helpful.

The more information we have, the easier it's to find the real cause.

----------

