Jump to content

ich777

Community Developer
  • Posts

    15,001
  • Joined

  • Days Won

    190

Report Comments posted by ich777

  1. 36 minutes ago, Squid said:

    6.12.6 fails silently in this circumstance (incorrect behavior)  Tested it all and I can get this via the GUI no problems.

    After a little bit of back and forth with @sonic6 I think this is simply a bad Docker template either the maintainer has to fill out a path by default for the host and container or he has to fill out the container path and mark the path as required so the user is forced to fill in the path or delete the path.

     

    That‘s my opinion on that.

  2. 6 hours ago, Can0n said:

    to add to my OP

    Please uninstall GVT-g since it seems like you aren't using it and see if this makes a difference.

     

    Can you also post your docker run command from Plex?

    I have a i5-10600 here and everything is running smoothly with Emby and Jellyfin everything on ZFS but without snapshots.

     

    I see a lot of this messages in your syslog, are you sure that this is correct:

    Jul 15 16:07:04 Thor pulseway: Periodically collected data not ready yet for Types::Reporting::Data::CoreReportData
    Jul 15 16:07:04 Thor pulseway: No data for module 1
    Jul 15 16:07:04 Thor pulseway: Periodically collected data not ready yet for Types::Reporting::Data::NetworksUsageData
    Jul 15 16:07:04 Thor pulseway: No data for module 3
    Jul 15 16:07:04 Thor pulseway: Failed to get package list
    Jul 15 16:07:04 Thor pulseway: No data for module 6
    Jul 15 16:12:20 Thor pulseway: Periodically collected data not ready yet for Types::Reporting::Data::CoreReportData
    Jul 15 16:12:20 Thor pulseway: No data for module 1
    Jul 15 16:12:20 Thor pulseway: Periodically collected data not ready yet for Types::Reporting::Data::NetworksUsageData
    Jul 15 16:12:20 Thor pulseway: No data for module 3
    Jul 15 16:12:20 Thor pulseway: Failed to get package list
    Jul 15 16:12:20 Thor pulseway: No data for module 6
    Jul 15 16:17:37 Thor pulseway: Periodically collected data not ready yet for Types::Reporting::Data::CoreReportData
    Jul 15 16:17:37 Thor pulseway: No data for module 1
    Jul 15 16:17:37 Thor pulseway: Periodically collected data not ready yet for Types::Reporting::Data::NetworksUsageData
    Jul 15 16:17:37 Thor pulseway: No data for module 3
    Jul 15 16:17:37 Thor pulseway: Failed to get package list
    Jul 15 16:17:37 Thor pulseway: No data for module 6
    Jul 15 16:22:53 Thor pulseway: Periodically collected data not ready yet for Types::Reporting::Data::CoreReportData
    Jul 15 16:22:53 Thor pulseway: No data for module 1
    Jul 15 16:22:53 Thor pulseway: Periodically collected data not ready yet for Types::Reporting::Data::NetworksUsageData
    Jul 15 16:22:53 Thor pulseway: No data for module 3

     

     

    I also see these lines in your go file:
     

    #Hardware video Transcode Enable and TMP File System
    modprobe i915
    ***line removed***
    #chmod -R 777 /dev/dri
    mkdir /tmp/PlexRamScratch
    chmod -R 777 /tmp/PlexRamScratch
    mount -t tmpfs -o size=32g tmpfs /tmp/PlexRamScratch

     

    Can you try to not use a tmpfs for Plex and transcode somewhere on a hard disk, maybe a spinning one?

    You also don't have to do the modprobe because unRAID is doing that for you and even if it wouldn't then Intel-GPU-TOP would do that for you.

     

    May I also ask why are you doing that:

    mount -o remount,size=1024m /var/log/

     

     

    It seems that you have a lot customized maybe start pulling back a bit at least in terms of Plex and see if it does if you run it bare bones with the default transcoding directory and so on.

     

     

    EDIT: Please also consider upgrading the BIOS, the BIOS that you are running (Version: 0811) is the first one that was released for this Motherboard, the newest version is: 1801

  3. 11 hours ago, Craig Dennis said:
    libkmod: kmod_config_parse: /etc/modprobe.d/i915.conf line 1: ignoring bad line starting with 'enable_dc=0'

    Exactly that is the case what @vojtagrec said, the contents of your file /boot/config/modprobe.d/i915.conf are:

    enable_dc=0

    whereas it should be:

    options i915 enable_dc=0

     

    The path from the file that you have to change is:

    /boot/config/modprobe.d/i915.conf

     

    After you've changed that you have to reboot!

    • Like 1
  4. 1 hour ago, Craig Dennis said:

    I have it applied via `/boot/config/modprobe.d/i915.conf`

    It seems that you are trying to applying it in multiple places and hope that one is working which is definitely not the way to do it.

     

    1 hour ago, Craig Dennis said:

     

    1442642589_Terminal2023-06-21at14_10.49@2x.thumb.jpg.458f95add9942d8563ca6f7129266703.jpg

    Please remove the line with the modprobe or comment it since this won't do anything because the module is already load at that stage.

     

    1 hour ago, Craig Dennis said:

    I have it in the `syslinux.config` in the flash page

    Also remove these lines for the i915 module because this is not how you would append that.

     

    1 hour ago, Craig Dennis said:
    libkmod: kmod_config_parse: /etc/modprobe.d/i915.conf line 1: ignoring bad line starting with 'enable_dc=0'

    Where are the contents from this file? They should be:

    options i915 enable_dc=0

    (please note that if you are using the default editor from OSX it will destroy the formatting and Linux can't read it)

     

    1 hour ago, Craig Dennis said:

    Running rc8 and for whatever reason I am unable to make `enable_dc=0` stick.

    Why are you not on 6.12.1 since it is now stable and try it there?

  5. 1 hour ago, Hoopster said:

    As far as I am concerned, yes

    Can you please test and try to disable VT-d in the BIOS, remove the i915.conf file (or move it to the root from your USB Boot device), reboot and see if that works?

     

    If not it's also fine but I'm very curious in your case if VT-d causes this.

    • Like 1
  6. @zoggy as you've said:

    Quote

    This is set with the Nvidia Driver plugin.

     

    This is something we should discuss on the support thread from the Nvidia Driver plugin because the plugin is not part from the OS nor is the Plugin-Update-Helper.

     

    Quote

    While on 6.11.5 and doing the update os to 6.12, it fires off the plugin helper which upgrades nvidia driver to latest v535.54.03.

    This was suboptimal as this driver does not support my video card. It would be nice if the plugin helper would ignore upgrading if the user is using the legacy 470.x drivers (As its probably by design).

    This is caused because the driver version from the legacy driver changes from time to time and the Plugin-Update-Helper simply can't find the 470.xx revision driver which you have selected and it falls back to the latest version.

    For the second recommendation about simply not downloading it, it would be the same outcome and simply not possible since even if the Plugin-Updated-Helper doesn't download the driver, the new Unraid version or better speaking the new Kernel version needs a updated driver which is compatible with the Kernel and as said above, even if the Plugin-Update-Helper doesn't download the driver for the new Kernel version the Plugin itself would do that on boot and since it can't find the same static driver version that you've set it to it falls back to the latest version.

     

    Quote

    Before rebooting to have it boot up on 6.12, I tried downgrading back to 470.141.03, which it said it did.

    That's because of the new Kernel version and the Nvidia legacy driver changes from time to time that I've explained above.
    The new driver version for Unraid 6.12.0 is: 470.182.03 instead of 470.141.03 for Unraid 6.11.5

     

    Quote

    So the only 6.12 logs I have is the current log where it shows it loading the correct 470 legacy drivers as expected.

    Hope that explains everything but I also have to say I won't change that behaviour since I don't know how long Nvidia is going to support the legacy driver and how long it will work with the container runtime <- which is required for the use from Nvidia cards in Docker containers.

     

    As a little side note, if the container runtime is dropping support for the legacy driver I will also stop compiling these legacy drivers.

     

    May I ask for what do you use the GT710? The GT710 is a pretty bad card for transcoding anyways because it even doesn't support h265 (HEVC) and in comparison it is really power hungry compared to something more recent like a Nvidia T400 which you can get for pretty cheap (often times for below 100,-), it only draws about 1-4 Watt in idle and it is based on the Turing architecture.

     

     

    Hope that helps and answers all your questions.

  7. 12 hours ago, Craig Dennis said:

    @ich777 I followed your guide above (still on rc-6) and the system crashed at the usual time. I will try with other DC values on rc-6 before upgrading to rc-7 (although I might skip it if the fix has a regression as reported above).

    Your issue seems to be different since power well is something completely differnt, have you yet tried to disable power well?

     

    You can do that by adding this to your syslinux.config

    i915.disable_power_well=1

     

    If the options do nothing for you (as you've previously mentioned the option enable_dc=0 in your case), you can always blacklist the module so that Unraid doesn't load it automatically on boot and enabling it in the go file like mentioned in my previous post with the line:

    modprobe i915 disable_power_well=1

    or:

    modprobe i915 disable_power_well=1 enable_dc=0

     

     

    Attention: If you have my Intel GPU TOP plugin installed it will also activate the iGPU so I would recommend that you uninstall it first before trying these options.

  8. 23 hours ago, vojtagrec said:

    @Craig Dennis On which RC are you? I just upgraded to rc7 and got a crash too. It looks like there is some regression, I had the enable_dc=0 applied via /boot/config/modprobe.d/i915.conf and it worked perfectly fine with rc6 but it seems to not work with rc7. I booted rc7 after the crash and checked /sys/module/i915/parameters/enable_dc and indeed it was "-1" (auto). When I added the kernel param to "Syslinux Configuration" it seems to work (I just tested with my server, current uptime 30+ min and it always crashed around ~20 min after boot for me).

    First of all, I completely missed that you've mentioned me here.

     

    Can you please test this:

    Remove the iGPU from the bus with:

    echo "1" > /sys/devices/pci0000\:00/0000\:00\:02.0/remove

    (in this case I'm assuming that the iGPU is on the PCI bus on: 00:02.0)

    After that unload the module with:

    rmmod i915

    Load the module again with enable_dc=0 with:

    modprobe i915 enable_dc=0

    Then rescan the PCIe bus to again get your iGPU into the system with:

    echo "1" > /sys/bus/pci/rescan

    After that issue:

    cat /sys/module/i915/parameters/enable_dc

    And enable_dc should be at 0 again

     

     

    Please not that none of these command should print an error, rmmod for example should display nothing and modprobe also doesn't display anything.

     

    Please let me know if that is working on your platform.

    Maybe also try to play around with different power states for you iGPU and if enable_dc=2 is maybe working, even enabled_dc=3 can work:

    Quote

    enable_dc:Enable power-saving display C-states. (-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; 3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO) (int)

     

  9. 22 minutes ago, vojtagrec said:

    Clearly the GPU driver really crashes, I lose any video output in PiKVM (looks like a connected monitor, I get the info about resolution, but I get no image, just blank screen).

    Can you try to connect a real monitor to it or at least disconnect the PiKVM for now and see if it does the same again?

     

    I see some changes in Kernel 6.1.23 which could cause this.

     

    From what I can see the i915.guc=2 isn't enabled or appended from what I can see from the diagnostics that you've posted.

  10. 16 minutes ago, vojtagrec said:

    I'll keep a SSH connection open and check what's going on.

    Please just let it run as usual and see if it is crashing again.

     

    If it is crashing again please append that to your syslinux.config (go to the Main tab, click the blue "Flash" text and append it, don't forget to click Apply on the bottom and reboot):

    i915.enable_guc=2

     

    Should look like that:

    grafik.thumb.png.f1bdedfc8049a886f8afb998842070e4.png

  11. 38 minutes ago, Tristankin said:

    The system is 100% stable with 6.8.3. 6 months when it was the latest version, and then another 6 months after trying to upgrade to 6.9.x and then downgrading to 6.8.3 again.

    But what about the other people with the same hardware (at least motherboard and cpu) out there which have zero issues.

     

    32 minutes ago, Tristankin said:

    Would it be possible to run a 4.19 kernel on the latest build? Could help identify the cause?

    No and no.

×
×
  • Create New...