Bug 493981 (F11BFailsGeforce7100)
Created attachment 338064 [details]
Default xorg.conf created after installing system-config-display
This is the default xorg.conf created by system-config-display which then successfully loads the VESA driver.
Created attachment 338065 [details]
Xorg log generated with default xorg.conf file
This is the Xorg log that is generated when the default xorg.conf file is generated with system-config-display. It results in a successful load of the VESA driver.
How do you go with the build available from http://koji.fedoraproject.org/koji/taskinfo?taskID=1275633 ? Created attachment 338133 [details]
Xorg log from updated nouveau driver
Updated Xorg log output from updated driver (from request for info)
(In reply to comment #4) > Created an attachment (id=338133) [details] > Xorg log from updated nouveau driver > > Updated Xorg log output from updated driver (from request for info) Tried it. No dice. Output from the updated driver attached... For what it's worth, I also tried with teh regular nv driver. Same result. Output is attached. Created attachment 338135 [details]
Xorg output from nv driver
Xorg output from nv driver
What type of monitor are you using and is it same as when you used it for F10? Have you tried a different one (doesn't matter what it is) just to test? Don't know why this would matter but just a *hunch* I have for some reason. (In reply to comment #8) > What type of monitor are you using and is it same as when you used it for F10? > Have you tried a different one (doesn't matter what it is) just to test? Don't > know why this would matter but just a *hunch* I have for some reason. Display is an Acer P243W flat screen and is connected via a DVI cable. Yes, it runs swimmingly well on F10 - in fact the display with the proprietary nVidia drivers is nothing short of stunning. I haven't tried this with another display as yet. I'm not sure why that would make a difference though. If I can find an extra VGA cable (or a DVI to VGA converter plug), I'll give this a shot with an old Compaq P1100 I have sitting around. I pushed another fix that will hopefully help, it's available from xorg-x11-drv-nouveau-0.0.12-25.20090408gitd8545e6.f11. How do you fare with that? I think we're getting closer...! X still fails to load in the end, but there is clear evidence in both the behavior and the logs (will attach 2 of them) that we almost got there. On the attachments: - The first will be the log file when there is no specific xorg.conf file - The second uses an xorg.conf file created by system-config-display and manually selecting the nouveau driver Of note - when I used system-config-display --reconfig to generate a new xorg.conf file, it still failed back to the vesa friver. I had to specifically select the nouveau driver. Created attachment 338704 [details]
Xorg log from xorg-x11-drv-nouveau-0.0.12-25.20090408gitd8545e6.f11
Xorg log created with xorg-x11-drv-nouveau-0.0.12-25.20090408gitd8545e6.f11. This one was generated with no xorg.conf file present.
Created attachment 338706 [details]
Xorg log from xorg-x11-drv-nouveau-0.0.12-25.20090408gitd8545e6.f11 using xorg.conf
Xorg log created from xorg-x11-drv-nouveau-0.0.12-25.20090408gitd8545e6.f11 when using an xorg.conf file created via system-config-display and manually selecting the nouveau driver.
Can you attach any /var/log/nv_*.rom files that may be present please? (In reply to comment #14) > Can you attach any /var/log/nv_*.rom files that may be present please? Checked for the presence of any nv_*.rom files anywhere on the file system and none exist. I then checked for everything starting with nv and came up only with things like nvdriver (a directory) and a .inf file. Not sure if that helps... Sorry, that would have been /var/run/nv*.rom (note the lack of "_"). Do you have any way to ssh into the machine remotely? If you do, can you install the xorg-x11-drv-nouveau-debuginfo package and get a proper backtrace with gdb? (gdb --args /usr/bin/Xorg -ac :0) Thanks! Got the packages installed, but will need to do some additional work to ssh to it. The issue is Network Manager doesn't start until you launch an X session, so I would have to re-configure the network to run without NM first. Any way to do this backtrace from the local machine? I'll try to get this done ASAP today. Otherwise I will not be able to until the weekend due to job related travel... This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping How is it going with this issue? Are you still having problems, and if so, have you done the backtrace from comment #16? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers I was never able to get backtrace to work on this by booting from a USB drive. However, I know that the issue still does exist on on a fresh F11 install, and has not changed to my knowledge even with the updates as of today. I've since moved to using the proprietary nVidia drivers, but could try to get this information from the nouveau drivers by reconfiguring on a temporary basis. I could then ssh into the machine from my laptop. I'll post those results back to here... Any luck with getting that info? Unfortunately no I was not. Thanks to the way NetworkManager works, the system would not come up on the network until after X had started. I was going to have to go through a number of additional steps that I didn't have time for to get the system up on the network. No sure what else to do at this point. It seems apparent this is something specific to this model of card. Not sure what to try else. Open to suggestions... In the meantime, I'm just continuing with the proprietary drivers. Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.] OK with me to close this bug. I am certainly one of those who has moved on to newer versions. Preparing to load F12 in a few days when it releases... alright then, thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers |
Created attachment 338062 [details] Xorg log showing failure of nouveau and failure to fall back to VESA Description of problem: F11B fails to load X with NVidia GeForce 7100 (on EVGA 7100 MB. Version-Release number of selected component (if applicable): How reproducible: Every time. Steps to Reproduce: 1. Create Live USB drive of F11 2.Boot from USB drive 3. X fails to load (blank screen instead. Actual results: X fails to load any driver. Expected results: X successfully loads either the nouveau or the VESA dirver Additional info: Appears from the logs that nouveau driver recognizes the card, but then fails with a Signal 11. By that time, it seems we're already committed to using nouveau so falling back to VESA is never tried. Xorg logs will be attached. Installing system-config-display and forcing a default xorg.conf file (attached) causes a successful fallback to using the VESA driver.