Created attachment 17914 [details] output of lspci -v Without the ForceEnablePipeA option, I can get X to start properly 1 in about 20 times; it's random. When startx fails, the display cycles red, green, blue, black and requires a soft reboot to get any output back. Adding the option makes startx work every time so far, so I'm opening this bug as requested by the man page.
Created attachment 17915 [details] output of lspci -vn
What's the driver version? Please attach Xorg.0.log. Next time when you file bugs, please refer to http://www.intellinuxgraphics.org/how_to_report_bug.html. Thanks.
Created attachment 17929 [details] Xorg.0.log This Xorg.0.log is from my current X session.
You may wish to make the man page section for ForceEnablePipeA refer to the 'how to report bugs' page; it simply referred to bugs.freedesktop.org. I'm sorry for not knowing how to report bugs but I already spent hours and hours trying to get X to work and was simply following the instructions I had.
Thanks for filing David, yeah I'll add a section to the man page on filing bugs.
ping Jesse ... other than fixing up the man page, we also need to resolve this bug as well...
Created attachment 18415 [details] [review] don't steal crtcs for detect There are a couple of patches that might help with this problem, this is one of them (the other is to not allocate a CRTC for hotplug polling, which we should be pushing soon).
Created attachment 18418 [details] lspci -v
Created attachment 18419 [details] lspci -vn
Bug description: The cycling colors happens always on start of X. I encountered this color cycle allready earlier with other distros, but this is the first time I found a cure - also its the first time that it happened *always* before it happened randomly. Option "ForceEnablePipeA" "True" , and the trouble is gone. System Environment: chipset: [954GM] system architecture: x86_64 xf86-video-intel/xserver/mesa/drm version: *no idea how to check* kernel version: 2.6.25.14-108.fc9.x86_64 Linux distribution: Fedora Core 9 Machine or mobo model: dont know exactly, custom made msi with intel core 2 duo. Display connector: VGA Reproduce Steps: Install fc9, update it, restart, voila color cycle. Additional Info: its my first bug report - I hope everything needed is listed... Attachement: Attachment #18418 [details] Attachment #18419 [details]
Can you retest with the latest git bits? We've pushed a few fixes that should help.
decreasing priority, and waiting for reporters' response.
ping response...David and alimanka
I can help testing, but I thought quote: "Can you retest with the latest git bits? We've pushed a few fixes that should help." is not addressed to me. regarding comment 13 this seems addressed to me? In which case I need some help, as I do not understand "latest git bits". But I am willing to test stuff on this machine out.
Sorry, I reported this bug and would be glad to test it. I run Debian Unstable. Please confirm the package name should be xserver-xorg-video-intel, and send a link to your git repositroy instructions, and the names of any other packages I also need to rebuild. I will try to build your tree using the Debian source package .dsc file.
(In reply to comment #15) > Sorry, I reported this bug and would be glad to test it. I run Debian > Unstable. Please confirm the package name should be > xserver-xorg-video-intel, and send a link to your git repositroy > instructions, and the names of any other packages I also need to > rebuild. I will try to build your tree using the Debian source > package .dsc file. > Those changes Jesse mentioned should be in Debian unstable tree now. Does the latest Debian unstable work for you?
ping for response...if you have a chance to test, pls attach your Xorg.log with ModeDebug turns on in conf file.
lost connection with bug reporter. reject. pls reopen with response to required test update. thanks.
Created attachment 21322 [details] Xorg.0.log with ModeDebug true, ForceEnablePipeA false Currently running xserver-xorg-video-intel debian package version 2:2.3.2-2+lenny5. Ran X, came up OK. Switched to VT and back OK. Suspended to memory (echo "mem" > /sys/power/state) and unsuspended, display did not come back OK, had to ctrl-alt-backspace, login at VT blind and run X again to fix the display.
reopen for review of attached Xorg.0.log with newer driver and debugging info.
(In reply to comment #20) > reopen for review of attached Xorg.0.log with newer driver and debugging info. > David, if you add the ForceEnablePipeA option, is everything works again then? Otherwise, this is probably now another bug. If so, we should open a new bug to track it.. thanks.
David, it seems comment# 19 is really another bug. would you please open a new bug to track it? we want one bug to track one thing, so that it won't messed up with growing comments... thanks.
(In reply to comment #22) > David, it seems comment# 19 is really another bug. would you please open a new > bug to track it? we want one bug to track one thing, so that it won't messed up > with growing comments... thanks. > Yes, this bug seems fixed. I started X about 10 times in a row with ForceEnablePipeA Off, and it worked fine every time. Losing display after suspending and resuming is a different issue, and I will open a separate bug for that. I'll probably wait a while and upgrade my kernel and userland first to see if it still happens.
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.