July 4, 20179 yr 19 minutes ago, GoChris said: Which frankly these RC's have been. As long as new features are being added, it's a beta IMO. While the rc's might appear to be more beta than rc, they are not really changing the underlying NAS functionality. Most of the issues being addressed in the rc's are related to the UI. You have to appreciate that a major change in the Linux version will have to be tested completely by LT for reliability and stability. I don't think this is an easy task, nor is it good use of their time. LT prides themselves on the stability and reliability of unRAID and I applaud that. If there is a new "have to have" feature in the latest LInux, it will eventually be included in unRAID. unRAID is not "bleeding edge", nor should it be. Edited July 4, 20179 yr by dlandon
July 4, 20179 yr Yes we're in agreement. I want a stable release so I can upgrade to get the new features. I don't think new features should be added to an RC. I will concede that UI features aren't like NAS features so sure they are more RC than beta, and these RCs are more true to the definition that past versions have been. I'm certainly looking forward to 6.4 stable.
July 4, 20179 yr I've been using 6.4 since the rc's first appeared and it is by far the best release of unRAID I've seen in the years I've been an unRAID user. I started back in the V4 days. unRAID has come a long way since then and it is just getting better. I know some are anxious about some new and fancy feature that is included in the latest Linux, but it will happen in unRAID in due time as the Linux versions become stable. LT, kudos on the UEFI boot. I have had some fleeting hardware issues (disable interrupt 18, USB failures, etc) that are totally gone now that I boot in UEFI. I understand that UEFI boot does a much better job at handling hardware than legacy boot. Another great job!
July 4, 20179 yr 41 minutes ago, Dephcon said: Ryzen support was added in 4.10 so we're good on that front. It's only the IOMMU optimizations for Ryzen in 4.12 that's an improvement over 4.11... which is only really useful for those doing wiz-bang VM pass-though stuff. With 8 core Ryzens I can imagine a lot of people want to do passthru
July 4, 20179 yr For me on RC6 the vnc remove (noVNC) is broken. My unraid IP is 192.168.24.4 but it tries to connect to a 169.254.138.80. If I downgrade back to 6.3 it works just fine. Edit: I did google the 1006 error on the forum, loading the webpage on a incognito window dint solve the issue. Edited July 4, 20179 yr by hcgonzalezpr
July 5, 20178 yr 6 minutes ago, Krzaku said: Please, can we go back to the narrow UI? It looks ridiculous now. Fixed in next release.
July 5, 20178 yr On 7/4/2017 at 5:27 PM, Dephcon said: Ryzen support was added in 4.10 so we're good on that front. It's only the IOMMU optimizations for Ryzen in 4.12 that's an improvement over 4.11... which is only really useful for those doing wiz-bang VM pass-though stuff. I don't agree with this statement. There's still a unRAID specific bug that makes Ryzen systems crash intermittently unless C-States are disabled in the BIOS. This causes high idle power usage (>100W) because the CPU never clocks down.
July 5, 20178 yr Author 3 hours ago, lionceau said: I don't agree with this statement. There's still a unRAID specific bug that makes Ryzen systems crash intermittently unless C-States are disabled in the BIOS. This causes high idle power usage (>100W) because the CPU never clocks down. Please add link to this issue.
July 6, 20178 yr 7 hours ago, limetech said: Please add link to this issue. Gladly, there are many reports of this in the large Ryzen thread. Thank you for looking into it. There's also an ongoing issue with Nested Page Table performance with KVM and the Zen platform. Disabling it impacts CPU/memory performance negatively, enabling it degrades GPU performance. This does not happen in Xen so that ball is in the KVM maintainer's court. They've recently acknowledged that NPT with AMD needs work but don't have the time to fix it. More details can be found in this thread: http://www.spinics.net/lists/kvm/msg152343.html Once both of these issues (unRAID-specific C-State crashing and KVM NPT bugfix) are resolved, Ryzen will a great alternative to Intel for unRAID. Edited July 6, 20178 yr by lionceau
July 6, 20178 yr that clear i think ryzen need updates from KVM , UnRaid and also linux kernel support , improvement and fix issues . from my side i 'am still need waiting more time before i decide to build my unraid server . Good Lucks .
July 6, 20178 yr 17 hours ago, lionceau said: I don't agree with this statement. There's still a unRAID specific bug that makes Ryzen systems crash intermittently unless C-States are disabled in the BIOS. This causes high idle power usage (>100W) because the CPU never clocks down. Since it is my system that is being quoted for power usage, I would like to offer a clarification on the impact of C-States on power consumption. I also performed most of the discovery testing on Ryzen stability issues, so below is a synopsis of my findings. Yes, there is an unRAID specific bug that causes Ryzen based systems to crash unless "Global C-State Control" is disabled in the BIOS. The bug seems to be related to an idle CPU going into power saving C-States, and "heavy" users who have lots of VM's running (especially Windows VMs) seem to have fewer issues as their CPU cores are less idle. We have not been able to determine if it is the act of going into a higher C-State (entering a power save mode), or the act of coming out of a higher C-State (returning to a performance mode), that is the problem. Disabling C6 was not enough, and the only workaround that has worked is completely disabling C-States via the "Global C-State Control". Various tests have been performed that have eliminated the Linux kernel as the culprit. Even pre-4.9 versions of the Linux kernel do not experience this issue, and Win10 does not experience this issue. Various flavors of Linux have been tested, and all have performed flawlessly. Whatever the issue is, it only occurs on unRAID, and the root cause is most likely in the "secret sauce" that makes unRAID so special, though I suppose it could be just a build parameter or something innocuous. unRAID plugins have also been eliminated as a root cause, as even running in Safe Mode, unRAID systems will crash when idle on a Ryzen system if C-States are enabled. The latest unRAID releases, including 6.4.0-rc6, have had no effect on the issue. Similarly, BIOS versions have had no impact on the issue, not even with the latest AGESA 1.0.0.6 code updates. For whatever reason, my system appears to be an excellent "canary in a coal mine" system, as it will consistently crash within a few hours with C-States enabled, quicker than most other Ryzen adopters. My system is typically idle, with no VM's running, which may be a contributing factor. Those "heavy" users with lots of VM's running can often go many days or even weeks, but eventually they too observe a crash with C-States enabled. With Global C-State Control disabled, my system has achieved 72 days of up-time, a streak that only ended so I could apply BIOS and unRAID upgrades. Disabling Global C-State Control is not a perfect solution, however, is it comes with increased idle power usage and heat, may reduce performance (due to heat related throttling), and shortens UPS up-time due to higher idle power consumption. On my system, with C-States enabled, I idle at about 108 watts (+/-5w), with CPU temps in the low 30's. With Global C-States disabled, I idle closer to 126w (again, +/-5w), with CPU temps in the low 40's. That represents a power consumption increase of somewhere between 8 and 28 watts, mostly consumed by the CPU, but some by the cooling system working harder. I know a 108w idle, even under ideal conditions, sounds high, but that is primarily due to my choice of a power hungry SATA controller card, 18 drives, and a pro-grade server case with powerful fans and SAS back-planes, without all of which I have seen my motherboard idle as low as 38w with C-States enabled, and 45-55w without. So disabling C-States does not give you >100w idle power consumption, but does significantly increase power consumption all the same. Last thought, especially for those considering Threadripper: The issues described here may be up to 2x worse on Threadripper, as combining two 8-core Ryzen CPUs into a single 16-core Threadripper, and bumping the TDP up from 95w to 155w (or maybe even 180w), will only amplify the power consumption/heat effects of disabling C-States. I'm very excited for Threadripper, but I advise a wait-and-see approach for Threadripper on unRAID. Hope the above helps clarify the situation. For those of us enjoying Ryzen unRAID systems, we are having great success with C-States disabled, but with the obvious impact of increased power consumption and heat. The fact that we have found this 'workaround' has probably shielded this issue from Limetech's awareness, but to be clear, the current situation is not ideal. Paul
July 6, 20178 yr Author 1 hour ago, Pauven said: Whatever the issue is, it only occurs on unRAID, and the root cause is most likely in the "secret sauce" that makes unRAID so special, though I suppose it could be just a build parameter or something innocuous. Thank you for the report. In regards to the linux kernel, unRAID OS isn't really special, other than we tend to only turn on options which we think need to be turned on in order to minimize the kernel memory footprint. In the area of Power Management however we have just about everything turned on (and have for several releases). The thread is giant, can you give me a "tldr" summary? In particular, what is the nature of the crash? Are there any syslogs, diags, screenshots, etc available?
July 6, 20178 yr Author 9 hours ago, lionceau said: There's also an ongoing issue with Nested Page Table performance with KVM This is some kind of kernel/kvm issue. You can follow progress in a large thread starting here with a post that defines the issue: http://www.spinics.net/lists/kvm/msg152133.html As you can see, top men are working on it.
July 6, 20178 yr 18 minutes ago, limetech said: This is some kind of kernel/kvm issue. You can follow progress in a large thread starting here with a post that defines the issue: http://www.spinics.net/lists/kvm/msg152133.html As you can see, top men are working on it. top men note: delete this if you must, but this post required this response
July 6, 20178 yr 40 minutes ago, limetech said: Thank you for the report. In regards to the linux kernel, unRAID OS isn't really special, other than we tend to only turn on options which we think need to be turned on in order to minimize the kernel memory footprint. In the area of Power Management however we have just about everything turned on (and have for several releases). The thread is giant, can you give me a "tldr" summary? In particular, what is the nature of the crash? Are there any syslogs, diags, screenshots, etc available? Yeah, the thread has grown really big, and covers a lot more than just this issue. I had to go back and re-read all my own posts to recall some of the details... The crash is always a hard freeze, sometimes with a reboot. I've never been able to capture anything in the log files: not through writing the log file to the flash drive; not through tailing the log over telnet; and not by tailing the log on the console. It simply hangs so fast and hard, that nothing is ever output related to the crash. I have seen one interesting message on the console that sometimes (but rarely, <10% of the time) appeared at some point before a crash: "Hangcheck: hangcheck value past margin!", often repeated over and over and over. On at least one occasion, I discovered the Hangcheck error was on the console while the server was still running. I'm not sure that this was indicative of the hang/crash issue we are discussing, and certainly this might have been an unrelated issue. [Side note (and most likely unrelated): the console would hang on Ryzen on unRAID 6.3.x, even quicker than the server would crash, typically within 15-30 minutes. The console would still display output (console messages), and the server would still be operational, but the console would be unresponsive to any input. Telnet was unaffected. The Global C-State Control fix did not resolve this issue. I just checked, and 6.4.0-rc6 doesn't seem to have this issue, so yay!] On the reboot, a Machine Check Exception (MCE) error is often reported. Though you can see the error indicated in the unRAID log files at boot-up, I was never able to view any error details in unRAID, but when I configured my server to reboot into Windows after a crash, I was able to see the MCE details in Windows, where it complained of a Cache Hierarchy Error: Quote I have experienced many of these errors, all identical except for the APIC ID: A fatal hardware error has occurred. Reported by component: Processor Core Error Source: Machine Check Exception Error Type: Cache Hierarchy Error Processor APIC ID: 6 The details view of this entry contains further information. Not exactly sure how it works, but it seems that for MCE's, the error is captured in the CPU or BIOS, and presented to the OS on the next reboot. That's how I was able to see details in Windows about a MCE that occurred in unRAID. I've provided diagnostics a few times in the thread, though I doubt any would be of help. See here for one: https://forums.lime-technology.com/topic/55150-anybody-planning-a-ryzen-build/?do=findComment&comment=547283 I'm not sure that the MCE info is faithfully reporting the root cause. I think a MCE for a Cache Hierarchy Error is more likely a symptom. Since disabling C-States effectively prevents the error, I think that is the biggest lead in finding the root cause. I haven't seen anyone else post more detail, though most have described the same crashes and workaround/solution. If anyone else has details to share, please step up. Since my system is so eager to crash, if there are any specific tests you would like me to perform, I'm available. Perhaps there is a debug version of unRAID you can share that might capture more detail than I've been able to provide. Paul
July 8, 20178 yr I have not been able to catch anything logging wise when I'm running with C-State enabled, but when it was enabled the system does crash. I tried it again after the last bios update and same issue occurred which is the system crashes while I'm not looking. With it disabled I've had uptime of weeks and I'm the one choosing to reboot.
July 9, 20178 yr Call Traces found .. And a LOT of them... I do not notice anything that is breaking down.. I got notified by "Common problems" Jun 28 04:00:57 Tower kernel: WARNING: CPU: 6 PID: 18186 at arch/x86/events/intel/ds.c:334 reserve_ds_buffers+0x124/0x38b Jun 28 04:00:57 Tower kernel: alloc_bts_buffer: BTS buffer allocation failure Jun 28 04:00:57 Tower kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables ip6table_filter ip6_tables vhost_net tun vhost tap macvlan xt_nat veth ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat xfs md_mod bonding e1000e ptp pps_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm intel_cstate intel_uncore mpt3sas i2c_i801 intel_rapl_perf i2c_core raid_class ipmi_si scsi_transport_sas video ahci libahci backlight thermal button fan [last unloaded: pps_core] Jun 28 04:00:57 Tower kernel: CPU: 6 PID: 18186 Comm: CPU 0/KVM Not tainted 4.11.6-unRAID #2 Jun 28 04:00:57 Tower kernel: Hardware name: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.0b 09/17/2012 Jun 28 04:00:57 Tower kernel: Call Trace: Jun 28 04:00:57 Tower kernel: dump_stack+0x61/0x7e Jun 28 04:00:57 Tower kernel: __warn+0xb8/0xd3 Jun 28 04:00:57 Tower kernel: warn_slowpath_fmt+0x46/0x4e Jun 28 04:00:57 Tower kernel: ? __kmalloc_node+0x22/0x135 Jun 28 04:00:57 Tower kernel: reserve_ds_buffers+0x124/0x38b Jun 28 04:00:57 Tower kernel: x86_reserve_hardware+0x136/0x153 Jun 28 04:00:57 Tower kernel: x86_pmu_event_init+0x49/0x1aa Jun 28 04:00:57 Tower kernel: perf_try_init_event+0x41/0x71 Jun 28 04:00:57 Tower kernel: perf_event_alloc+0x435/0x766 Jun 28 04:00:57 Tower kernel: ? reprogram_counter+0x54/0x54 [kvm] Jun 28 04:00:57 Tower kernel: perf_event_create_kernel_counter+0x24/0x120 Jun 28 04:00:57 Tower kernel: pmc_reprogram_counter+0xc7/0x10c [kvm] Jun 28 04:00:57 Tower kernel: reprogram_fixed_counter+0xc8/0xd9 [kvm] Jun 28 04:00:57 Tower kernel: reprogram_counter+0x4f/0x54 [kvm] Jun 28 04:00:57 Tower kernel: kvm_pmu_handle_event+0x6f/0x8d [kvm] Jun 28 04:00:57 Tower kernel: kvm_arch_vcpu_ioctl_run+0x64a/0xff8 [kvm] Jun 28 04:00:57 Tower kernel: ? kvm_arch_vcpu_load+0xe3/0x196 [kvm] Jun 28 04:00:57 Tower kernel: kvm_vcpu_ioctl+0x16c/0x483 [kvm] Jun 28 04:00:57 Tower kernel: ? do_futex+0xe2/0x86e Jun 28 04:00:57 Tower kernel: vfs_ioctl+0x13/0x2f Jun 28 04:00:57 Tower kernel: do_vfs_ioctl+0x4df/0x4f2 Jun 28 04:00:57 Tower kernel: ? __fget+0x72/0x7e Jun 28 04:00:57 Tower kernel: SyS_ioctl+0x3e/0x5c Jun 28 04:00:57 Tower kernel: entry_SYSCALL_64_fastpath+0x1a/0xa9 Jun 28 04:00:57 Tower kernel: RIP: 0033:0x2b99a2316337 Jun 28 04:00:57 Tower kernel: RSP: 002b:00002b99a6612988 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Jun 28 04:00:57 Tower kernel: RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00002b99a2316337 Jun 28 04:00:57 Tower kernel: RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000012 Jun 28 04:00:57 Tower kernel: RBP: 00002b99a5fa9140 R08: 000055f8f68f85b0 R09: 000000003b9aca00 Jun 28 04:00:57 Tower kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Jun 28 04:00:57 Tower kernel: R13: 00002b999ddf3000 R14: 0000000000000000 R15: 00002b99a5fa9140 Jun 28 04:00:57 Tower kernel: ---[ end trace 7c7fe78e9becbc41 ]--- Jun 28 04:00:57 Tower kernel: CPU 0/KVM: page allocation failure: order:4, mode:0x160c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO|__GFP_NOTRACK), nodemask=(null) Jun 28 04:00:57 Tower kernel: CPU 0/KVM cpuset=vcpu0 mems_allowed=0 Jun 28 04:00:57 Tower kernel: CPU: 6 PID: 18186 Comm: CPU 0/KVM Tainted: G W 4.11.6-unRAID #2 Jun 28 04:00:57 Tower kernel: Hardware name: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.0b 09/17/2012 Jun 28 04:00:57 Tower kernel: Call Trace: Jun 28 04:00:57 Tower kernel: dump_stack+0x61/0x7e Jun 28 04:00:57 Tower kernel: warn_alloc+0xdf/0x158 Jun 28 04:00:57 Tower kernel: ? __alloc_pages_direct_compact+0x4f/0xe3 Jun 28 04:00:57 Tower kernel: __alloc_pages_nodemask+0xb0d/0xc01 Jun 28 04:00:57 Tower kernel: ? vprintk_func+0x45/0x47 Jun 28 04:00:57 Tower kernel: ? __warn+0xc7/0xd3 Jun 28 04:00:57 Tower kernel: kmalloc_large_node+0x54/0x82 Jun 28 04:00:57 Tower kernel: __kmalloc_node+0x22/0x135 Jun 28 04:00:57 Tower kernel: reserve_ds_buffers+0x2dd/0x38b Jun 28 04:00:57 Tower kernel: x86_reserve_hardware+0x136/0x153 Jun 28 04:00:57 Tower kernel: x86_pmu_event_init+0x49/0x1aa Jun 28 04:00:57 Tower kernel: perf_try_init_event+0x41/0x71 Jun 28 04:00:57 Tower kernel: perf_event_alloc+0x435/0x766 Jun 28 04:00:57 Tower kernel: ? reprogram_counter+0x54/0x54 [kvm] Jun 28 04:00:57 Tower kernel: perf_event_create_kernel_counter+0x24/0x120 Jun 28 04:00:57 Tower kernel: pmc_reprogram_counter+0xc7/0x10c [kvm] Jun 28 04:00:57 Tower kernel: reprogram_fixed_counter+0xc8/0xd9 [kvm] Jun 28 04:00:57 Tower kernel: reprogram_counter+0x4f/0x54 [kvm] Jun 28 04:00:57 Tower kernel: kvm_pmu_handle_event+0x6f/0x8d [kvm] Jun 28 04:00:57 Tower kernel: kvm_arch_vcpu_ioctl_run+0x64a/0xff8 [kvm] Jun 28 04:00:57 Tower kernel: ? kvm_arch_vcpu_load+0xe3/0x196 [kvm] Jun 28 04:00:57 Tower kernel: kvm_vcpu_ioctl+0x16c/0x483 [kvm] Jun 28 04:00:57 Tower kernel: ? do_futex+0xe2/0x86e Jun 28 04:00:57 Tower kernel: vfs_ioctl+0x13/0x2f Jun 28 04:00:57 Tower kernel: do_vfs_ioctl+0x4df/0x4f2 Jun 28 04:00:57 Tower kernel: ? __fget+0x72/0x7e Jun 28 04:00:57 Tower kernel: SyS_ioctl+0x3e/0x5c Jun 28 04:00:57 Tower kernel: entry_SYSCALL_64_fastpath+0x1a/0xa9 Jun 28 04:00:57 Tower kernel: RIP: 0033:0x2b99a2316337 Jun 28 04:00:57 Tower kernel: RSP: 002b:00002b99a6612988 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Jun 28 04:00:57 Tower kernel: RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00002b99a2316337 Jun 28 04:00:57 Tower kernel: RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000012 Jun 28 04:00:57 Tower kernel: RBP: 00002b99a5fa9140 R08: 000055f8f68f85b0 R09: 000000003b9aca00 Jun 28 04:00:57 Tower kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Jun 28 04:00:57 Tower kernel: R13: 00002b999ddf3000 R14: 0000000000000000 R15: 00002b99a5fa9140 Jun 28 04:00:57 Tower kernel: Mem-Info: Jun 28 04:00:57 Tower kernel: active_anon:3137760 inactive_anon:28859 isolated_anon:0 Jun 28 04:00:57 Tower kernel: active_file:1359865 inactive_file:3054158 isolated_file:0 Jun 28 04:00:57 Tower kernel: unevictable:0 dirty:239 writeback:0 unstable:0 Jun 28 04:00:57 Tower kernel: slab_reclaimable:243817 slab_unreclaimable:226704 Jun 28 04:00:57 Tower kernel: mapped:46671 shmem:156345 pagetables:10988 bounce:0 Jun 28 04:00:57 Tower kernel: free:96896 free_pcp:30 free_cma:0 Jun 28 04:00:57 Tower kernel: Node 0 active_anon:12551040kB inactive_anon:115436kB active_file:5439460kB inactive_file:12216632kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:186684kB dirty:956kB writeback:0kB shmem:625380kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 5136384kB writeback_tmp:0kB unstable:0kB pages_scanned:32 all_unreclaimable? no Jun 28 04:00:57 Tower kernel: Node 0 DMA free:15880kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15964kB managed:15880kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Jun 28 04:00:57 Tower kernel: lowmem_reserve[]: 0 3137 32063 32063 Jun 28 04:00:57 Tower kernel: Node 0 DMA32 free:132812kB min:13216kB low:16520kB high:19824kB active_anon:2381520kB inactive_anon:128kB active_file:226068kB inactive_file:467488kB unevictable:0kB writepending:0kB present:3363300kB managed:3354540kB mlocked:0kB slab_reclaimable:114408kB slab_unreclaimable:27776kB kernel_stack:224kB pagetables:1568kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Jun 28 04:00:57 Tower kernel: lowmem_reserve[]: 0 0 28926 28926 Jun 28 04:00:57 Tower kernel: Node 0 Normal free:238892kB min:121884kB low:152352kB high:182820kB active_anon:10168140kB inactive_anon:115308kB active_file:5213392kB inactive_file:11748880kB unevictable:0kB writepending:956kB present:30146560kB managed:29620912kB mlocked:0kB slab_reclaimable:860860kB slab_unreclaimable:879040kB kernel_stack:14440kB pagetables:42384kB bounce:0kB free_pcp:120kB local_pcp:0kB free_cma:0kB Jun 28 04:00:57 Tower kernel: lowmem_reserve[]: 0 0 0 0 Jun 28 04:00:57 Tower kernel: Node 0 DMA: 0*4kB 1*8kB (U) 0*16kB 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 3*4096kB (M) = 15880kB Jun 28 04:00:57 Tower kernel: Node 0 DMA32: 824*4kB (UME) 830*8kB (UME) 557*16kB (UMEH) 390*32kB (UMEH) 278*64kB (UMEH) 199*128kB (UMEH) 92*256kB (UME) 41*512kB (ME) 14*1024kB (ME) 0*2048kB 0*4096kB = 133472kB Jun 28 04:00:57 Tower kernel: Node 0 Normal: 59235*4kB (UME) 182*8kB (UME) 24*16kB (H) 7*32kB (MH) 2*64kB (H) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 239132kB Jun 28 04:00:57 Tower kernel: 4570296 total pagecache pages Jun 28 04:00:57 Tower kernel: 0 pages in swap cache Jun 28 04:00:57 Tower kernel: Swap cache stats: add 0, delete 0, find 0/0 Jun 28 04:00:57 Tower kernel: Free swap = 0kB Jun 28 04:00:57 Tower kernel: Total swap = 0kB Jun 28 04:00:57 Tower kernel: 8381456 pages RAM Jun 28 04:00:57 Tower kernel: 0 pages HighMem/MovableOnly Jun 28 04:00:57 Tower kernel: 133623 pages reserved Jun 28 04:00:57 Tower kernel: 0 pages cma reserved Jun 28 04:05:20 Tower kernel: CPU 0/KVM: page allocation failure: order:4, mode:0x160c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO|__GFP_NOTRACK), nodemask=(null) Jun 28 04:05:20 Tower kernel: CPU 0/KVM cpuset=vcpu0 mems_allowed=0 Jun 28 04:05:20 Tower kernel: CPU: 6 PID: 18186 Comm: CPU 0/KVM Tainted: G W 4.11.6-unRAID #2 Jun 28 04:05:20 Tower kernel: Hardware name: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.0b 09/17/2012 Jun 28 04:05:20 Tower kernel: Call Trace: Jun 28 04:05:20 Tower kernel: dump_stack+0x61/0x7e Jun 28 04:05:20 Tower kernel: warn_alloc+0xdf/0x158 Jun 28 04:05:20 Tower kernel: ? __alloc_pages_direct_compact+0x4f/0xe3 Jun 28 04:05:20 Tower kernel: __alloc_pages_nodemask+0xb0d/0xc01 Jun 28 04:05:20 Tower kernel: ? intel_get_event_constraints+0x21d/0x246 Jun 28 04:05:20 Tower kernel: ? intel_pmu_enable_all+0xb/0xd Jun 28 04:05:20 Tower kernel: ? x86_pmu_enable+0x24b/0x257 Jun 28 04:05:20 Tower kernel: kmalloc_large_node+0x54/0x82 Jun 28 04:05:20 Tower kernel: __kmalloc_node+0x22/0x135 Jun 28 04:05:20 Tower kernel: reserve_ds_buffers+0x2dd/0x38b Jun 28 04:05:20 Tower kernel: x86_reserve_hardware+0x136/0x153 Jun 28 04:05:20 Tower kernel: x86_pmu_event_init+0x49/0x1aa Jun 28 04:05:20 Tower kernel: perf_try_init_event+0x41/0x71 Jun 28 04:05:20 Tower kernel: perf_event_alloc+0x435/0x766 Jun 28 04:05:20 Tower kernel: ? reprogram_counter+0x54/0x54 [kvm] Jun 28 04:05:20 Tower kernel: perf_event_create_kernel_counter+0x24/0x120 Jun 28 04:05:20 Tower kernel: pmc_reprogram_counter+0xc7/0x10c [kvm] Jun 28 04:05:20 Tower kernel: reprogram_fixed_counter+0xc8/0xd9 [kvm] Jun 28 04:05:20 Tower kernel: reprogram_counter+0x4f/0x54 [kvm] Jun 28 04:05:20 Tower kernel: kvm_pmu_handle_event+0x6f/0x8d [kvm] Jun 28 04:05:20 Tower kernel: kvm_arch_vcpu_ioctl_run+0x64a/0xff8 [kvm] Jun 28 04:05:20 Tower kernel: ? kvm_arch_vcpu_load+0xe3/0x196 [kvm] Jun 28 04:05:20 Tower kernel: kvm_vcpu_ioctl+0x16c/0x483 [kvm] Jun 28 04:05:20 Tower kernel: ? do_futex+0xe2/0x86e Jun 28 04:05:20 Tower kernel: vfs_ioctl+0x13/0x2f Jun 28 04:05:20 Tower kernel: do_vfs_ioctl+0x4df/0x4f2 Jun 28 04:05:20 Tower kernel: ? __fget+0x72/0x7e Jun 28 04:05:20 Tower kernel: SyS_ioctl+0x3e/0x5c Jun 28 04:05:20 Tower kernel: entry_SYSCALL_64_fastpath+0x1a/0xa9 Jun 28 04:05:20 Tower kernel: RIP: 0033:0x2b99a2316337 Jun 28 04:05:20 Tower kernel: RSP: 002b:00002b99a6612988 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Jun 28 04:05:20 Tower kernel: RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00002b99a2316337 Jun 28 04:05:20 Tower kernel: RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000012 Jun 28 04:05:20 Tower kernel: RBP: 00002b99a5fa9140 R08: 000055f8f68f85b0 R09: 00000000ffffffff Jun 28 04:05:20 Tower kernel: R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000000 Jun 28 04:05:20 Tower kernel: R13: 00002b999ddf3000 R14: 0000000000000006 R15: 00002b99a5fa9140 Jun 28 04:05:20 Tower kernel: Mem-Info: Jun 28 04:05:20 Tower kernel: active_anon:3143006 inactive_anon:28859 isolated_anon:0 Jun 28 04:05:20 Tower kernel: active_file:1311275 inactive_file:3104526 isolated_file:0 Jun 28 04:05:20 Tower kernel: unevictable:0 dirty:247 writeback:0 unstable:0 Jun 28 04:05:20 Tower kernel: slab_reclaimable:242757 slab_unreclaimable:226750 Jun 28 04:05:20 Tower kernel: mapped:45856 shmem:156357 pagetables:11025 bounce:0 Jun 28 04:05:20 Tower kernel: free:91075 free_pcp:112 free_cma:0 Jun 28 04:05:20 Tower kernel: Node 0 active_anon:12572024kB inactive_anon:115436kB active_file:5245100kB inactive_file:12418104kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:183424kB dirty:988kB writeback:0kB shmem:625428kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 5136384kB writeback_tmp:0kB unstable:0kB pages_scanned:32 all_unreclaimable? no Jun 28 04:05:20 Tower kernel: Node 0 DMA free:15880kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15964kB managed:15880kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Jun 28 04:05:20 Tower kernel: lowmem_reserve[]: 0 3137 32063 32063 Jun 28 04:05:20 Tower kernel: Node 0 DMA32 free:133024kB min:13216kB low:16520kB high:19824kB active_anon:2385192kB inactive_anon:128kB active_file:224568kB inactive_file:466384kB unevictable:0kB writepending:12kB present:3363300kB managed:3354540kB mlocked:0kB slab_reclaimable:112488kB slab_unreclaimable:27860kB kernel_stack:192kB pagetables:1568kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Jun 28 04:05:20 Tower kernel: lowmem_reserve[]: 0 0 28926 28926 Jun 28 04:05:20 Tower kernel: Node 0 Normal free:215396kB min:121884kB low:152352kB high:182820kB active_anon:10187576kB inactive_anon:115308kB active_file:5020856kB inactive_file:11951104kB unevictable:0kB writepending:976kB present:30146560kB managed:29620912kB mlocked:0kB slab_reclaimable:858540kB slab_unreclaimable:879140kB kernel_stack:14128kB pagetables:42532kB bounce:0kB free_pcp:444kB local_pcp:0kB free_cma:0kB Jun 28 04:05:20 Tower kernel: lowmem_reserve[]: 0 0 0 0 Jun 28 04:05:20 Tower kernel: Node 0 DMA: 0*4kB 1*8kB (U) 0*16kB 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 3*4096kB (M) = 15880kB Jun 28 04:05:20 Tower kernel: Node 0 DMA32: 478*4kB (UME) 814*8kB (UME) 540*16kB (UMEH) 413*32kB (UMEH) 183*64kB (UMEH) 234*128kB (UMEH) 104*256kB (UME) 41*512kB (ME) 14*1024kB (ME) 0*2048kB 0*4096kB = 133896kB Jun 28 04:05:20 Tower kernel: Node 0 Normal: 51970*4kB (UME) 763*8kB (UME) 51*16kB (MH) 17*32kB (MH) 2*64kB (H) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 215472kB Jun 28 04:05:20 Tower kernel: 4572211 total pagecache pages Jun 28 04:05:20 Tower kernel: 0 pages in swap cache Jun 28 04:05:20 Tower kernel: Swap cache stats: add 0, delete 0, find 0/0 Jun 28 04:05:20 Tower kernel: Free swap = 0kB Jun 28 04:05:20 Tower kernel: Total swap = 0kB Jun 28 04:05:20 Tower kernel: 8381456 pages RAM Jun 28 04:05:20 Tower kernel: 0 pages HighMem/MovableOnly Jun 28 04:05:20 Tower kernel: 133623 pages reserved Jun 28 04:05:20 Tower kernel: 0 pages cma reserved Jun 28 04:05:20 Tower kernel: CPU 0/KVM: page allocation failure: order:4, mode:0x160c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO|__GFP_NOTRACK), nodemask=(null) Jun 28 04:05:20 Tower kernel: CPU 0/KVM cpuset=vcpu0 mems_allowed=0 Jun 28 04:05:20 Tower kernel: CPU: 6 PID: 18186 Comm: CPU 0/KVM Tainted: G W 4.11.6-unRAID #2 Jun 28 04:05:20 Tower kernel: Hardware name: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.0b 09/17/2012 Jun 28 04:05:20 Tower kernel: Call Trace: Jun 28 04:05:20 Tower kernel: dump_stack+0x61/0x7e Jun 28 04:05:20 Tower kernel: warn_alloc+0xdf/0x158 Jun 28 04:05:20 Tower kernel: ? __alloc_pages_direct_compact+0x4f/0xe3 Jun 28 04:05:20 Tower kernel: __alloc_pages_nodemask+0xb0d/0xc01 Jun 28 04:05:20 Tower kernel: ? intel_pmu_enable_all+0xb/0xd Jun 28 04:05:20 Tower kernel: ? x86_pmu_enable+0x24b/0x257 Jun 28 04:05:20 Tower kernel: kmalloc_large_node+0x54/0x82 Jun 28 04:05:20 Tower kernel: __kmalloc_node+0x22/0x135 Jun 28 04:05:20 Tower kernel: reserve_ds_buffers+0x2dd/0x38b Jun 28 04:05:20 Tower kernel: x86_reserve_hardware+0x136/0x153 Jun 28 04:05:20 Tower kernel: x86_pmu_event_init+0x49/0x1aa Jun 28 04:05:20 Tower kernel: perf_try_init_event+0x41/0x71 Jun 28 04:05:20 Tower kernel: perf_event_alloc+0x435/0x766 Jun 28 04:05:20 Tower kernel: ? reprogram_counter+0x54/0x54 [kvm] Jun 28 04:05:20 Tower kernel: perf_event_create_kernel_counter+0x24/0x120 Jun 28 04:05:20 Tower kernel: pmc_reprogram_counter+0xc7/0x10c [kvm] Jun 28 04:05:20 Tower kernel: reprogram_fixed_counter+0xc8/0xd9 [kvm] Jun 28 04:05:20 Tower kernel: reprogram_counter+0x4f/0x54 [kvm] Jun 28 04:05:20 Tower kernel: intel_pmu_set_msr+0x164/0x2b5 [kvm_intel] Jun 28 04:05:20 Tower kernel: kvm_pmu_set_msr+0x15/0x17 [kvm] Jun 28 04:05:20 Tower kernel: kvm_set_msr_common+0x9bb/0x9e8 [kvm] Jun 28 04:05:20 Tower kernel: ? x86_emulate_insn+0xb2b/0xb3a [kvm] Jun 28 04:05:20 Tower kernel: vmx_set_msr+0x6a3/0x6b3 [kvm_intel] Jun 28 04:05:20 Tower kernel: kvm_set_msr+0x61/0x64 [kvm] Jun 28 04:05:20 Tower kernel: handle_wrmsr+0x3b/0x62 [kvm_intel] Jun 28 04:05:20 Tower kernel: vmx_handle_exit+0x100f/0x1093 [kvm_intel] Jun 28 04:05:20 Tower kernel: ? vmx_vcpu_run+0x3a6/0x3c8 [kvm_intel] Jun 28 04:05:20 Tower kernel: kvm_arch_vcpu_ioctl_run+0xdcb/0xff8 [kvm] Jun 28 04:05:20 Tower kernel: ? kvm_arch_vcpu_load+0xe3/0x196 [kvm] Jun 28 04:05:20 Tower kernel: kvm_vcpu_ioctl+0x16c/0x483 [kvm] Jun 28 04:05:20 Tower kernel: ? do_futex+0xe2/0x86e Jun 28 04:05:20 Tower kernel: vfs_ioctl+0x13/0x2f Jun 28 04:05:20 Tower kernel: do_vfs_ioctl+0x4df/0x4f2 Jun 28 04:05:20 Tower kernel: ? __fget+0x72/0x7e Jun 28 04:05:20 Tower kernel: SyS_ioctl+0x3e/0x5c Jun 28 04:05:20 Tower kernel: entry_SYSCALL_64_fastpath+0x1a/0xa9 Jun 28 04:05:20 Tower kernel: RIP: 0033:0x2b99a2316337 Jun 28 04:05:20 Tower kernel: RSP: 002b:00002b99a6612988 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Jun 28 04:05:20 Tower kernel: RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00002b99a2316337 Jun 28 04:05:20 Tower kernel: RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000012 Jun 28 04:05:20 Tower kernel: RBP: 00002b99a5fa9140 R08: 000055f8f68f85b0 R09: 00000000ffffffff Jun 28 04:05:20 Tower kernel: R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000000 Jun 28 04:05:20 Tower kernel: R13: 00002b999ddf3000 R14: 0000000000000006 R15: 00002b99a5fa9140 tower-diagnostics-20170709-0831.zip Edited July 9, 20178 yr by Helmonder
July 9, 20178 yr Don't know if this was a regression in 6.4 or not, but I run emhttp on port 88 rather than 80, and when launching VNC from the VM management page, it does not add the port 88 to the IP, so VNC fails to connect. If I append the :88 to the IP manually, it works fine.
July 10, 20178 yr On 7/4/2017 at 9:43 AM, hcgonzalezpr said: For me on RC6 the vnc remove (noVNC) is broken. My unraid IP is 192.168.24.4 but it tries to connect to a 169.254.138.80. If I downgrade back to 6.3 it works just fine. Edit: I did google the 1006 error on the forum, loading the webpage on a incognito window dint solve the issue. I had the same thing happen. I tweaked something with the config and it worked but I don't recall what I did. Make yours look like this
July 10, 20178 yr I've been reluctant to install this on my Production machine and just setup a new machine and first ran 6.35 for a few days to get a feel for it and just gave this a run. Right from the boot you can tell this is much snappier via the interface. Not sure why, but 6.35 on my new machine felt like it was thinking when you clicked a button, but 6.4 its almost instant when you click on something. Good job guys!!! I know its not much of a report, but I haven't had a lot of time running this new build and just wanted to say its definitely noticeable on how much faster this new interface is.
July 10, 20178 yr 31 minutes ago, kizer said: I know its not much of a report, but I haven't had a lot of time running this new build and just wanted to say its definitely noticeable on how much faster this new interface is. Wait for the next rc release, you may want to repeat that sentence
July 12, 20178 yr On 06/07/2017 at 5:40 PM, limetech said: This is some kind of kernel/kvm issue. You can follow progress in a large thread starting here with a post that defines the issue: http://www.spinics.net/lists/kvm/msg152133.html As you can see, top men are working on it. This NPT issue is a serious brick wall for those of us wanting to play high-end games. I thought it was my VM/980ti that was causing stuttering and general low fps in titles that played absolutely fine on my Xeon. Whoever fixes this issue is going to be Knighted.
July 14, 20178 yr Anything with respect to my call traces ? They are still happening.. Edited July 14, 20178 yr by Helmonder
July 14, 20178 yr On 7/11/2017 at 2:04 AM, bonienl said: Wait for the next rc release, you may want to repeat that sentence So more RCs to come? Not sure I can wait much longer. I vowed to stay away from beta or RC after I got hit by that RFS defect that corrupted small files. But these glowing reports of 6.4 are weakening my resolve. Edited July 17, 20178 yr by dalben
Archived
This topic is now archived and is closed to further replies.