I cannot say in advance. If you post them, something may stand out. Could you post requested information for working case at least?
Maybe appending “3 nomodeset” to your kernel boot line gives at least a console login in single user mode with framebuffer (no X Windows)?
Thanks for the tips and sorry for the late reply. ‘nomodeset’ helped me to get a text login but it didn’t help to find why X didn’t start with the iGPU. However I found that changing kernel boot parameters from (current setting) video=2560x1440 to video=1600x1200 (or even 1024x768) also helped to get a text consle + showed what (I suppose) seems to be the problem.
TLDR: I think I may be experiencing a bug quite similar to one of these:
https://bugzilla.kernel.org/show_bug.cgi?id=79261
https://bugs.freedesktop.org/show_bug.cgi?id=89806
I tested the following cases (pasting excerpts from command output which seem related). To keep it as short as possible:
Case 1
BIOS setting: Primary GPU = Auto (or PCIE)
X works. The iGPU does not show in virt-manager unless I also enable the multi-monitor iGPU setting in BIOS (which seems to have no effect on the following):
lspci shows only the dGPU
dmesg
/var/log/Xorg.0.log
Case 2
BIOS setting: Primary GPU = iGPU. Multi-monitor for iGPU can be enabled or disabled (doesn’t seem to matter). Lowering ‘video=…’ as explained so I can see what is going on.
X doesn’t start. I get a boot time message similar to the one in the bug report links:
[drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A
[drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
after which the text login appears. In console Alt+7 I see only a blank screen with a blinkin cursor on top.
lspci shows both GPUs.
dmesg shows some warning that:
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
which I have no idea how to use.
Xorg.0.logAny idea if there is a way to resolve all this?
Never mind… at least your system now can see both GPUs simultaneously!
But let’s see if we can avoid some clutter first.
‘nomodeset’ helped me to get a text login but it didn’t help to find why X didn’t start with the iGPU. However I found that changing kernel boot parameters from (current setting) video=2560x1440 to video=1600x1200 (or even 1024x768) also helped to get a text consle + showed what (I suppose) seems to be the problem.
TLDR: I think I may be experiencing a bug quite similar to one of these:
https://bugzilla.kernel.org/show_bug.cgi?id=79261
https://bugs.freedesktop.org/show_bug.cgi?id=89806
Maybe, since your iGPU seems similar to those reported. Or maybe it is something I witnessed with older Intel graphics (GM965) and similar error messages. I needed to add to the kernel boot line:
video=SVIDEO-1:d
even if my system had no SVIDEO output, simply because the relevant GPU HW was not properly initialized with kernels 4.4.x and up.
I tested the following cases (pasting excerpts from command output which seem related). To keep it as short as possible:
Case 1
BIOS setting: Primary GPU = Auto (or PCIE)
X works. The iGPU does not show in virt-manager unless I also enable the multi-monitor iGPU setting in BIOS (which seems to have no effect on the following):
lspci shows only the dGPU
dmesg
/var/log/Xorg.0.log
Case 2
BIOS setting: Primary GPU = iGPU. Multi-monitor for iGPU can be enabled or disabled (doesn’t seem to matter). Lowering ‘video=…’ as explained so I can see what is going on.
X doesn’t start. I get a boot time message similar to the one in the bug report links:
[drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A [drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
after which the text login appears. In console Alt+7 I see only a blank screen with a blinkin cursor on top.
Apparently your Xserver has been configured or tuned to take advantage of the Nvidia GPU and that might be one of the reasons why it does not even start when the iGPU is on duty, but I’m not smart enough to tell for sure 
lspci shows both GPUs.
Nice news, at least there is one setup in which the system sees both of them at the same time. Maybe there is a way to use the iGPU as “main” system console and use sort of pci-passthrough to access the Nvidia card…
dmesg shows some warning that:
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
which I have no idea how to use.
I’ve been seeing those for years, seems like an updated ACPI code doesn’t like some lines of ASUS firmware code which seems not so up to date (at least on the HW I currently have).
But those never gave me problems of sort, so I think you can safely ignore them for the time being.
HTH
I see you’ve already posted in the Virtualization forum.
Just to be sure all is clear, an approach to implement QEMU and optionally use the Spice protocol(not always a requirement) is a very different approach than what is being described and discussed in all the other posts in this Forum thread.
If you want to explore this QEMU approach further, based on your error I’d recommend
- Read <all> the posts and links in the Virtualization Forum thread you posted to, note that I updated that thread with a reference to another post I made that provides links to the latest articles on Pass-through GPU for <all> the major virtualization technologies we commonly run on openSUSE as of May 2017.
- Search the Virtualization forum for threads related to installing and implementing the Spice protocol and KVM if that is what you choose to try to set up. IIRC it’s not necessarily straightforward, and discussions describe likely best choices.
TSU
Tried that - still getting the result from case 2.
Apparently your Xserver has been configured or tuned to take advantage of the Nvidia GPU and that might be one of the reasons why it does not even start when the iGPU is on duty, but I’m not smart enough to tell for sure
I have been thinking the same. I even thought about switching to nouveau in case nvidia messes up something but that would be contrary to the idea of having and passing 3D acceleration to the VM guest I suppose. So I gave up the idea.
I have been reading various stuff for the last 2 years (definitely not <all> and each and every line) and the only result was lots of wasted time. One cannot become a professor in virtualization just because a checkbox doesn’t work properly. 
So right now I am focused on making the 2 GPUs work together properly. Then I will proceed accordingly.
It is not “tuned”, it is just that there can be only one GL implementation. On client side glvnd tries to solve this problem, but on server side there still can be only one library. nVidia binary drivers install own, incompatible, implementation.
Anyway, seeing that OP intentionally truncates all information and just shows some arbitrary random snippets out of log files I guess OP does not want it to be solved.
Are you suggesting to uninstall nvidia driver? Wouldn’t that be contrary to (later) getting 3d acceleration in VM guest?
Anyway, seeing that OP intentionally truncates all information and just shows some arbitrary random snippets out of log files I guess OP does not want it to be solved.
The OP is not a security expert but has been told by people who are that sharing full logs (especially publicly) is not a good idea. That does not mean the OP does not want it to be solved, he is just careful, so please don’t make such conclusions. I asked what I should be looking for and you suggested to look for something that stands out, so I shared everything related to graphics that stands out. Why do you say that is arbitrary?
If you need any additional information in order to suggest a solution - just let me know and I will provide it. But please don’t get angry just because someone is careful.
As mentioned the NVIDIA driver replaces parts of the X stack (mesa) which breaks other brand GPU. So yes at the least you must remove the NVIDIA driver if you wish also to use the Intel also nouveau driver is 3D also.
I can do that but what worries me is that nouveau perhaps does not give the same performance as the nvidia driver. Running (a command line for testing which I found a long ago):
grep VGA /proc/pci || lspci | grep VGA | colrm 1 4 ; egrep "model name|MHz" /proc/cpuinfo ; xdpyinfo | egrep "version:|dimensions|depth of" ; glxinfo | egrep -A2 "direct rendering|OpenGL vendor" ; uname -sr ; __GL_SYNC_TO_VBLANK=0 glxgears & sleep 30 ; killall glxgears
gives me ~24500FPS with the nvidia driver and (when i tested long ago) about 60FPS with the nouveau. I have read people saying that glxgears is not a benchmark but still… Here is an article which compares both drivers in more detail.
What do you think? Should I remove the nvidia driver just to test? And if it turns out that the nvidia driver itself is the issue - then what?
Point is still that the NVIDIA drivers Break the X stack for any other driver.
Take it up with NVIDIA nothing we can do about this. It has been that way forever.
Solution put in a second NVIDIA card and you can use both
What are you really trying to achieve?
If you are talking about the normal use of your desktop you are correct, do use the Nvidia driver all the time (although the Nouveau driver in recent kernels is not that bad with a GKxxx GPU: the 60 FPS you see is just the monitor refresh rate, try some other command or benchmark).
BUT if you are trying to achieve PCI pass-through the final picture should be something like the following AFAIK:
- the host system is controlled through the iGPU (or ssh via a remote terminal if you prefer…) thus freeing the Nvidia from ANY host job;
- at that point the Nvidia may be “hijacked” by a Virtual Guest via PCI pass-through, making it effectively “invisible” to the host (and so which driver is installed in the host should be irrelevant);
- so you have to install a driver for the Nvidia on the Guest OS (may be tricky business as some of the references pointed out by tsu2 suggest);
- at this point you should be able to use the iGPU on the Host system and rhe dGPU on the Guest VM.
My understanding is that we are helping you achieve point 1) in this thread; once there you might be better off asking in the Virtualization subforum to achieve points 2)…4).
But I’m no expert on those matters so I might be wrong here.
Thanks for the info. I didn’t know that.
Might that have anything to do with disabling kernel mode setting? Or is that only for console? Currently I have nouveau.modeset=0 in the kernel command line and in my test case 2 I tried without it but it didn’t change anything.
Get rid of bare metal Windows installation (which I maintain just because of few programs which require graphics acceleration and which don’t have decent FOSS alternative).
If you are talking about the normal use of your desktop you are correct, do use the Nvidia driver all the time (although the Nouveau driver in recent kernels is not that bad with a GKxxx GPU: the 60 FPS you see is just the monitor refresh rate, try some other command or benchmark).
BUT if you are trying to achieve PCI pass-through the final picture should be something like the following AFAIK:
- the host system is controlled through the iGPU (or ssh via a remote terminal if you prefer…) thus freeing the Nvidia from ANY host job;
- at that point the Nvidia may be “hijacked” by a Virtual Guest via PCI pass-through, making it effectively “invisible” to the host (and so which driver is installed in the host should be irrelevant);
Thanks for clarifying all this. I was wondering if that was actually the case but now it makes sense. Thanks.
My understanding is that we are helping you achieve point 1) in this thread; once there you might be better off asking in the Virtualization subforum to achieve points 2)…4).
That’s correct.
I will try how things work with the nouveau driver.
Has nothing to do with mode setting. Mode setting is just the auto detection and driver selection which does have to be disabled for the NVIDIA driver. But the reason is that NVIDIA supplies their own mesa files which make the x stack broken for any other driver. As I said they have done this forever. the NVIDIA mesa files are optimized for their binary blob driver
nouveau seem to use the sync to V blank which generally is 60 hz This can be turned on or off in the NVIDIA server app which results in higher or lower frame rates reported on the GL test suite
Ok, I tried uninstalling the nvidia driver. The result is similar to case 2 - getting the exact same boot time error.
With iGPU set as primary and even manually setting driver to “i915” in xorg.conf I am getting:
There was also observable slowdown in graphics performance with the nouveau driver (even panning an image in gwenview is lagging). I ran glmark2 (total score: 1287) before switching back to nvidia driver. I couldn’t compare it to nvidia because with nvidia driver I get:
~]: glmark2
Segmentation fault (core dumped)
Here is also my xorg.conf
Considering that the nouveau is obviously too slow to work normally, I’ve been wondering: is there any configuration which can be manually put in xorg.conf which would allow driver #1 (nvidia) to be used with one monitor and driver #2 (i915 or whatever would work for the iGPU) to be used for another monitor?
AFAIK (see “man intel”) you have to set 'Driver “intel” ’ in xorg.conf, not “i915”.
Then maybe you have to tweak your config further, because you now have two “devices” (or graphics cards) and possibly two “Monitor” and two “Screen” to choose from if you have a monitor connected to the iGPU and one to the dGPU.
So your “Layout” section might be more complex, but I’m not smart enough to suggest one on the fly, sorry.