Ah I forgot, I can boot it with i915.modeset=0.

Some debug logs are vital to know what is going on here.

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

[    7.354170] No ACPI video bus found

You have no driver for your backlight, apparently.

It's not a netbook, it's an ITX board with a separate TFT.

Odd, I would have thought from those warnings that it had an LVDS connection. Can you attach the drm.debug=0xe dmesg.

Dmesg with drm.debug=0xe

http://bsdpaste.bsdgroup.de/40828

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.

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.

I forgot: the display is connected via VGA (the board doesn't have any other connection).

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)?

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)

It's in the repo: git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

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

intel_reg_dumper build from the git repository:

(kernel 2.6.36, kms)

http://bsdpaste.bsdgroup.de/40841

Now the same (intel_reg_dumper) for kernel 2.6.37 and kms:

http://bsdpaste.bsdgroup.de/40844

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.

Sorry for the delay,

dmesg with drm debug for kernel 2.6.36/kms:

http://bsdpaste.bsdgroup.de/40863

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

This patch fails on my 2.6.37 source ...

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().

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;

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.

(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.

>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.

Is this still an issue Alfe?

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 :-/

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).

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?

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 ...

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

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