Kernel – 4.20-rc3 Released, OK with latest VMware, Still no NVIDIA Fix.. — 4 Comments

  1. The NVIDIA issue seems to be related to the Mali drivers issue I’m having on ARM systems.

    It seems that the transition from vm_insert_pfn to vmf_insert_pfn was done through at least 2 kernel versions (4.18 and 4.19) and they all involved changing the signature of the function set to the .fault field of the local struct vm_operations_struct structure.

    The signature changes from … int my_driver_cpu_vm_fault to vmfault_t my_driver_cpu_vm_fault and uses vmf_insert_pfn here as the return value of the function.

    However, in most driver cases, the cpu_vm_fault is a very simple function :

    Anyway, vmf_insert_pfn have been introduced like this :

    The simple (but semi broken) way I found to solve this issue is to replace the .fault function signature accordingly, and then use a vmfault_t identifier to store the result of the vmf_insert_pfn function and break only if it’s equal to “VM_FAULT_NOPAGE”…

    Now, that behaviour in my patch is stupid since vmf_insert_pfn *always* return a VM_FAULT error. There’s no other return paths :
    However, I don’t know why the Mali driver is calling this function outside fault functions. I’m still trying to search for another driver that mimics this mechanism.

    That said, it still made the Mali drivers able to boot semi properly and provide OpenGL ES output, with degraded performances.

    Maybe those informations could help you in trying to patch the NVIDIA kernel drivers.

    • Thanks for the detailed summary.. I would strongly recommend posting this on the NVIDIA dev forum, if you haven’t already done so, as this is where the people with the necessary skills will read it…

    • Just tested it, and no change from the previous version..
      I still haven’t got any response to my post on the dev forum, either..

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.