• Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About mf808

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Has anyone got the intel uhd 630 passthrough to work with a macinabox so that It outputs to the motherboard hdmi port?
  2. After 27 days with the new kit of ram it hasnt crashed or shown any errors yet. I call this closed.
  3. Ok, this is the behaviour as you described. htop shows minimal cpu usage and the dashboard is as shown in the screenshot. Issue: slow transfer speeds. Anyone have an idea whats up with this?
  4. I have noticed that transfer from the array to my desktop over a 10G network is now only running at 40MB/s or lower. Previously this was running smoothly at over 100MB/s. Also on the dashboard shows high usage of all cores. Ther are no other activities on this drive or the server. Clean reboot. Any ideas?
  5. Good call. Turns out I had a bad stick. Removed the bad kit and did a 16 hour run of Memtest86 without errors. I will retest.
  6. Upgraded to beta25 System ran for again around ~22 days then became unresponsive. I do have a syslog, which I copied into the diag zip. Does this look like a memory issue? First error appeared: Sep 20 19:25:37 NASMUC kernel: BUG: Bad page map in process php-fpm pte:ffff88902fe84d20 pmd:e31dd2067 Sep 20 19:25:37 NASMUC kernel: addr:0000151c039f4000 vm_flags:00100073 anon_vma:ffff88813df81160 mapping:0000000000000000 index:151c039f4 Next error: Sep 22 21:24:12 NASMUC kernel: general protection fault, probably for non-canonical address 0x6bb0100000000: 0000 [
  7. Hi Squid, thanks for your reply. I added the diagnostic file. Although it was created after a reboot. How much more of the syslog is required? The excerpt I have copied above is the first occurence of this error. After that it keeps repeating.
  8. I had my unraid server crash on me. Web Front End is not anymore responsive. SSH Login with root does not work. Docker Containers are working. Running 6.9 Beta 22 From my syslog server I was able to pull this information. I assume the server was running for about 20 days. <1>Aug 6 15:43:14 NASMUC kernel: BUG: unable to handle page fault for address: 000000015d3ea242 <1>Aug 6 15:43:14 NASMUC kernel: #PF: supervisor write access in kernel mode <1>Aug 6 15:43:14 NASMUC kernel: #PF: error_code(0x0002) - not-present
  9. If @capalm's table is to be believed, then I would really would like to hear something from the devs @jonp @limetech The data presented suggests that a feature that has come with 6.8.0 is causing these write amplifications by a factor of 4 to 5x. (according to the data that @capalm provided) I am assuming that virtually all users with 6.8.X are affected who are using ssds/nvmes as their cache drives. Many are not even aware (!) that their drives will have a shortened life span because of excessive and unnecessary writes. When the drive prematurely fails during warranty
  10. Well there goes another 3TB wasted in under 2 hours. Issue: While post processing a 500mb file Nzbget was caught in a loop (still have to figure out what happened) and effectively did 3TB of writes. The appdata folder resides on my raid 1 btrfs cache disk. I only noticed the problem as I got high temp warnings on the nvmes. This issue does not give me the confidence to leave the server running unattended.