Red Hat Bugzilla – Full Text Bug Listing
|Summary:||NV1f Chipset - Garbled Display. Needs nouveau.tv_disable=1 on boot to work|
|Product:||[Fedora] Fedora||Reporter:||Al Thomas <astavale>|
|Component:||xorg-x11-drv-nouveau||Assignee:||Ben Skeggs <bskeggs>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||15||CC:||airlied, awilliam, bskeggs|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-07 15:28:36 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Al Thomas 2010-03-12 15:05:46 EST
Created attachment 399736 [details] Garbled display photo - DVI-D interface Description of problem: Booted F13 Alpha from LiveDVD. Display is garbled. See attached Version-Release number of selected component (if applicable): How reproducible: Every time Steps to Reproduce: 1.Boot from Fedora 13 Alpha LiveDVD 2. 3. Actual results: Unreadable display Expected results: Readable display Additional info:
Comment 1 Al Thomas 2010-03-12 16:24:44 EST
Created attachment 399752 [details] Xorg.0.log Managed to get copies of Xorg.0.log and /var/log/messages off the system by switching to VGA output. This still had significant distortions, but legible enough to enter commands. I have always used DVI-D up until now and left the VGA unplugged. Rebooting into F12 with the VGA plugged in also lead to a scrambled display.
Comment 2 Al Thomas 2010-03-12 16:25:30 EST
Created attachment 399753 [details] /var/log/messages (edited)
Comment 3 Ben Skeggs 2010-03-18 19:55:49 EDT
I presume you don't actually have anything plugged into the TV connector also? If not, can you install this kernel (http://koji.fedoraproject.org/koji/buildinfo?buildID=161838) and boot with "nouveau.tv=0" and see how things go for you then? Thanks!
Comment 4 Ben Skeggs 2010-03-21 21:29:28 EDT
Just a correction: it's nouveau.tv_disable=1 you'll need to use
Comment 5 Al Thomas 2010-03-27 07:23:34 EDT
You're right there is nothing plugged into the TV connector. I have tried this with kernel kernel-126.96.36.199-21.fc13 (http://koji.fedoraproject.org/koji/buildinfo?buildID=163495) and nouveau.tv_disable=1 does bring back a stable image. Thanks. As an aside there is some interference and occasional flicker with the image when switching back to the F12 drivers. Black flecks can appear on screen and the image shakes now and again, then goes back to stable. This, however, sorts itself out after a reboot into F12 again. Unfortunatley the workaround for Bug 517917 (https://bugzilla.redhat.com/show_bug.cgi?id=517917) no longer works for the F13-Alpha drivers. The screen is moved down permanently by one line. I'll update that bug separately.
Comment 6 Al Thomas 2010-04-13 15:34:41 EDT
Tested now with Fedora 13 Beta and nouveau.tv_disable=1 no longer stabilises the image. It does improve it, but it is not stable.
Comment 7 Ben Skeggs 2010-04-13 20:26:42 EDT
What kernel is F13 beta using?
Comment 8 Al Thomas 2010-04-14 14:37:11 EDT
Kernel is 188.8.131.52-19.fc13. Build date of RPM is 19/3/2010. After booting from a cold start (switched off at the plug overnight) the nouveau.tv_disable=1 option does still bring a stable image. What happened yesterday is I booted F13-Beta without the extra kernel option to see if it worked and got the garbled image. I then rebooted and entered the kernel option, which only made the image a bit more stable but not completely. So not sure this is actually a regression, but tested in a slightly different way. F13-Beta only tested with DVI-D interface and the image is still shifted down by a line.
Comment 9 Adam Williamson 2010-04-14 14:56:35 EDT
the final beta image uses kernel -24. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 10 Ben Skeggs 2010-04-14 19:21:55 EDT
Without the extra option nouveau will incorrectly program a non-existant output, I guess some of this bad programming survives a reboot. If things work coming up from cold, and survives across reboots *with* keeping the option, I don't consider this a regression.
Comment 11 Al Thomas 2010-09-28 13:57:15 EDT
Tested with graphics_test_201009-i686.iso and still present. Good to see though that the nForce2 GeForce 4MX IGP is being identified as NV1f instead of just NV18.
Comment 12 Adam Williamson 2010-09-28 14:06:45 EDT
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 13 Ben Skeggs 2010-09-30 01:26:46 EDT
What kernel was present on the LiveCD? If it was before 184.108.40.206-19, can you try that kernel (or any after it) and see if it still happens.
Comment 14 Adam Williamson 2010-09-30 12:57:17 EDT
I built the live images with kernel-220.127.116.11-34.fc14 .
Comment 15 Al Thomas 2011-02-26 10:36:55 EST
Tested with gfx_test_week_20110221_i386.iso and bug still there. <a href="https://bugzilla.redhat.com/show_bug.cgi?id=679366">679366</a> sounds similar.
Comment 16 Al Thomas 2011-05-28 12:33:34 EDT
Tested with F15 and still present
Comment 17 Al Thomas 2011-05-30 12:48:27 EDT
Dowloaded latest Nouveau drivers from git://anongit.freedesktop.org/nouveau/linux-2.6 and framebuffer console is rock steady with CONFIG_VT_HW_CONSOLE_BINDING compile option. So looking promising from upstream.
Comment 18 Ben Skeggs 2011-05-30 18:40:03 EDT
(In reply to comment #17) > Dowloaded latest Nouveau drivers from > git://anongit.freedesktop.org/nouveau/linux-2.6 and framebuffer console is rock > steady with CONFIG_VT_HW_CONSOLE_BINDING compile option. So looking promising > from upstream. I find that surprising. There's absolutely no changes to the modesetting code for your chipset *at all*, between nouveau git and what I packaged in F15.
Comment 19 Al Thomas 2011-05-31 16:43:27 EDT
Created attachment 502109 [details] Nouveau framebuffer console from git 29 May 2011 I'm obviously not expert on this, but if you could take a look at the attached screenshot and confirm that the kernel has got as far as using the nouveau framebuffer drivers. It does say 'nvidiafb: PCI nVidia NV1f framebuffer (64MB @ 0xB0000000)' I've not got as far as creating a root filesystem for it to boot into, but I was surprised as well when the framebuffer appeared as clear as this. I had intended to confirm it didn't work with the latest git and raise a bug at freedesktop as this bug is now 18 months old with no progress.
Comment 20 Al Thomas 2011-05-31 16:44:36 EDT
Created attachment 502111 [details] Nouveau framebuffer console from F15 for comparison
Comment 21 Al Thomas 2011-05-31 16:45:41 EDT
Created attachment 502112 [details] Kernel .config used to compile nouveau from git
Comment 22 Ben Skeggs 2011-05-31 18:29:28 EDT
(In reply to comment #19) > Created attachment 502109 [details] > Nouveau framebuffer console from git 29 May 2011 > > I'm obviously not expert on this, but if you could take a look at the attached > screenshot and confirm that the kernel has got as far as using the nouveau > framebuffer drivers. It does say 'nvidiafb: PCI nVidia NV1f framebuffer (64MB @ > 0xB0000000)' Ah, nvidiafb isn't the same as nouveau, and provides no acceleration of X or 3D etc, just a framebuffer console. You can't use nvidiafb and nouveau at the same time. Nouveau is under "Device Drivers->Staging Drivers->Nouveau (nVidia) cards" in menuconfig.
Comment 23 Fedora End Of Life 2012-08-07 15:28:38 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping