January 28, 20179 yr My vote is Tips & Tweaks. One of the tweaks is triggering a call to emhttp Boot Device: Can't explain either. There has always been one thing that I want to test but is a pita for me to do so since my desktop is a vm. Open up two tabs to unRaid. Reboot unRaid on one of them and don't touch the other until the system is back up and running. Navigate around the second. Do you get a ton of wrong_csrf errors? I rebooted with my phone and got a bunch of csrf errors. Tried to back out of the reboot page.
January 28, 20179 yr My vote is Tips & Tweaks. One of the tweaks is triggering a call to emhttp Boot Device: Can't explain either. There has always been one thing that I want to test but is a pita for me to do so since my desktop is a vm. Open up two tabs to unRaid. Reboot unRaid on one of them and don't touch the other until the system is back up and running. Navigate around the second. Do you get a ton of wrong_csrf errors? I'll take a look at Tips & Tweaks.
January 28, 20179 yr My vote is Tips & Tweaks. One of the tweaks is triggering a call to emhttp Boot Device: Can't explain either. There has always been one thing that I want to test but is a pita for me to do so since my desktop is a vm. Open up two tabs to unRaid. Reboot unRaid on one of them and don't touch the other until the system is back up and running. Navigate around the second. Do you get a ton of wrong_csrf errors? I rebooted with my phone and got a bunch of csrf errors. Tried to back out of the reboot page. How with your phone? Via ControlR?
January 28, 20179 yr My vote is Tips & Tweaks. One of the tweaks is triggering a call to emhttp Boot Device: Can't explain either. There has always been one thing that I want to test but is a pita for me to do so since my desktop is a vm. Open up two tabs to unRaid. Reboot unRaid on one of them and don't touch the other until the system is back up and running. Navigate around the second. Do you get a ton of wrong_csrf errors? I rebooted with my phone and got a bunch of csrf errors. Tried to back out of the reboot page. By doing what I said? With another window open on a desktop or something? The thing with csrf is that they are randomly generated on each reboot, so I *think* that an open session to unRaid during a reboot and then attempting to access via that session will generate wrong csrf errors.
January 28, 20179 yr Bug--- found this: Jan 28 08:17:42 Rose cache_dirs: cache_dirs process ID 8071 started Jan 28 08:17:42 Rose root: Fix Common Problems Version 2017.01.24 Jan 28 08:17:45 Rose emhttp: Starting services... Jan 28 08:17:45 Rose emhttp: nothing to sync Jan 28 08:17:45 Rose root: error: webGui/include/ProcessStatus.php: missing csrf_token Jan 28 08:17:45 Rose root: error: webGui/include/ProcessStatus.php: missing csrf_token Jan 28 08:49:42 Rose kernel: mdcmd (41): spindown 0 Jan 28 08:49:42 Rose kernel: mdcmd (42): spindown 2 Jan 28 08:49:43 Rose kernel: mdcmd (43): spindown 29 Jan 28 08:49:47 Rose kernel: mdcmd (44): spindown 1 Jan 28 08:49:48 Rose kernel: mdcmd (45): spindown 3 Jan 28 09:08:31 Rose sSMTP[27232]: Creating SSL connection to host Jan 28 09:08:31 Rose sSMTP[27232]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256 Jan 28 09:08:33 Rose sSMTP[27232]: Sent mail for [email protected] (221 2.0.0 closing connection c19sm6799946qtc.29 - gsmtp) uid=0 username=root outbytes=626 Jan 28 09:22:11 Rose kernel: kvm: already loaded the other module Jan 28 09:58:27 Rose kernel: mdcmd (46): spindown 1 Jan 28 10:00:03 Rose kernel: mdcmd (47): spindown 2 Attached diagnostics file also. Just to clarify (since Fix Common Problems is listed right at the beginning), FCP is not responsible for the csrf error. Looks like this is at the start of array, and the tests that FCP performs at array start do not trigger the error (just tried it) One other thing that I just noticed. Under 'Main' >> 'Boot Device', there is no listing for the boot device. It is just blank... I will be following up on dlandon suggestions but I am excepting company in the next few minutes. Something funny is going on. I had two or three open windows to the server and when I closed down to just one window, the Boot Device listing reappeared when I navigated to that window. I will try to figure out what is causing it later...
January 28, 20179 yr My vote is Tips & Tweaks. One of the tweaks is triggering a call to emhttp Boot Device: Can't explain either. There has always been one thing that I want to test but is a pita for me to do so since my desktop is a vm. Open up two tabs to unRaid. Reboot unRaid on one of them and don't touch the other until the system is back up and running. Navigate around the second. Do you get a ton of wrong_csrf errors? I rebooted with my phone and got a bunch of csrf errors. Tried to back out of the reboot page. By doing what I said? With another window open on a desktop or something? The thing with csrf is that they are randomly generated on each reboot, so I *think* that an open session to unRaid during a reboot and then attempting to access via that session will generate wrong csrf errors. No now that think about it, I don't think I did it like you initially said. Alot of times on a mobile browser I have to open a new tab because the password dialog/page will refresh before I can enter them. I think I just used the session from before the reboot and tried to navigate back after reboot. If I have to reboot soon I'll try like you said.
January 28, 20179 yr No now that think about it, I don't think I did it like you initially said. Alot of times on a mobile browser I have to open a new tab because the password dialog/page will refresh before I can enter them. I think I just used the session from before the reboot and tried to navigate back after reboot. If I have to reboot soon I'll try like you said. Net result is the same though. The session was from before the reboot, so it all had the wrong csrf's unless you reloaded the page and didn't just try to navigate from it... Maybe Eric / Tom will pipe in if I'm correct about this...
January 28, 20179 yr Post the output of this command: ls /usr/local/emhttp/plugins/*/event/disks_mounted The problem occurs after the cache_dirs plugin starts and is probably one of the other plugins started at the disks_mounted event. The ProcessStatus.php gets the status to display on the upper right corner of the page. In cache_dirs it shows the "Status: Running" or "Status: Stopped".
January 28, 20179 yr Post the output of this command: ls /usr/local/emhttp/plugins/*/event/disks_mounted The problem occurs after the cache_dirs plugin starts and is probably one of the other plugins started at the disks_mounted event. The ProcessStatus.php gets the status to display on the upper right corner of the page. In cache_dirs it shows the "Status: Running" or "Status: Stopped". It's definitely because of the old dynamix.plg. I had bleeding edge still with rc7 and got those errors (ProcessStatus.php) till I removed the plg rebooted for rc8.
January 28, 20179 yr Post the output of this command: ls /usr/local/emhttp/plugins/*/event/disks_mounted The problem occurs after the cache_dirs plugin starts and is probably one of the other plugins started at the disks_mounted event. The ProcessStatus.php gets the status to display on the upper right corner of the page. In cache_dirs it shows the "Status: Running" or "Status: Stopped". It's definitely because of the old dynamix.plg. I had bleeding edge still with rc7 and got those errors (ProcessStatus.php) till I removed the plg rebooted for rc8. That would make sense.
January 29, 20179 yr Author Post the output of this command: ls /usr/local/emhttp/plugins/*/event/disks_mounted The problem occurs after the cache_dirs plugin starts and is probably one of the other plugins started at the disks_mounted event. The ProcessStatus.php gets the status to display on the upper right corner of the page. In cache_dirs it shows the "Status: Running" or "Status: Stopped". If you look at ProcessStatus.php all it does is output a string which indicates whether something is "running" or "stopped". The thing it checks is determined by a parameter called 'name' which is passed in the POST data. This means you have to use a POST request on it. Because it's a POST request we now insist the csrf_token be passed as well. I was going to change this to respond to a GET request instead and would be very easy to do in the stock webGui but I didn't because I think this is used in plugins.
January 29, 20179 yr Author Small bug, I've done everything but wipe my setting and start again. It's reproducible for me: Go to http://tower/Shares Click "Compute All" ... Page refreshes ... Hasn't computed all (not in the foreground anyway) If you then click "Compute..." on a specific share, it'll show you the size just fine. tl;dr - Compute All share sizes doesn't work correctly. Diagnostics attached (if they're at all useful in this case?) We'll look into that, thanks!
January 29, 20179 yr Author Boot Device: Can't explain either. I don't see that issue, ie, boot device shows up fine for me. Open up two tabs to unRaid. Reboot unRaid on one of them and don't touch the other until the system is back up and running. Navigate around the second. Do you get a ton of wrong_csrf errors? Shouldn't because as soon as you refresh the stale tab it will obtain the then-current csrf_token.
January 29, 20179 yr Open up two tabs to unRaid. Reboot unRaid on one of them and don't touch the other until the system is back up and running. Navigate around the second. Do you get a ton of wrong_csrf errors? Shouldn't because as soon as you refresh the stale tab it will obtain the then-current csrf_token. Yeah you're right. On the stale tab you'll get nothing but csrf errors, but as soon as you navigate to a different tab everything starts working correct.
January 29, 20179 yr Bug--- found this: Jan 28 08:17:42 Rose cache_dirs: cache_dirs process ID 8071 started Jan 28 08:17:42 Rose root: Fix Common Problems Version 2017.01.24 Jan 28 08:17:45 Rose emhttp: Starting services... Jan 28 08:17:45 Rose emhttp: nothing to sync Jan 28 08:17:45 Rose root: error: webGui/include/ProcessStatus.php: missing csrf_token Jan 28 08:17:45 Rose root: error: webGui/include/ProcessStatus.php: missing csrf_token Jan 28 08:49:42 Rose kernel: mdcmd (41): spindown 0 Jan 28 08:49:42 Rose kernel: mdcmd (42): spindown 2 Jan 28 08:49:43 Rose kernel: mdcmd (43): spindown 29 Jan 28 08:49:47 Rose kernel: mdcmd (44): spindown 1 Jan 28 08:49:48 Rose kernel: mdcmd (45): spindown 3 Jan 28 09:08:31 Rose sSMTP[27232]: Creating SSL connection to host Jan 28 09:08:31 Rose sSMTP[27232]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256 Jan 28 09:08:33 Rose sSMTP[27232]: Sent mail for [email protected] (221 2.0.0 closing connection c19sm6799946qtc.29 - gsmtp) uid=0 username=root outbytes=626 Jan 28 09:22:11 Rose kernel: kvm: already loaded the other module Jan 28 09:58:27 Rose kernel: mdcmd (46): spindown 1 Jan 28 10:00:03 Rose kernel: mdcmd (47): spindown 2 Attached diagnostics file also. It appears to be from a plugin that has an event at the 'starting_services' event. I'm going to take a wild guess that it is the nerd pack. Look in the /usr/local/emhttp/plugins/NerdPack/events and see if there is a starting_services event? All of your other plugins appear to be the "usual suspects" that I use and have no issues with. You also need to remove the /flash/config/plugin/dynamix.plg. That is no longer needed. I removed the dynamix.plg from the folder, rebooted and the "missing csrf_token" error disappeared. That is another conformation that this old plugin will cause an issue with any version later than 6.3.0-rc9.
January 29, 20179 yr We're looking in to this. Could you please post the SMART data output from your Samsung 950 Pro and Toshiba/OCZ RD400 NVMe drives for us to take a look at? (e.g. smartctl -A /dev/nvme0n1) The Samsung is on my desktop at the moment, but I can boot with unRAID and get a SMART report if it's really needed and someone else doesn't post it before. This is for the Toshiba/OCZ RD 400: smartctl -A /dev/nvme0n1 smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.9.6-unRAID] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF SMART DATA SECTION === Read NVMe SMART/Health Information failed: NVMe Status 0x4002 Do either of these two commands return temperature info for your Toshiba/OCZ RD 400?: smartctl -d scsi -A /dev/nvme0n1 smartctl -d nvme -A /dev/nvme0n1
January 29, 20179 yr Do either of these two commands return temperature info for your Toshiba/OCZ RD 400?: smartctl -d scsi -A /dev/nvme0n1 smartctl -d nvme -A /dev/nvme0n1 Nope, both fail, I guess it's not an easy fix after all, strange that it works on v6.2.
January 29, 20179 yr What about? smartctl -d sat -A /dev/nvme0n1 Also no: smartctl -d sat -A /dev/nvme0n1 smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.9.6-unRAID] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org Read Device Identity failed: Inappropriate ioctl for device A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
January 30, 20179 yr I'm getting an OOM error and one or both of my VMs get killed when running the mover, IIRC this started happening with the last couple of rcs. Server has 32GB of RAM, not using dockers at the moment, there are 2 VMs always running using 4GB each, total memory in use is usually at around 32%, mover was set to run at 2:55AM: Jan 30 02:55:22 Tower7 kernel: cpuload invoked oom-killer: gfp_mask=0x24200ca(GFP_HIGHUSER_MOVABLE), nodemask=0, order=0, oom_score_adj=0 Jan 30 02:55:22 Tower7 kernel: cpuload cpuset=/ mems_allowed=0 Jan 30 02:55:22 Tower7 kernel: CPU: 0 PID: 1860 Comm: cpuload Not tainted 4.9.6-unRAID #1 Jan 30 02:55:22 Tower7 kernel: Hardware name: Supermicro Super Server/X11SSM-F, BIOS 1.0b 12/29/2015 Jan 30 02:55:22 Tower7 kernel: ffffc900059ff880 ffffffff813a33fa ffffc900059ffa68 ffffffff8193cef3 Jan 30 02:55:22 Tower7 kernel: ffffc900059ff900 ffffffff8111eab3 0000000000000000 0000000000000000 Jan 30 02:55:22 Tower7 kernel: ffffffff810b2067 0000000000000000 ffffc900059ff8d8 ffffffff81053fe5 Jan 30 02:55:22 Tower7 kernel: Call Trace: Jan 30 02:55:22 Tower7 kernel: [<ffffffff813a33fa>] dump_stack+0x61/0x7e Jan 30 02:55:22 Tower7 kernel: [<ffffffff8111eab3>] dump_header+0x76/0x20e Jan 30 02:55:22 Tower7 kernel: [<ffffffff810b2067>] ? delayacct_end+0x51/0x5a Jan 30 02:55:22 Tower7 kernel: [<ffffffff81053fe5>] ? has_ns_capability_noaudit+0x34/0x3e Jan 30 02:55:22 Tower7 kernel: [<ffffffff810c7a2a>] oom_kill_process+0x81/0x377 Jan 30 02:55:22 Tower7 kernel: [<ffffffff810c81f3>] out_of_memory+0x3aa/0x3e5 Jan 30 02:55:22 Tower7 kernel: [<ffffffff810cbe82>] __alloc_pages_nodemask+0xb2f/0xc31 Jan 30 02:55:22 Tower7 kernel: [<ffffffff8110358d>] alloc_pages_vma+0x189/0x1e4 Jan 30 02:55:22 Tower7 kernel: [<ffffffff810dacb1>] shmem_alloc_page+0x5c/0x7d Jan 30 02:55:22 Tower7 kernel: [<ffffffff81122a8a>] ? get_empty_filp+0x4e/0x162 Jan 30 02:55:22 Tower7 kernel: [<ffffffff811380c1>] ? setattr_copy+0x9b/0xe0 Jan 30 02:55:22 Tower7 kernel: [<ffffffff810dafdf>] shmem_alloc_and_acct_page+0xd4/0x152 Jan 30 02:55:22 Tower7 kernel: [<ffffffff810db49a>] shmem_getpage_gfp+0x43d/0x9a5 Jan 30 02:55:22 Tower7 kernel: [<ffffffff810dbbe3>] shmem_getpage+0x16/0x18 Jan 30 02:55:22 Tower7 kernel: [<ffffffff810dbc23>] shmem_write_begin+0x3e/0x40 Jan 30 02:55:22 Tower7 kernel: [<ffffffff810c49d4>] generic_perform_write+0xd0/0x17a Jan 30 02:55:22 Tower7 kernel: [<ffffffff810c5ac6>] __generic_file_write_iter+0xcc/0x172 Jan 30 02:55:22 Tower7 kernel: [<ffffffff810c5c77>] generic_file_write_iter+0x10b/0x160 Jan 30 02:55:22 Tower7 kernel: [<ffffffff81120be7>] __vfs_write+0xc3/0xec Jan 30 02:55:22 Tower7 kernel: [<ffffffff811215ce>] vfs_write+0xcd/0x176 Jan 30 02:55:22 Tower7 kernel: [<ffffffff811222a9>] SyS_write+0x49/0x83 Jan 30 02:55:22 Tower7 kernel: [<ffffffff8167ce37>] entry_SYSCALL_64_fastpath+0x1a/0xa9 Jan 30 02:55:22 Tower7 kernel: Mem-Info: Jan 30 02:55:22 Tower7 kernel: active_anon:2487715 inactive_anon:16989 isolated_anon:0 Jan 30 02:55:22 Tower7 kernel: active_file:5064310 inactive_file:408609 isolated_file:128 Jan 30 02:55:22 Tower7 kernel: unevictable:0 dirty:416267 writeback:0 unstable:0 Jan 30 02:55:22 Tower7 kernel: slab_reclaimable:40726 slab_unreclaimable:30017 Jan 30 02:55:22 Tower7 kernel: mapped:13084 shmem:122944 pagetables:7034 bounce:0 Jan 30 02:55:22 Tower7 kernel: free:67697 free_pcp:186 free_cma:0 Jan 30 02:55:22 Tower7 kernel: Node 0 active_anon:9950860kB inactive_anon:67956kB active_file:20257240kB inactive_file:1634436kB unevictable:0kB isolated(anon):0kB isolated(file):512kB mapped:52336kB dirty:1665068kB writeback:0kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 9377792kB anon_thp: 491776kB writeback_tmp:0kB unstable:0kB pages_scanned:33122412 all_unreclaimable? yes Jan 30 02:55:22 Tower7 kernel: Node 0 DMA free:15864kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15960kB managed:15876kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:12kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Jan 30 02:55:22 Tower7 kernel: lowmem_reserve[]: 0 1832 31909 31909 Jan 30 02:55:22 Tower7 kernel: Node 0 DMA32 free:127948kB min:7756kB low:9692kB high:11628kB active_anon:21880kB inactive_anon:4kB active_file:1651528kB inactive_file:177524kB unevictable:0kB writepending:180844kB present:2033580kB managed:2023600kB mlocked:0kB slab_reclaimable:32384kB slab_unreclaimable:5148kB kernel_stack:160kB pagetables:64kB bounce:0kB free_pcp:248kB local_pcp:0kB free_cma:0kB Jan 30 02:55:22 Tower7 kernel: lowmem_reserve[]: 0 0 30077 30077 Jan 30 02:55:22 Tower7 kernel: Node 0 Normal free:126976kB min:127344kB low:159180kB high:191016kB active_anon:9928980kB inactive_anon:67952kB active_file:18605712kB inactive_file:1456768kB unevictable:0kB writepending:1484224kB present:31322112kB managed:30799232kB mlocked:0kB slab_reclaimable:130520kB slab_unreclaimable:114908kB kernel_stack:7840kB pagetables:28072kB bounce:0kB free_pcp:496kB local_pcp:24kB free_cma:0kB Jan 30 02:55:22 Tower7 kernel: lowmem_reserve[]: 0 0 0 0 Jan 30 02:55:22 Tower7 kernel: Node 0 DMA: 0*4kB 1*8kB (U) 1*16kB (U) 1*32kB (U) 1*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 3*4096kB (M) = 15864kB Jan 30 02:55:22 Tower7 kernel: Node 0 DMA32: 893*4kB (UM) 413*8kB (U) 3743*16kB (UMEH) 542*32kB (UMEH) 125*64kB (UME) 22*128kB (UME) 21*256kB (M) 26*512kB (UM) 8*1024kB (M) 3*2048kB (M) 0*4096kB = 127948kB Jan 30 02:55:22 Tower7 kernel: Node 0 Normal: 3726*4kB (UME) 537*8kB (UME) 304*16kB (UE) 360*32kB (UMEH) 260*64kB (UME) 188*128kB (UME) 118*256kB (UME) 34*512kB (UM) 1*1024kB (U) 1*2048kB (M) 0*4096kB = 126976kB Jan 30 02:55:22 Tower7 kernel: 5596000 total pagecache pages Jan 30 02:55:22 Tower7 kernel: 0 pages in swap cache Jan 30 02:55:22 Tower7 kernel: Swap cache stats: add 0, delete 0, find 0/0 Jan 30 02:55:22 Tower7 kernel: Free swap = 0kB Jan 30 02:55:22 Tower7 kernel: Total swap = 0kB Jan 30 02:55:22 Tower7 kernel: 8342913 pages RAM Jan 30 02:55:22 Tower7 kernel: 0 pages HighMem/MovableOnly Jan 30 02:55:22 Tower7 kernel: 133236 pages reserved Jan 30 02:55:22 Tower7 kernel: [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name Jan 30 02:55:22 Tower7 kernel: [ 1378] 0 1378 5040 719 13 3 0 -1000 udevd Jan 30 02:55:22 Tower7 kernel: [ 1626] 0 1626 59436 578 25 3 0 0 rsyslogd Jan 30 02:55:22 Tower7 kernel: [ 1769] 81 1769 4900 60 14 3 0 0 dbus-daemon Jan 30 02:55:22 Tower7 kernel: [ 1777] 1 1777 3342 519 10 3 0 0 rpcbind Jan 30 02:55:22 Tower7 kernel: [ 1782] 32 1782 5352 1455 15 3 0 0 rpc.statd Jan 30 02:55:22 Tower7 kernel: [ 1792] 0 1792 1619 393 7 4 0 0 inetd Jan 30 02:55:22 Tower7 kernel: [ 1801] 0 1801 6120 670 16 3 0 -1000 sshd Jan 30 02:55:22 Tower7 kernel: [ 1815] 0 1815 24545 1173 21 3 0 0 ntpd Jan 30 02:55:22 Tower7 kernel: [ 1822] 0 1822 1095 29 7 3 0 0 acpid Jan 30 02:55:22 Tower7 kernel: [ 1831] 0 1831 1621 419 8 3 0 0 crond Jan 30 02:55:22 Tower7 kernel: [ 1833] 0 1833 1618 347 8 3 0 0 atd Jan 30 02:55:22 Tower7 kernel: [ 1839] 0 1839 55384 1448 103 4 0 0 nmbd Jan 30 02:55:22 Tower7 kernel: [ 1841] 0 1841 74644 3888 142 4 0 0 smbd Jan 30 02:55:22 Tower7 kernel: [ 1842] 0 1842 73063 1138 136 4 0 0 smbd-notifyd Jan 30 02:55:22 Tower7 kernel: [ 1843] 0 1843 73067 1087 136 4 0 0 cleanupd Jan 30 02:55:22 Tower7 kernel: [ 1848] 0 1848 68146 1815 128 3 0 0 winbindd Jan 30 02:55:22 Tower7 kernel: [ 1850] 0 1850 68147 1723 129 3 0 0 winbindd Jan 30 02:55:22 Tower7 kernel: [ 1860] 0 1860 2383 591 9 3 0 0 cpuload Jan 30 02:55:22 Tower7 kernel: [ 2910] 0 2910 2929 573 10 3 0 0 autofan Jan 30 02:55:22 Tower7 kernel: [ 8519] 0 8519 22474 954 17 3 0 0 emhttp Jan 30 02:55:22 Tower7 kernel: [ 8550] 0 8550 1627 404 8 3 0 0 agetty Jan 30 02:55:22 Tower7 kernel: [ 8551] 0 8551 1627 398 8 3 0 0 agetty Jan 30 02:55:22 Tower7 kernel: [ 8552] 0 8552 1627 396 8 3 0 0 agetty Jan 30 02:55:22 Tower7 kernel: [ 8553] 0 8553 1627 412 8 3 0 0 agetty Jan 30 02:55:22 Tower7 kernel: [ 8554] 0 8554 1627 415 8 3 0 0 agetty Jan 30 02:55:22 Tower7 kernel: [ 8555] 0 8555 1627 390 8 3 0 0 agetty Jan 30 02:55:22 Tower7 kernel: [ 8601] 0 8601 20203 66 13 4 0 0 apcupsd Jan 30 02:55:22 Tower7 kernel: [ 8624] 61 8624 8623 607 21 3 0 0 avahi-daemon Jan 30 02:55:22 Tower7 kernel: [ 8625] 61 8625 8557 63 21 3 0 0 avahi-daemon Jan 30 02:55:22 Tower7 kernel: [ 8633] 0 8633 3185 26 11 3 0 0 avahi-dnsconfd Jan 30 02:55:22 Tower7 kernel: [ 8939] 0 8939 38321 128 17 4 0 0 shfs Jan 30 02:55:22 Tower7 kernel: [ 8949] 0 8949 527341 3134 84 5 0 0 shfs Jan 30 02:55:22 Tower7 kernel: [ 9036] 0 9036 3457 1338 10 3 0 0 cache_dirs Jan 30 02:55:22 Tower7 kernel: [ 9568] 0 9568 18821 841 38 3 0 0 virtlockd Jan 30 02:55:22 Tower7 kernel: [ 9574] 0 9574 35734 958 41 4 0 0 virtlogd Jan 30 02:55:22 Tower7 kernel: [ 9589] 0 9589 203012 3191 88 3 0 0 libvirtd Jan 30 02:55:22 Tower7 kernel: [ 9724] 99 9724 4378 509 13 3 0 0 dnsmasq Jan 30 02:55:22 Tower7 kernel: [ 9725] 0 9725 4345 53 12 3 0 0 dnsmasq Jan 30 02:55:22 Tower7 kernel: [14216] 0 14216 1277617 1196801 2523 8 0 0 qemu-system-x86 Jan 30 02:55:22 Tower7 kernel: [14771] 0 14771 1266824 1178993 2441 8 0 0 qemu-system-x86 Jan 30 02:55:22 Tower7 kernel: [16490] 0 16490 103483 4444 174 4 0 0 smbd Jan 30 02:55:22 Tower7 kernel: [16491] 0 16491 68146 1004 127 3 0 0 winbindd Jan 30 02:55:22 Tower7 kernel: [21510] 99 21510 105342 6016 180 4 0 0 smbd Jan 30 02:55:22 Tower7 kernel: [23403] 0 23403 1090 172 6 3 0 0 sleep Jan 30 02:55:22 Tower7 kernel: [26064] 0 26064 2374 640 9 3 0 0 sh Jan 30 02:55:22 Tower7 kernel: [26067] 0 26067 2397 673 9 3 0 0 mover Jan 30 02:55:22 Tower7 kernel: [26071] 0 26071 1087 183 6 3 0 0 move Jan 30 02:55:22 Tower7 kernel: [26087] 0 26087 3039 560 10 3 0 0 rsync Jan 30 02:55:22 Tower7 kernel: [26088] 0 26088 2944 378 10 3 0 0 rsync Jan 30 02:55:22 Tower7 kernel: [26089] 0 26089 3009 357 10 3 0 0 rsync Jan 30 02:55:22 Tower7 kernel: [26306] 0 26306 1090 185 7 3 0 0 sleep Jan 30 02:55:22 Tower7 kernel: [26336] 0 26336 43375 5053 75 4 0 0 php Jan 30 02:55:22 Tower7 kernel: [26338] 0 26338 42656 2936 70 3 0 0 notify Jan 30 02:55:22 Tower7 kernel: Out of memory: Kill process 14216 (qemu-system-x86) score 146 or sacrifice child Jan 30 02:55:22 Tower7 kernel: Killed process 14216 (qemu-system-x86) total-vm:5110468kB, anon-rss:4770032kB, file-rss:24kB, shmem-rss:17148kB Jan 30 02:55:22 Tower7 kernel: oom_reaper: reaped process 14216 (qemu-system-x86), now anon-rss:0kB, file-rss:20kB, shmem-rss:24kB Jan 30 02:55:22 Tower7 kernel: ------------[ cut here ]------------ Jan 30 02:55:22 Tower7 kernel: WARNING: CPU: 1 PID: 14216 at arch/x86/mm/pat.c:1023 untrack_pfn+0x69/0xaa Jan 30 02:55:22 Tower7 kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables iptable_filter ip_tables vhost_net tun vhost macvtap macvlan md_mod ipmi_devintf mlx4_en mlx4_core igb ptp pps_core fbcon ast bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font ttm x86_pkg_temp_thermal coretemp drm_kms_helper cfbfillrect kvm_intel cfbimgblt cfbcopyarea drm kvm agpgart syscopyarea i2c_i801 sysfillrect i2c_smbus sysimgblt fb_sys_fops i2c_algo_bit fb nvme fbdev i2c_core nvme_core mpt3sas ahci libahci r8169 raid_class scsi_transport_sas mii ipmi_si video backlight [last unloaded: mlx4_core] Jan 30 02:55:22 Tower7 kernel: CPU: 1 PID: 14216 Comm: qemu-system-x86 Not tainted 4.9.6-unRAID #1 Jan 30 02:55:22 Tower7 kernel: Hardware name: Supermicro Super Server/X11SSM-F, BIOS 1.0b 12/29/2015 Jan 30 02:55:22 Tower7 kernel: ffffc900096dfa58 ffffffff813a33fa 0000000000000000 ffffffff81935f52 Jan 30 02:55:22 Tower7 kernel: ffffc900096dfa98 ffffffff8104d04c 000003ff10d02678 ffff880810e74508 Jan 30 02:55:22 Tower7 kernel: 00002ac519f8b000 00002ac519f8a000 ffffc900096dfb60 ffffc900096dfb60 Jan 30 02:55:22 Tower7 kernel: Call Trace: Jan 30 02:55:22 Tower7 kernel: [<ffffffff813a33fa>] dump_stack+0x61/0x7e Jan 30 02:55:22 Tower7 kernel: [<ffffffff8104d04c>] __warn+0xb8/0xd3 Jan 30 02:55:22 Tower7 kernel: [<ffffffff8104d114>] warn_slowpath_null+0x18/0x1a Jan 30 02:55:22 Tower7 kernel: [<ffffffff81046360>] untrack_pfn+0x69/0xaa Jan 30 02:55:22 Tower7 kernel: [<ffffffff810eadc1>] unmap_single_vma+0x4e/0x72 Jan 30 02:55:22 Tower7 kernel: [<ffffffff810eb056>] unmap_vmas+0x51/0x7e Jan 30 02:55:22 Tower7 kernel: [<ffffffff810f1d94>] exit_mmap+0x71/0x10c Jan 30 02:55:22 Tower7 kernel: [<ffffffff8110bd20>] ? kmem_cache_free+0x15f/0x164 Jan 30 02:55:22 Tower7 kernel: [<ffffffff8110bd20>] ? kmem_cache_free+0x15f/0x164 Jan 30 02:55:22 Tower7 kernel: [<ffffffff8104a9fc>] mmput+0x48/0xec Jan 30 02:55:22 Tower7 kernel: [<ffffffffa001ea0b>] vhost_dev_cleanup+0x351/0x361 [vhost] Jan 30 02:55:22 Tower7 kernel: [<ffffffffa00328ce>] vhost_net_release+0x3a/0xf5 [vhost_net] Jan 30 02:55:22 Tower7 kernel: [<ffffffff811228b8>] __fput+0xed/0x19f Jan 30 02:55:22 Tower7 kernel: [<ffffffff81122996>] ____fput+0x9/0xb Jan 30 02:55:22 Tower7 kernel: [<ffffffff81062569>] task_work_run+0x6a/0x7d Jan 30 02:55:22 Tower7 kernel: [<ffffffff81050163>] do_exit+0x3ae/0x86a Jan 30 02:55:22 Tower7 kernel: [<ffffffff81050687>] do_group_exit+0x3c/0x98 Jan 30 02:55:22 Tower7 kernel: [<ffffffff81058024>] get_signal+0x47e/0x4b0 Jan 30 02:55:22 Tower7 kernel: [<ffffffff8101e446>] do_signal+0x23/0x4a5 Jan 30 02:55:22 Tower7 kernel: [<ffffffff81131c00>] ? do_sys_poll+0x388/0x481 Jan 30 02:55:22 Tower7 kernel: [<ffffffff81130b1e>] ? poll_select_copy_remaining+0xe6/0xfe Jan 30 02:55:22 Tower7 kernel: [<ffffffff81002b09>] exit_to_usermode_loop+0x3a/0x81 Jan 30 02:55:22 Tower7 kernel: [<ffffffff81002c61>] syscall_return_slowpath+0x44/0x47 Jan 30 02:55:22 Tower7 kernel: [<ffffffff8167cec4>] entry_SYSCALL_64_fastpath+0xa7/0xa9 Jan 30 02:55:22 Tower7 kernel: ---[ end trace c09dcb38baeb7750 ]--- Jan 30 02:55:22 Tower7 kernel: virbr0: port 2(vnet0) entered disabled state Jan 30 02:55:22 Tower7 kernel: device vnet0 left promiscuous mode Jan 30 02:55:22 Tower7 kernel: virbr0: port 2(vnet0) entered disabled state Jan 30 02:55:24 Tower7 ntpd[1815]: Deleting interface #4 virbr0, 192.168.122.1#123, interface stats: received=0, sent=0, dropped=0, active_time=150378 secs Jan 30 02:55:24 Tower7 kernel: pci-stub 0000:01:00.0: claimed by stub Jan 30 03:04:31 Tower7 move: rmdir: /mnt/cache/./Downloads Directory not empty Jan 30 04:05:40 Tower7 kernel: mdcmd (53): spindown 0 Jan 30 04:05:41 Tower7 kernel: mdcmd (54): spindown 1 Full diags below, some mover lines removed to make the syslog smaller. tower7-diagnostics-20170130-1247.zip
January 30, 20179 yr unRAID has stopped loading in "dashboard" type web apps since RC9. Tried on both the LSIO Muximux docker and Organizr, neither of them load the page where they would previously.
January 30, 20179 yr Third time I get disk issues on my SASLP cards.. I am getting responses from people telling me there might be something wrong with the latest RC's wrt this.. I cannot phantom the technical details, but following thread shows my issues: http://lime-technology.com/forum/index.php?topic=56052.0
January 30, 20179 yr Starting with 6.3.0-rc9, we have made numerous changes to harden the unRAID OS webGui against XSS and CSRF vulnerabilities. In addition we have introduced a server-generated variable called csrf_token which must now be included in all POST requests. This is great news! Huge thanks to LT and all the plugin authors for implementing this!
February 1, 20179 yr Getting some errors in the log, system seems to be working hunky dory though Feb 1 08:55:30 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 08:55:30 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 09:07:29 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 09:07:29 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 09:59:42 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 09:59:42 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 11:13:00 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 11:13:00 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 13:22:14 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 13:22:14 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set lspci 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) Note this is whilst my Unraid VM running, so I think it's something to do with virtualisation. No real reason for assuming that other than these links below. https://forums.gentoo.org/viewtopic-t-1042686-start-0.html https://forums.virtualbox.org/viewtopic.php?f=7&t=51143 EDIT: May be wrong, with no VM running, same thing, although searching around the topic, IOMMU seems to be a recurring thing. Feb 1 18:54:38 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 18:54:38 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 19:46:48 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 19:46:48 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 20:23:24 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 20:23:24 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 20:23:24 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 20:23:24 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 20:43:13 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 20:43:13 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 20:59:06 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 20:59:06 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 20:59:49 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 20:59:49 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 21:33:59 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 21:33:59 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set Feb 1 23:05:37 tower kernel: DMAR: DRHD: handling fault status reg 3 Feb 1 23:05:37 tower kernel: DMAR: [DMA Write] Request device [03:00.0] fault addr ec1a3000 [fault reason 05] PTE Write access is not set
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.