# Screen LVDS1 turns black early at boot with kernel 3.14

## charles17

This laptop has been used with an external screen plugged (VGA) for last several months.  

Yesterday I unplugged the VGA from the laptop and was getting a black screen at boot.  Grub2 screen is ok but in the very early stage at boot just after showing the first few kernel lines the built-in screen turns black.  And it stays black until I do CTRL-ALT-F1 + CTRL-ALT--F7.

Surprisingly with the VGA plugged (even when it's power is off) the boot is normal with all the boot messages visible on the built-in screen.  This behaviour is reproducible:  VGA plugged: Screen is ok

VGA unplugged: Screen tuns black at bootKernel is 3.14.14-gentoo. Dmesg doesn't show me any significant differences. Checking with lspci shows

```
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])

        Subsystem: Hewlett-Packard Company Device 30aa

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 0

        Interrupt: pin A routed to IRQ 16

        Region 0: Memory at e8400000 (32-bit, non-prefetchable) [size=512K]

        Region 1: I/O ports at 6000 [size=8]

        Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]

        Region 3: Memory at e8480000 (32-bit, non-prefetchable) [size=256K]

        Expansion ROM at <unassigned> [disabled]

        Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-

                Address: 00000000  Data: 0000

        Capabilities: [d0] Power Management version 2

                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

        Kernel driver in use: i915

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

        Subsystem: Hewlett-Packard Company Device 30aa

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-

        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 0

        Region 0: Memory at e8500000 (32-bit, non-prefetchable) [size=512K]

        Capabilities: [d0] Power Management version 2

                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
```

Please shed some light on me. What is the strange magic with VGA plug?Last edited by charles17 on Tue Feb 10, 2015 10:05 am; edited 2 times in total

----------

## eccerr0r

What brand and model laptop is this?

Likely there's some confusion by the kernel KMS code to read the current brightness (conflict with the BIOS) and set the wrong values in.  Does using the Fn key to brighten the display work or not (just to see if it initialized the display properly or not?)

----------

## charles17

 *eccerr0r wrote:*   

> What brand and model laptop is this?

 It's an HP Compaq nc6320.

 *eccerr0r wrote:*   

> Likely there's some confusion by the kernel KMS code to read the current brightness (conflict with the BIOS) and set the wrong values in.  Does using the Fn key to brighten the display work or not (just to see if it initialized the display properly or not?)

 

Yes, the Fn keys are working, regardless if VGA is plugged or not.

In case VGA is unplugged even the black gets kinda darker or brighter with these keys.

After booting VGA unplugged, doing CTRL-ALT-F1 + CTRL-ALT-F7 and login, xrandr gives *Quote:*   

> $ xrandr
> 
> Screen 0: minimum 320 x 200, current 1024 x 768, maximum 32767 x 32767
> 
> LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 304mm x 228mm
> ...

 

Booting with VGA connected (power off), getting visible screen, simply login, I get *Quote:*   

> $ xrandr
> 
> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 32767 x 32767
> 
> LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 304mm x 228mm
> ...

 

Then any changes I do on LVDS1 are useless but adjusting resolution on on VGA1 changes the built-in screen.

That's annoying   :Sad:   :Evil or Very Mad: 

----------

## eccerr0r

Ok, that's a different problem than what I had...  My HP Envy4t blacked out the screen on startup but I could Fn- to brighten the display and the text is now readable with the backlight turned on.  In your case it's not initializing the LVDS display properly...

----------

## charles17

 *eccerr0r wrote:*   

> In your case it's not initializing the LVDS display properly...

 

Dmesg doesn't even mention LVDS http://pastebin.com/raw.php?i=hMa3X6vB  :Sad: 

Two other postings were here about almost the same problem:

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

https://forums.gentoo.org/viewtopic-p-7596748.html

Each time it's kernel 3.14.14 making problems with CONFIG_DRM_i915_FBDEV=y

No problem here with kernel 3.12.21-r1, it doesn't have that driver which seems to be new in kernel 3.14.xx.

With kernel 3.14.14 for i915 the CONFIG_DRM_i915_FBDEV=y turns out to be essential.  I've had it activated but that doesn't solve my problem.

BTW: I'm using grub2, no EFI.

Any idea how to debug or to collect relevant information for fixing?

----------

## eccerr0r

Interesting, I'll have to try 3.14.x and see if it's reproduceable on my computer(s) - I'm using 3.12.21 which doesn't exhibit the problem.  I have a Core i5-3317U and an Atom N270+945G laptop that I'll need to try it on...

----------

## charles17

Meanwhile kernel 3.14 is version gentoo-sources:3.14.31 and the problem persists.  Kernels 3.16 and 3.17 were ok but I'd like this fixed in 3.14 as it presently is the latest "longterm release kernel".

What else could I do to find the root cause of the display turning black at boot?

----------

## chithanh

If kernel 3.16 works ok, it is probably a bug in the kernel's i915 driver, which was fixed in later kernel releases.

You could do a git bisect to find the commit which fixed it, then apply to your 3.14 kernel.

A workaround may be to force the output to on with video=LVDS-1:e kernel parameter or something (adjust to the actual kernel output name per /sys/class/drm entries).

----------

## charles17

 *chithanh wrote:*   

> If kernel 3.16 works ok, it is probably a bug in the kernel's i915 driver, which was fixed in later kernel releases.
> 
> You could do a git bisect to find the commit which fixed it, then apply to your 3.14 kernel.

 

After some trouble with git bisect I realized I should try reverse bisect. So in my output good and bad are inverted.  The full log ends with  *Quote:*   

> # good: [d978ef14456a38034f6c0e94a794129501f89200] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12
> 
> git bisect good d978ef14456a38034f6c0e94a794129501f89200
> 
> # bad: [d1a59868efa65379482c79de997973b06cefb9d2] drm/i915: Prevent use-after-free of inherited framebuffer
> ...

 

And the final message reads *Quote:*   

> 484b41dd70a9fbea894632d8926bbb93f05021c7 is the first bad commit
> 
> commit 484b41dd70a9fbea894632d8926bbb93f05021c7
> 
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> ...

 As said above, in these outputs good means bad and bad means good.

What's confusing for me is that the last run produced a kernel /boot/vmlinuz-3.13.0+ when I ecpected some late 3.14 or early 3.15. 

How could this last commit be the fix for the error I am having in kernel 3.14?

Internet search yields git.kernel.org/ and bugs.freedesktop.org.  How could I see it's in kernel 3.14 or not?

----------

## chithanh

Finding out which branch or tag contains that particular commit is possible with

```
git branch --contains 484b41dd70a9fbea894632d8926bbb93f05021c7

git tag --contains 484b41dd70a9fbea894632d8926bbb93f05021c7
```

----------

## charles17

Sounds quite easy. So I did  *Quote:*   

> $ cd /usr/src/linux-stable/
> 
> $ git branch --contains 484b41dd70a9fbea894632d8926bbb93f05021c7 
> 
>   master
> ...

 So it looks to me as being fixed starting from v3.15

How could I get it applied to v3.14.31 for testing?

Created bug 539968 and upstream bug 94231.

----------

