Hello,
I am running a Toradex Apalis TK1 module.
I try to get the X server to work but it fails with:
drmPrimeFDToHandle() failed: Invalid argument
failed to add fb -6
I’m using the Yocto Project BSP, with mainline Linux kernel (4.14.8) with Nouveau drivers. The Tegra Yocto Project layer I’m currently working with is meta-toradex-tegra (morty-next). I’m not using the provided LXDE image but created a custom one.
Now I have some questions:
Is Xorg using the xf86-video-nouveau DDX driver? Or am I wrong here. It seems your BSP won’t compile and use this Xorg driver. Maybe your combination of Xorg components doesn’t require this driver?
I also can’t see any hint for a provided xorg.conf which makes the X server switch to the nouveau driver.
Instead Xorg makes use of the standard modesetting_drv.
Can you tell me if I am missing something important here?
Hello, I am running a Toradex Apalis TK1 module. I try to get the X server to work but it fails with:
drmPrimeFDToHandle() failed: Invalid argument failed to add fb -6
I’m using the Yocto Project BSP, with mainline Linux kernel (4.14.8) with Nouveau drivers. The Tegra Yocto Project layer I’m currently working with is meta-toradex-tegra (morty-next). I’m not using the provided LXDE image but created a custom one.
Now I have some questions:
Is Xorg using the xf86-video-nouveau DDX driver?
No, that one is only for “real” NVIDIA cards. Remember, TK1 uses a Tegra display controller frontend which uses the modesetting driver with GLamor (e.g. somewhat mentioned here).
Or am I wrong here. It seems your BSP won’t compile and use this xorg driver. Maybe your combination of xorg components doesn’t require this driver? I also can’t see any hint for a provided xorg.conf which makes the Xserver switch to the nouveau driver. Instead xorg makes use of the standard modesetting_drv.
Yes, it is using modesetting with GLamor and xorg.conf files are completely optional nowadays.
Can you tell me if I am missing something important here?
I guess you missed that on the Tegras only the backend GPU rendering part is similar to regular NVIDIA graphics cards while the actual display controller is still quite different and therefore also handlled differently.
Please note that our official Morty BSPs were still using Linux kernel 4.9 and only later Rocko BSPs make use of 4.14. So whether or not 4.14 works with Morty user space is somewhat in doubt.
Thank you for answering.
So switched back to modesetting + kernel 4.9 but the problem still persists.
Additionally dmesg now outputs multiple “vgaarb: this pci device is not a vga device” messages.
I created a stack backtrace from drmPrimeFDToHandle() but that doesn’t give me any clear direction.
Thank you for answering.
You are very welcome.
So switched back to modesetting + kernel 4.9 but the problem still persists.
I just checked and our latest BSP 2.7 mainline nightly build actually does use 4.14 which works fine (see log file). You may find the used glmark2 package here.
Additionally dmesg now outputs multiple “vgaarb: this pci device is not a vga device” messages.
I believe those were expected back in the 4.9 kernel. But on second thought I would rather recommend going with later 4.14 stuff.
I created a stack backtrace from drmPrimeFDToHandle() but that doesn’t give me any clear direction.
We really never heard of any such issue. Can you try with our pre-built nightly and go from there?
Ok I finally got the stuff working with your 4.14.30 Kernel and related Kernel Modules.
My kernelversion was 4.14.8 and there nothing worked for me. I also tried the 4.9 kernel and had exactly the same issues.
Can you please provide me the commit hashes from all layers used in the latest nightly build?
It’s basically using this manifest together with the following in your conf/local.conf:
MACHINEOVERRIDES =. "use-head-next:"
Ok X seems to work now. Thank you so much!
Unfortunatelly I did not locate the root of the error, but there I think there may be a race condition somewhere in the drm_prime and “gem” handling of the kernel, but I’m not sure.
Thanks for the feedback. Could you tell us your working settings/setup (Kernel Version, local.conf, …)? This will be a great help for the other users.
I think I have found the root cause of the error. My custom kernelconfig turned off the iommu based configs
“CONFIG_TEGRA_IOMMU_GART” and “CONFIG_TEGRA_IOMMU_SMMU”.
Without enabling this configs the tegra_gem_prime_import() callbacks’ behavour is different and returns with EINVAL.
