Bug 555202 - nVidia NV5M64 [RIVA TNT2 Model 64/Model 64 Pro core dump
nVidia NV5M64 [RIVA TNT2 Model 64/Model 64 Pro core dump
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
12
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-13 19:10 EST by Philip Walden
Modified: 2010-01-15 17:00 EST (History)
3 users (show)

See Also:
Fixed In Version: 0.0.15-19.20091105gite1c2efd.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-15 17:00:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log (7.07 KB, text/plain)
2010-01-13 19:10 EST, Philip Walden
no flags Details
dmesg log (29.73 KB, text/plain)
2010-01-13 19:15 EST, Philip Walden
no flags Details
Xorg.0.log with nomodeset removed (7.37 KB, text/plain)
2010-01-13 19:58 EST, Philip Walden
no flags Details
vbois.rom from dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64 (64.00 KB, application/octet-stream)
2010-01-13 22:14 EST, Philip Walden
no flags Details
successful Xorg.0.log using patched nouveau driver and nomodeset (68.91 KB, text/plain)
2010-01-14 12:28 EST, Philip Walden
no flags Details

  None (edit)
Description Philip Walden 2010-01-13 19:10:41 EST
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
Comment 1 Philip Walden 2010-01-13 19:15:29 EST
Created attachment 383581 [details]
dmesg log
Comment 2 Ben Skeggs 2010-01-13 19:20:25 EST
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.
Comment 3 Philip Walden 2010-01-13 19:56:50 EST
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
Comment 4 Philip Walden 2010-01-13 19:58:00 EST
Created attachment 383586 [details]
Xorg.0.log with nomodeset removed
Comment 5 Ben Skeggs 2010-01-13 20:14:11 EST
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.
Comment 6 Philip Walden 2010-01-13 22:13:14 EST
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
Comment 7 Philip Walden 2010-01-13 22:14:18 EST
Created attachment 383603 [details]
vbois.rom from dd if=/dev/mem of=vbios.rom bs=1k skip=768 count=64
Comment 8 Ben Skeggs 2010-01-13 22:34:24 EST
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 :)
Comment 9 Ben Skeggs 2010-01-14 01:42:58 EST
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!
Comment 10 Philip Walden 2010-01-14 01:56:28 EST
OK. Will try tommorrow
Comment 11 Philip Walden 2010-01-14 12:28:06 EST
Created attachment 384064 [details]
successful Xorg.0.log using patched nouveau driver and nomodeset
Comment 12 Philip Walden 2010-01-14 12:49:14 EST
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?
Comment 13 Ben Skeggs 2010-01-14 17:47:13 EST
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.
Comment 14 Fedora Update System 2010-01-14 20:33:59 EST
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
Comment 15 Fedora Update System 2010-01-15 17:00:25 EST
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.

Note You need to log in before you can comment on or make changes to this bug.