Created attachment 383579 [details] Xorg.0.log Description of problem: I upgraded from F9 to F12 using CDs. Had to use basic video driver mode as the the standard failed on my nVidia TNT2 Model 64 card. When I reset the X11 driver to nouveau, I get a core dump and no login display. Changing to "nv" driver works and I can login and proceed. Main complaint is that install process fails and causes lots of confusion. Version-Release number of selected component (if applicable): PCI:*(0:1:0:0) 10de:002d:1043:0239 nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] rev 21, Mem @ 0xf4000000/16777216, 0xf6000000/33554432, BIOS @ 0x????????/65536 Linux walden3.local 2.6.31.9-174.fc12.i686.PAE #1 SMP Mon Dec 21 06:04:56 UTC 2009 i686 i686 i386 GNU/Linux box: HP 750n, http://h10025.www1.hp.com/ewfrf/wc/document?lc=en&dlc=en&cc=us&docname=bph07045 xorg-x11-drv-nouveau-0.0.15-18.20091105gite1c2efd.fc12.i686 How reproducible: always Steps to Reproduce: 1. set xorg.conf Driver to "nouveau" 2. reboot Actual results: Boot suceeds, but no display, just black screen with white blinking text cursor that follows mouse Expected results: graphical login screen should appear Additional info: See Xorg.0.log and dmesg
Created attachment 383581 [details] dmesg log
Is it possible to get a dmesg log *without* nomodeset being set? If you see nothing on the display it might be possible to login blindly and save the output somewhere, or reboot blindly and it may be in /var/log/messages. Another thing that may be worth trying is booting with nouveau.noagp=1 in your kernel boot options.
I removed the nomodeset from grub.conf. Here is the appropriate section: title Fedora (2.6.31.9-174.fc12.i686.PAE) root (hd0,0) rdblacklist=nouveau vmalloc=256m kernel /vmlinuz-2.6.31.9-174.fc12.i686.PAE ro root=/dev/mapper/vg_walden3-lv_root LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb vga=0x318 quiet The display rapidly blinked the message: [drm] nouveau 0000:01:00.0: Bad Dispay Configuration Block signature () and remained a black screen with a blinking text cursor. the message log had lots of the follow: Jan 13 16:45:06 walden3 init: prefdm main process (1846) terminated with status 1 Jan 13 16:45:06 walden3 init: prefdm main process ended, respawning Jan 13 16:45:07 walden3 gdm-binary[1913]: WARNING: GdmDisplay: display lasted 0.445352 seconds Jan 13 16:45:07 walden3 gdm-binary[1913]: WARNING: GdmDisplay: display lasted 0.435846 seconds Jan 13 16:45:08 walden3 gdm-binary[1913]: WARNING: GdmDisplay: display lasted 0.444915 seconds Jan 13 16:45:08 walden3 gdm-binary[1913]: WARNING: GdmDisplay: display lasted 0.435438 seconds Jan 13 16:45:09 walden3 gdm-binary[1913]: WARNING: GdmDisplay: display lasted 0.434722 seconds Jan 13 16:45:09 walden3 gdm-binary[1913]: WARNING: GdmDisplay: display lasted 0.437279 seconds Jan 13 16:45:09 walden3 gdm-binary[1913]: WARNING: GdmLocalDisplayFactory: maximum number of X display failures reached: check X server log for errors The new Xorg.0.log with nomodeset removed is attached
Created attachment 383586 [details] Xorg.0.log with nomodeset removed
Ok. Both KMS and UMS have the same bug it appears. Can you grab me a VBIOS image, instructions on how to do so are at http://nouveau.freedesktop.org/wiki/DumpingVideoBios. Can you follow the vbtracetool instructions from that page please. You will need to disable selinux before vbtracetool will operate however. Thanks.
I could not get vbtracetool to work. It kept giving me "mmap /dev/zero: Permission denied" errors. So I tried the dd method and I have attached the vbois.rom file
Created attachment 383603 [details] vbois.rom from dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64
If that still happens even while trying to run it as root, it's because you haven't disabled SELinux. Anyway, thank you! The dd copy *may* be ok, we'll see :)
Can you install the appropriate RPM for your architecture from http://koji.fedoraproject.org/koji/taskinfo?taskID=1920413 and retry? You will need to use "nomodeset" to test the change, if it works OK there I'll do the appropriate fixes to KMS also. Thanks!
OK. Will try tommorrow
Created attachment 384064 [details] successful Xorg.0.log using patched nouveau driver and nomodeset
I downloaded new driver and installed it. It worked (mostly)! See attached Xorg.0.log grub.conf is: root (hd0,0) rdblacklist=nouveau vmalloc=256m kernel /vmlinuz-2.6.31.9-174.fc12.i686.PAE ro root=/dev/mapper/vg_walden3-lv_root nomodeset LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb vga=0x318 quiet initrd /initramfs-2.6.31.9-174.fc12.i686.PAE.img xorg.conf is: Section "Device" Identifier "Videocard0" Driver "nouveau" EndSection Problem (fixed I think): Initially after boot, the monitor was dark and displaying "Out of Range". Looking at the Xorg.0.log, it ended with a "resize called 1600 1200" message, which is way too big for my display. When I ssh'ed in an pkill'ed the Xorg, it seemed to sense the monitor better and I got a 1024x960. Using the system-config-display to force 1280x1024 did not seem to help. I was getting "Out of Range" after each log out. I would have to kill the Xorg to get it to restart with a proper setting. I then remembered I had older xorg.conf from another system in place from prior work arounds, so I replaced it with the small one listed above, which seems to have solved the "Out of Range" problem. I have had this "Out of Range" problem previously in F9 using nv. I also have a KVM switch connecting my monitor to 2 different systems, so I have also suspected that causing some problems. All in all, the monitor is now being sensed, which it never was before. glxgears is noticeable better than with the nv driver, too. Question: When this patch is put into the KMS, can I drop the the "rdblacklist=nouveau vmalloc=256m" and "nomodeset vga=0x318" and have real rhgb?
I'd wager that something in the previous xorg.conf overrode the display's EDID and allowed the 1600x1200 mode to be validated when it shouldn't have been. You'll definitely be able to drop "rdblacklist=nouveau nomodeset vga=0x318" once it's in KMS (the patch is upstream already, I'll get it into F12 soon) and have a graphical boot. I'm not sure why you've got vmalloc=256m, it may still be required.
xorg-x11-drv-nouveau-0.0.15-19.20091105gite1c2efd.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/xorg-x11-drv-nouveau-0.0.15-19.20091105gite1c2efd.fc12
xorg-x11-drv-nouveau-0.0.15-19.20091105gite1c2efd.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.