Created attachment 24488 [details] X log Originally filed as: https://bugzilla.redhat.com/show_bug.cgi?id=492399 When using DVI (to a Dell 2005FPW), it fails to set up the mode correctly. The screen briefly appears, wobbles, and then blinks on and off. VGA connection works fine. Relevant dmesg: mtrr: type mismatch for e8000000,8000000 old: write-back new: write-combining agpgart-intel 0000:00:00.0: AGP 3.0 bridge agpgart: Xorg tried to set rate=x12. Setting to AGP3 x8 mode. agpgart-intel 0000:00:00.0: putting AGP V3 device into 8x mode pci 0000:01:00.0: putting AGP V3 device into 8x mode [drm] Allocating FIFO number 0 [drm] nouveau_fifo_alloc: initialised FIFO 0 [drm] Allocating FIFO number 1 [drm] nouveau_fifo_alloc: initialised FIFO 1 lspci: 00:00.0 Host bridge: Intel Corporation E7505 Memory Controller Hub (rev 03) 00:00.1 Class ff00: Intel Corporation E7505/E7205 Series RAS Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation E7505/E7205 PCI-to-AGP Bridge (rev 03) 00:02.0 PCI bridge: Intel Corporation E7505 Hub Interface B PCI-to-PCI Bridge (rev 03) 00:02.1 Class ff00: Intel Corporation E7505 Hub Interface B PCI-to-PCI Bridge RAS Controller (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation NV34GL [Quadro FX 500/600 PCI] (rev a1) 02:1c.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04) 02:1d.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 04) 02:1e.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04) 02:1f.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 04) 03:03.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01) No xorg.conf. Xorg.log attached. Version-Release number of selected component (if applicable): kernel-2.6.29-0.258.2.3.rc8.git2.fc11.i686.PAE xorg-x11-drv-nouveau-0.0.12-10.20090310git8f9a580.fc11.i586 How reproducible: Every time
If the computer is booted with this (and only this) screen attached, does it work with the "nv" x driver? Failing that, does it work with the proprietary "nvidia" linux driver?
Sorry, also, if you start X with nouveau and it does this blinking thing, if you then close X and do startx again, does it work any better the second time around?
It has worked with nv in the past. I have never tried nvidia on this box.
Further restarts with nouveau do not help; neither does starting novueau after starting successfully once with nv.
Created attachment 24601 [details] X log with nv module Here's the X log with 'nv' used as the driver, if it helps.
Ok. As it works with nv should should be reasonably easy to fix. Could you make and attach comparative register dumps please: git clone git://anongit.freedesktop.org/~stuart/radeontool; cd radeontool; make then from an xterm while using the nv driver do "./radeontool regs > regs-nv", then from an xterm while using the nouveau driver do "./radeontool regs > regs-nouveau" (or if the blinking makes this impractical, running the dump command over ssh is fine so long as X is running at the time).
Created attachment 24606 [details] nouveau register dump
Created attachment 24607 [details] nv register dump
Thanks. Two initial things to try (see if it stops the blinking): 1) when nouveau is running, do "./radeontool regset 0x680848 0x11100110" 2) when nouveau is running, do "./radeontool regset C0:33 0x9" if these don't help, does the blinking stop if you close X and go back to the terminal? Does "nv" still work successfully following nouveau having been used?
(In reply to comment #9) > Thanks. Two initial things to try (see if it stops the blinking): > 1) when nouveau is running, do "./radeontool regset 0x680848 0x11100110" > 2) when nouveau is running, do "./radeontool regset C0:33 0x9" Neither appears to help. > if these don't help, does the blinking stop if you close X and go back to the > terminal? 80x25 text mode is fine (either with VT switch, or after X exists.) > Does "nv" still work successfully following nouveau having been > used? Yes. Attempting to describe more, since 'blinking' is a bit of a shorthand: - The display starts (mouse cursor on black). The cursor wobbles a bit (out of sync?), and there are some minor display artifiacts. - The display flashes on and off a couple of times (when it's on, it's still wobbling with slight artifacts) - The 'on' flashes decrease in frequency, to a point after about 30 seconds where the display's just blank.
(In reply to comment #10) > > Does "nv" still work successfully following nouveau having been > > used? > > Yes. Well that narrows it down thankfully, but sadly those two registers were the obvious candidates, so there's going to be some more investigation required. 0) an Xorg.0.log of nouveau *including* X shut-down (or a switch to VT actually) would help. If there's any line containing "Parsing digital output script table" that has a different number than 0xB555, attach a copy of your video bios ( http://nouveau.freedesktop.org/wiki/DumpingVideoBios -- the "dd" method should suffice) 1) I now see you reported against xorg-x11-drv-nouveau-0.0.12-10.20090310git8f9a580.fc11.i586. While it probably won't fix anything, could you use xorg-x11-drv-nouveau-0.0.12-21.20090403git11be9a9.fc11 (or even git://anongit.freedesktop.org/nouveau/xf86-video-nouveau), so at least the code I'm looking at is relevant to the symptoms? :) 2) try putting `Option "randr12" "off"' in the Device section of your xorg.conf -- this makes nouveau use almost the same code as nv for bringing up displays, so if this doesn't work there's something subtle going on. 3) there's a few other relevant regs that "radeontool regs" doesn't dump; please do "./radeontool regmatch REGISTER" under nv and nouveau for REGISTER being: 0x00600804 0x00602804 0x00680608 0x00682608 0x00680630 0x00682630 0x00680634 and 0x00682634 . For any of these where there's a difference between the drivers, you could try regset using the "nv" value like before, when running nouveau, and see if things get fixed. 4) assuming 1 & 3 don't fix it, and 2 works as expected, the next step is trying to eliminate most of the differences comparing the reg dumps; would you prefer a patch to nouveau that does this (with later patches to bisect down to find which reg/regs need attention), or are you happy doing radeontool regset for 15-20 regs if I give you a list?
Created attachment 24613 [details] X log (full) Here's the full X log, startup and shutdown. It does use only 0xB555 (whatever that means :) ).
(In reply to comment #11) > 1) I now see you reported against > xorg-x11-drv-nouveau-0.0.12-10.20090310git8f9a580.fc11.i586. While it probably > won't fix anything, could you use > xorg-x11-drv-nouveau-0.0.12-21.20090403git11be9a9.fc11 (or even > git://anongit.freedesktop.org/nouveau/xf86-video-nouveau), so at least the code > I'm looking at is relevant to the symptoms? :) It's been upgraded as time goes on - it's running xorg-x11-drv-nouveau-0.0.12-22.20090404git836d985.fc11.i586 now. > 2) try putting `Option "randr12" "off"' in the Device section of your xorg.conf > -- this makes nouveau use almost the same code as nv for bringing up displays, > so if this doesn't work there's something subtle going on. Yes, that fixes it. > 3) there's a few other relevant regs that "radeontool regs" doesn't dump; > please do "./radeontool regmatch REGISTER" under nv and nouveau for REGISTER > being: 0x00600804 0x00602804 0x00680608 0x00682608 0x00680630 0x00682630 > 0x00680634 and 0x00682634 . For any of these where there's a difference > between the drivers, you could try regset using the "nv" value like before, > when running nouveau, and see if things get fixed. diff -u rr-nv rr-nouveau --- rr-nv 2009-04-06 15:24:57.000000000 -0400 +++ rr-nouveau 2009-04-06 15:25:58.000000000 -0400 @@ -1,7 +1,7 @@ -0x00600804 0x00000000 (0) +0x00600804 0x00000002 (2) 0x00602804 0x00000000 (0) 0x00680608 0xf0010000 (-268369920) -0x00682608 0x00000000 (0) +0x00682608 0xf0000000 (-268435456) 0x00680630 0x00000000 (0) 0x00682630 0x00000000 (0) 0x00680634 0x00000000 (0) Setting 00600804 to 0 doesn't help. Setting 00682608 to 0 doesn't work (it stays set to 0xf0000000). > 4) assuming 1 & 3 don't fix it, and 2 works as expected, the next step is > trying to eliminate most of the differences comparing the reg dumps; would you > prefer a patch to nouveau that does this (with later patches to bisect down to > find which reg/regs need attention), or are you happy doing radeontool regset > for 15-20 regs if I give you a list? Sure, I can poke random values in.
Hopefully fixed with http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=a5d45c80e85611c9e22d8eca27294eef5378a549 I imagine it'll find its way into a rawhide rpm at some point.
Confirmed, fixed in a rawhide build of 11451ca.
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.