Bug 22872 - [pineview] Blackscreen after start KMS-based fb on GMA3150
Summary: [pineview] Blackscreen after start KMS-based fb on GMA3150
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri-intel@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-14 17:56 UTC by Piotr Karbowski
Modified: 2012-05-03 10:16 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.37-rc1
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Piotr Karbowski 2010-11-14 17:56:17 UTC
while kernel is booting and it setting bigger console (kms-based framebuffer) instead of highter screen res I am getting just black screen. I think there is a kernel panic.

Netbook Asus 1215n
Graphics card: GMA3150

It may be somehow related to: https://bugzilla.kernel.org/show_bug.cgi?id=22862
Comment 1 Piotr Karbowski 2010-11-14 17:56:45 UTC
Ah I forgot, I can boot it with i915.modeset=0.
Comment 2 Chris Wilson 2010-12-16 14:11:53 UTC
Some debug logs are vital to know what is going on here.
Comment 3 Oliver Herold 2011-01-09 12:35:48 UTC
Same problem as mentioned above. Didn't have any problems with 2.6.32 up to 2.6.36.2 (same config)

OS: Debian Squeeze (64bit)
Hardware: Intel Desktop Board D510MO (Intel Atom plus GMA 3150)
Dmesg: http://bsdpaste.bsdgroup.de/40810
Xorg log: http://bsdpaste.bsdgroup.de/40811

lspci:

00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Intel Corporation DeskTop Board D510MO
	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 43
	Region 0: Memory at f0300000 (32-bit, non-prefetchable) [size=512K]
	Region 1: I/O ports at 20c0 [size=8]
	Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
	Region 3: Memory at f0200000 (32-bit, non-prefetchable) [size=1M]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0f00c  Data: 4189
	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
Comment 4 Chris Wilson 2011-01-09 12:54:57 UTC
[    7.354170] No ACPI video bus found

You have no driver for your backlight, apparently.
Comment 5 Oliver Herold 2011-01-09 13:14:34 UTC
It's not a netbook, it's an ITX board with a separate TFT.
Comment 6 Chris Wilson 2011-01-09 13:23:37 UTC
Odd, I would have thought from those warnings that it had an LVDS connection. Can you attach the drm.debug=0xe dmesg.
Comment 7 Oliver Herold 2011-01-09 14:42:37 UTC
Dmesg with drm.debug=0xe

http://bsdpaste.bsdgroup.de/40828
Comment 8 Chris Wilson 2011-01-09 14:57:22 UTC
So we detected both an LVDS (1280x800) and a VGA connection (1920x1080). Does your panel show any signs of a signal?

This is quite scary:

[    6.404043] [drm:intel_calculate_wm], FIFO entries required for mode: 32
[    6.404049] [drm:intel_calculate_wm], FIFO watermark level: 470
[    6.404055] [drm:pineview_update_wm], DSPFW1 register is eb030f0f
[    6.404061] [drm:intel_calculate_wm], FIFO entries required for mode: 36
[    6.404067] [drm:intel_calculate_wm], FIFO watermark level: 23
[    6.404074] [drm:intel_calculate_wm], FIFO entries required for mode: 309
[    6.404080] [drm:intel_calculate_wm], FIFO watermark level: 193
[    6.404086] [drm:intel_calculate_wm], FIFO entries required for mode: 314
[    6.404092] [drm:intel_calculate_wm], FIFO watermark level: -255

As that hints that we cannot set the FIFO big enough to keep the panel active, which may cause the sync to be lost. Lowering the resolution should be enough in this case.
Comment 9 Oliver Herold 2011-01-09 15:00:19 UTC
Yes of course, if I deactivate KMS it's okay (then I'm in the console). But the Intel driver is of no use without KMS. Furthermore if I choose 2.6.36 if have no problems at all with a resolution of 1920x1080.
Comment 10 Oliver Herold 2011-01-09 15:02:09 UTC
I forgot: the display is connected via VGA (the board doesn't have any other connection).
Comment 11 Chris Wilson 2011-01-09 15:15:10 UTC
I meant any detected signal at 1920x1080 (and at 1024x768 after adjusting the mode with xrandr) with 2.6.37 :). Can you also attach the debug dmesg from 2.6.36.2 along with intel_reg_dumper for both kernels (with KMS)?
Comment 12 Oliver Herold 2011-01-09 15:34:07 UTC
Intel GPU dump? There is no intel_reg_dumper

If so: http://bsdpaste.bsdgroup.de/40837 (Kernel 2.6.36/KMS/runs X in 1920x1080)
Comment 13 Chris Wilson 2011-01-09 15:40:57 UTC
It's in the repo: git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Comment 14 Oliver Herold 2011-01-09 15:41:57 UTC
Lots of data,

dmesg (2.6.36, KMS, Xorg):

http://bsdpaste.bsdgroup.de/40838

xorg log (2.6.36, KMS):

http://bsdpaste.bsdgroup.de/40840
Comment 15 Oliver Herold 2011-01-09 15:53:59 UTC
intel_reg_dumper build from the git repository:

(kernel 2.6.36, kms)

http://bsdpaste.bsdgroup.de/40841
Comment 16 Oliver Herold 2011-01-09 15:59:31 UTC
Now the same (intel_reg_dumper) for kernel 2.6.37 and kms:

http://bsdpaste.bsdgroup.de/40844
Comment 17 Chris Wilson 2011-01-09 16:26:23 UTC
Strange, the dump from 2.6.36 implies that no pipes and no outputs are switched on. In .37, we have the oddity of
                FPB0: 0x004000b3 (n = 0, m1 = 0, m2 = 51)
                FPB1: 0x004000b3 (n = 0, m1 = 0, m2 = 51)
which I suspect is making the hw do silly things.
Comment 18 Oliver Herold 2011-01-09 18:27:33 UTC
Sorry for the delay,

dmesg with drm debug for kernel 2.6.36/kms:

http://bsdpaste.bsdgroup.de/40863
Comment 19 Chris Wilson 2011-01-09 18:51:19 UTC
ARGH! This should remove the false LVDS and hopefully prevent us from misconfiguring the hardware:


diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds
index aa23070..3fbd79c 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -812,6 +812,8 @@ static bool lvds_is_present_in_vbt(struct drm_device *dev,
                if (child->addin_offset)
                        return true;
 
+               return false; /* lying VBT */
+
                /* But even then some BIOS writers perform some black magic
                 * and instantiate the device without reference to any
                 * additional data.  Trust that if the VBT was written into
Comment 20 Oliver Herold 2011-01-09 18:59:27 UTC
This patch fails on my 2.6.37 source ...
Comment 21 Chris Wilson 2011-01-09 19:16:47 UTC
Just cause the intel_lvds_init() to return early before it attaches an LVDS. On your system lvds_is_present_in_vbt() returns true in 2.6.37 but false in 2.6.36, so one easy change is to just put a return false at the start of lvds_is_present_in_vbt().
Comment 22 Oliver Herold 2011-01-09 20:20:30 UTC
Hmm, didn't change anything or I changed the wrong part.


Changed line 810 in intel_lvds.c from true to false ...

 /* However, we cannot trust the BIOS writers to populate
                 * the VBT correctly.  Since LVDS requires additional
                 * information from AIM blocks, a non-zero addin offset is
                 * a good indicator that the LVDS is actually present.
                 */
                if (child->addin_offset)
                        return false;



                /* But even then some BIOS writers perform some black magic
                 * and instantiate the device without reference to any
                 * additional data.  Trust that if the VBT was written into
                 * the OpRegion then they have validated the LVDS's existence.
                 */
                if (dev_priv->opregion.vbt)
                        return true;
        }

        return false;
Comment 23 Oliver Herold 2011-01-10 19:42:35 UTC
Sorry, but it seems the best solution is: not to use Intel graphics anymore. I see lots of bug reports for different kernel versions and lots of problem reports for the release candidates of .37.
Comment 24 Alfe 2011-01-21 13:48:03 UTC
(In reply to comment #23)
> Sorry, but it seems the best solution is: not to use Intel graphics anymore.

Nice remark for the ones of us who are stuck with this hardware.
Comment 25 Oliver Herold 2011-01-21 15:29:32 UTC
>Nice remark for the ones of us who are stuck with this hardware.

I have a PCI slot on this Intel board and now I use some old PCI graphics adapter instead of the integrated one. It's that easy. My remark doesn't hurd anyone, it's Intels lousy software that hurds everyone.
Comment 26 Jesse Barnes 2012-04-18 21:37:41 UTC
Is this still an issue Alfe?
Comment 27 Alfe 2012-04-19 10:44:33 UTC
When I replied to this task (more than a year ago!) it was scanning lots of tickets which sounded at least a little like my problem.  I've got a Dell Latitude E6510 with Intel graphics with full-HD resolution but I'm not sure after so long ago whether this ticket concerns exactly my hardware at all.  Just the described fault sounded like what I experience.  And yes, this problem still exists, sporadically as from the beginning.  In one of ten cases of a re-awaken I am stuck.  I don't dist-upgrade from my Ubuntu 11.04 because of it.  In 11.04 it seems to work most of the time with most features, but newer dists have harder problems again.

My comment here was merely because hints on changing the hardware are not a solution for the problem, just a workaround.  And I guess most people are quite aware that with more or less trouble a hardware change always is an option.  In my case it is not as the hardware belongs to my employer who in question would rather ask me to switch to Windows to solve any driver problems before buying new hardware :-/
Comment 28 Jesse Barnes 2012-04-19 15:21:01 UTC
I have an E6510, but I haven't tried too many suspend/resume cycles on it.  I'll put it in a loop today and see what happens.

It would be great if you could confirm this is still an issue with current kernels (Ubuntu has repos with the very latest -rc kernels you can install).
Comment 29 Jesse Barnes 2012-04-19 15:23:15 UTC
Arg this bug is actually several bugs.

Alfe, since you have very different hardware than the original reporter, your issue is likely caused by something else.  If you're able to try out a new kernel and run into an issue, please file a new bug for it at bugs.freedesktop.org.

Piotr or Oliver, do either of you still have this issue?
Comment 30 Alfe 2012-04-19 15:51:34 UTC
I am using a docking station with a full-HD monitor attached to it.  Hot-plugging from and to the docking station seems to be a *very* critical point.  I typically put the computer to sleep before plugging it, and it still sometimes doesn't wake up anymore afterwards.

Also closing the lid sometimes raises the trouble.

I'm not sure that simple putting to sleep and re-awakening it ever produced the symptom.

JFWIW ...
Comment 31 Jesse Barnes 2012-04-19 17:00:55 UTC
Ok thanks Alfe.  Looks like the original reporters are gone now, can you open new bugs for your issues (docking + plugging, and lid close trouble) at bugs.freedesktop.org?

Thanks,
Jesse
Comment 32 Alfe 2012-05-03 10:16:53 UTC
I've updated to Ubuntu 12.04 in the last days (hence the delay) and can happily report that I could not reproduce the problem anymore with it :-)  My testing wasn't too thorough, though, but at least plugging & unplugging the running system (with a second monitor attached to the docking station), closing & opening the lid and suspending and waking-up worked several times.  Automatic change of the display setup when unplugging or plugging to the second monitor is still a bit jerky and once I ended up with a clone-setup for both displays, but I could manually correct that afterwards (and thus it was not a big deal).

Thank you for your concern,

Alfe

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