Disable on-board video?

I’ve spent the better part of two days trying to find a way to disable an on-board video card on a machine that was given to me. It’s an old Dell PowerEdge SC440 server, dual-core Xeon 1.86GHz processor and 4-G of ram. I recently installed a nVidia GeForce 8400 in it, and thought the card works great in X, when I switch to a console the text is unreadable. Searching for a cause I found the consensus is the two cards can’t co-exist. The output of ‘lspci | grep VGA’ shows:

05:07.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI ES1000
06:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS] (rev a1)

Some time on Dell’s site shows the card can’t be disabled in bios, nor are there any motherboard switches or jumpers to do it. Searching around I found that most believe Dell just omitted any way of disabling the card on the belief that it would never be used for anything other than a low-cost server.

I’d like to somehow stop the kernel from recognizing the AMD card so it uses the nVidia for the default, but hours upon hours of looking at docs on kernel.org has only taught me that I’ll never understand kernel-talk. Searching on forums have yielded nothing usable either. Anyone had a similar problem, or know a way of telling the kernel to ignore the on-board card? Or… know which wire to cut to permanently disable it?

Any help or ideas are appreciated. Oh, if it matters I’m running openSUSE Tumbleweed with kernel 3.6.4-9.
Rob

If the onboard can’t be disable
Try looking in the bios if there is an option of setting the priority to the second card.

What was the reasons given for that concensus? In any regard, I suspect that that is not the case. Rather…

What driver do you have installed for the nvidia card. I’m betting the proprietary nvidia driver. And if that’s the case, then I"m doubling down on my wager and saying that its your console framebuffer driver that is the problem (in either that it conflicts with the nvidia driver or that you have it set up incorrectly) and would ask that you provide what fb driver your using and the parameters you are trying to pass for it … (you can find that from your kernel boot command line used in the bootloader)

Some time on Dell’s site shows the card can’t be disabled in bios, nor are there any motherboard switches or jumpers to do it. Searching around I found that most believe Dell just omitted any way of disabling the card on the belief that it would never be used for anything other than a low-cost server.
yes, quite possible.

I’d like to somehow stop the kernel from recognizing the AMD card so it uses the nVidia for the default … Anyone had a similar problem, or know a way of telling the kernel to ignore the on-board card? Or… know which wire to cut to permanently disable it?
If you’re booting into X with the nvidia card already, then the nviidia card is the boot video device. The fact that the amd adpater is enabled in the system (i.e. its been turned on in the bios) doesn’t mean that Linux is using it – even if you see it recognized/detected as shown in the output of lspci. If the other graphics device is configured for use, the AMD adapter is just sitting there sucking juice (electricity) and minding its own business.

Hello conram. I’ve gone through every inch of the bios settings, there is no options at all for the video on the machine.

Hello Tyler_K. The driver is the proprietary one, 304.60, compiled for this machine and kernel following “The Hard Way” recommendations posted somewhere in the Tumbleweed wiki. As for a framebuffer driver, I haven’t picked or set any myself, if one’s being loaded it’s whatever the system is set to load by default, I see nothing in the boot line that would load it. I found a lot of mention about that on the kernel.org site, in the /usr/share/doc files and on other sites, but I’m afraid most of what I was reading was beyond my understanding, and some that I could make heads or tails of was written a while back, the 2.4 kernel was mentioned, and I was a bit leery of trying any of it. Anyway, here’s the boot loader line from Yast:

‘resume=/dev/disk/by-id/ata-ST3160812AS_5LSAZCNH-part2 splash=silent quiet acpi_display_output=nvidia showopts’

The ‘acpi_display_output=nvidia’ bit I inserted in there as an attempt to get it to recognize the nVidia card first, and that seems to work. Before I didn’t see the Plymouth splash screen or anything else until after the machine was booted all the way to X, now I see it and can even <ESC> from it and watch the boot messages. And the thing is, the boot messages are perfectly readable, so whatever’s happening is happening it seems after X has started. If I <CTRL><ALT><F1> to a console screen from the X login, the text is already illegible. Switch back to X and everything’s fine. Been driving me nuts.

What was the reasons given for that concensus? In any regard, I suspect that that is not the case. Rather…

That was on a forum I found in my search from back in 2008 where some people were trying to do the same thing I am, with no luck. Sorry I don’t have the link handy, though I could probably find it in my browser’s history if you’d like or think it might help.

If you’re booting into X with the nvidia card already, then the nviidia card is the boot video device. The fact that the amd adpater is enabled in the system (i.e. its been turned on in the bios) doesn’t mean that Linux is using it – even if you see it recognized/detected as shown in the output of lspci. If the other graphics device is configured for use, the AMD adapter is just sitting there sucking juice (electricity) and minding its own business.

I believe you’re right, the machine does boot into the nVidia card, and I have to think that when I switch to a console it’s still using the nVidia, otherwise I wouldn’t see the text at all. Now, that makes sense! So, how do I keep the kernel using the nVidia driver for consoles? Or perhaps the question is: why is the kernel trying to change drivers when I switch to a console?

Thanks for you help, I’ve already learned more than I did after two days of searching on my own!

okay

I see nothing in the boot line that would load it. I found a lot of mention about that on the kernel.org site, in the /usr/share/doc files and on other sites, but I’m afraid most of what I was reading was beyond my understanding, and some that I could make heads or tails of was written a while back, the 2.4 kernel was mentioned, and I was a bit leery of trying any of it. Anyway, here’s the boot loader line from Yast:

‘resume=/dev/disk/by-id/ata-ST3160812AS_5LSAZCNH-part2 splash=silent quiet acpi_display_output=nvidia showopts’

Okay. We need to find out what framebuffer driver your system is using (likely vesafb, but that’s just a guess). Have a look in your xorg log (found in /var/log … paste it to SUSE Paste ).

The ‘acpi_display_output=nvidia’ bit I inserted in there as an attempt to get it to recognize the nVidia card first, and that seems to work. Before I didn’t see the Plymouth splash screen or anything else until after the machine was booted all the way to X, now I see it and can even <ESC> from it and watch the boot messages. And the thing is, the boot messages are perfectly readable, so whatever’s happening is happening it seems after X has started…
That’s interesting. But you see the POST messages and the grub menu, correct? I have two thoughts on this, but will wait for your response as it would provide me with some thought direction.

If I <CTRL><ALT><F1> to a console screen from the X login, the text is already illegible. Switch back to X and everything’s fine. Been driving me nuts
That part is easy to explain – once the DM (display manager) starts, X has already started (in part). So the nvidia driver gets loaded, and so when you then switch back to a console you (more then likely) are bumping up against a video mode conflict (the console is being driven by a framebuffer driver which wants to set its own video mode, different than what the nvidia driver has set the hardware into … if there isn’t a smooth transition – KAPOW! Batman :wink: … p.s. I made the last part up, but functionally I don’t think its too far from the truth)

That was on a forum I found in my search from back in 2008 where some people were trying to do the same thing I am, with no luck. Sorry I don’t have the link handy, though I could probably find it in my browser’s history if you’d like or think it might help.
No worries. At this moment I don’t think its important, though keep the cache handy in case it might prove useful to see if there was any pertinent info to be found there after all (which, at this point, I don’t believe to be the case).

I believe you’re right, the machine does boot into the nVidia card, and I have to think that when I switch to a console it’s still using the nVidia, otherwise I wouldn’t see the text at all. Now, that makes sense!
There are some sysfs attributes that you can “cat” which provide indication of which device are the boot device and running console (sorry, I don’t recall them off the top of my head) … but, but, but: even better proof would be my bet that you have only one cable attached to the monitor and that its coming out of the back of the discrete nvidia card rotfl!

So, how do I keep the kernel using the nVidia driver for consoles?
You can’t; the nvidia driver is just an X11 driver.

Or perhaps the question is: why is the kernel trying to change drivers when I switch to a console?
For a framebuffer console (see Linux framebuffer - Wikipedia, the free encyclopedia ) you need a couple of pieces – the console driver, fbcon, (which provides the generic/universal/shared console code) and the framebuffer driver (which range from being hardware specific to universal for all adapters (in theory))… (see the kernel documentation for more info: Linux Kernel Documentation :: fb … there is also, in some cases, a bit of carry over to: Linux Kernel Documentation :: svga.txt )

That’s pretty much describes the old approach with UMS (user mode setting) based drivers. The more modern approach is via DRM/KMS (kernel mode setting/switching) based drivers. So now you essentially (its actually more complicated, and there are more pieces, then what I’m describing) the same X driver also driving the console framebuffer. And as its KMS, it handles and provides all the video modes, so there is no inherent conflict between video mode setting (like as what can happen with the prop. drivers and the legacy/traditional framebuffer drivers) cause its left hand always knows what its right hand is doing (so to speak).

Can you post the[size=2] out[size=2]put of “[size=2]/sbin/lspci -v[size=2]n -s 05:07.0” [/size][/size][/size][/size]

[QUOTE=Tyler_K,post:5,topic:84400"]

That’s interesting. But you see the POST messages and the grub menu, correct? I have two thoughts on this, but will wait for your response as it would provide me with some thought direction.[/QUOTE]I lied :stuck_out_tongue: I have some further questions instead:

Earlier, when you were booting without that kernel boot parm., were you at least able to press esc and get the kernel messages displayed?

but, but, but: even better proof would be my bet that you have only one cable attached to the monitor and that its coming out of the back of the discrete nvidia card
Here’s another little test that will help pin point what is going on: what happens, or rather, what do you see on screen if you unplug the monitor from the nvidia card and hook it up to the onboard AMD adapter ? (both with and without the acpi boot parameter)

Okay, the output from Xorg.log is here. I also copied the output from dmesg and it’s here. Thought it might help too.

That’s interesting. But you see the POST messages and the grub menu, correct? I have two thoughts on this, but will wait for your response as it would provide me with some thought direction.

Yes I do. I see the grub starting message, then it goes to the Plymouth splash screen, but if I escape it I can see all the POST messages. They’re perfectly readable and clear.

but, but, but: even better proof would be my bet that you have only one cable attached to the monitor and that its coming out of the back of the discrete nvidia card

Yes, it’s a DVI cable and it’s the only one hooked up, directly to the nVidia card.

This is the output from ‘/sbin/lspci -vn -s 05:07.0’

05:07.0 0300: 1002:515e (rev 83) (prog-if 00 [VGA controller])
Flags: user-definable features, fast devsel, IRQ 19
Memory at c0000000 (32-bit, non-prefetchable) [size=128]
Memory at 0000dc00 (32-bit, prefetchable) [size=256]
I/O ports at efaf0000 [disabled] [size=64]
Memory at <ignored> (32-bit, non-prefetchable)
Expansion ROM at efb00000 [disabled] [size=128]

Earlier, when you were booting without that kernel boot parm., were you at least able to press esc and get the kernel messages displayed?

I would see the initramfs message, then the grub starting message, then nothing until X started. No Plymouth, couldn’t see the POST messages, there was nothing.

Here’s another little test that will help pin point what is going on: what happens, or rather, what do you see on screen if you unplug the monitor from the nvidia card and hook it up to the onboard AMD adapter ? (both with and without the acpi boot parameter)

That’s actually what started me on this. In that forum I mentioned from back in 08, one of the people trying to solve it asked the same question, so I tried it to see what happened. With the nVidia line in the boot, as soon as grub loads the screen goes blank, kind of like what was happening to the nVidia card before I put the line in, only it never comes back, it stays blank. Without the line in grub it works like normal, even shows X and I can work in it like the nVidia card isn’t even there. And, the console text doesn’t get corrupted. I then hooked two monitors up, one to each card, and the nVidia worked too, though I think it was using the nouveau driver. Sounds like it would be a neat deal, but in use there was a lot of tearing and screen-redraw problems with both. Being the nVidia is a much better card, I started looking for a way to kill the AMD/ATI one.

Thanks for your patience and help Tyler.[/size][/size][/size][/size]

Yes, it (the dmesg) does help

Yes I do. I see the grub starting message, then it goes to the Plymouth splash screen, but if I escape it I can see all the POST messages. They’re perfectly readable and clear.

I would see the initramfs message, then the grub starting message, then nothing until X started. No Plymouth, couldn’t see the POST messages, there was nothing

That’s actually what started me on this. In that forum I mentioned from back in 08, one of the people trying to solve it asked the same question, so I tried it to see what happened. With the nVidia line in the boot, as soon as grub loads the screen goes blank, kind of like what was happening to the nVidia card before I put the line in, only it never comes back, it stays blank. Without the line in grub it works like normal, even shows X and I can work in it like the nVidia card isn’t even there. And, the console text doesn’t get corrupted. i then hooked two monitors up, one to each card, and the nVidia worked too, though I think it was using the nouveau driver. Sounds like it would be a neat deal, but in use there was a lot of tearing and screen-redraw problems with both. Being the nVidia is a much better card, I started looking for a way to kill the AMD/ATI one.
.
Okay. I’m a bit confused by your last part of the description about having the two monitors going … but lets leave that for now. So, for a summary referesher, it seems to me that

Problem 1/Old Problem:
Before I would see the grub starting message, then the screen blanks and I’m unable to see the Plymouth splash screen or anything else (e.g. I was unable to ‘esc’ out of the graphical slient splash mode and evoke into graphical verbose mode), with the screen staying blank until after the machine was booted all the way to X … (I’m not sure if you meant to the DM, or if you were unable to see the DM too, and didn’t see anything until the desktop environment was pulled up … though I suspect you saw the DM too)

Problem 2/New Problem:
After inserting the ‘acpi_display_output=nvidia’ boot parameter (in there as an attempt to get it to recognize the nVidia card first, and that seems to work. ) I now I see the grub starting message, then it goes to the Plymouth splash screen and I see it, and I can even <ESC> from it and watch the boot messages and they are perfectly readable and clear. However, after X has started, the console is all messed up when I switch to it…

This is the output from ‘/sbin/lspci -vn -s 05:07.0’
Okay, I was wondering if it would show a driver loaded for it, and it doesn’t. Further to that, you can see in your dmesg output, beginning at line 728, that the DRM/KMS radeon tries to start up but coughs out … that seqment is followed by some acpi warnings, which I suspect are related to your passing of the acpi_nvidia boot parameter (but I don’t know … would have to be more familar with what that acpi_ command actually does)…

Some noteworthy points and things I see:

  • Plymouth will try to use DRM/KMS if available, if not, it tries for a framebuffer driver, and failing that its supposed to fallback to text mode (essentially splash = 0 ).
  • both the xorg and kernel logs highlight the 'vga=" boot parameter … used to set video mode of framebuffer drivers (typically the vesafb driver, though others can pass the vga parm too) … I’d actually be interested in knowing if you don’t see it from in the bootloader kernel line … anyway, I guess I should have asked you for “cat /proc/cmdline” to begin with, but I couldn’t remember that one
  • starting line 523 of dmesg, we see that the vesafb driver is loading (its video mode info also provided)… you could likely further confirm that vesafb is the fb driver by the command “/usr/sbin/fbset -i”
  • Mentioning this only for the sake of thoroughness, as it is not applicable to your case (given that you see the plymouth splash; i.e. providing visual evidence that the fb driver is working given your not using a DRM/KMS driver), one of the problems with getting the tradional framebuffers to work is that the video mode selected must still match a VBE mode the hardware is capable of providing … one way you can do that with: “cat /sys/class/graphics/fb0/modes” which should list the modes available to the fb driver and (as root) “hwinfo --framebuffer”, which should provide what the adapter is capable of.
  • Now, back to what is applicable to you – while the framebuffer seens fine on its own, your homework is to investigate whether the nvidia driver is known to conflict with vesafb or vice versa (I do not know offhand – I haven’t used a nvidia adapter for a couple of years and forget what is likely to work and what isn’t
  • I also didn’t see mention of an xorg.conf file being used in your xorg log – last I checked, the nvider driver still set up a static xorg.conf file … in fact, you can see that it, X, goes through the autodetection routine (picking up the possible driver candidates; nv, nouveau, nvidia, vesa, fbdev (which, btw, despite what its name appears as, is not a console fb driver, but, rather an X11 fb driver in the traditional sense of “framebuffer”) … and then unloading them in favour of the nvidia). I suspect you never configed the driver through nvidia-settings or whatever…I don’t think its particularly a big deal, as the X autodetection/automagic routine is working fine.

Question: did you get the machine, install openSUSE on it and then put the nvidia card in, and then installed the nvidia prop dirver ?
or
did you get the machine, put the nvidia card in it, then installed openSUSE on the system, and then later installed the prop. nvidia driver?

No sooner had I shut everything down last night then when I thought – what if that isn’t the case of being no big deal … what if the DRM/KMS nouveau driver is trying to load when you switch to console? (or maybe its even a case of the radeondrmfb) ? … and you end up with a race condition and conflict between the KMS and nvidia

What happens if you use the nomodeset kernel boot parm. ? I’d also look to see about properly configing the nvidia (including blacklisting the nouveau and radeon drivers)

Got to run.

Problem solved! Did some more digging after I read your posts, especially this one:

Now, back to what is applicable to you – while the framebuffer seens fine on its own, your homework is to investigate whether the nvidia driver is known to conflict with vesafb or vice versa (I do not know offhand – I haven’t used a nvidia adapter for a couple of years and forget what is likely to work and what isn’t

The answer is “sometimes” yes. In the nVidia documentation they mention framebuffer drivers that get loaded in init, before grub is read, may cause problems with the nVidia driver due to a modeset already existing when the driver tries to load. Normally this isn’t too much of a problem as the kernel just switches them back and forth as needed (console vs. X) and the world keeps spinning. In my case however, the kernel loads two drivers after vesafb, the radeon one and the nVidia (shown in dmesg). I figure that might be confusing the hell out of the kernel, so I tried what you suggested, adding ‘nomodeset’ but it didn’t help. Still got the green grub screen and all the rest. Then I tried deleting the “splash” part of the grub line and viola! It worked! I have a plain grub menu, and don’t get the Plymouth graphics, but I can now switch to a console and work in it.

Unfortunately work right now limits my time with this, but I’ll be off in a few days and I want to investigate this further, make sure it stays solid (and is repeatable) and post all the findings here for others. Who knows, I may do a kernel update or some other such and it all goes to hell, so I want to find out exactly what’s happening and be sure it is actually a “fix”.

I’ll be on my “weekend” this Monday, I’ll get back to you with more info and snippets from tests, and to let you know if it’s staying stable.

Catch ya on Monday.

that should be “after grub is read, framebuffer drivers that …” – grub is just the bootloader … nothing to do with the OS/kernel.

framebuffer drivers that get loaded before …may cause problems with the nVidia driver due to a modeset already existing when the driver tries to load.
Correct – but this is talking about trying to get into X … something which you have no problem doing – so, while we don’t know for sure whether there is an absolutely smooth transition, its fair to say that the nvidia X driver is able to load and carry forth

Normally this isn’t too much of a problem as the kernel just switches them back and forth as needed (console vs. X) and the world keeps spinning.
Correct.

In my case however, the kernel loads two drivers after vesafb, the radeon one and the nVidia (shown in dmesg). I figure that might be confusing the hell out of the kernel
No, this is normal – your system starts up in console (VT1) and it the framebuffer driver enables the visual for it – allowing you to see the kernel boot message (or bootsplash; regardless of whether its set to silent or verbose modes). In later part of the boot sequence (if you’ve choosen to boot into an X environment, something that is associated as “runlevel 5”, if you prefer to think of it in terms of the old sysintV classification), a second console (VT7; though it need not be VT7, but for all intense purposes VT7 is, by general practice, the defacto) is initialized and X is loaded on that. And, of course, having X requires X drivers. So, as you can see, that loading sequence is fine. Also note that, as I mentioned earlier, the radeon driver loading (for the onboard graphics device) fails, so it is not an issue as to interferring with the nvidia driver for entering into X.

The problem (“Problem 2/New Problem” by my labelling) that you face is a problem of transitioning back into the Framebuffer console environment. Specifically, (or, at least, it is my opinion that) it appears that something is preventing a smooth transition from the video mode used by the X driver (nvidia) and the video mode used by the framebuffer driver (vesafb).

Your situation is further complicated by several factors:

  • the existence of the onboard AMD graphics adapter which can’t be disabled (on a system, as in hardware system, level basisi) in the BIOS
  • the fact that your X driver (nvidia) is not a KMS driver and is known to conflict with some framebuffer drivers … (and most certainly would with KMS drivers; see below)
  • the fact that it doesn’t appear that you have a correctly configured nvidia install (no evidence of an xorg.conf being used)
  • and while I doubt it, I don’t want to completely discount the possibility that loading of the DRM/KMS drivers (nouveau, radeon) may be retriggered when you switch back (from X) to console … particularly given that it doesn’t appear that your nvidia driver setup was done (see nvidia-xconfig: http://us.download.nvidia.com/XFree86/Linux-x86_64/304.60/README/editxconfig.html} or that you have the KMS drivers blacklisted … (Have a look at nouveau Wiki - KernelModeSetting )

So, with all these moving parts, its difficult to peg down what is the exact cause. But here is something I completely missed the other day from your dmesg:

  1. 34.887351] NVRM: Your system is not currently configured to drive a VGA console
  2. 34.887356] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver
  3. 34.887358] NVRM: requires the use of a text-mode VGA console. Use of other console
  4. 34.887360] NVRM: drivers including, but not limited to, vesafb, may result in
  5. 34.887362] NVRM: corruption and stability problems, and is not supported.

Okay, let’s parse it:

  • “Your system is not currently configured to drive a VGA console on the primary VGA device. The NVIDIA Linux graphics driver requires the use of a text-mode VGA console” … the fact that you previously showed that plymouth works (effectively splash=silent) and could “esc” out of it and that worked too (which doing so effectively sets splash=verbose until next boot) indicates that you can indeed have a framebuffer console (i.e. you are very much capable of having a graphical console environment). So perhaps the message means from the standpoint of switching back into a console from an nvidia driver driven X environment.
  • “Use of other console drivers including, but not limited to, vesafb, may
    result in corruption and stability problems, and is not supported” … okay, I’m not surprised – there are known conflicts. But there is a marked difference between “is absolutely not supported” and “it may not work” … IOW, its open for interpretation … perhaps one is that nividia is saying “it can be made to work but we just aren’t going to tell anyone what is compatible with our binary blob” … or maybe its nvidia saying “it can be made to work but we, at the very least, aren’t willing to provide helpdesk support in this regards so figure it out on your own, or just use a text console” … and, of course, figuring it out on your own is difficult, and might be best characterised by the fact that “‘NVIDIA’ taints kernel.” lol!

Anyway,

Lets clarify that a bit – your mission is to find a framebuffer (and configure correctly) such that it can work inconjunction with the nvidia driver. I know that they are out there …

I tried what you suggested, adding ‘nomodeset’ but it didn’t help. Still got the green grub screen and all the rest.
Okay … my thought there was that maybe the nouveau (or possibly even the radeon) driver was somehow being triggered to load when you swithced back to console … that is, I mean, their respective DRM/KMS elements (nouveaufb, radeondrmfb) which are capable of handling console framebuffer…so switching off modesetting would/should have prevented such a scenario

Then I tried deleting the “splash” part of the grub line and viola! It worked! I have a plain grub menu, and don’t get the Plymouth graphics, but I can now switch to a console and work in it.
Well, combined with removing the vga= parameter earlier, that effectively has accomplished the solution prescribed by Nvidia’s message…or, at least I believe, you have ended up with a text mode console when you switch back into it … though I’m not certain of the dynamics of the mode switching and whether the nvidia driver is prescribing this in the handoff to the console driver.

Here is another question: while you didn’t see the Plymouth bootsplash (because you removed the splash= ), did you see the kernel text boot messages at all during startup (i.e. after grub and before X/DM)?

If not, you might want to try with:

  • splash=0 or
  • splash=0 and vga=normal or
  • vga=normal

You may also be refereeing to anything getting packed into the initrd … and if so, this is why I was asking earlier about the order of hardware and OS installation that you had performed … but I don’t think it matters now, so disregard.

Okay, had a* very* interesting day so far. As so often with Linux, if you start changing too many parameters without being sure of what you’re doing, you’re going to hose your system. Such is what happened to me this morning. But it was worth it. You asked how I installed the system, so this time I took notes! :wink:

To answer an earlier question first, when I got the computer it had Ubuntu 10.10 on it, and that’s when I noticed how poor the graphics were with the on-board graphics card. So the first thing I did was go in my “spare parts” box and dug out the nVidia card and put it in. Not being an Ubuntu user, the next step was installing openSUSE 12.2 from a usb I had just made a few days before. But, back to the chain of events this morning. This is directly from my notes, so it’s kind of terse and point-to-point.

Fresh install of openSUSE 12.2 from the usb.

After choosing default boot entry, there’s no screen until the X display manager login.

Changed boot entry to try and keep on-board card from doing too much by changing splash and quiet to ‘modeset.radeon=0’. The output from cmdline looks like this:

BOOT_IMAGE=/boot/vmlinuz-3.4.6-2.10-desktop root=UUID=d2211019-0184-43e8-8175-5d321ea074ef resume=/dev/disk/by-id/ata-ST3160812AS_5LSAZCNH-part2 modeset.radeon=0 showopts vga=0x31b

Now I can see the boot messages and system smoothly boots to X.

Output from ‘fbset -i’ with newly installed 12.2:

mode "1280x1024"
    geometry 1280 1024 1280 1024 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode


Frame buffer device information:
    Name        : nouveaufb
    Address     : 0xd0013000
    Size        : 5242880
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 5120
    Accelerator : No

Everything works, switching to console is smooth and text is clear, X works well but is quite slow.

Logged out of X to command console, updated system with ‘zypper dup’, then rebooted. After update everything is the same as after initial install. Next I switched repositories to Tumbleweed, and updated again. Checked system and it’s still the same as after initial install, using nouveau.

Downloaded and installed the nVidia driver installer from nVidia: Rebooted the system and entered runlevel 3, not loading X. Ran the nVidia script and installed the proprietary driver.

The nVidia installer created the necessary blacklist entries for the nouveau driver. It does not add or change entries in ‘/etc/modprobe.d/blacklist.conf’, the documentation states that can be overwritten in an update, so instead it creates it’s own blacklist file ‘nvidia.conf’ which is read by the loader. Per instructions here, (if all else fails, follow instructions!) I used Yast to change ‘NO_KMS_IN_INITRD’ to yes in sysconf. Then used the boot loader editor in Yast and added ‘xdriver=no’ to the command line, changed ‘Graphical’ console to ‘Text’ and rebooted.

Boot entry now:

BOOT_IMAGE=/boot/vmlinuz-3.4.6-2.10-desktop root=UUID=d2211019-0184-43e8-8175-5d321ea074ef resume=/dev/disk/by-id/ata-ST3160812AS_5LSAZCNH-part2 modeset.radeon=0 xdriver=no showopts vga=normal

There’s no longer any framebuffer output, ‘fbset -i’ shows no such file or device. The tty console is now 80X24 so it’s not very attractive, but I only need it for updating the system. Whenever I do an update I like to exit X altogether and run zypper in a console. Not being able to see or read the text in that console is what started me on all this. Like I said, not pretty, but it works. I spend all my time in X anyway, so the once a month or so I update the system, I can live with the console text being so big.

Things I missed the first time was the ‘NO-KMS-IN-INITRD’ in sysconf, and setting the console to text mode so no framebuffer gets loaded. I’ve put the output now from ‘dmesg’ here, as you can see there’s no longer any warning about not having a console driver from the nVidia driver. I still have to go in and blacklist the radeonfb and radeon drivers in ‘/etc/modprobe.d/blacklist.conf’ but they don’t seem to be affecting anything so I may not bother.

I really, REALLY appreciate all your help on this Tyler, it’s kept me from getting too frustrated and taking a hammer to this box. If you have other questions or want more info, let me know. For now I’m going to say this problem is solved. Hopefully someone else will find it helpful and keep them from pulling their hair out.

Thanks. Right now I’d suggest you give it a rest and enjoy your system for a while, and then come back to this later. I know you can achieve better, but all in due time.