Bug 15963

Summary: [855GM] panel enabled but no display at startup
Product: xorg Reporter: James <theholyettlz>
Component: Driver/intelAssignee: Jesse Barnes <jbarnes>
Status: RESOLVED WONTFIX QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium CC: michael.fu
Version: unspecifiedKeywords: NEEDINFO
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Server log with attached CRT
none
Server log without CRT
none
xrandr --verbose output
none
xorg.conf file
none
lspci -nnvv output
none
Xorg log from 2.3.1.
none
Log from intel 2.3.1 with rawhide (2.6.26-series) kernel
none
Xorg log output with ModeDebug enabled (intel 2.3.1)
none
intel_reg_dumper before X.org/intel 2.3.2 started
none
intel_reg_dumper while X.org/intel 2.3.2 running
none
intel_reg_dumper after X.org/intel 2.3.2 quit
none
Xorg.0.log with intel 2.3.2 driver.
none
xorg.conf in use with intel 2.3.2 driver
none
Xorg log file from current git driver
none
Video ROM
none
dump more PP regs none

Description James 2008-05-16 12:38:37 UTC
With the intel driver (Fedora 9, version 2.2.1, core server 1.4.99.901), the panel on my notebook lights up but is otherwise blank. Normally it should run at 1280x768@60Hz. However, the CRT output works if present at boot-time. I'm not using kernel modesetting, this seems to provoke similar symptoms even before X is started. In detail,

No CRT attached at boot:
 - Console works fine;
 - X starts, panel switches off briefly, the switches back on, but is blank;
 - Can return to text-mode console OK;
 - Attaching CRT seems to make no difference.

CRT attached at boot:
 - BIOS keeps panel off;
 - Console OK on CRT;
 - X starts, CRT shows the display. Panel switches on but is blank;
 - Switching to text-mode console shows console on CRT, panel switches off.

I've attached logs from both scenarios above, the verbose output of xrandr with both displays attached, the xorg.conf and lspci output.

Thanks in advance.
Comment 1 James 2008-05-16 12:39:14 UTC
Created attachment 16576 [details]
Server log with attached CRT
Comment 2 James 2008-05-16 12:39:39 UTC
Created attachment 16577 [details]
Server log without CRT
Comment 3 James 2008-05-16 12:40:12 UTC
Created attachment 16578 [details]
xrandr --verbose output
Comment 4 James 2008-05-16 12:40:31 UTC
Created attachment 16579 [details]
xorg.conf file
Comment 5 James 2008-05-16 12:40:54 UTC
Created attachment 16580 [details]
lspci -nnvv output
Comment 6 Jesse Barnes 2008-05-20 18:09:53 UTC
Hm, it looks like your LVDS display is being detected correctly, but some other mode setting bug is causing either your pipe or plane to not light up at startup time.  Does this also occur with 2.3.1?  We made some changes that could affect things...
Comment 7 James 2008-05-21 11:05:20 UTC
I'm unfamiliar with X.org development, can you tell me where I can download and build intel driver version 2.3.1? Thanks!
Comment 8 Jesse Barnes 2008-05-21 13:18:48 UTC
You can download 2.3.1 and the other Intel driver releases from http://xorg.freedesktop.org/archive/individual/driver/.  Or you can use git to get it from git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel.

Fedora has a lot of changes relative to upstream; are you running Fedora 9 in the experimental kernel mode setting mode?
Comment 9 Jesse Barnes 2008-05-21 13:20:21 UTC
Nevermind about the kernel mode setting question; I see from your logs that you're running the driver normally...  
Comment 10 James 2008-05-21 16:02:52 UTC
OK, first I grabbed the source from git --- this turned out to be version 2.2.0. So next I tried 2.3.1 from the download area. Grabbed the X server devel package from Fedora 9 repo, and built intel with

    ./configure --prefix=/usr
    make
    make install

The screen flashes a bit, and then X quits on "Couldn't bind memory for BO front buffer". See log attached below.
Comment 11 James 2008-05-21 16:03:46 UTC
Created attachment 16670 [details]
Xorg log from 2.3.1.
Comment 12 James 2008-05-21 16:20:24 UTC
There was also this

[drm:drm_buffer_object_validate] *ERROR* Failed moving buffer.

in dmesg, so I updated to kernel-2.6.26-0.17.rc3.fc10.i686. Now X starts with intel 2.3.1, but the results are the same as before (log attached below).
Comment 13 James 2008-05-21 16:21:20 UTC
Created attachment 16671 [details]
Log from intel 2.3.1 with rawhide (2.6.26-series) kernel
Comment 14 Michael Fu 2008-06-05 06:27:42 UTC
james, would you please tell us more about your environment.e.g. HW info. You have provided many information, but I will appreciate if you can provide more according to http://www.intellinuxgraphics.org/how_to_report_bug.html. 

Also, please turn ModeDebug option on and attach the xorg log again. thanks!
Comment 15 James 2008-06-06 11:57:30 UTC
Requested info (much of which is in the dmesg etc. above):

Graphics:      Intel i855 mobile chipset (see X log or lspci output for more);
               1280x768 flat panel display
               DVI-D and VGA connectors
Architecture:  i686/Intel Pentium M 1.7 GHz family 6 model 13 stepping 6
Kernel:        2.6.26-0.17.rc3.fc10.i686
Distribution:  Fedora 9
Machine:       MiTAC 8011 notebook, BIOS 1.05

Xorg log with ModeDebug enabled to follow.
Comment 16 James 2008-06-06 12:06:50 UTC
Created attachment 16968 [details]
Xorg log output with ModeDebug enabled (intel 2.3.1)
Comment 17 Michael Fu 2008-06-19 22:31:39 UTC
ping Jesse...
Comment 18 Jesse Barnes 2008-06-20 14:46:20 UTC
Ok, this is pretty weird.  What was your last working configuration?  The register state from EnterVT looks ok...
Comment 19 James 2008-06-20 14:55:29 UTC
The last time I had this "working" with the intel driver was some time ago --- back with Fedora 7 when the repos had an experimental version. The display worked, but had glitches and flickered (refresh rate problem).

In Fedora 8, the intel driver started giving this problem. I reverted manually to the old i810 driver and all was well. (I might be able to find an old i810 log on the RH bugzilla from an old I830WaitLpRing crash report.) So, basically it's never worked correctly under the intel driver.
Comment 20 Jesse Barnes 2008-06-20 15:15:12 UTC
I doubt the ForceEnablePipeA option will help in this case like it did for an 830 bug I just looked at; can you capture a register dump from after X starts using the intel_reg_dumper tool?  It *should* be the same as the one in your  log, but I'd like to go through it.  Please attach a register dump from before X starts too (again this should be the same as what's in the log, but we've had bugs that changed things before).
Comment 21 James 2008-06-20 15:56:57 UTC
Created attachment 17268 [details]
intel_reg_dumper before X.org/intel 2.3.2 started
Comment 22 James 2008-06-20 15:57:20 UTC
Created attachment 17269 [details]
intel_reg_dumper while X.org/intel 2.3.2 running
Comment 23 James 2008-06-20 15:57:29 UTC
Created attachment 17270 [details]
intel_reg_dumper after X.org/intel 2.3.2 quit
Comment 24 James 2008-06-20 15:57:57 UTC
Created attachment 17271 [details]
Xorg.0.log with intel 2.3.2 driver.
Comment 25 James 2008-06-20 15:58:40 UTC
Created attachment 17272 [details]
xorg.conf in use with intel 2.3.2 driver
Comment 26 James 2008-06-20 15:59:05 UTC
OK, I've attached the requested information. The "during" register dump was captured using

    startx & (sleep 20 ; <dump command>) 

and I then killed the X server with Ctrl+Alt+Backspace. This is all with intel 2.3.2.
Comment 27 Jesse Barnes 2008-06-20 22:24:21 UTC
Awesome, thanks James.  I should be able to take a look either this weekend or next week.
Comment 28 Jesse Barnes 2008-07-17 13:47:44 UTC
Sorry for the delay James...  Looking at your dumps there are a couple of interesting differences:

-(II):         PFIT_CONTROL: 0x80000668
+(II):         PFIT_CONTROL: 0x00000008

so panel fitting was enabled before you started up...

-(II):            PIPEACONF: 0x80000000 (enabled, single-wide)
+(II):            PIPEACONF: 0x00000000 (disabled, single-wide)

pipe A got disabled too (though its associated plane was already off, so that shouldn't have mattered)...

-(II):               DPLL_A: 0x808b0000 (enabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 13, p2 = 4)
+(II):               DPLL_A: 0x10860000 (disabled, non-dvo, default clock, DAC/serial mode, p1 = 8, p2 = 4)

and the PLL got disabled also, hm...

and we switched to pipe B, which is expected.  But my 855 has similar startup values.

Can you try git master?  I just pushed a fix that prevents pipe A from ever getting disabled on 855.  On some configurations, disabling pipe A can cause hangs at enable time, but maybe in your case it's just causing the panel to not sync, so it's worth a try.


Comment 29 James 2008-07-17 15:30:30 UTC
Tried it, but still no luck. Log file attached.
Comment 30 James 2008-07-17 15:31:01 UTC
Created attachment 17733 [details]
Xorg log file from current git driver
Comment 31 Michael Fu 2008-07-30 23:09:38 UTC
ping Jesse....
Comment 32 Jesse Barnes 2008-07-31 16:22:10 UTC
This is getting ugly... James can you attach your video ROM file?
  $ cd /sys/devices/pci0000\:00/0000\:00\:02.0/
  $ echo 1 > rom
  $ cat rom > /tmp/rom.bin
  $ echo 0 > rom

then attach /tmp/rom.bin to this bug?  Maybe there's some timing info we need to get from your BIOS that we're failing to grab.
Comment 33 James 2008-08-03 06:37:59 UTC
Created attachment 18089 [details]
Video ROM

Attached. Still no luck with latest git pull.
Comment 34 Jesse Barnes 2008-08-20 13:56:09 UTC
Created attachment 18420 [details] [review]
dump more PP regs

Can you apply this patch and get a couple more register dumps from before & after starting X?
Comment 35 Michael Fu 2008-09-25 00:56:50 UTC
ping James...
Comment 36 Michael Fu 2008-09-25 18:13:27 UTC
James confirmed he won't be able to test. Wait to see if we can find someone else with the same HW ...
Comment 37 Gordon Jin 2008-10-28 01:31:23 UTC
I'm wondering if we should close this. What's the laptop model?
Comment 38 Michael Fu 2008-11-11 21:52:12 UTC
not able to continue bug fixing on this one. close it..

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.