Bug 20115

Summary: [lvds dual channel]KMS fails to completely configure 855 chip
Product: DRI Reporter: Bruno <bonbons>
Component: DRM/IntelAssignee: ykzhao <yakui.zhao>
Status: CLOSED FIXED QA Contact:
Severity: critical    
Priority: high CC: arthurspitzer, bryce, ling.ma, maxi, michael.fu, renegabriels
Version: unspecifiedKeywords: patch
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
kernel boot log
none
Xorg log
none
Kernel config
none
kernel boot log for 2.6.29-rc6
none
dmesg of 2.6.29 with KMS enabled
none
Xorg.0.log with kernel 2.6.29 and KMS enabled
none
kernel boot log for 2.6.30-rc3
none
Xorg.0.log with kernel 2.6.30-rc3 and KMS enabled
none
Xorg.0.log with kernel 2.6.30-rc3 and KMS enabled but no xorg.conf
none
contents of /sys/kernel/debug/dri/{0,64}
none
dmesg with KMS disabled
none
Xorg.0.log with KMS disabled
none
dmesg with KMS enabled
none
Xorg.0.log with KMS enabled
none
Register dump for xf86-video-intel-2.7.1 user mode (2.6.30-rc7-git kernel as of today)
none
Register dump for KMS with 2.6.30-rc7-git kernel as of today
none
dmesg matching attachment 26295
none
Xorg.log matching attachments 26295 and 26296
none
pleaset try the patch on your machine, thanks.
none
dmesg
none
pleaset try the patch on your machine in UMS mode, thanks.
none
Request Xorg.log
none
Xorg log
none
pleaset try the patch on your machine in KMS mode, thanks.
none
reject of failed Hunk #3
none
Adapted variant of Ming's patch that works for me
none
dmesg
none
Xorg log
none
pleaset try the patch on your machine in KMS mode, thanks.
none
reject of patch on 2.6.31-rc3 none

Description Bruno 2009-02-14 03:30:25 UTC
Created attachment 22938 [details]
kernel boot log

When booting with 2.6.29-rc5 (with DRM patches) and KMS enabled my laptop (Acer TravelMate 660) boots up completely but the display remains black (backlight on) after switching from vga console to drm frambuffer.

Starting xorg-server-1.5.3 on top of it does not cause the laptop to display anything else than black-ness.

Trying to suspend to RAM with KMS enabled fails during the suspend process (don't know at which point exactly, is after disk has been stopped)

Suspending without enabled KMS works fine (vesa framebuffer).


Patches applied to kernel:
  From airlied, drm-fixes branch
01-drm-2.6.git-e7bc956788ff6f5ef24084e639db0cd492d2373c.patch
02-drm-2.6.git-1722e8cebb908037e114ff53beb876568e93f64f.patch
03-drm-2.6.git-44760f76ba20b876ba3b1ed8b7f87081d91aba40.patch
04-drm-2.6.git-14286a60c8695657c3908a1d82097076e68d3eee.patch
05-drm-2.6.git-153b395113f70d03ac051cf1d45fd1a09c39df35.patch
06-drm-2.6.git-5de77c0b8a286cc97b1926668e0edade8b1b22a7.patch
07-drm-2.6.git-53117dd308fd6a006379a593467b2d10c0c7fa89.patch
08-drm-2.6.git-459f87b17c307742a709173aa280f6a60e6b177e.patch
09-drm-2.6.git-ee7de8fdb6233606295d41fa2b20316e95e6910d.patch
10-drm-2.6.git-4950c852bcd9061fadd6cfbc70904b6449f3f337.patch
11-drm-2.6.git-1a1c5c9671a0b8105e3109ec0e4ba379204a08f3.patch
12-drm-2.6.git-d734cdd819a545af112eea21aad9d32fe3814f91.patch
  From anholt, for-airlied branch
01-drm-intel.git-1d880a5c336a7ca22f5c0258ef3be40e2992b539.patch
02-drm-intel.git-d8885b0ccc2f39134e601fe6b8ffc63397c1ad79.patch
03-drm-intel.git-971df058091897b1a0419eaf0e754c662c2985de.patch
04-drm-intel.git-3a4d0c9c15c354403c6972d5932dd956afe4577a.patch
05-drm-intel.git-e9db4627388eca83ec7a8593130882c066e409d2.patch
06-drm-intel.git-076d53efedcfd21e454eb8a3d30d1f9c58f2169b.patch
07-drm-intel.git-36312bf720afcf387d4eb73bde0f3e0f9874c6aa.patch
08-drm-intel.git-50739ab5f242d65f1ba831681efb1f2ddab3da50.patch
09-drm-intel.git-60c7b1961e03513873536163affc0cac56690ae2.patch
10-drm-intel.git-95ca9d386d03a591a7cee74b61c3fcba0144b921.patch
11-drm-intel.git-fbddcfcbe0b3a0d50b8b8538a03ab88a69b0655f.patch
12-drm-intel.git-5d18a1611b16afb2b8794435e2701daa68008ce7.patch

And manually set drm_debug = 1 in drm_stub.c


System details:
00:00.0 Host bridge [0600]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3580] (rev 02)
00:00.1 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3584] (rev 02)
00:00.3 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3585] (rev 02)
00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)
00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 03)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 03)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 03)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 03)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 83)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] (rev 03)
00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] (rev 03)
00:1f.3 SMBus [0c05]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller [8086:24c3] (rev 03)
00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 03)
00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6] (rev 03)
02:02.0 Ethernet controller [0200]: Broadcom Corporation BCM4401 100Base-T [14e4:4401] (rev 01)
02:04.0 Network controller [0280]: Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter [8086:1043] (rev 04)
02:06.0 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus Controller [1217:7113] (rev 20)
02:06.1 CardBus bridge [0607]: O2 Micro, Inc. OZ711EC1 SmartCardBus Controller [1217:7113] (rev 20)
02:07.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) [104c:8026]

Acer TravelMate 660
Gentoo Linux (xorg-server-1.5.3, xf86-video-intel-2.6.1, mesa-7.3)

Attachments:
- kernel boot log
Comment 1 Bruno 2009-02-14 03:31:00 UTC
Created attachment 22939 [details]
Xorg log
Comment 2 Bruno 2009-02-14 03:31:43 UTC
Created attachment 22940 [details]
Kernel config
Comment 3 Bruno 2009-02-23 11:07:34 UTC
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.
Comment 4 Maximilian Engelhardt 2009-03-18 12:43:06 UTC
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.
Comment 5 Maximilian Engelhardt 2009-03-23 19:04:29 UTC
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.
Comment 6 Maximilian Engelhardt 2009-03-23 19:05:43 UTC
Created attachment 24174 [details]
Xorg.0.log with kernel 2.6.29 and KMS enabled
Comment 7 Jesse Barnes 2009-04-07 16:41:24 UTC
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.
Comment 8 Bruno 2009-04-22 09:27:45 UTC
(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?
Comment 9 Jesse Barnes 2009-04-23 18:46:56 UTC
Yeah just got my machine working again, I expect to have some fixes shortly.
Comment 10 Jesse Barnes 2009-04-24 15:22:19 UTC
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?
Comment 11 Bruno 2009-04-25 02:24:37 UTC
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).
Comment 12 Bruno 2009-04-25 02:30:17 UTC
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
Comment 13 Arthur Spitzer 2009-04-25 03:10:07 UTC
(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?
Comment 14 Bruno 2009-04-25 03:19:08 UTC
(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)
Comment 15 Jesse Barnes 2009-04-25 10:24:11 UTC
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.
Comment 16 Bruno 2009-04-25 10:42:48 UTC
(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)
Comment 17 Bruno 2009-04-25 11:45:27 UTC
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)
Comment 18 Bruno 2009-04-25 11:52:11 UTC
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
Comment 19 Jesse Barnes 2009-05-04 15:54:46 UTC
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).
Comment 20 Arthur Spitzer 2009-05-05 03:03:11 UTC
(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
Comment 21 Maximilian Engelhardt 2009-05-06 06:20:51 UTC
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.

Comment 22 Maximilian Engelhardt 2009-05-06 06:22:09 UTC
Created attachment 25546 [details]
dmesg with KMS disabled
Comment 23 Maximilian Engelhardt 2009-05-06 06:22:57 UTC
Created attachment 25547 [details]
Xorg.0.log with KMS disabled
Comment 24 Maximilian Engelhardt 2009-05-06 06:23:48 UTC
Created attachment 25548 [details]
dmesg with KMS enabled
Comment 25 Maximilian Engelhardt 2009-05-06 06:24:16 UTC
Created attachment 25549 [details]
Xorg.0.log with KMS enabled
Comment 26 djenett 2009-05-11 03:56:24 UTC
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.
Comment 27 Bruno 2009-05-29 12:46:05 UTC
Created attachment 26294 [details]
Register dump for xf86-video-intel-2.7.1 user mode (2.6.30-rc7-git kernel as of today)
Comment 28 Bruno 2009-05-29 12:47:14 UTC
Created attachment 26295 [details]
Register dump for KMS with 2.6.30-rc7-git kernel as of today
Comment 29 Bruno 2009-05-29 12:47:53 UTC
Created attachment 26296 [details]
dmesg matching attachment 26295 [details]
Comment 30 Bruno 2009-05-29 12:50:51 UTC
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)
Comment 31 Jesse Barnes 2009-06-23 18:07:55 UTC
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.
Comment 32 Bruno 2009-06-24 13:29:39 UTC
(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)
Comment 33 Jesse Barnes 2009-06-24 14:08:16 UTC
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?
Comment 34 MaLing 2009-06-24 19:47:32 UTC
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
Comment 35 Arthur Spitzer 2009-06-25 02:16:02 UTC
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
Comment 36 Bruno 2009-06-25 12:04:49 UTC
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.
Comment 37 Arthur Spitzer 2009-07-15 06:54:08 UTC
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?
Comment 38 Jesse Barnes 2009-07-15 09:59:39 UTC
http://bugs.freedesktop.org/show_bug.cgi?id=22262 has a patch to check the dual/single channel status.  Has anyone tried that?
Comment 39 Bruno 2009-07-15 11:09:15 UTC
(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)
Comment 40 Bruno 2009-07-15 12:20:53 UTC
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 ...)
Comment 41 Jesse Barnes 2009-07-15 14:11:47 UTC
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?
Comment 42 MaLing 2009-07-16 07:20:15 UTC
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
Comment 43 MaLing 2009-07-16 07:34:24 UTC
(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
Comment 44 Bruno 2009-07-16 10:10:59 UTC
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).
Comment 45 Arthur Spitzer 2009-07-16 12:53:27 UTC
Created attachment 27773 [details]
Xorg log

requested log. I patched xf86-video-intel-2.7.1 without problems
kernel 2.6.31-rc3
Comment 46 MaLing 2009-07-16 20:48:38 UTC
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
Comment 47 Arthur Spitzer 2009-07-17 01:42:02 UTC
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).
Comment 48 MaLing 2009-07-17 02:19:30 UTC
(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 :)
Comment 49 Arthur Spitzer 2009-07-17 03:01:16 UTC
(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
Comment 50 Bruno 2009-07-18 06:39:04 UTC
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))
Comment 51 Arthur Spitzer 2009-07-19 00:16:30 UTC
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
Comment 52 Arthur Spitzer 2009-07-19 00:19:21 UTC
Created attachment 27828 [details]
Xorg log

of the above configuration with kms enabled
Comment 53 MaLing 2009-07-20 05:26:25 UTC
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
Comment 54 Arthur Spitzer 2009-07-20 10:20:00 UTC
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).
Comment 55 Bruno 2009-07-22 14:33:23 UTC
(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
Comment 56 Wang Zhenyu 2009-08-19 20:08:49 UTC
Not sure if #23399 is relate to this?
Comment 57 Arthur Spitzer 2009-08-20 03:13:38 UTC
(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].
Comment 58 Michael Fu 2009-08-20 05:40:29 UTC
bug# 23399 doesn't use dual channel panel, so should not be the same bug...
Comment 59 Arthur Spitzer 2009-08-20 06:10:14 UTC
(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.
Comment 60 Bruno 2009-08-20 06:35:59 UTC
(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.
Comment 61 ykzhao 2009-08-24 01:23:45 UTC
(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.

Comment 62 Maximilian Engelhardt 2009-08-24 05:21:53 UTC
(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.
Comment 63 ykzhao 2009-08-24 19:00:55 UTC
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.
Comment 64 Michael Fu 2009-09-26 19:53:51 UTC
*** Bug 22977 has been marked as a duplicate of this bug. ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.