Leaderboard

Popular Content

Showing content with the highest reputation since 12/22/21 in Reports

  1. Since the 5.x kernel based releases many users have been reporting system hangs every few days once the i915 module is loaded. With reports from a few users detailed in the thread below we have worked out that the issue is caused by the i915 module and is a persistent issue with both the 6.9.x release and 6.10 release candidates. The system does not need to be actively transcoding for the hang to occur. 6.8.3 does not have this issue and is not hardware related. Unloading the i915 module stops the hangs. Hangs are still present in 6.10.0RC2. I can provide a list of similar reports if required.
    3 points
  2. just to keep this issue alive as there are more open questions regarding this and its still open in 6.10 rc2 description is simple as the topic, whenever there was a unsafe shutdown, starting unraid with docker setting will result in a non working state, stopping/starting docker service or rebooting clean resolving the issue. easy to reproduce and annoying when you externally working on the mashine and hard reboot externally while using as sample ssh guac to access it again, but doesnt work as described above, so only VPN backdoor to restart it. may a workaroud possible if its a bigger issue ? like you can trigger parity after a unclean shutdown, trigger a docker service restart too ? tested here from 6.92 until today 6.10 rc2 on 4 different mashines with the same result, open issues as reminder ...
    1 point
  3. With this version that has nfs4 enabled in the kernel, I was able mount all my mount points with version 4 instead of version 3. To enable nfs4 I made no changes on the Unraid side (other than just upgrading to 6.10.0-rc2d). I use systemd to mount my unraid nfs shares. For each of my .mount files, I simply changed Type=nfs to Type=nfs4 I then rebooted to see everything automount as expected. I also manually mounted a share with the following command sudo mount -t nfs4 -o proto=tcp,port=2049 x.x.x.x:/mnt/user/BookLibrary /mnt/ADrive I checked the output of nfsstat -m to verify: ❯ nfsstat -m /nfs_mnt/AtlasBackups from x.x.x.x:/mnt/user/AtlasBackups Flags: rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.1.3,local_lock=none,addr=x.x.x.x /nfs_mnt/AtlasMedia from x.x.x.x:/mnt/user/AtlasMedia Flags: rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.1.3,local_lock=none,addr=x.x.x.x /nfs_mnt/GameUtils from x.x.x.x:/mnt/user/GameUtils Flags: rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.1.3,local_lock=none,addr=x.x.x.x /nfs_mnt/syslog_share from x.x.x.x:/mnt/user/syslog_share Flags: rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.1.3,local_lock=none,addr=x.x.x.x /nfs_mnt/GamesStorage from x.x.x.x:/mnt/user/GamesStorage Flags: rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.1.3,local_lock=none,addr=x.x.x.x /nfs_mnt/unsorted from x.x.x.x:/mnt/user/unsorted Flags: rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.1.3,local_lock=none,addr=x.x.x.x /mnt/ADrive from x.x.x.x:/mnt/user/BookLibrary Flags: rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.0.1.3,local_lock=none,addr=x.x.x.x So it looks like it mounted ok. Everything on my Manjaro linux desktop that uses those mounts at least starts ok. I'll do some more rigorous testing over the weekend but right now I'm running a backup and having Steam install a game to see how things shake out. So far so good though, fingers crossed! -Greg
    1 point
  4. There seem to be samba-problems in combination of macOS Monterey and 6.10.0-rc2. Mounting the smaba shares on macOS Monterey works fine but subjectively slightly slower. But immediately after starting a filecopy to the unraid-system, strange things happen: the destination folder goes blank for a moment then suddenly many previously existing folders appear multiple times you can not cancel the copy process the smb share drops I also have the impression that the reactivity/perfomance of the samba shares are much slower than in 6.9.2. The whole thing is reproducible. Unfortunately, I could only test with macOS Monterey. I cannot say whether the problem also occurs with other macOS versions. @Maxrad also Reported: Reverting to 6.9.2 or to 6.10.0-rc1 (Maxrad) worked. Tested with this "Samba extra configuration": #unassigned_devices_start #Unassigned devices share includes include = /tmp/unassigned.devices/smb-settings.conf #unassigned_devices_end [global] spotlight backend = tracker [data] path = /mnt/user/data spotlight = yes #vfs_recycle_start #Recycle bin configuration [global] syslog only = No syslog = 0 logging = 0 log level = 0 vfs:0 #vfs_recycle_end nas.fritz.box-diagnostics-20211108-1021.zip
    1 point