9100m G card (for acer aspire 4350)

Bug #321613 reported by homunq on 2009-01-26
Affects Status Importance Assigned to Milestone
xserver-xorg-video-nv (Ubuntu)

Bug Description

Binary package hint: xserver-xorg-video-nv

My 9100m G card doesn't work with vanilla nv, but works fine when I add the line:

  { 0x10DE0844, "GeForce 9100M G" },

to the end of the list in nv_driver.c (and recompile, of course :)

Bryce Harrington (bryce) wrote :

Hi homunq,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

Changed in xserver-xorg-video-nv:
status: New → Incomplete
Gaetan Nadon (memsize) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 333040, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.

Thanks for the valuable information you provided.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-nv - 1:2.1.13-1ubuntu2

xserver-xorg-video-nv (1:2.1.13-1ubuntu2) karmic; urgency=low

  * Add 104_geforce_6600gt_9100mg.patch:
    + Support PCI ID for GeForce 6600 GT (LP: #219101)
    + Support PCI ID for GeForce 9100M G (LP: #321613)

 -- Bryce Harrington <email address hidden> Mon, 08 Jun 2009 19:06:05 -0700

Changed in xserver-xorg-video-nv (Ubuntu):
status: Incomplete → Fix Released
homunq (homunq) wrote :

This does not work for me in Jaunty. I may be doing something wrong. Here's what I do:

-download https://launchpad.net/ubuntu/karmic/+source/xserver-xorg-video-nv/1:2.1.13-1ubuntu2
-unpack, configure, make, make install
-copy /usr/local/lib/xorg/modules/drivers/nv_drv.so to /usr/lib/xorg/modules/drivers/nv_drv.so
-add "10DE0844" as penultimate line of /usr/share/xserver-xorg/pci/nv.ids (in correct order for hex)

Result: X won't start at all (no screens).

I went back to the proprietary drivers for now.

homunq (homunq) wrote :

(small note: I did not sudo for unpack, configure or make, I did of course for the rest of the steps.)

Bryce Harrington (bryce) wrote :

Looks like you forgot to apply the patch! ;-) You need to have patch 104_geforce_6600gt_9100mg.patch applied at least.

A better way to backport packages is to download the code and use 'debuild -uc -us -i' to build debs. (You can use 'apt-get build-dep xserver-xorg-video-nv' to install the build dependencies for it.)

An alternative approach is to download the package, use 'dch -i' to add an empty changelog entry and make sure the distro specified is 'jaunty' instead of 'karmic', and upload that to your ppa, and then download the debs when it's done building.

In either case, installing the debs takes care of updating the .ids file and installing the so, man page, etc. and ensures you can cleanly downgrade or upgrade if needed.

Robert Hooker (sarvatt) wrote :

Can you provide a Xorg.0.log of it working by any chance homunq? I can't imagine this works since 8xxx and up IGPs arent supported at all and IGPs in general require more than just editing the pci ids from what I can see.

Gaetan Nadon (memsize) wrote :

I was going to ask why the 9100M G would be the only C77 card to be supported. In bug 333040, Asif Youssuff provided a clean set of log files that demonstrates how the GPU fails under karmic. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/333040/comments/27.
What I found troubling is that the "nv" driver get loaded even in the absence of the id in the nv.ids file.

(==) Matched nv for the autoconfigured driver
(==) Assigned the driver to the xf86ConfigLayout
(II) LoadModule: "nv"

This would explain the line later in the log:
(WW) NV: Ignoring unsupported device 0x10de0844 (C77 [GeForce 9100M G]) at 02@00:00:0
(EE) No devices detected.

The expected behaviour when the id is not supported is to load the vesa driver. I suspect that when the id is manually added, the vesa driver is loaded (an equally incorrect behavior) which leads to claims that it now works. We have yet to see hard evidence that the "nv" driver is loaded and performing adequately. I am only speculating, but one difference between IGPs and discrete video cards is that they have support in the kernel for the chipset.

I know this is a side issue, but it may lead to the resolution of this bug report. Further more, the main design point of a vesa fallback driver was to avoid a "crashing video" scenario to provide a great "out-of-the-box" experience. It does not seem to work in the case of the 9100M G and I suspect it does not in the case of other IGPs.

Robert Hooker (sarvatt) wrote :

Yeah, by the point he posted that set of logs the patch was already there which would force it to use nv because the pci id did exist even though it didn't work. The main problem is that we need to delete the xorg.conf entirely (and the pci ids) for xserver to use it's internally generated default driver priority system which would get around this issue. That has some problems in practice that I've run into where people have had framebuffer drivers by the kernel which can make the detections skip over some KMS drivers in favor of the fbdev ones.. Leaving the xorg.conf around and sticking to the pci.ids files is a horrible way to go about this because each driver handles it differently, and there are major problems with the way -nv in particular ends up having it done because a large portion of the supported cards do not get id's generated. One thing I noticed in this regard -- In the livecd-rootfs script a very old bug fix is included (that isn't relevant anymore per tjaalton) which deletes then touches an empty xorg.conf and even just having a blank one like that will screw up in this manner.

Line 477 here -

One partial solution I can see would be to drop the xorg.conf completely at least on livecd's. Just dropping the xorg.conf would let xservers automatic configuration mechanism work which would let each brand of cards have their own priority table and the server will try to load each driver and then let the driver decide if its compatable or not before moving on to the next in the list. For instance on my intel graphics, it sets up a priority table of intel > i810 > vesa > fbdev and works its way down the list if the previous driver claims it doesn't support it. i810 should be removed probably as a side note, and we will have to make fbdev not try to claim it's the matching driver because of the small problem that kms has when its a module and there are framebuffer devices available packed into our initrds by the greedy initramfs-tools scripts. I have attached my /var/log/Xorg.0.log to show how it works when no xorg.conf exists, I didn't know it was this smart either :)

I think it would be possible for instance for ubuntu to carry a patch against hw/xfree86/common/xf86AutoConfig.c in the xserver package to change around the autodetection priorities for specific troublesome cards which can be matched in a wildcard manner instead of manually adding them to the ids. It just so happens this is how fedora is handling changing nouveau to the default nvidia driver through this patch.


Also notice they specifically force all nvidia cards in the 084x and 086x series (of which the 9100M G in this bug report belongs to) to use vesa because it is unsupported by anything else?

Anyway, these are just my thoughts on it after discussing it with people who understand how it works alot more than I do. I hope we can get it worked out so it's a painless release :)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers