-
Posts
15,001 -
Joined
-
Days Won
190
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by ich777
-
-
5 minutes ago, Amane said:
root@unraid:~# grep -c .processor /proc/cpuinfo
You've run different commands, I need the output from that:
grep -c ^processor /proc/cpuinfo
-
Thanks @bubbl3!
-
Can someone with a 64+ core system the output from:
grep -c ^processor /proc/cpuinfo
-
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.
-
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
-
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!
- 1
-
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: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?
-
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.
- 1
-
@zoggy as you've said:
QuoteThis 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.
QuoteWhile 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.
QuoteBefore 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.5QuoteSo 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.
-
1 minute ago, Craig Dennis said:
@ich777 Awesome. Thanks. Maybe a silly question, will I be able to use the Intel GPU TOP plugin after I have changed these settings?
Intel GPU Top should append the arguments that you've added to the sysllinux.config but you have to try.
I can always modify the plugin so that you can append things there.
-
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.
-
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:
Quoteenable_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)
-
Please wait for the next RC and try if it solves your issues.
-
@vojtagrec please also check for available BIOS updates for your Motherboard.
-
8 hours ago, vojtagrec said:
Let me know if I should try some more flags/changes.
You can try multiple flags for the i915 Kernel module.
I would first try it with that:
i915.enable_dc=0
You can also first try to disable power management and see if that helps:
i915.disable_power_well=1
In the meantime I will look further into that.
-
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.
-
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:
-
On 4/16/2023 at 10:30 AM, rachid596 said:
Since i upgrade yesterday from RC2 to RC3 my server is very slow and ui is unresponsive.
Please also remove Intel-GVT-g and please post your diagnostics there:
-
@vojtagrec do you have a monitor attached to the system?
As a thing of precaution can you please switch to IPVLAN in the Docker Settings too?
-
19 minutes ago, Jclendineng said:
Mine is slow to non-responsive now as well. I had a crash yesterday after upgrading to RC3
Please post your Diagnostics.
-
7 hours ago, Kwakx said:
I had exactly the same thing, a few hours after upgrading to rc3 the server stopped responding. I wasn't able to collect any logs, syslog server didn't note anything either.
Please post your diagnostics.
-
7 hours ago, hawihoney said:
Will it still be possible to copy files in /usr/bin/ during first array start without problems?
Yes.
- 1
- 1
-
20 minutes ago, Tristankin said:
I have just changed from deluge to binhex/arch-qbittorrentvpn:4.3.9-2-01 after seeing the freeze reports under general.
Have you yet tried to disable torrent for a bit and see if this causes your issues since libtorrent is know to crash systems (not only Unraid).
-
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.
[6.12.8] No WebGUI - /run full
in Stable Releases
Posted
Oh sorry, completely overlooked that because of the quotes...
Thanks for pointing that out.