Olivier Langlois's blog

No idea what is the value added of this support.

I have modified the function KCL_EFI_IS_ENABLED() to return 0 on my UEFI enabled system and it made 0 difference.

It will remain like that until I have an explanation. In my experience, UEFI usage is rarely benefiting the end-user.

I have recompiled my kernel with CONFIG_AGP=n (The last chipset with AGP support is at least 10 years old and only Intel integrated graphics (like i915) still use the AGP code as a hack) and by doing so, it has broken fglrx with:

lano1106@whippet2 ~ sad $ dmesg | grep fglrx
[ 2.897539] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[ 2.899186] fglrx: Unknown symbol KCL_AGP_FindCapsRegisters (err 0)

I have just moved this function outside the #if CONFIG_AGP block and it is ok to do so since it does not contain anything specific to agp. only generic pci functions.

You can get the patch at:

http://www.trillion01.com/patches/kcl_agp_13_4.patch

Here is what I have done:

1. Enable crossfire
2. Start x
3. Start tracing X with strace
4. execute glxinfo
5. Boom!

The last entry in my trace log is:

ioctl(13, 0xc03064a6

where 13 is a file descriptor to fglrx fs frontend.

lrwx------ 1 root root 64 May 24 23:36 13 -> /dev/ati/card0
lrwx------ 1 root root 64 May 24 23:36 14 -> /dev/ati/card1
lrwx------ 1 root root 64 May 24 23:36 15 -> /dev/ati/card0
lrwx------ 1 root root 64 May 24 23:36 16 -> /dev/ati/card0
lrwx------ 1 root root 64 May 24 23:36 17 -> /dev/ati/card0

Next step will be activate kernel profiling, with some luck, maybe I'll find out that this is a simple to fix deadlock in spinlocks located on the public side of the driver.

In the meantime, this exercise did allow me to find out that the catalyst X driver was doing silly things. Such as totally rewrite the amdpcsdb file several times in the span of about a minute:

lano1106@Wailaba2 /dev/snd $ grep amdpcsdb /nas/x_trace.out
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33
open("/etc/ati/amdpcsdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33

and reading a 3 bytes file containing " \n" 5 times:

lano1106@whippet2 /etc/ati $ ls -l atiapfxx.blb
-rw-r--r-- 1 root root 3 Apr 27 15:35 atiapfxx.blb
lano1106@whippet2 /etc/ati $ grep 'atiapfxx.blb' /nas/x_trace.out
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 33
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 33
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 33
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 33
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 33
open("/etc/ati/atiapfxx.blb", O_RDONLY) = 33

I have sorted out the IOMMU thing.

#if defined(CONFIG_AMD_IOMMU) || defined(CONFIG_DMAR)
#define FIREGL_DMA_REMAPPING
#endif

I have noticed CONFIG_DMAR does not exist anymore. It has been replaced by CONFIG_INTEL_IOMMU.

For people having a Intel chipset with VT-d. It might be worthwile to try. To enable FIREGL_DMA_REMAPPING,

1. replace CONFIG_DMAR by CONFIG_INTEL_IOMMU in firegl_public.c and rebuild the driver
2. Enable VT-d in BIOS
3. Edit kernel command line param in grub.cfg by adding 'intel_iommu=on'

The whole purpose FIREGL_DMA_REMAPPING is to avoid compatibility issues between different kernel version in regards to DMA API. On most distribution CONFIG_AMD_IOMMU and/or CONFIG_INTEL_IOMMU will be defined and when fglrx will be compiled, FIREGL_DMA_REMAPPING will be defined even if at runtime no HW IOMMU will be detected and it works fine anyway.

DMA API is fine. Interface is the same for HW and SW IOMMU.

DMA api ends up using functions in arch/x86/kernel/pci-nommu.c if no hardware IOMMU is on the system. So, unless proven wrong, I would say force FIREGL_DMA_REMAPPING for all setup.

That being said and after having done a fantastic journey in IOMMU and DMA kernel code, I have found out that my problem was much simpler than that:

In /etc/X11/xorg.conf, section "ServerLayout"

2 screens, each one associated to one of my 2 cards, were enumerated. I have removed the second screen of the section and by doing so, it has allowed me to activate Crossfire.

Now, X server starts but hard freeze as soon as I try to access opengl functionality. It can be something as simple as 'glxinfo'.