Bug 9076

Created attachment 7825 [details]
Xorg.log

I'm not seeing this problem on my 64-bit G965 system, either with current head 
of modesetting, or the head Joshua was using.

Your version of the driver is missing some interesting debugging output.  Could
you update and post a new log?

Created attachment 7945 [details]
Xorg.log r2

Updated to git head 81dde11d419c8f9198ab3502d9813d66d0bc6d6d.  I'm still seeing
the same symptoms (using the internal display, with no external monitor
connected).  The display goes blank (but the backlight is on).	This time,
though, when Ctrl+Alt+Backspacing to kill the X server, instead of restoring
the original text video mode, the screen's backlight turns off.

Hope the new logfile helps.  Thanks for looking into this.

OK, a few things I was concerned about looked good there.  Could you flip the
"if (0)" in i830_bios.c to "if (1)" and attach the resulting
/tmp/xf86-video-intel-VBIOS?

(oh, also, clearing the NEEDINFO state helps make sure I see the bug again)

Gordon: this bug is about LVDS support, so you wouldn't see it on a desktop system.

Created attachment 8060 [details]
xf86-video-intel-VBIOS

Video BIOS dump, as requested.

I updated to fde52de870c84821ab457e17634c334a10cf71ab.

What resolution is your panel supposed to be?  I thought we might have a h/vsync
polarity issue, but looking at your bios it seems confused as to whether you've
got 1024x768 or 1440x900.

The builtin native flatpanel resolution is 1440x900.

Interestingly enough, though ... using the 1.7.3 release, I can only drive my 
1600x1200 external monitor at 1024x768.  I wonder if those two things are 
related.

OK, thanks.  My guess was wrong.  However, in the meantime we've done a massive
overhaul to the mode setting paths that may help.

Created attachment 8172 [details]
Xorg.log r3

Updated to 2ef4c5e8f6444aad192304e5a2f7a0c77bfb917d, and I'm still seeing the
same symptoms as before.  New Xorg.log is attached.

Created attachment 8280 [details]
Xorg.log r4

Any more ideas on this?  I've updated to head
d960deab39eef91fb82b9f23118323aeb4c9c63e, and I'm still not seeing improvement.

Not sure if this'll help, but could you try changing I9XX_P2_LVDS_SLOW_LIMIT in
i830_display.c to 100000 -- your LVDS reg sounds like it's in dual-channel mode,
but we're setting things up for single-channel.

Created attachment 8308 [details]
Xorg.log r5

I changed the #define and recompiled/reinstalled.  Still no luck,
unfortunately. :-/  New Xorg.log (with the #define changed) is attached.

I don't see too much difference between this one and the previous, but I don't
understand video drivers enough to know what's significant and what's not, so
I'll attach it anyway. ;)

Thanks again for taking the time to troubleshoot this.

Created attachment 8628 [details]
Xorg.log r6

Updated to 44eacf2323454e26b535cc5a4f0789cb0ff0e7fb.  Still seeing the same symptoms.  New Xorg.log attached.

I notice that this time, there was one line in there that looked rather suspicious to me:

(EE) intel(0): I830 Vblank Pipe Setup Failed 0

From the r5 log, it looks like we didn't program the fast-mode clock in.  So, I'm wondering if you could try the same change in the current code (#define I9XX_P2_LVDS_SLOW_LIMIT 100000), and if that doesn't work, put an ErrorF("dpll %08x\n", dpll) at the end of i830_crtc_mode_set() to make sure we're trying to set the clock as expected.

Created attachment 8932 [details]
Xorg.log r7

Updated to d5df52be59...

Still no love.  New Xorg.log (with the dpll values, and the LVDS change, as requested) is attached.

I note that in this log, the BIOS and the driver seem to disagree about the H/VSync polarity.  (Or at least, one gives a modeline with "-hsync -vsync", and the other doesn't.)  I don't remember seeing that before.  I wonder if maybe it's an issue after all.

hmm.  I just now noticed the Hardware type on this bug was set incorrectly.  This is an Intel Core 2 Duo machine running in 64-bit mode, not an IA-32 machine.

Sorry, I read the wrong line of the log.  The limit I needed you to set was 90000, rather than 100000 (your chosen clock is 100000, but the target was 95000ish).  I'll check if we can set that limit generally, if this works for you.

Created attachment 9052 [details]
Xorg.log r8 partial

Progress!  Sort of ... it did something different this time, anyway. ;)

I've updated to 14ee9195d... on master, with the limit changed as you requested.

X starts and displays random garbage (garbage at 1440x900, at least), and then hard-locks the machine.  I couldn't reboot even using Alt+SysRq.

I've attached the Xorg.log, though it appears to end abruptly.  I don't know how much of it made it to disk before the machine crashed.  I tried to Alt+SysRq+Sync before rebooting, but I suspect that didn't work either.

That log looked pretty good, though I'm confused as to how we could have hard-locked things.  Could you try removing your VideoRam line?

Tried removing the VideoRam line, got the same results.  Tried commenting out the other Option lines in the driver section, and commenting out the HorizSync and VertRefresh options as well, still same results.  The screen displays garbage, and the machine hard-locks.

New code in master may help with mysterious issues like this, so please try again.

The bug priority was upgraded (P2->high) with the bugzilla configuration change.
I'm Changing the priority back to the normal one.
Sorry for the spam.

Seems mostly happy now with the I9XX_P2_LVDS_SLOW_LIMIT set to 90000.

There are two other issues, but they're probably not related to this bug: First (and most worrisome), the X server (1.2.99.902) crashes whenever the display gets reset (e.g. by kdm on logout).  Second, DRI doesn't seem to be working, so OpenGL is totally unaccelerated.  Would you like me to file separate bug reports for these, or...?

Thanks a lot for the help!

setting I9XX_P2_LVDS_SLOW_LIMIT to 90000
helped me with Debian bug http://bugs.debian.org/415061
(Dell Inspiron 640m, Intel 945GM, 1400x900 panel, Core Duo)

OK, could you test the code in master at this point?  It should fix things automatically.

Created attachment 9242 [details]
Xorg log with 1.9.92 + patches

This is not using a complete update to current master.  The following post 1.9.92 patches have been applied to a 1.9.92 debian source archive:

 - Move vendor ID check in the utils to after pci_device_probe.
 - Make i830_sdvo_write_sdvox write everything twice.
 - Add debug output for ADPA.
 - Print the mode actually being set per pipe.
 - Attempt to fix single/dual-channel issues on i9xx LVDS panels.

At this stage it still does not work, presenting me with a display overlaid with vertical purple lines.

If I also set I9XX_P2_LVDS_SLOW_LIMIT to 90000 on top of this things work again (although that also works purely on top of 1.9.92 in my case).  I can also upload logs of either of those two (working) runs as well if you would like.

Note that this laptop, an HP Compaq nx6320 (model RM714PA), has a 1400x1050 display, slightly different from the 1440x900 display that the reporter of this bug has.

Thanks,
Andrew McMillan.

Thanks for noting that setting the limit still fixed it.  Could you try with current master?

In summary:

   :-)

From my previous run, I have:

(a) reverted the value of I9XX_P2_LVDS_SLOW_LIMIT to 112000 as it normally is, and
(b) applies patch f7befe50af4c13554d1f7aee6b05848ac312411b (i.e. Power on the LVDS B-channel pairs only when we've chosen dual-channel mode.)

So, with this new patch applied and the I9XX...SLOW_LIMIT reverted everything works correctly for me.

Do you want an Xorg log with that?

I will check when the proper 1.9.93 Debian packages are released, likely some time in the next few days, but it certainly looks like you've nailed it.

Thanks,
Andrew McMillan.

I can also confirm that it all works for me with the latest packages of 1.9.93 from Debian.

Thanks.

*** Bug 10260 has been marked as a duplicate of this bug. ***

Looks like this bug has been fixed; thanks for helping.