Created attachment 22939 [details]
Xorg log

Created attachment 22940 [details]
Kernel config

Created attachment 23220 [details]
kernel boot log for 2.6.29-rc6

Initialization still fails as of this kernel version.
The display remains black with backlight on.

Having a VGA display connected (connecting after booting or while at boot loader) sees to go undetected, /sys/class/drm/card0-VGA-1/modes remains empty.


Note1: I adjusted INTELPllInvalid intel_display.c to combine duplicate outputs so it does not push previous messages out of kernel log buffer.

Note2: Starting Xorg does not affect what's visible on LVDS and Xorg crashes in GEM code when exiting.

This seems to be the same problem that I have. I also tried 2.6.29-rc8 with KMS enabled on my Acer TravelMate 660 and everything seems to boot fine except that I get a black screen.
if it's helpful I can provide my logs, I just don't have them here right now.

Created attachment 24173 [details]
dmesg of 2.6.29 with KMS enabled

I still have this problem with 2.6.29. I'll attach dmesg and my Xorg.0.log.
Let me know if there's anything I can do/should try.

Created attachment 24174 [details]
Xorg.0.log with kernel 2.6.29 and KMS enabled

Ugg, I can't even get 2.6.29 to boot on my 855 machine (though I think it's an initrd problem).  Working on fixing that now so I can test properly.

(In reply to comment #7)
> Ugg, I can't even get 2.6.29 to boot on my 855 machine (though I think it's an
> initrd problem).  Working on fixing that now so I can test properly.

Hi Jesse, any news regarding KMS on 855 chipsets?

Yeah just got my machine working again, I expect to have some fixes shortly.

Ok my 855GM is working fine with 2.6.30-rc2 and both 2.6.3 and git master drivers using KMS.  The 2.6.29 kernel is missing a few fixes though; can you try 2.6.30-rc2 or something from Eric's drm-intel branch to see if things are fixed for you now?

Created attachment 25128 [details]
kernel boot log for 2.6.30-rc3

Still no difference here with 2.6.30-rc3 from linux console point of view.

When booting with KMS enabled I always end up with the black screen (e.g. backlight is on, but it displays only black).
Some information that might help, the bottom edge of the screen seems to have a 10-20 pixel high fading from black to dark gray (dark gray on bottom of screen).

Created attachment 25129 [details]
Xorg.0.log with kernel 2.6.30-rc3 and KMS enabled

Running Xorg does not cause any visible change on screen, even starting some xterm, nothing shows up. (for a i915 system where KMS works, Xorg starts with black screen so an app is required to check if X works)

When closing the xterm Xorg crashed on me. (see Xorg.0.log and few lines at end of dmesg attached in previous comment).

Software in use (Gentoo):
  x11-base/xorg-server-1.5.3-r5
  x11-drivers/xf86-video-intel-2.6.3-r1
  x11-libs/libdrm-2.4.5
  media-libs/mesa-7.3-r1

(In reply to comment #12) 
> Software in use (Gentoo):
>   x11-base/xorg-server-1.5.3-r5
I think you need xorg-server 1.6 for kms. You can get the ebuild in the x11 overlay. But I didn't try it yet.
Btw: I have the same machine (Travelmate 660). And the same results with kms.

(In reply to comment #11)
> When booting with KMS enabled I always end up with the black screen (e.g.
> backlight is on, but it displays only black).
> Some information that might help, the bottom edge of the screen seems to have a
> 10-20 pixel high fading from black to dark gray (dark gray on bottom of
> screen).
Besides xorg, the framebuffer should work with kms, shouldn't it?

(In reply to comment #13)
> (In reply to comment #12) 
> > Software in use (Gentoo):
> >   x11-base/xorg-server-1.5.3-r5
> I think you need xorg-server 1.6 for kms. You can get the ebuild in the x11
> overlay. But I didn't try it yet.
> Btw: I have the same machine (Travelmate 660). And the same results with kms.
Not sure here though I guess it's more a thing of libdrm/intel driver than xorg-server.
Until console works I consider this part as secondary and don't really care about an update of xorg... (but once console work I will do so as I did on a i915 system)

> Besides xorg, the framebuffer should work with kms, shouldn't it?
Linux console should definitely work (with drmintelfb or how it's called exactly) independently of userspace! (though it doesn't yet)

Your X log looks pretty funky, it appears the memory manager failed to start up at all...  Can you try w/o an xorg.conf?  The kernel log looks ok, it appears that fbcon is loaded and displaying something, but apparently not on your screen.

(In reply to comment #15)
> Your X log looks pretty funky, it appears the memory manager failed to start up
> at all...  Can you try w/o an xorg.conf?  The kernel log looks ok, it appears
> that fbcon is loaded and displaying something, but apparently not on your
> screen.

Will do.

Is there a way to find out where kernel is displaying it's framebuffer?

xrandr against X told me it would be LVDS with 1400x1050... (and VGA, DVI were marked as not connected)

Created attachment 25141 [details]
Xorg.0.log with kernel 2.6.30-rc3 and KMS enabled but no xorg.conf

Same result without xorg.conf, black screen, X crashing when it would "reset" (e.g. last client exists).

changing resolution with xrandr makes the backlight go off an on again (so it does something) but screen remains the same.
I also tried to move output from LVDS1 to VGA1 (enabled a mode on VGA1, --off for LVDS1, but screen remained black with active backlight - no VGA monitor connected)

Created attachment 25142 [details]
contents of /sys/kernel/debug/dri/{0,64}

In case something useful can be extracted from /sys/kernel/debug/dri/{0,64}/* here is an archive (.tar.gz) with its content.

I saved the content with an iteration like this:
cd /sys/kernel/debug/dri/0
for X in *; do cat $X > /tmp/0/$X; done
cd /sys/kernel/debug/dri/64
for X in *; do cat $X > /tmp/64/$X; done
cd /tmp
tar -zcf archive.tar.gz 0 64

Can you try the 2.7.0 driver instead?  Also, for the framebuffer console you'll need to modprobe i915 modeset=1 after loading fbcon (or building it in, it's under CONFIG_FRAMEBUFFER_CONSOLE).

(In reply to comment #19)
> Also, for the framebuffer console you'll
> need to modprobe i915 modeset=1 after loading fbcon (or building it in, it's
> under CONFIG_FRAMEBUFFER_CONSOLE).
> 
vanilla-sources-2.6.30-rc4
CONFIG_FRAMEBUFFER_CONSOLE=y

- started kernel without loading i915 module, showed all bootup messages (default behaviour)
- I turned X off for this
- manually modprobed i915 modeset=1 made the whole screen black (like described before) with following dmesg:

[   61.036660] i915 0000:00:02.0: setting latency timer to 64
[   61.372602] i2c-adapter i2c-1: unable to read EDID block.
[   61.415138] i915 0000:00:02.0: VGA-1: no EDID data
[   61.660393] allocated 1400x1050 fb: 0x01fff000, bo f6636d40
[   61.662778] Console: switching to colour frame buffer device 175x65
[   61.998031] [drm] LVDS-8: set mode 1400x1050 e
[   62.207231] fb0: inteldrmfb frame buffer device
[   62.207234] registered panic notifier
[   62.207244] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

I tried again with kernel 2.6.30-rc4, xserver-xorg 1.6.1 and xserver-xorg-video-intel 2.7.99.1. The Problem is still the same, as soon as the KMS framebuffer starts the screen turns back.
I'll attach logs from the kernel and X with KMS enabled and disabled.

Created attachment 25546 [details]
dmesg with KMS disabled

Created attachment 25547 [details]
Xorg.0.log with KMS disabled

Created attachment 25548 [details]
dmesg with KMS enabled

Created attachment 25549 [details]
Xorg.0.log with KMS enabled

On the kernel bugzilla I submitted the same bug also.
For reference: http://bugzilla.kernel.org/show_bug.cgi?id=13214

To me it looks like this bug have nothing to do with xorg/xserver, it's a kernel bug.

Created attachment 26294 [details]
Register dump for xf86-video-intel-2.7.1 user mode (2.6.30-rc7-git kernel as of today)

Created attachment 26295 [details]
Register dump for KMS with 2.6.30-rc7-git kernel as of today

Created attachment 26296 [details]
dmesg matching attachment 26295 [details]

Created attachment 26297 [details]
Xorg.log matching attachments 26295 and 26296

Running Xorg as "Xorg -nolisten tcp -noreset" and running xterm on it. (X crashed when exiting xterm)

(x11-libs/libdrm-2.4.9, media-libs/mesa-7.3-r1, x11-base/xorg-server-1.5.3-r5)

Can you guys confirm the kernels you tested had this fix?

commit e76a16deb8785317a23cca7204331af053e0fb4e
Author: Eric Anholt <eric@anholt.net>
Date:   Tue May 26 17:44:56 2009 -0700

    drm/i915: Fix tiling pitch handling on 8xx.

8xx chips were pretty busted until Eric tested on his 8xx machines and put together that fix.

(In reply to comment #31)
> Can you guys confirm the kernels you tested had this fix?
> 
> commit e76a16deb8785317a23cca7204331af053e0fb4e
> Author: Eric Anholt <eric@anholt.net>
> Date:   Tue May 26 17:44:56 2009 -0700
> 
>     drm/i915: Fix tiling pitch handling on 8xx.
> 
> 8xx chips were pretty busted until Eric tested on his 8xx machines and put
> together that fix.
> 

2.6.30 has it, but that one fails just as the previous kernels... (I've not tested 2.6.31-git yet though I plan to do so over the coming week-end)


Those I remember who added themselves to this bug (or is equivalent http://bugzilla.kernel.org/show_bug.cgi?id=13214) also have Acer TM66x or similar Acer laptops...

I do rather think it has something to do with the mode line programmed by KMS (please compare register dumps as in attachment #26294 [details] and attachment #26295 [details])

Things that stand out (single-channel versus dual-channel LVDS and DPLL_B[p2]):
--- attachment #26294 [details] (xf86-video-intel-2.7.1, good)
+++ attachment #26295 [details] (2.6.30-rc7 KMS, bad)
...
-(II):                 ADPA: 0x00001c18 (disabled, pipe A, +hsync, +vsync)
-(II):                 LVDS: 0xc000833c (enabled, pipe B, 18 bit, 2 channels)
+(II):                 ADPA: 0x80000c00 (enabled, pipe A, -hsync, -vsync)
+(II):                 LVDS: 0xc0008300 (enabled, pipe B, 18 bit, 1 channel)
...
 (II):             DSPBSIZE: 0x04190577 (1400, 1050)
-(II):             DSPBBASE: 0x03000000
+(II):             DSPBBASE: 0x01fff000
 (II):             DSPBSURF: 0x00000000
 (II):          DSPBTILEOFF: 0x00000000
 (II):            PIPEBCONF: 0x80000000 (enabled, single-wide)
 (II):             PIPEBSRC: 0x05770419 (1400, 1050)
-(II):            PIPEBSTAT: 0x00000000 (status:)
+(II):            PIPEBSTAT: 0x80000202 (status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS)
 (II):                 FPB0: 0x0003170d (n = 3, m1 = 23, m2 = 13)
 (II):                 FPB1: 0x00021207 (n = 2, m1 = 18, m2 = 7)
-(II):               DPLL_B: 0x90020000 (enabled, non-dvo, default clock, LVDS mode, p1 = 2, p2 = 7)
+(II):               DPLL_B: 0x90010000 (enabled, non-dvo, default clock, LVDS mode, p1 = 1, p2 = 14)
 (II):            DPLL_B_MD: 0x00000000
-(II):             HTOTAL_B: 0x06670577 (1400 active, 1640 total)
-(II):             HBLANK_B: 0x06670577 (1400 start, 1640 end)
-(II):              HSYNC_B: 0x061705a7 (1448 start, 1560 end)
-(II):             VTOTAL_B: 0x04280419 (1050 active, 1065 total)
-(II):             VBLANK_B: 0x04280419 (1050 start, 1065 end)
+(II):             HTOTAL_B: 0x06970577 (1400 active, 1688 total)
+(II):             HBLANK_B: 0x06970577 (1400 start, 1688 end)
+(II):              HSYNC_B: 0x05f70587 (1416 start, 1528 end)
+(II):             VTOTAL_B: 0x04290419 (1050 active, 1066 total)
+(II):             VBLANK_B: 0x04290419 (1050 start, 1066 end)
 (II):              VSYNC_B: 0x041d041a (1051 start, 1054 end)

Bruno, yeah that seems likely.  I wonder why the mode timings are different, they should both be coming from EDID or VBT data and so should be the same.  The fact that they're different might lead to different PLL calculations which would explain the dual vs. single channel config...  Looks like the UMS case is definitely using EDID data, why would KMS use different data?

EDID (according to the X log):

(II) intel(0): clock: 108.0 MHz   Image Size:  305 x 228 mm
(II) intel(0): h_active: 1400  h_sync: 1448  h_sync_end 1560 h_blank_end 1640 h_border: 0
(II) intel(0): v_active: 1050  v_sync: 1051  v_sync_end 1054 v_blanking: 1065 v_border: 0

whereas the mode used is:

(II) intel(0): Modeline "1400x1050"x60.0  108.00  1400 1416 1528 1688  1050 1051 1054 1066 (64.0 kHz)

The clocks seem the same though (both 108), so I'm not sure why our PLL calculations end up different.

Ma Ling has worked in this area most... any ideas Ling?

Created attachment 27110 [details]
pleaset try the patch on your machine, thanks.

I think the reason may be the chip set is detected as 852, and all 8xx class chips have the 66/48 split, not just 855.

Thanks
Ma Ling

Created attachment 27119 [details]
dmesg

proposed patch didn't work. Loading i915 module after system startup, so relevant messeges appear last. Screen went black as before. System configuration:
gentoo-sources-2.6.30-r1

Btw. startup of Xorg crashed the system completely. Configuration:
- xorg-server-1.6.1.901-r3
- xf86-video-intel-2.7.1
- mesa-7.4.2
- libdrm-2.4.11

Same status here, the patch makes no difference.

The output of regdumper with and without the patch from attachment #27110 [details] is 100% identical.

An attempt (with and without patch) with linux-2.6.31-rc1 with drm-fixes from airlied's tree merged on top (as of 2 hours ago) makes no difference.

Comparing registers as set by VESA it's probably the single channel versus dual channel that causes the black display (most settings for pipe B match of KMS match either VESA or UMS, the difference standing out is 2 channel for both UMS and VESA but 1 channel for KMS)

Is there a way to "force" KMS to work in dual-channel mode (even if it's just a testing-patch that would break other systems)? This would also allow verifying my hypothesis that the channel count is the culprint.

tried vanilla-sources 2.6.31-rc3 today. Still no improvements. Everything black. But it seems xserver (version 1.6.2) does not hang anymore. Would it be possible to resolve this issue for 2.6.31?

http://bugs.freedesktop.org/show_bug.cgi?id=22262 has a patch to check the dual/single channel status.  Has anyone tried that?

(In reply to comment #38)
> http://bugs.freedesktop.org/show_bug.cgi?id=22262 has a patch to check the
> dual/single channel status.  Has anyone tried that?

The patch in attachment #27708 [details] of bug #22262 unfortunately does not help in my case. It does choose the value of lvds_is_dual_channel correctly, but it does not program the registers accordingly (e.g. regdump show exactly the same result with and without that patch)

Oh, I have an idea of what it might be:

KMS:
DPLL_B: 0x90010000 (enabled, non-dvo, default clock, LVDS mode, p1 = 1, p2 = 14)
pipe B dot 96000 n 3 m1 23 m2 13 p1 1 p2 14

UMS:
DPLL_B: 0x90020000 (enabled, non-dvo, default clock, LVDS mode, p1 = 2, p2 = 7)
pipe B dot 96000 n 3 m1 23 m2 13 p1 2 p2 7


As visible, appart from the wrong channel choice (1 for KMS, 2 for UMS) the p1 and p2 are different too.

Looking at the code in intel_display.c there is 
#define I8XX_P2_LVDS_SLOW             14
#define I8XX_P2_LVDS_FAST             14 /* No fast option */

Not sure if the I8XX_* apply for all I8XX or not... Could it be that the FAST started existing around I830 and should be represented here?

So for my i855 I8XX_P2_LVDS_FAST should probably be 7 instead of 14 (don't know if some other change might be needed ...)

One of those dual channel patches just landed in drm-intel-next, it might work better than Ma Ling's last patch?

Ling, any ideas on this one?

Created attachment 27761 [details]
pleaset try the patch on your machine in UMS mode, thanks.

The root cause seem to be channel type. today I sent one patch on 9xx platform to set lvds dual/single channe. so let me try to find the right approach to judge dual/single channel on this platform.

Thanks
Ma Ling

(In reply to comment #42)
> Created an attachment (id=27761) [details]
> pleaset try the patch on your machine in UMS mode, thanks.
> The root cause seem to be channel type. today I sent one patch on 9xx platform
> to set lvds dual/single channe. so let me try to find the right approach to
> judge dual/single channel on this platform.
> Thanks
> Ma Ling 
BTW
by this patch please upload your X log file with modedebug option on.
thanks
Ma lIng

Created attachment 27771 [details]
Request Xorg.log

Hi Ming,

Here is the result for patch in attachment #27761 [details], but I had to apply the patch to i830_lvds.c instead of i830_dvo.c in order to get the output line. (hence the DEBUG3 as I added the debug lines to multiple files and numbered them to know which file it came from).

Created attachment 27773 [details]
Xorg log

requested log. I patched xf86-video-intel-2.7.1 without problems
kernel 2.6.31-rc3

Created attachment 27780 [details]
pleaset try the patch on your machine in KMS mode, thanks.

I think the patch should fix the issue.

Thanks
Ma Ling

Created attachment 27786 [details]
reject of failed Hunk #3

I tried to patch 2.6.31-rc3 with following output:
patching file drivers/gpu/drm/i915/i915_drv.h
patching file drivers/gpu/drm/i915/intel_display.c
Hunk #3 FAILED at 643.
1 out of 5 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_display.c.rej
patching file drivers/gpu/drm/i915/intel_lvds.c
Hunk #1 succeeded at 848 (offset -8 lines).
Hunk #2 succeeded at 1035 (offset -8 lines).

(In reply to comment #47)
> Created an attachment (id=27786) [details]
> reject of failed Hunk #3
> I tried to patch 2.6.31-rc3 with following output:
> patching file drivers/gpu/drm/i915/i915_drv.h
> patching file drivers/gpu/drm/i915/intel_display.c
> Hunk #3 FAILED at 643.
> 1 out of 5 hunks FAILED -- saving rejects to file
> drivers/gpu/drm/i915/intel_display.c.rej
> patching file drivers/gpu/drm/i915/intel_lvds.c
> Hunk #1 succeeded at 848 (offset -8 lines).
> Hunk #2 succeeded at 1035 (offset -8 lines).

the patch is against v2.6.29-rc1-26127-gdff33cf :)

(In reply to comment #48)
> the patch is against v2.6.29-rc1-26127-gdff33cf :)
> 
I'm really sorry, but gentoo has this version not available. Could you please make a patch against something non rc? Or something against an rc of 2.6.31? Thanks

Created attachment 27810 [details] [review]
Adapted variant of Ming's patch that works for me

This patch (adapted from Ming's patch in attachment #27780 [details]) works for me.

I essentially had to remove the "IS_I9XX(dev)" check in intel_find_best_PLL()
to make it work.

I don't know if that has any side-effects on other non-I9XX chips.


With KMS now working when using the patch I had a new look at Xorg running on top of it, but that one crashes as soon as I start enlightenment... The details are for a different/new bug (and first an update of Xorg... (x11-base/xorg-server-1.5.3-r6, media-libs/mesa-7.3-r1, x11-libs/libdrm-2.4.9, x11-drivers/xf86-video-intel-2.7.1))

Created attachment 27827 [details]
dmesg

(In reply to comment #50)
Bruno's patch works here, too. :-D 
I patched kernel 2.6.31-rc3 without rejects. KMS in general works. I get an 1400x1050 resolution on my framebuffer screen. But there are some error messages during the startup of the kernel (found in dmesg at second 1)

Xorg works without problems (except opengl beeing slow, but that's also the case without kms). Here are the version numbers:
x11-drivers/xf86-video-intel-2.7.1
x11-base/xorg-server-1.6.2
x11-libs/libdrm-2.4.11
media-libs/mesa-7.4.4

Created attachment 27828 [details]
Xorg log

of the above configuration with kms enabled

Created attachment 27845 [details]
pleaset try the patch on your machine in KMS mode, thanks.

sorry for slow reply, this is updated version, please try it.

Thanks
Ma Ling

Created attachment 27855 [details]
reject of patch on 2.6.31-rc3

(In reply to comment #53)

linux-2.6.31-rc3 # patch -p1 < /home/ich/Downloads/0001-dual_lvds.patch 
patching file drivers/gpu/drm/i915/i915_drv.h
patching file drivers/gpu/drm/i915/intel_display.c
Hunk #2 FAILED at 643.
1 out of 4 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/intel_display.c.rej
patching file drivers/gpu/drm/i915/intel_lvds.c
Hunk #1 succeeded at 848 (offset -8 lines).
Hunk #2 succeeded at 1035 (offset -8 lines).

(In reply to comment #53)
> Created an attachment (id=27845) [details]
> pleaset try the patch on your machine in KMS mode, thanks.
> 
> sorry for slow reply, this is updated version, please try it.
Hi Ling,

This version does not work.

Changing I8XX_P2_LVDS_FAST from 14 to 7 is required for KMS to program LVDS correctly for the display. (I did not dump variables this time, just checked for visible result)

Thus attachment #27810 [details] [review] provides a working patch (including adjustment to apply against 2.6.31-rc3).

Delta between patches in attachment #27780 [details] and #27810:
- adjust removed code to match 2.6.31-rc3
- drop IS_9XX() check in intel_find_best_PLL()
- fix argument to intel_lvds_detect_channel_type()

Delta between patches in attachment #27810 [details] [review] and #27845:
- revert I8XX_P2_LVDS_FAST to 14
- revert adjust removed code to match 2.6.31-rc3

Not sure if #23399 is relate to this?

(In reply to comment #56)
> Not sure if #23399 is relate to this?

It really looks, like it is. The only thing that does not fit with is the fact, that here the backlight stays on. While Laurent describes in comment #10 that it turns off. 
He probably could try the kernel patch Bruno provided in attachment #27810 [details] [review].

bug# 23399 doesn't use dual channel panel, so should not be the same bug...

(In reply to comment #58)
> bug# 23399 doesn't use dual channel panel, so should not be the same bug...

Ok. But can we proceed on this bug somehow? I tried 2.6.31_rc6 lately, with no improvement.

(In reply to comment #59)
> Ok. But can we proceed on this bug somehow? I tried 2.6.31_rc6 lately, with
> no improvement.

See the patch I've sent here: http://thread.gmane.org/gmane.comp.video.dri.devel/37592

-rc6 contains only half the changes needed to fix this bug.

(In reply to comment #60)
> (In reply to comment #59)
> > Ok. But can we proceed on this bug somehow? I tried 2.6.31_rc6 lately, with
> > no improvement.
> 
> See the patch I've sent here:
> http://thread.gmane.org/gmane.comp.video.dri.devel/37592
> 
> -rc6 contains only half the changes needed to fix this bug.
> 
Great job. And I already add the acked-by.
Thanks.

(In reply to comment #60)
> See the patch I've sent here:
> http://thread.gmane.org/gmane.comp.video.dri.devel/37592
> 
> -rc6 contains only half the changes needed to fix this bug.

I can confirm that with this patch KMS does work fine on my 855GM.

The patch is already shipped in the Eric's drm-intel-next tree.
   commit bc5e5718acd7f7d000d913e619562767863610bf
Author: Bruno Prémont <bonbons@linux-vserver.org>
Date:   Sat Aug 8 13:01:17 2009 +0200

    drm/i915: Check if BIOS enabled dual-channel LVDS on 8xx, not only on 9xx

So this bug will be marked as resolved.
Thanks.

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