nouveau E[DRM] failed to create ce channel, -22


i am getting nouveau E[ DRM] failed to create ce channel, -22
error on linux bootup.

Is this a hardware issue ?, i tried with different version of OS like Baserock development system and GDP but still issue is same.
Please light some points on the above error,below is the complete log from dmesg:

9.729145] nouveau [ DEVICE][57000000.gpu] BOOT0 : 0x0ea000a1
[ 9.739687] nouveau [ DEVICE][57000000.gpu] Chipset: GK20A (NVEA)
[ 9.750829] nouveau [ DEVICE][57000000.gpu] Family : NVE0
[ 9.795527] nouveau [ INSTMEM][57000000.gpu] using IOMMU
[ 9.806837] nouveau [ VOLT][57000000.gpu] The default voltage is 1000000uV
[ 9.819089] nouveau [ VOLT][57000000.gpu] GPU voltage: 1043000uv
[ 9.830457] nouveau [ CLK][57000000.gpu] parent clock rate: 12 Mhz
[ 9.843755] nouveau [ CLK][57000000.gpu] --: core 198 MHz
[ 9.954319] nouveau [ PGRAPH][57000000.gpu] using external firmware
[ 9.974873] [TTM] Zone kernel: Available graphics memory: 374080 kiB
[ 9.986256] [TTM] Zone highmem: Available graphics memory: 1033534 kiB
[ 9.997934] [TTM] Initializing pool allocator
[ 9.998027] [TTM] Initializing DMA pool allocator
[ 9.998175] nouveau [ DRM] VRAM: 0 MiB
[ 9.998180] nouveau [ DRM] GART: 1048576 MiB
[ 10.083102] nouveau E[ PFIFO][57000000.gpu] unsupported engines 0x00000030
[ 10.144359] nouveau E[ DRM] failed to create ce channel, -22
[ 10.217782] nouveau [ DRM] MM: using GRCE for buffer copies.

Thanks in advance.

Is this running on a Jetson?

yes ,Jetson TK1

I know Fedora has an ARMv7 port which probably works on a JTK1, but I’ve never touched it. All of the non-nVidia ports probably start with the nouveau driver, and the nouveau driver across architectures likely has much in common…but as the saying goes “the devil is in the details”. Nouveau itself probably needs to be adapted to not just the ARMv7 CPU architecture, but also to the specific video device on the tegra124 SoC. JTK1 video does not use the PCIe bus, so this would not be a trivial custom task.

I’m not sure where to go from there to make things work, but if the JTK1 works when flashed with L4T I would say hardware is working fine. What’s the exact Linux distribution being used? Is there a URL to the distribution which might list details about it?

I have followed procedure from the below link.Currently I am working on GENIVI.

I saw the demo from the bottom of that web URL. It looks like their system worked for their hardware. I don’t know much about the nouveau driver (that’s one of the first things I replace when I install desktop Linux), but if the driver worked for their setup but not for yours, I’d suspect any mention of “DRM” (assuming this DRM is for the digital rights management over the video display) could actually be a result of video cabling or video hardware. I have no idea what the Genivi software requires or supports, but one of the highest ranked video failure causes for a Jetson would be video cable and monitor specification combinations.

Are you using an HDMI cable on an HDMI monitor without any kind of VGA adapter? How much of your video works…during boot, does text mode show up prior to failing at graphical mode? What is the exact chain of video cable to monitor?

The GDP Demo works fine for me also.But the problem is , I have a HMI custom application which works intermittently some time it throws continuous “nouveau [DRM] skipped size 0” to the console .When tried to debug i got above error mentioned earlier from dmesg.

Yes, I am using HDMI cable on HDMI monitor without any adapter.

I think what that comes down to is finding out more about the nouveau driver. I found this link explaining part of it:

According to that the driver is allocating a zero-size buffer and should not. The question then mutates into finding out in the nouveau code why it allocated that size. It could be that the ARMv7 nouveau needs to be modified to work better with memory manage, but other than that it’s impossible to say and looks very much to need help from the nouveau maintainers.

It would be very long and involved, with a lot of guessing and failures along the way, but if the X11 ABI matches the current Jetson L4T, then it may be you could dump nouveau and use the binary driver files from L4T. If you look in /var/log/Xorg.0.log for L4T R21.4, and search for “Module ABI versions” you’ll find the video driver module (“Video Driver”) is version 15.0. Note that if this is not matching your actual video driver (nouveau in this case) video will crash and burn. If you change your Xorg version to something else instead of changing video driver brand while holding ABI constant, then you’d also need to change other modules, especially XInput (changing Xorg without changing XInput would mean keyboard and mouse don’t work). If Video Driver and XInput driver in your custom install show boot or log messages matching versions 15.0 and 20.0, respectively, it may be reasonable to attempt just dropping nVidia files in as substitutes (this would be the simplest scenario).

There’s also a possibility that even if you replace nouveau with nVidia drivers there would still be the same failure…knowing why nouveau is doing what it is doing could be important…perhaps it is something as simple as a kernel memory management issue.

Thank you very much for your feedback.
I will try as you suggested .One more thing , my current system runs on wayland/Weston protocol not X11.

The nVidia binary drivers require X11. I suppose if I were to personally design something like Wayland, I might be tempted to use the same ABI as X11 in order to make as many video drivers as possible compatible without custom driver builds. However, I’ve never worked on Wayland, so I have no idea if they actually did this in the Wayland design. Unless Wayland provided compatibility with an X11 ABI, you won’t be able to adapt the nVidia binaries. This in turn would force debugging of the nouveau driver instead of going with nVidia binaries.