Hide Forgot
Created attachment 804549 [details] dmesg from init-Intel-first boot. I have a new computer on which I'm trying to set up multi-seat, so to that end, I re-used the discrete nVidia card from the old machine as a second graphics head. Unfortunately, I seem to only be able to use one of them at a time. Generally, it seems I can only use the card which was set in the BIOS to initialize first. Sometimes I may have seen slightly different behaviour between the BIOS, the console, and X, but this is the general rule. The integrated is the HD4600 on the Intel i5-4670 (Haswell) and the discrete card is an XFX GeForce 7800GT (nVidia). Both of these work separately if I swap the settings in the BIOS. The BIOS only appears on one screen, so it may be a BIOS issue. I have a slight inclination it's not (at least not totally) because the second monitor does light up when the kernel loads, it's just blank or displaying garbage. When I set integrated to load first, the nvidia card will fail with nouveau reporting: nouveau E[ DRM] failed to create kernel channel, -12 The -12 is -ENOMEM, which I have traced back from `nouveau_accel_init` through to `nouveau_ramht_insert` where the error originates. The problem is that the RAM hash table is "full", except it can't be since the module is just loading. The code that allocates the hash table is supposed to zero it out, but I added a read immediately after, and it doesn't seem to have worked (unless there's some kind of flush missing). At this point, I'm not sure where to continue debugging. Is the BIOS giving a bogus PCI map? Is the kernel using the wrong region? Is the card not accepting it? I dunno... Version-Release number of selected component (if applicable): kernel-3.11.1-200.fc19.x86_64 but I also tested with a vanilla 3.11.2 that I built myself.
Created attachment 804550 [details] lspci from Intel adapter
Created attachment 804551 [details] lspci from nVidia adapter
With F20 and kernel-3.13.3-201.fc20.x86_64, things are a little bit different. When the firmware setting is integrated-first, then firmware+plymouth appear on the Intel display. However, X fails to load because of some sort of interrupt issue: kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 ... kernel: nouveau W[ PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0 kernel: nouveau E[ PFIFO][0000:01:00.0] still angry after 101 spins, halt Interestingly, it's a bit closer to working by switching the firmware to init the PCIe card first. The firmware appears on the nvidia-connected display, as does GRUB. However, Plymouth shows up on the Intel display, and then X goes back to the nvidia card. The Intel display then becomes garbage (it's a view of some part of RAM, for sure, just not a part with any graphics in it.) (PS, the motherboard is UEFI, not BIOS, as I stated earlier.)
Updated now to the following versions: * kernel-3.14.2-200.fc20.x86_64 * xorg-x11-drv-intel-2.21.15-5.fc20.x86_64 * xorg-x11-drv-nouveau-1.0.9-2.fc20.x86_64 * xorg-x11-server-Xorg-1.14.4-7.fc20.x86_64 * mesa et. al. 10.1-6.20140305.fc20 Booting with integrated-first crashes in OsLookupColor, but the backtrace doesn't go anywhere, really. Some related bugs suggest removing glamor, but doing so just gives "No screens found". Booting with discrete-first is much the same as before. Firmware and GRUB appear on nvidia display, Plymouth on Intel display, X back on nvidia display. Intel display then shows some sort of RAM cross-section.
As an additional test, I tried setting up some Xorg config to specify specific adapters. So, booting with integrated-first, I added a config to use nouveau only. This did not work at first, and said "no devices found". I then added BusID to the config, and this problem cleared. However, the display remains black. There are no errors in the log; it just seems to periodically EDID. Booting with discrete-first, I added a config to use intel only. As before, this did not work, and said "no devices found". I then added BusID to the config, and it correctly showed on the Intel display only. So then I tried a config that specifies both intel and nouveau with the correct BusID. Unfortunately, the result seems about the same as the previous comment.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still problematic.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.