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

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)

Actually this is the same problem that was resolved in 9.04

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/304445

So this is a regression

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.

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.

https://edge.launchpad.net/~sarvatt/+archive/bugs

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:

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.

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

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

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

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

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 1.6.2.901-1 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

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.

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.

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.

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.

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.

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

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.

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.

http://lists.x.org/archives/xorg-devel/2009-September/002019.html

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.

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).

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.

Hi,

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.
>

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.

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

if you're using amd64 or lpia you can use this PPA:
https://launchpad.net/~albertomilone/+archive/x-testing

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)".

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

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

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).