|Summary:||"NVIDIA GeForce Go 7150M" not known by lspci or xorg driver|
|Product:||[Fedora] Fedora||Reporter:||Trever Adams <trever>|
|Component:||xorg-x11-drv-nouveau||Assignee:||Ben Skeggs <bskeggs>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||airlied, bskeggs, jpg, mcepl, vedran, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-02-14 02:37:16 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Trever Adams 2007-12-03 09:15:55 UTC
Description of problem: This device has mixed results with the nv and vesa driver for various people. I am not sure if it will work or not. The pci-ids are in the "additional info" section. I believe this just needs to be added to the pci-id database and, if it is supported, added to what the NV driver knowns about. Version-Release number of selected component (if applicable): xorg-x11-drv-nv.x86_64 Additional info: 00:12.0 VGA compatible controller : nVidia Corporation Unknown device [10de:0531] (rev a2) (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company Unknown device [103c:30cf] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at f5000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 3: Memory at f4000000 (64-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at 88000000 [disabled] [size=128K] Capabilities: <access denied>
Comment 1 Adam Jackson 2008-02-22 20:15:51 UTC
According to the nv maintainer, this chip just plain doesn't work with the nv driver yet. Should certainly get fixed, but I don't believe this to be a blocker for F9.
Comment 2 Trever Adams 2008-03-28 20:55:52 UTC
Any progress or has this been punted?
Comment 3 Jim Bradbury 2008-04-05 02:35:21 UTC
Created attachment 301357 [details] This file is actually /var/log/Xorg.0.log This Xorg log file shows that GeForce 7150M is not supported by xorg-x11-drv-nv-2.1.8-1.fc9.x86_64 This video card is prevalent in new HP laptops (Apr 2008)
Comment 4 Jim Bradbury 2008-04-05 02:46:11 UTC
Created attachment 301358 [details] This file is /var/log/Xorg.0.log
Comment 5 Bug Zapper 2008-05-14 04:04:34 UTC
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Trever Adams 2009-04-06 17:52:12 UTC
Retargetting to rawhide and nouveau driver. Still a problem.
Comment 7 Ben Skeggs 2009-04-06 22:02:50 UTC
Can I see /var/log/Xorg.0.log after trying to use the nouveau driver?
Comment 8 Bug Zapper 2009-06-09 09:22:45 UTC
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
Comment 9 Trever Adams 2009-08-31 09:52:59 UTC
Ben, I am sorry I never provided the log. Here is what is going on now. Kernel modesetting or the nouveau driver have the same bugs. Plymouth center of screen ends up in lower right (if you view my WXGA laptop, 1280x800, as two rows of three columns, it goes from the middle (1,2 and 2,2) to the bottom right (2,3)). A text login screen goes from 1,1 to 1,2. GDM login goes from 1,2 & 2,2 to 2,3. It also appears that there are some doubling of the first character in the text login. The plymouth boot screen and some other graphic stuff appears that some lines are not drawn in the right place. It appears that some rows are inserted as black. This is a huge leap from F11. It is far from usable, but it is MUCH better. Problem is, now I can't use my laptop for the moment. Is this a bug in memory location computation?
Comment 10 Trever Adams 2009-09-02 00:56:07 UTC
Created attachment 359461 [details] Log from recent session with problems described in last post
Comment 11 Ben Skeggs 2009-09-02 01:13:24 UTC
Thanks for the update :) Ok, with your current setup can I also see the output from dmesg? (just run "dmesg > dmesg.log" from a console after you've booted and attach it here) Something that might be worth trying too is to boot with "nouveau.modeset=0" and seeing if you fare any better. Thanks, Ben.
Comment 12 Trever Adams 2009-09-02 06:48:53 UTC
nomodeset and nouveau.modeset=0 cause the same symptoms. Text mode is great. The second X tries to start, the screen goes back. ALT-CTRL-F# doesn't seem to fix it. Three finger salute doesn't reboot the system either. I am going back to linux now to try and get the dmesg log (I thought it would be better to do it without any command line options).
Comment 13 Trever Adams 2009-09-02 11:09:32 UTC
The last round of updates makes it so that the system hangs on vt switch. I am unable to capture the dmesg log at this time.
Comment 14 Trever Adams 2009-09-03 10:17:38 UTC
Created attachment 359662 [details] Requested dmesg log Took enough time to make sense of the corrupted screen. Here is the dmesg.log.
Comment 15 Trever Adams 2009-09-15 18:09:37 UTC
kernel-2.6.31-12.fc12.x86_64.rpm xorg-x11-drv-nouveau-0.0.15-10.20090914git1b72020.fc12.x86_64.rpm Still broken with these two. A whole lot of flickering has gone away, but not all, over the last week. But I still get a really weird, corrupted display, with and without nouveau.modeset=0.
Comment 16 Trever Adams 2009-09-30 01:00:18 UTC
Created attachment 363097 [details] Plymouth shot showing corruption Sorry that this is blurry. I am doing the best I can to show the corruption.
Comment 17 Trever Adams 2009-09-30 01:03:05 UTC
Created attachment 363098 [details] GDM login showing corruption
Comment 18 Trever Adams 2009-09-30 01:04:15 UTC
As of today, xorg-driver-nouveau and kernel do not fix this problem. The flickering is also very bad again.
Comment 19 Juan Pablo Giménez 2009-10-12 21:26:36 UTC
I have the same symptoms reported in this bug, https://bugzilla.redhat.com/show_bug.cgi?id=492251
Comment 20 Trever Adams 2009-10-13 01:32:58 UTC
Thank you, this does appear to be identical problem. I am glad you have provided the files requested in your bug report, as I was never asked for such.
Comment 21 Matěj Cepl 2009-11-05 17:11:30 UTC
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 (at least F12Beta, but even better if the very latest versions). 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.]
Comment 22 Trever Adams 2009-11-06 12:18:07 UTC
This bug is still indeed a problem.
Comment 23 Bug Zapper 2009-11-16 07:59:31 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 24 Trever Adams 2010-03-26 19:29:36 UTC
This problem still exists in the 13 Alpha install. I will be trying it with the updates to 13 since the Alpha release.
Comment 25 Trever Adams 2010-04-23 13:38:46 UTC
In some emails related to this bug, I stated that the nouveau driver was doing better. That while it wouldn't give me 1280x800 that it was giving me a 1024x768 (actually about 800, but past 768 was borked) and that there was a black strip on the right side of the screen (1024->1280). The kernel one was still totally messed up. I am not sure where things changed, but the kernel driver is still borked. Now, nouveau in xorg won't start with nomodeset=1. So, it is not screwed up just like kernel where things are as they were described above.
Comment 26 Vedran Miletić 2010-06-07 18:42:06 UTC
Trever, how about Fedora 13 final?
Comment 27 Trever Adams 2010-06-08 00:45:13 UTC
I tested this just a day or two ago. The problem still exists in the kernel mode setting and in X. I have installed the proprietary drivers for now. I hope this gets fixed soon.
Comment 28 Trever Adams 2011-03-06 23:07:00 UTC
This problem still exists. The text mode may be slightly better than it used to be, everything else is still a problem.
Comment 29 Trever Adams 2011-09-30 07:03:52 UTC
This problem still exists in RC3 of F16B. Worse, the installation menu now lacks the basic video driver option, making it a pain to dig around to find nomodeset to do it manually.
Comment 30 Fedora End Of Life 2013-01-17 01:04:58 UTC
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is 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" 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
Comment 31 Fedora End Of Life 2013-02-14 02:37:21 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.