Attempting to start xorg-server-1.9.0.901 fails when ATI/Radeon is one of the hardware drivers. Reproducible: Always Steps to Reproduce: 1. Attempt to start xdm/Xorg with previously working (1.8) configuration involving both Intel (motherboard) and ATI (add-in card) graphics drivers. 2. Graphics fails to start, no X terminals and VTs are non-functional. Actual Results: No graphics. No VTs. Computer still functions but can only be accessed via ssh from other systems. Expected Results: X configurations and graphics drivers should not destroy the functionality of VTs. Further they should not destroy the functionality of unrelated graphics drivers. When the xorg.conf file was edited to remove the ati/radeon drivers the intel drivers were able to function properly again. So it is the Xorg-1.8.0.901 and/or the ATI drivers that are destroying the functionality of the rest of the system.
Created attachment 250935 [details] emerge --info
Created attachment 250937 [details] core dump trace from Radeon/R600 driver Obvious problem with Radeon "aborting" when attempting to initialize with Xorg-server-1.9.0.901. The ATI driver was compiled after compiling the xorg-server so they were in theory "in-sync". The ati driver version was: x11-drivers/xf86-video-ati-6.13.2
Created attachment 250939 [details] xorg.conf that fails xorg.conf setup for both Intel and ATI/Radeon drivers. This configuration fails to start, produces a core dump and produces non-working VTs.
Please attach dmesg output too.
Created attachment 251761 [details] Dmesg from last system boot ~ 10 days old. This is the dmesg from the last system boot (Oct. 13). Before then there was a brief period in late August and September (around xorg-server 1.8.1 - 1.8.2 when it appeared that one might actually be getting the intel driver and the ati driver to behave well with each other. All of that now is toast as on Oct 13 I had to gut the ATI driver from my xorg.conf to get X to boot at all. There is an argument for falling back to everything less than xorg-server-1.9.0.901 but one is already up to 902 which one is prompted to ask is it better or worse. I'm fairly sure the problem of Xorg programs segfaulting due to stack overflows and filling up my root filesystem hasn't been fixed. And that is an easily fixable problem involving xdm limiting the stack size of all Xorg programs.
Some things are odd: > video=intelfb:1680x1050-32@60,vram=32,mtrr vga=0xF05 You have a reference to intelfb and vesafb there. Get rid of those, best disable vesafb and intelfb in the kernel entirely. Then you have an xorg.conf which tries to run one X server for two graphics adapters. While this works sometimes with all DRI/KMS/acceleration disabled, it is not a well supported configuration. Separate X servers for each graphics card should work though.
Ok, the point about the boot-up FB is taken. But I specifically want those to allow boot up with small fonts on a wide screen to allow the most information on the screen during boot up (50+ lines on the display vs. ~23 lines). It works, generally, switching from a normal font display over to the FB font display (more info per screen) shortly into the Init process (I presume when the display drivers are activated). I also want (though it is questionable whether I will get it) to be able to use the framebuffer drivers on the VTs 1-4 and the Xorg drivers on VTs 8-12. Now with respect to xorg-server-1.9.X -- It fails to start when loading both the Intel and the ATI drivers. That is in contrast to previous versions of X. 1.6 or 1.7 were problematic with respect to either the Intel or the ATI drivers due to their development state. However 1.8 would load and run with both drivers though I never managed to get them to do Intel <-> ATI cross screen (xinerama like) as I would expect from a robust system. In this standard configuration I should be able to support 3 screens. One VGA off of the Intel and one VGA off of the ATI card and one DVI off of the ATI card. And if X works as one would expect one should be able to move things to and fro from any of those screens as a single session. Linux should let me do anything the reporters can do on CNN screens or iPhone users can do on their mini-screens (even if I have to do it with a mouse).
(In reply to comment #7) > Ok, the point about the boot-up FB is taken. Then please give that a try. > But I specifically want those to allow boot up with small fonts on a wide > screen to allow the most information on the screen during boot up (50+ lines on > the display vs. ~23 lines). It works, generally, switching from a normal font > display over to the FB font display (more info per screen) shortly into the > Init process (I presume when the display drivers are activated). > > I also want (though it is questionable whether I will get it) to be able to use > the framebuffer drivers on the VTs 1-4 and the Xorg drivers on VTs 8-12. > > Now with respect to xorg-server-1.9.X -- It fails to start when loading both > the Intel and the ATI drivers. That is in contrast to previous versions of X. > 1.6 or 1.7 were problematic with respect to either the Intel or the ATI drivers > due to their development state. However 1.8 would load and run with both > drivers though I never managed to get them to do Intel <-> ATI cross screen > (xinerama like) as I would expect from a robust system. > > In this standard configuration I should be able to support 3 screens. One VGA > off of the Intel and one VGA off of the ATI card and one DVI off of the ATI > card. > > And if X works as one would expect one should be able to move things to and fro > from any of those screens as a single session. Linux should let me do anything > the reporters can do on CNN screens or iPhone users can do on their > mini-screens (even if I have to do it with a mouse). First things first. Try without all your fb drivers, we'll get to your Star Trek fantasies later. Thanks
It think changing the kernel line will not make a difference, from dmesg it seems that those lines have no effect. It is really a problem in upstream's xorg-server that multiple cards are not supported properly.
There's not really anything Gentoo developers can do to solve this. Please file a bug upstream https://bugs.freedesktop.org/enter_bug.cgi?product=DRI if the problem persists.
