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):
Steps to Reproduce:
1.Boot from Fedora 13 Alpha LiveDVD
Created attachment 399752 [details]
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.
Created attachment 399753 [details]
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?
Just a correction: it's nouveau.tv_disable=1 you'll need to use
You're right there is nothing plugged into the TV connector.
I have tried this with kernel kernel-220.127.116.11-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.
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.
What kernel is F13 beta using?
Kernel is 18.104.22.168-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.
the final beta image uses kernel -24.
Fedora Bugzappers volunteer triage team
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.
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.
Fedora Bugzappers volunteer triage team
What kernel was present on the LiveCD? If it was before 22.214.171.124-19, can you try that kernel (or any after it) and see if it still happens.
I built the live images with kernel-126.96.36.199-34.fc14 .
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.
Tested with F15 and still present
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.
(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.
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.
Created attachment 502111 [details]
Nouveau framebuffer console from F15 for comparison
Created attachment 502112 [details]
Kernel .config used to compile nouveau from git
(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 @
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.
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: