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.
Created attachment 16576 [details] Server log with attached CRT
Created attachment 16577 [details] Server log without CRT
Created attachment 16578 [details] xrandr --verbose output
Created attachment 16579 [details] xorg.conf file
Created attachment 16580 [details] lspci -nnvv output
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...
I'm unfamiliar with X.org development, can you tell me where I can download and build intel driver version 2.3.1? Thanks!
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?
Nevermind about the kernel mode setting question; I see from your logs that you're running the driver normally...
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.
Created attachment 16670 [details] Xorg log from 2.3.1.
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).
Created attachment 16671 [details] Log from intel 2.3.1 with rawhide (2.6.26-series) kernel
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!
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.
Created attachment 16968 [details] Xorg log output with ModeDebug enabled (intel 2.3.1)
ping Jesse...
Ok, this is pretty weird. What was your last working configuration? The register state from EnterVT looks ok...
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.
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).
Created attachment 17268 [details] intel_reg_dumper before X.org/intel 2.3.2 started
Created attachment 17269 [details] intel_reg_dumper while X.org/intel 2.3.2 running
Created attachment 17270 [details] intel_reg_dumper after X.org/intel 2.3.2 quit
Created attachment 17271 [details] Xorg.0.log with intel 2.3.2 driver.
Created attachment 17272 [details] xorg.conf in use with intel 2.3.2 driver
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.
Awesome, thanks James. I should be able to take a look either this weekend or next week.
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.
Tried it, but still no luck. Log file attached.
Created attachment 17733 [details] Xorg log file from current git driver
ping Jesse....
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.
Created attachment 18089 [details] Video ROM Attached. Still no luck with latest git pull.
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?
ping James...
James confirmed he won't be able to test. Wait to see if we can find someone else with the same HW ...
I'm wondering if we should close this. What's the laptop model?
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.