Jump to content

LushFire

Members
  • Posts

    4
  • Joined

  • Last visited

Posts posted by LushFire

  1. On 2/3/2021 at 12:46 AM, dglb99 said:

    Just wanted to add another report of /dev/dri showing up but VAAPI not being accessed inside the docker containers with my i5 10400.  I plan on trying to get the new intel media-driver working once I get a chance.

    What is the max temp you see on your chip, passing all 6c/12t to a windows vm running cinebench I see low 50's . I am not sure if my sensor readings are wrong or if something else is going on.

  2. On 1/29/2021 at 11:48 PM, LushFire said:

    Has anyone been able to get the Intel IGPU to work with this container? I pass it through to the container but get this error from ffmpeg 

     

    
    [AVHWDeviceContext @ 0x4db2380] No VA display found for device: /dev/dri/renderD128.
    Device creation failed: -22.
    Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': Invalid argument
    Error parsing global options: Invalid argument

     

    Used linuxserver docker container and it worked right away

  3. Has anyone been able to get the Intel IGPU to work with this container? I pass it through to the container but get this error from ffmpeg 

     

    [AVHWDeviceContext @ 0x4db2380] No VA display found for device: /dev/dri/renderD128.
    Device creation failed: -22.
    Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': Invalid argument
    Error parsing global options: Invalid argument

     

  4. I am on version 6.9.0 RC2

     

    I have been trying to find a way to get control of my fans through unraid.

    So far I have found one method which I do not particulary like found here

     

    I have also found a discussion regarding this issue here it seems like the better solution than changing the above mentioned parameter.

     

    This is the potential risk with using "acpi_enforce_resources=lax"

     

    Quote

    With previous kernels hwmon drivers used to drive IO ranges which were potentially used by the ACPI code in your BIOS (which is active not only during but also after boot), we now explicitly check for this and if the ACPI code claims the IO-ports used by the hwmon chip, we no longer allow the hwmon driver to load.

    Banging IO-ports of a chip from 2 different drivers, the Linux hwmon driver and the ACPI code is a really bad idea and can cause all sort of issues (including things like changing CPU / RAM voltage or clock speed). So the old behaviour was a really bad idea.

    So even though this change in behaviour makes some people unhappy as to old behaviour happened to work without problems in their case (by sheer luck really), this change is really for the best!

    If you have an Asus motherboard, chances are good there is an ACPI interface to read your sensors, which is safe, and no more sensors.conf tweaking needed for conversion formulas! Make sure you have the asus_atk0110 driver enabled in your kernel configuration to use this. You will also need lm-sensors version 3.1.0 or later.

    If you want to restore the old behaviour (which might be dangerous) add: "acpi_enforce_resources=lax" to the kernel cmdline when booting

     

    I have been trying to follow the install instructions for the driver but I run into this error when running make command.

    make[1]: *** No rule to make target 'modules'.  Stop.
    make: *** [Makefile:73: modules] Error 2

     

    Any help or guidance is appreciated.

×
×
  • Create New...