Created attachment 36597 [details] Kernel log with nouveau built from git Ctrl+Alt+Fn switches to virtual consoles but the display is blank although the keyboard works. The backlight _is_ on. The console works OK up to the point when X starts. video=1280x1024 is specified in the kernel boot line in GRUB otherwise KMS switches to something like the TV resolution (720x576) before X starts and X starts at 1024x768.
Created attachment 36598 [details] Xorg log to go wth the kernel log Added the Xorg log.
It appears that there are some bits left from the blob (/usr/lib/xorg/modules/extensions/libglx.so), and the xorg.conf is not setup correctly (you should use, nouveau, rather than nv/vesa). Have you gone through the TroubleShooting [1], namely sections 3 and 8 [1] http://nouveau.freedesktop.org/wiki/TroubleShooting
Oh dear, how embarrassing. I _thought_ I had gone through section 3, but I had done it on the wrong instance of Arch... I had not removed the nvidia-173xx-utils package on the test instance. I also didn't realise I even had the vesa driver installed. So the problem is now resolved. And now I know what RandR does, and how to disable the TV out in xorg.conf. Again, many apologies fot the time wasted.. Pete
(In reply to comment #0) > video=1280x1024 is specified in the kernel boot line in GRUB otherwise KMS > switches to something like the TV resolution (720x576) before X starts and X > starts at 1024x768. An mmiotrace from the blob would be useful to fix that (see [1] and [2]). Do you have access to a TV? [1] http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/trace/mmiotrace.txt [2] http://nouveau.freedesktop.org/wiki/MmioTrace
The GUI resolution when X starts is fixed by having the proper drivers and an xorg.conf that specifies the resolution I want. The consoles are still not using the full screen though - about a 720x576 sized patch in the top LH corner of the screen. Smaller than the TV-1 when that was overlayed on VGA-1 Do you just want an mmio trace that covers the point when the Kernel switches from VGA to 720x576, or do you want one that covers X starting as well? And I don't have access to a TV. Actually, since there's nothing connected to the TV (S-video?) connector I don't understand why the driver is using it in the first place. It doesn't use the DVI connector which also has nothing connected to it. Pete
(In reply to comment #5) > Do you just want an mmio trace that covers the point when the Kernel switches > from VGA to 720x576, or do you want one that covers X starting as well? > > And I don't have access to a TV. Actually, since there's nothing connected to > the TV (S-video?) connector I don't understand why the driver is using it in > the first place. It doesn't use the DVI connector which also has nothing > connected to it. Right, that's why an mmiotrace from your card would be useful. If you're interested on fixing it you could: * Start tracing (the details are described in the links I posted in my last comment). * Start X with the nvidia proprietary driver (IOW the "blob"), but before, put the following in your xorg.conf, 'Section "Device"': > Option "UseDisplayDevice" "TV" * Stop tracing and send the compressed results to mmio.dumps at gmail.com.
I'm currently on Xorg 1.8 and apparently the NVIDA driver is not supported by that version of Xorg (which is why I'm using nouveau in the first place). For the purposes of getting a trace will it be OK to use Xorg 1.8 or should I downgrade to 1.7? No big deal, but if I need to downgrade it will have to wait until I can have unfettered access to this PC for a few hours - which will not be till the weekend at the earliest. Pete
(In reply to comment #7) > I'm currently on Xorg 1.8 and apparently the NVIDA driver is not supported by > that version of Xorg (which is why I'm using nouveau in the first place). For > the purposes of getting a trace will it be OK to use Xorg 1.8 or should I > downgrade to 1.7? > Not sure. > No big deal, but if I need to downgrade it will have to wait until I can have > unfettered access to this PC for a few hours - which will not be till the > weekend at the earliest. > Ok, could I also have a look at your VBIOS [1]? It might be enough to fix it. > Pete [1] http://nouveau.freedesktop.org/wiki/DumpingVideoBios
Created attachment 36630 [details] Video rom
(In reply to comment #9) > Created an attachment (id=36630) [details] > Video rom Nothing suspicious in it, so yeah, a full mmiotrace would be more useful.
If you can load the nvidia kernel module it might be enough to do this to get a trace (instead of starting X): mknod nvidia0 c 195 0 cat nvidia0
(In reply to comment #11) > If you can load the nvidia kernel module it might be enough to do this to get a > trace (instead of starting X): > > mknod nvidia0 c 195 0 > cat nvidia0 I don't think so, we need to catch it while it's trying to detect TV.
(In reply to comment #7) > I'm currently on Xorg 1.8 and apparently the NVIDA driver is not supported by > that version of Xorg (which is why I'm using nouveau in the first place). For > the purposes of getting a trace will it be OK to use Xorg 1.8 or should I > downgrade to 1.7? You could start X with the "-ignoreABI" command-line option (or set it somewhere in xorg.conf). I'm guessing that if X works with this option, the trace will be useful.
Turned out I only had to downgrade the kernel from 2.6.34 to 3.6.33. I've emailed the trace to mmio.dump at gmail.com. It's also available at: http://www.somborneshetlands.co.uk/things/Zotac-FX5200-mmiotrace.tar.gz Pete
(In reply to comment #14) > Turned out I only had to downgrade the kernel from 2.6.34 to 3.6.33. I've > emailed the trace to mmio.dump at gmail.com. It's also available at: > > http://www.somborneshetlands.co.uk/things/Zotac-FX5200-mmiotrace.tar.gz > Thanks. It turns out that the blob's also detecting load in your TV output: R 4 195.041175 1 0xfc682608 0xf0001000 0x0 0 ^ So most likely someone screwed it up when the board was assembled: We can do nothing besides skipping load detection for your specific card. Can you provide the output from "lspci -vvnn"? > Pete
Created attachment 36724 [details] Output of lspci -vvnn Ouput of lspci -vvnn attached. TBH now I've installed this card in my Windows machine I'm undecided whether the false load detection is a bug or a 'feature'. The Windows installer fires up a configurator after it's loaded the driver, and the first thing it tells you is that you probably don't want the card configured as it is! It initialises in the same mode the nouveau driver does 'Clone' with both TV and VGA enabled and one overlaid on the other. The difference is that the VGA is on top so if you don't understand what the configurator is telling you and leave it alone no harm is done visually - so long as you really haven't got a TV and no monitor - but maybe it can detect no monitor - I don't have a TV so can't test that scenario. It also avoids the 'you must have xxx installed before you can configure the driver' syndrome you often get with multi-function printers. The xorg.conf Option lines added by nvidia-settings to disable TV don't work for nouveau, but 'xrandr --output TV-1 --off' does work for X. Pete
Created attachment 36728 [details] [review] nv34_tv_detect_quirk.patch (In reply to comment #16) > Created an attachment (id=36724) [details] > Output of lspci -vvnn > > Ouput of lspci -vvnn attached. > Ok, could you try the attached patch? > The xorg.conf Option lines added by nvidia-settings to disable TV don't work > for nouveau, but 'xrandr --output TV-1 --off' does work for X. > See [1], 'Option "Ignore"' is what you were looking for, but you shouldn't need it anymore. > Pete [1] http://wiki.debian.org/XStrikeForce/HowToRandR12
Thanks for the patch. Building a Linux kernel seems to be a complete nightmare unlike NetBSD where its very easy. I'll give it a go once I've figured out how its done -and why it seems so complicated. I'd found 'Option "Ignore"' at [1] just after I'd added the output of lspci. [1] http://www.thinkwiki.org/wiki/Xorg_RandR_1.2#xorg.conf
I've built a kernel incorporating the nv34_tv_detect_quirk patch and it now all works as it should - KMS wsitches to the monitor's native resolution of 1280x1024 as the module is loaded at boot, the virtual ttys use the same resolution, and there is no need to turn TV-1 off before starting X, or use the "Ignore" option in xorg.conf. Pete
(In reply to comment #19) > I've built a kernel incorporating the nv34_tv_detect_quirk patch and it now all > works as it should - KMS wsitches to the monitor's native resolution of > 1280x1024 as the module is loaded at boot, the virtual ttys use the same > resolution, and there is no need to turn TV-1 off before starting X, or use the > "Ignore" option in xorg.conf. > Thanks, it should be fixed in master now. > Pete
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.