'nv' is selected when no xorg.conf is present even if it doesn't support the nvidia hardware

Bug #385658 reported by Mario Limonciello on 2009-06-10
This bug affects 8 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Canonical Ubuntu QA Team
X.Org X server
Won't Fix
xserver-xorg-video-nv (Ubuntu)
Alberto Milone

Bug Description

Binary package hint: xserver-xorg-video-nv

Testing out the daily image from September 12 2009, the live cd is not booting up to X. It is falling back to failsafe graphics mode.

This happens because the 'nv' driver has it's pci_match_id section set to match any nvidia device and does it's logic to abort in the probe routine. This approach causes troubles because the X server has already claimed the device by the time it's been matched, and so it's not able to free it after the probe routine fails. This prevents any fallback drivers (such as vesa or fbdev) from claiming the device.

This problem has been known to manifest on mostly newer NVIDIA hardware such as the 9400M in the Studio XPS 1340, or the Zotac ION.

ProblemType: Bug
Architecture: i386
Date: Wed Jun 10 13:27:13 2009
DistroRelease: Ubuntu 9.10
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Alpha i386 (20090609)
NonfreeKernelModules: wl
Package: xserver-xorg-video-nv 1:2.1.13-1ubuntu1
ProcVersionSignature: Ubuntu 2.6.30-8.9-generic
 xserver-xorg 1:7.4~5ubuntu21
 libgl1-mesa-glx 7.4.1-1ubuntu1
 libdrm2 2.4.11-0ubuntu1
 xserver-xorg-video-intel 2:
 xserver-xorg-video-ati 1:6.12.2-2ubuntu1
SourcePackage: xserver-xorg-video-nv
Uname: Linux 2.6.30-8-generic i686
 distro: Ubuntu
 architecture: i686kernel: 2.6.30-8-generic

Mario Limonciello (superm1) wrote :
Mario Limonciello (superm1) wrote :

Here's my failsafe .tar. It's far more informative than any of that ubuntu-bug stuff (since the ubuntu-bug stuff was done when I booted with VESA forcefully)

affects: xserver-xorg-video-nv (Ubuntu) → xorg-server (Ubuntu)
Jerone Young (jerone) wrote :

Actually this is the same problem that was resolved in 9.04


So this is a regression

Jerone Young (jerone) wrote :

This justification on this issue is it was an issue in Jaunty that got fixed before release. When users install Ubuntu 9.10 on a Studio XPS 1340 they can not get graphics at all and xorg fails. This is because this machine uses Nvidia Hybrid graphics, and the graphics core trying to be used is not supported by the nv driver.

The patches that fixed this in Jaunty apparently didn't make into upstream xorg or something has changed. The patches in Jaunty would actually use the first graphics card found on the bus. In this case and other hybrid card cases that card is the one that is supported by the open source driver.

Robert Hooker (sarvatt) wrote :

Mario, can you please try the xserver-xorg-video-nv driver on this PPA so we can see how dropping the nv.ids install reacts in this specific situation? The problem is obviously that nv.ids is matching the pci id for your 9200M GS which -nv _does_ support, but your PC wants to use the IGP to save power since it is a hybrid. This wasn't a problem in jaunty because xserver had a default to vesa patch to work around it, but that causes problems with how things are handled in karmic so it will require a bit more work.


Mario Limonciello (superm1) wrote :

Hi Robert:

I've removed the nv.ids from /usr/share/xserver-xorg/pci (if there was more that your package does, i'll add your package on too - it's just harder to test from a PPA behind a network requiring proxy authentication).

Still have failures, here's the Xorg.0.log from that scenario:

Robert Hooker (sarvatt) wrote :

Ahh its ok, that should have the same effect. How about if you delete /etc/X11/xorg.conf entirely? xorg.conf is going away "real soon now", if it works without it great, if not a simple little patch in the detection logic for xserver to match 10DE 086x pci id's to vesa will do it.

Mario Limonciello (superm1) wrote :

Deleting the xorg.conf, it still fails. Here's the log with it deleted and nv.ids gone.

Bryce Harrington (bryce) on 2009-07-13
Changed in xorg-server (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Jerone Young (jerone) on 2009-07-20
summary: - karmic alpha2 candidate doesn't boot up on Studio XPS 1340
+ Karmic doesn't boot up on Studio XPS 1340 with Nvidia Hybrid graphics

there's a new -nv version available, could you try it now?

Changed in xorg-server (Ubuntu):
status: Confirmed → Incomplete
Timo Aaltonen (tjaalton) wrote :

hmm, doesn't look like it supports 0866 yet.

Matt Zimmerman (mdz) on 2009-07-30
Changed in xorg-server (Ubuntu):
status: Incomplete → Confirmed

Bryce - could you please see if we can do anything to help resolve this?

Changed in xorg-server (Ubuntu):
assignee: nobody → Bryce Harrington (bryceharrington)
Bryce Harrington (bryce) wrote :

The original Jaunty patch referred to by Jerone is one I pulled in from RedHat, 170_primary_pci_video_device.patch. We were still carrying that patch up until the 28th (at which point it was dropped as already included in debian when was merged in).

But the actual cause of this is not a dropped patch but rather that the detection system has shifted from the pci.ids based system (local to Debian/Ubuntu) to being detected in xserver and the video drivers themselves, as discussed by previous commenters. It appears the issue is simply that this new logic is claiming support for this hardware in -nv incorrectly.

(WW) NV: Ignoring unsupported device 0x10de0866 (C79 [GeForce 9400M G]) at 03@00:00:0

Bryce Harrington (bryce) wrote :

Fundamentally I think we have at least three separate bugs here.

First, the lack of support for 0866 cards. There's several bug reports upstream about lacking support for 9400 cards, such as fdo #19545, however none mentioned 0866 specifically, so I've filed an upstream bug with this request: https://bugs.freedesktop.org/show_bug.cgi?id=23044 and subscribed Mario (Jerone, you'll need to subscribe yourself since you seem not to be already subscribed to the freedesktop.org bug tracker). Please follow up with upstream with any info or testing they need with this hardware.

Changed in xorg-server (Ubuntu):
status: Confirmed → Triaged
Bryce Harrington (bryce) wrote :

Second is the issue that if a card is not supported by -nv, the xserver should not attempt to boot -nv, but rather use -vesa. I've filed this issue upstream as https://bugs.freedesktop.org/show_bug.cgi?id=23045 - sub to this one if you wish; it's probably the more likely bug to get solved in time for karmic.

Changed in xorg-server:
status: Unknown → Confirmed
Bryce Harrington (bryce) wrote :

Third is the more fundamental issue of selecting which device and driver to use with a hybrid system. A simple solution would be to get a behavior consistent with the previous patch. But a better solution would be for it to try -nv on each card, and then if both fail, try -vesa on each. I've filed this issue upstream as https://bugs.freedesktop.org/show_bug.cgi?id=23046 - again, subscribe if you're interested in following it.

Ultimately I'd like to see all three issues solved, but I'll consider a solution to any one of these three upstream bug reportss to be an acceptable solution to this bug report for karmic; let me know if you think differently.

Timo Aaltonen (tjaalton) wrote :

Bryce: the server is working right; it first tried the driver recognized by the vendor id, and if it doesn't support it, falls back to using the platform fallback driver and then as a last resort, fbdev. In this case though it seems that the fallback just fails for some reason :)

On Thu, Jul 30, 2009 at 07:31:16PM -0000, Timo Aaltonen wrote:
> Bryce: the server is working right; it first tried the driver recognized
> by the vendor id, and if it doesn't support it, falls back to using the
> platform fallback driver and then as a last resort, fbdev. In this case
> though it seems that the fallback just fails for some reason :)

Ah okay, well then the question seems to be, why is the fallback
failing? (But from the Xorg.0.log it appears to be giving up right when
-nv fails, and not trying -vesa.)

It does fall back to probe the devices using vesa, but that fails, so it goes further trying out fbdev (which fails with a more verbose message). Why vesa fails.. that's a mystery, but might be due to the dual-card setup or something.

Changed in xorg-server:
status: Confirmed → Invalid
Bryce Harrington (bryce) on 2009-08-11
description: updated
Bryce Harrington (bryce) on 2009-08-13
tags: added: karmic
Jerone Young (jerone) on 2009-08-25
Changed in oem-priority:
importance: Undecided → High
Changed in oem-priority:
importance: High → Medium
assignee: nobody → Canonical Ubuntu QA Team (canonical-qa)
Changed in oem-priority:
importance: Medium → High
Bryce Harrington (bryce) on 2009-09-03
description: updated

The only graphics drivers that can safely use PCI_MATCH_ANY are 'vesa' and 'fbdev'. -ati and -intel both explicitly list out their supported hardware.

By using PCI_MATCH_ANY for the device IDs, the nvidia driver erroneously reports that it is able to support ANY NVIDIA hardware but then collapses during the probe routine on any unsupported NVIDIA device.

Because the actual failure happens in the probe routine, the X server has already allocated an entity for this card, and a fallback to VESA or FBDEV is no longer possible. This causes trouble when trying to use a system without an xorg.conf.

I'd recommend looking at -ati as they dynamically generate their list of supported IDs.

There are a few handfuls of bugs on the Ubuntu launchpad tracker for karmic that won't boot to X on a live disk, and boil down to this problem, I'd be glad to share links if requested.

Confirmed on karmic daily liveCD from 09/09/09 with a nvidia 9400M graphic card (regular card, not hybrid).
NV doesn't support this card, but for some reason the vesa fallback does not work; the user is sent to a text only login prompt.

From this terminal, creating a minimal xorg.conf to force the use of vesa then starting X works fine.

tags: added: regression-potential
Changed in xorg-server:
status: Invalid → Unknown

Created an attachment (id=29454)
Move logic for matching devices out of probe routine

Created an attachment (id=29455)
Run the parsing script once

I experience the same problem, karmic alpha 5 can not start the installation

summary: - Karmic doesn't boot up on Studio XPS 1340 with Nvidia Hybrid graphics
+ 'nv' is selected when no xorg.conf is present even if it doesn't support
+ the nvidia hardware
affects: xorg-server (Ubuntu) → xserver-xorg-video-nv (Ubuntu)
description: updated
Mario Limonciello (superm1) wrote :

Here's a debdiff that I verified fixed the problem on the Studio XPS 1340. Considering the type of solution, it should fix any other system that was having the same problem.

Changed in xserver-xorg-video-nv (Ubuntu):
milestone: none → karmic-alpha-6
Changed in xorg-server:
status: Unknown → Confirmed
Mario Limonciello (superm1) wrote :

So upstream is likely not going to take this patch in time for karmic, they would rather focus upon getting the X server to be able to fallback later in the detection process.


I would like to propose carrying this patch (or at least a variation of this patch) for karmic, with the intention of dropping it during karmic+1 or karmic+2, basically whenever upstream would have the xserver more gracefully allowing falling back onto another driver.

I don't expect regressions in doing this, but if there was going to be any regression, the worst would be user's with the device ID's 00f0->00ff and 02e0->02e4 not being able to boot into the 'nv' driver, and falling back to VESA.

Changed in xserver-xorg-video-nv (Ubuntu):
status: Triaged → New
assignee: Bryce Harrington (bryceharrington) → nobody
Martin Pitt (pitti) wrote :

Assigning to Alberto for now, who covers for Bryce. Timo, Mario, please feel free to assign to you if you can/want to handle it.

Thanks Mario for putting together the patch. This approach seems appropriate to me in the sense that it errs on the side of caution. As for the regression potential, having a functional VESA on some cards which could work with nv does not seem to be a major problem to me, since realistically you have to install the proprietary driver (or nouveau) to do anything sensible anyway. So +1 from me.

Could you please put this into a PPA and ask for some more widespread testing on ubuntu-devel@? Feedback should be put into this bug preferably (to -devel@ will also do).

Changed in xserver-xorg-video-nv (Ubuntu):
assignee: nobody → Alberto Milone (albertomilone)
Alberto Milone (albertomilone) wrote :

I was aware of the problem but I've never had the time to focus on it. I'm glad to see that Mario did it.

I have reviewed Mario's patch and it looks good to me. I think we should adopt it and keep it (as a workaround) until the problem is fixed in X.

I definitely I agree with Martin that we need feedback so as to be sure that the fix doesn't cause regressions.

+1 from me too.


Is the patch on the build already? I want to test if its working since I
have a Zotac ION. Thanks

On Tue, 2009-09-15 at 15:44 +0000, Alberto Milone wrote:
> I was aware of the problem but I've never had the time to focus on it.
> I'm glad to see that Mario did it.
> I have reviewed Mario's patch and it looks good to me. I think we should
> adopt it and keep it (as a workaround) until the problem is fixed in X.
> I definitely I agree with Martin that we need feedback so as to be sure
> that the fix doesn't cause regressions.
> +1 from me too.

Mario Limonciello (superm1) wrote :

The PPA system is currently broke, so here's a hand compiled deb. It's for i386.

Boot an i386 live disk, and install it using dpkg.

rhpot1991 (rhpot1991) wrote :

Mario's patch fixes my boot issues on a Zotac Ion box.

Alberto Milone (albertomilone) wrote :

if you're using amd64 or lpia you can use this PPA:

Simon Olofsson (simono) wrote :

Works for me with and without Mario's fix. So I don't see a regression. My card is a "nVidia Corporation G73GL [Quadro FX 560] (rev a1)".

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-nv - 1:2.1.14-2ubuntu3

xserver-xorg-video-nv (1:2.1.14-2ubuntu3) karmic; urgency=low

  * Add patches from f.d.o # 23870
    - 0001-Move-the-logic-for-matching-devices-out-of-probe-rou.patch
      + Disable the logic for matching devices in the probe routine.
      + Instead match explicitly on pci_id_match (LP: #385658)
    - 0002-Run-the-parsing-script-to-generate-an-initial-list-o.patch
      + Generate the list of devices to match once
  * Refresh 105_gf7025_gf7050 to match the new way of doing things.

 -- Mario Limonciello <email address hidden> Sat, 12 Sep 2009 10:04:05 -0500

Changed in xserver-xorg-video-nv (Ubuntu):
status: New → Fix Released
Mark Cariaga (mzc) wrote :

Live CD and drivers are already working on a ZOTAZ ION Board.. great work guys.

Jerone Young (jerone) on 2009-09-29
Changed in oem-priority:
status: New → Fix Released
Bojan Vitnik (bvitnik) wrote :

Mario's patches introduce some regressions. Bridged AGP cards are affected because of the missing PCI-IDs in "nv_list.csv". I suppose "nv_list.csv" was based on NVKnownChipsets[] table from "nv_driver.c", but, as I already confirmed, NVKnownChipsets[] is not a complete table of all *supported* chips. Bridged AGP cards are handled differently by the code so their PCI-IDs are not listed in NVKnownChipsets[]. NVKnownChipsets[] is mare string reference. Affected PCI-IDs are 02E0-02E4 and 00F0-00FF. The result of all of this is that -nv is refusing to work with affected cards even when they are supported. In Jaunty, -nv worked just fine with my card - GeForce 7600 GS AGP, thou autodetection failed because of the same reason. Now in Karmic, autodetection works but driver fails to work.

More in the bug #385703 (read the last few comments).

Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium

Nobody is supporting xf86-video-nv and it will be going away at some point in the future. If your problem persists with nouveau or the proprietary driver provided by nVidia, please re-file accordingly. We apologize for the inconvenience.

This is part of an automated bulk action; if you believe that this bug was closed in error, then change the targeted component and reopen it.

Changed in xorg-server:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.