X incorrectly defaults to using disabled Intel onboard graphics card instead of nVidia FX5500 PCI card

OK insteading using loads of attachments I decided to put them all into one file...here's the output of:

lspci -vv > lscpi-vv.log
dmesg > dmesg.log
cat /proc/version > proc_version.log
cat /etc/X11/xorg.conf

BTW, that's all on my working Edgy installation, not the Feisty LiveCD in question. Its the same hardware, so shouldn't make a difference right?

Sorry if I've done anything wrong...feel free to ask for more info (and give detailed instructions on how to get it and put it here please :$)

-Rashid

Hi Rashid,

Actually, if you could, please attach your /etc/X11/xorg.conf and /var/log/Xorg.0.log files from when you've booted Feisty. This will give us a clue why feisty is not detecting your hardware as it had with Edgy.

Hi Bryce

I'm in Ubuntu feisty now and when I booted I had the same problem...I just copied my Edgy xorg.conf over into feisty and changed the driver line from "nvidia" to "nv" and started x and this is what I've been using since so my xorg.conf in feisty is effectively already attached...

Or do you mean that I should try booting a feisty livecd and attach the xorg.conf the livecd tries to use? I'll have to download and burn a new feisty CD...

BTW, interestingly, sidux also has this problem, but knoppix and pclinuxos detected my card and used the nv driver perfectly. They must be doing something right...

Thanks for your reply.

-Rashid

Rashid:
The /var/log/Xorg.0.log is still required though...

Do you mean from my current installation of feisty or from when I try to boot the LiveCD?

Here is the /var/log/Xorg.0.log from my current installation.

If its the latter you want (livecd one) I'll try to post that up soon, once I've burnt the kubuntu cd.

-Rashid

Rashid:
That log is not from the open source nv driver - it says you are using the NVIDIA binary driver (AND you have sometimes problematic TrippleBuffer option set).

Is this bug about the open source nv driver or the closed source NVIDIA binary driver?

Sitsofe:
Haha yeah that's what I was confused about...which did you want. It's not about the nv nor the nvidia driver as such, but xorg's inability to use nv.

I'm in Kubuntu Feisty LiveCD now and I've attached the Xorg.0.log from when it firsts boots and doesn't manage to start X.

What I had to do was edit xorg.conf and change my device from "Intel blah blah" to "FX5500" and change driver from "i810" to "nv" and change the BusID from "PCI:0:2:0" to "PCI:2:7:0" and then change Screen to "FX5500" also and then startx and it worked. Dunno if that helps you?

Sorry if I've done the wrong thing again! Bare with me, this is my first bug report :$

-Rashid

Rashid:
Ah I see. You have both an onboard Intel integrated card and an NVIDIA card and what you are finding is that X is defaulting to using the onboard Intel card rather than using the discrete NVIDIA card. Furthermore you have to manually rectify this situation by manually editing /etc/X11/xorg.conf ? Is that correct? Effectively you are seeing the problem described on http://doc.gwos.org/index.php/Nvidia_Intel_Integrated ?

Yes, that is correct :)

Regarding that page: my intel chipset is disabled in my BIOS, and the monitor is connected to the PCI nvidia card so I don't know why X tries to use the intel one :S

So, is this a bug or something else?

Thanks for your reply.

-Rashid

Rashid:
Oh hang on. You did the install using one graphics card and then switched to another post install? That won't be automatically dealt with. I'm not sure if that's a bug per se...

Bryce what do you think?

No, I installed my graphics card quite a while ago, and have had my monitor plugged into the new PCI Nvidia card since, and I disabled the intel one in my BIOS when I installed the new card (last year).

When I try the LiveCD first it tries to use the intel card, but I manually change xorg so it uses the nvidia card, and then start X in the livecd and do the install. Once installed, it remembers my xorg configuration.

I think this is a bug, because xorg shouldn't try to use my Intel chip, but rather the nvidia one (because thats the one selected in the BIOS, plus my monitor is plugged into the nvidia one)

-Rashid

Rashid:
OK thanks for clearing that up.

Sitsofe, yes this is an interesting (and probably not altogether uncommon) case we should test for.

I am doubtful the automatic installation will be able to detect this case properly all the time, although if it can see that a monitor is connected to one card, and nothing is connected to the other, that ought to be a sufficient clue. However in the not-so-uncommon case where the monitor can't be detected, then it would seem reasonable to default to the onboard intel port (although I suppose one could argue that if there is a card beyond the onboard chip, the user's intent is likely to be to override the motherboard, but trying to guess user intentions can sometimes make things worse...) In that case, the approach Rashid took may be the best we can hope for.

Rashid, thanks, you've give sufficient information on this bug. It will probably take a while for us to get this fixed, but at least now I think we understand it.

Can anyone confirm this bug? My test systems all either are laptops or don't have a built-on graphics chip, so I don't have one to test with at the moment.

Marking as high, since this may prove to be a difficult corner-case for BulletProofX, but one we'll need to handle somehow.

You're welcome :)

Hope you get this worked out

-Rashid

Rashid, could you rename your xorg.conf or move it out ot /etc/X11 to see if the xserver notices where the monitor is attached.

I just booted into Ubuntu and renamed xorg.conf to xorg.conf.launchpad and did a startx. I was quite surprised because X started, I got an X cursor and a dotted screen and a box asking whether I wanted to use X or Gnome's keyboard settings. (and the screen was misaligned with my monitor so I'm assuming it was a new config that was built)

After that though, I didn't ever get to a proper desktop, it just carried on like that until I killed it.

Thats strange that X can build an almost correct config now, but can't in the livecd :S

Hope that helps

-Rashid

Very good to hear, that it nearly worked.

Can you try it again, and try getting the /var/log/Xorg.0.log file and attaching it here?

On 20/10/2007, Bryce Harrington <email address hidden> wrote:
>
> ** Changed in: xorg (Ubuntu)
> Status: New => In Progress
>
> --
> X incorrectly defaults to using disabled Intel onboard graphics card
> instead of nVidia FX5500 PCI card
> https://bugs.launchpad.net/bugs/103223
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Sorry my computer blew up (power surge I think) I currently have no choice
but to use an ancient laptop with Windows *ME* on it :( So I can't do any
more tests or whatever for now...

Hope you get everything fixed for when I can get a working computer back and
install a new version of [K]ubuntu on it :D

-Rashid

While this is well reported I just wanted to note I experience the exact same behaviour in Gutsy using the Xubuntu live disk. Re-enabling the onboard and switching over seems to be the only solution. The installation halts and will not even allow switching over to another terminal so it is impossible to edit the xorg.conf.

This is fixed in Hardy alpha3, which is released later this week. BusID is not hardcoded anymore, and neither is the video driver.

On 08/01/2008, Timo Aaltonen <email address hidden> wrote:
>
> This is fixed in Hardy alpha3, which is released later this week. BusID
> is not hardcoded anymore, and neither is the video driver.
>
> ** Changed in: xorg (Ubuntu)
> Status: In Progress => Fix Released
>
> --
> X incorrectly defaults to using disabled Intel onboard graphics card
> instead of nVidia FX5500 PCI card
> https://bugs.launchpad.net/bugs/103223
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Wicked :D

@Timo: The problem still exists in both 8.04 LTS, 8.10 and 9.04 on Fujitsu-Siemens (FSC) computers using AMI BIOS.

It seems to be a problem where the on-board Intel integrated graphics card paired with a slot-graphics card has Ubuntu, reading the xorg.conf, so confused it freezes at boot-up, LiveCD or not, where the only option is a on/off-button shutdown.

This happens when the slot-graphics card is promoted by the user to primary graphics, downgrading the onboard Intel GPU to secondary graphics in the AMI BIOS -- [Peripherals] Graphics: OnBoard=>PCI switched to PCI=>OnBoard. Note that there is no disable option available of the OnBoard graphics!

Ordinary users, wanting to use advanced graphics on FSC-computers, hence their addition of a slot graphics card, are out of luck with now-a-days Ubuntu and have to resort to a more wide-spread OS. Advanced users, understanding hardware adresses, Xorg and Linux has a bit of tinkering and log-reading to do, to get their xorg.conf going -- one little error and your in low graphics mode.

I, myself, is doing okey in Ubuntu 9.04, with an old cherished Ubuntu 8.04/Envy-generated xorg.conf --- non-nowadays-EnvyNG. But I'm not fine, still forced to have a secondary display attached to the OnBoard graphics card and the OnBoard=>PCI BIOS-setting active.

A note: I believe this issue to be a Xorg and Linux-problem. All LiveCD or RescueCD I've tried freezes-up at boot, using this BIOS graphics card priority change.

Any suggestions?