raun

Members
  • Posts

    21
  • Joined

  • Last visited

Everything posted by raun

  1. Anyone upgrade to 6.12.4 to see if this crash as gone away?
  2. Thanks for the help - in the short term I'll roll back to 6.11.5 and keep an eye on the forums.
  3. root@Tower:~# docker network ls NETWORK ID NAME DRIVER SCOPE 3072d7630feb br0 ipvlan local 27dc2f81b4e6 bridge bridge local 1c177321660e host host local 4434f0935c25 none null local 1460fa1acee5 wg0 bridge local b001f8dbb75d wg1 bridge local root@Tower:~#
  4. Now I have a different, but similar crash. Log attached. unraid.log
  5. I switched to ipvlan. All my containers seem to run fine. Now we wait......
  6. Just upgraded from 6.11.5 to 6.12.3 and am experiencing near daily crashes. The machine does not respond to web ui or even pings after this crash occurs. I run about 12 dockers and a VM running hasos/homeassistant. Log from a remote syslog is attached. unraid.crash.log
  7. I'm slightly creeping up after 2 weeks. root@Tower:~# !45 cat /proc/sys/kernel/pty/nr 3714 root@Tower:~# uptime 21:28:59 up 17 days, 10:55, 0 users, load average: 0.35, 0.29, 0.27 root@Tower:~#
  8. After 3 days after a reboot my open ptys are holding steady at 3524 (give-or-take). After hitting this point I dont see ptys not being closed anymore.
  9. Same thing on my box: cat /proc/sys/kernel/pty/max == 4096 cat /proc/sys/kernel/pty/nr == 3518 cat /proc/sys/kernel/pty/reserve == 1024 I'm not creating my own containers.
  10. I'm seeing the same thing when opening the console window to any running docker container. A reboot fixes it a few hours, but at some point this happens again. Same symptoms as you - stopping/restarting doesn't help. My docker.img is not full.
  11. Same boat as me. memtest is clean, run of the mill hardware (skylake i5, no external cards), backed by ubiquiti network equipment with a repeatable panic every few weeks. 6.8.3 is on a LTS kernel, but its ~50 revisions behind (with many kernel panic fixes in those revisions) and with 6.9 looming, I doubt unraid would spin another 6.8.x series to update the kernel. I'm not all that interested in doing a custom 4.19.xxx kernel for the same reason.
  12. You have posts about panics in 6.9.0Beta29, and 6.8.3. These are very different different kernels. You're either very unlucky or have a hardware problem. Run memtest86 for several iterations
  13. I'm been having the same problem, and finally reproduced it after switching to remote syslog. Oct 15 00:11:13 Tower rpc.mountd[8523]: authenticated mount request from 192.168.2.31:918 for /mnt/user/Camera (/mnt/user/Camera) Oct 15 00:11:13 Tower rpcbind[25022]: connect from 192.168.2.31 to getport/addr(nfs) Oct 15 01:32:59 Tower kernel: general protection fault: 0000 [#1] SMP PTI Oct 15 01:32:59 Tower kernel: CPU: 3 PID: 23479 Comm: python3 Tainted: G W 4.19.107-Unraid #1 Oct 15 01:32:59 Tower kernel: Hardware name: Gigabyte Technology Co., Ltd. H170M-D3H-GSM/H170M-D3H-GSM-CF, BIOS F23e 03/09/2018 Oct 15 01:32:59 Tower kernel: RIP: 0010:nf_nat_setup_info+0x365/0x666 [nf_nat] Oct 15 01:32:59 Tower kernel: Code: ed 75 23 45 8b 17 48 8d 7c 24 58 b9 0a 00 00 00 48 8d 74 24 30 f3 a5 41 f6 c2 01 0f 85 c4 00 00 00 e9 25 02 00 00 8a 44 24 56 <41> 38 45 46 74 15 4d 8b ad 98 00 00 00 4d 85 ed 74 c7 49 81 ed 98 Oct 15 01:32:59 Tower kernel: RSP: 0018:ffff88881eb836d8 EFLAGS: 00010202 Oct 15 01:32:59 Tower kernel: RAX: ffff8880106aaa11 RBX: ffffffff81e91080 RCX: 000000002c2404e6 Oct 15 01:32:59 Tower kernel: RDX: ffff8887ade00000 RSI: 00000000b3a23fac RDI: 00000000f115a28e Oct 15 01:32:59 Tower kernel: RBP: ffff88881eb837b0 R08: ffff88881eb83708 R09: ffffffff81c8aa80 Oct 15 01:32:59 Tower kernel: R10: ffff888188d78388 R11: 0000000000000000 R12: 0000000000000000 Oct 15 01:32:59 Tower kernel: R13: 0de29a5fffffff68 R14: ffff88810f1923c0 R15: ffff88881eb837c4 Oct 15 01:32:59 Tower kernel: FS: 00001548557ad700(0000) GS:ffff88881eb80000(0000) knlGS:0000000000000000 Oct 15 01:32:59 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 15 01:32:59 Tower kernel: CR2: 000014944eb6d280 CR3: 000000034629c004 CR4: 00000000003606e0 Oct 15 01:32:59 Tower kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Oct 15 01:32:59 Tower kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Oct 15 01:32:59 Tower kernel: Call Trace: Oct 15 01:32:59 Tower kernel: <IRQ> Oct 15 01:32:59 Tower kernel: ? fib_rules_lookup+0x11f/0x16e Oct 15 01:32:59 Tower kernel: ? __krealloc+0x25/0x5d Oct 15 01:32:59 Tower kernel: ? nf_ct_ext_add+0x97/0xf6 Oct 15 01:32:59 Tower kernel: nf_nat_masquerade_ipv4+0x123/0x14b [nf_nat_ipv4] Oct 15 01:32:59 Tower kernel: masquerade_tg+0x44/0x5e [ipt_MASQUERADE] Oct 15 01:32:59 Tower kernel: ipt_do_table+0x582/0x62a [ip_tables] Oct 15 01:32:59 Tower kernel: ? fib_validate_source+0xc6/0xd5 Oct 15 01:32:59 Tower kernel: ? ipt_do_table+0x5da/0x62a [ip_tables] Oct 15 01:32:59 Tower kernel: nf_nat_inet_fn+0xeb/0x1b9 [nf_nat] Oct 15 01:32:59 Tower kernel: nf_nat_ipv4_out+0xf/0x89 [nf_nat_ipv4] Oct 15 01:32:59 Tower kernel: nf_hook_slow+0x3a/0x90 Oct 15 01:32:59 Tower kernel: ip_output+0xab/0xdd Oct 15 01:32:59 Tower kernel: ? ip_fragment.constprop.0+0x7d/0x7d Oct 15 01:32:59 Tower kernel: ip_forward+0x3c0/0x3ef Oct 15 01:32:59 Tower kernel: ? ipv4_frags_exit_net+0x2b/0x2b Oct 15 01:32:59 Tower kernel: ip_sabotage_in+0x38/0x3e Oct 15 01:32:59 Tower kernel: nf_hook_slow+0x3a/0x90 Oct 15 01:32:59 Tower kernel: ip_rcv+0x8e/0xbe Oct 15 01:32:59 Tower kernel: ? ip_rcv_finish_core.isra.0+0x2e1/0x2e1 Oct 15 01:32:59 Tower kernel: __netif_receive_skb_one_core+0x53/0x6f Oct 15 01:32:59 Tower kernel: netif_receive_skb_internal+0x79/0x94 Oct 15 01:32:59 Tower kernel: br_pass_frame_up+0x128/0x14a Oct 15 01:32:59 Tower kernel: ? br_port_flags_change+0x29/0x29 Oct 15 01:32:59 Tower kernel: br_handle_frame_finish+0x342/0x383 Oct 15 01:32:59 Tower kernel: ? br_pass_frame_up+0x14a/0x14a Oct 15 01:32:59 Tower kernel: br_nf_hook_thresh+0xa3/0xc3 Oct 15 01:32:59 Tower kernel: ? br_pass_frame_up+0x14a/0x14a Oct 15 01:32:59 Tower kernel: br_nf_pre_routing_finish+0x24a/0x271 Oct 15 01:32:59 Tower kernel: ? br_pass_frame_up+0x14a/0x14a Oct 15 01:32:59 Tower kernel: ? br_handle_local_finish+0xe/0xe Oct 15 01:32:59 Tower kernel: ? nf_nat_ipv4_in+0x1e/0x62 [nf_nat_ipv4] Oct 15 01:32:59 Tower kernel: ? br_handle_local_finish+0xe/0xe Oct 15 01:32:59 Tower kernel: br_nf_pre_routing+0x31c/0x343 Oct 15 01:32:59 Tower kernel: ? br_nf_forward_ip+0x362/0x362 Oct 15 01:32:59 Tower kernel: nf_hook_slow+0x3a/0x90 Oct 15 01:32:59 Tower kernel: br_handle_frame+0x27e/0x2bd Oct 15 01:32:59 Tower kernel: ? br_pass_frame_up+0x14a/0x14a Oct 15 01:32:59 Tower kernel: __netif_receive_skb_core+0x4a7/0x7b1 Oct 15 01:32:59 Tower kernel: ? enqueue_task_fair+0xba/0x676 Oct 15 01:32:59 Tower kernel: __netif_receive_skb_one_core+0x35/0x6f Oct 15 01:32:59 Tower kernel: process_backlog+0x77/0x10e Oct 15 01:32:59 Tower kernel: net_rx_action+0x107/0x26c Oct 15 01:32:59 Tower kernel: __do_softirq+0xc9/0x1d7 Oct 15 01:32:59 Tower kernel: do_softirq_own_stack+0x2a/0x40 Oct 15 01:32:59 Tower kernel: </IRQ> Oct 15 01:32:59 Tower kernel: do_softirq+0x4d/0x5a Oct 15 01:32:59 Tower kernel: __local_bh_enable_ip+0x42/0x4a Oct 15 01:32:59 Tower kernel: ip_finish_output2+0x30d/0x353 Oct 15 01:32:59 Tower kernel: ip_output+0xbe/0xdd Oct 15 01:32:59 Tower kernel: ? ip_reply_glue_bits+0x36/0x36 Oct 15 01:32:59 Tower kernel: ip_send_skb+0x10/0x32 Oct 15 01:32:59 Tower kernel: udp_send_skb+0x26a/0x2cb Oct 15 01:32:59 Tower kernel: udp_sendmsg+0x5df/0x809 Oct 15 01:32:59 Tower kernel: ? ip_reply_glue_bits+0x36/0x36 Oct 15 01:32:59 Tower kernel: ? seccomp_run_filters+0x101/0x143 Oct 15 01:32:59 Tower kernel: ? sock_sendmsg+0x14/0x1e Oct 15 01:32:59 Tower kernel: sock_sendmsg+0x14/0x1e Oct 15 01:32:59 Tower kernel: __sys_sendto+0xce/0x10c Oct 15 01:32:59 Tower kernel: ? __sys_connect+0x86/0xad Oct 15 01:32:59 Tower kernel: ? syscall_trace_enter+0x163/0x1aa Oct 15 01:32:59 Tower kernel: __x64_sys_sendto+0x20/0x23 Oct 15 01:32:59 Tower kernel: do_syscall_64+0x57/0xf2 Oct 15 01:32:59 Tower kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Oct 15 01:32:59 Tower kernel: RIP: 0033:0x15485eb0ee46 Oct 15 01:32:59 Tower kernel: Code: d5 53 49 89 f4 89 fb 48 83 ec 10 e8 64 da 00 00 45 31 c9 89 c5 45 31 c0 45 89 f2 4c 89 ea 4c 89 e6 89 df b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 36 89 ef 48 89 44 24 08 e8 96 da 00 00 48 8b Oct 15 01:32:59 Tower kernel: RSP: 002b:00001548557a9dc0 EFLAGS: 00000246 ORIG_RAX: 000000000000002c Oct 15 01:32:59 Tower kernel: RAX: ffffffffffffffda RBX: 0000000000000036 RCX: 000015485eb0ee46 Oct 15 01:32:59 Tower kernel: R10: 0000000000004000 R11: 0000000000000246 R12: 00001548557aa060 Oct 15 01:32:59 Tower kernel: R13: 000000000000002a R14: 0000000000004000 R15: 0000000000000000 Oct 15 01:32:59 Tower kernel: Modules linked in: veth xt_CHECKSUM ipt_REJECT ip6table_mangle ip6table_nat nf_nat_ipv6 ip6table_filter ip6_tables vhost_net vhost tap macvlan xt_nat ipt_MASQUERADE iptable_filter iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ip_tables ext4 mbcache jbd2 xfs nfsd lockd grace sunrpc md_mod tun bonding x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd e1000e glue_helper cdc_acm intel_cstate intel_wmi_thunderbolt intel_uncore ahci video intel_rapl_perf libahci wmi backlight fan thermal acpi_pad pcc_cpufreq button Oct 15 01:32:59 Tower kernel: ---[ end trace 9b52bba97c992e66 ]---
  14. I'm an idiot. There's nothing wrong. My script adds a prerouting mangle rule. I wasn't displaying the mangle table when looking at iptables rules. My real problem was that my docker container's IP changed - not sure if that was caused the 6.8.3 upgrade, or if it was me messing something up.
  15. Attached. I did check that. Both shares have 0KB minimum free space. tower-diagnostics-20200531-1537.zip
  16. Both /mnt/user/appdata and /mnt/user/system report "No space left on devce" when trying to write to these shares. Both are set to cache only, and the cache drive is not full. I can write to /mnt/cache/appdata and /mnt/cache/system manually just fine. I didn't notice the cache nearly full because the 'main' tab on the UI was incorrect - reporting 700GB free, when in reality less then 1GB is actually free on the cache drive. A reboot caused it to report correctly. Tho, that's a separate problem. After manually running the mover for a few minutes writes started working: Why with 1 GB free do writes to the cache fail, but succeed with 7GB free? Is there some limit I'm not aware of? Is there a warning I turned off?
  17. I finally upgraded from 6.7.2 to 6.8.3 I run openvpn-as and openvpn client. My default route is through the openvpn client (interface tun5). I accept openvpn-as connections through interface br0. I solved the somewhat common problem with this configuration that openvpn-as attempts replies to client connection requests over tun5 instead of the interface used to start the connection request (br0) using a PREROUTING rule: iptables -t mangle -A PREROUTING -s 172.17.0.7 -p tcp --sport 9443 -j MARK --set-mark 4321 ip route add default via 192.168.2.1 dev br0 table 3412 ip rule add fwmark 4321 table 3412 I'm far from a networking expert, but this allowed me to run a service in a docker using NAT on the docker and ensure the service replied using the same interface/gateway as the incoming request. This allowed openvpn-as to accept connections over my ISP's public IP, but route all external traffic through the VPN (tun5). After my upgrade to 6.8.3 any modifications to the PREROUTING table don't stick. The table always contains only a single rule Chain PREROUTING (policy ACCEPT) target prot opt source destination DOCKER all -- 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL Is there a solution to get my old behaviour back in 6.8.3?
  18. That definitely fixed the broken HDMI audio, and I can install drivers. Hopefully it fixes the stability issues too. Thanks for the tip!
  19. I upgraded my working GTX 750 to a RX 580. I have 1 Win10 VM that passes through the GPU. The GTX 750 worked great. The RX 580 has been a headache. The RX 580 does not appear to have reset problems. I can reboot the VM all day long and it has a 'reset' entry in /sys/kernel/iommu_groups/22 First, the only driver that will install is the AMD driver currently in Windows Update 17.1.1. Any other driver (18.1.1, 19.2.1, 19.2.2) will blank the screen, cause the VM to reboot and then hard hang the VM part way through the windows boot process. I cant enter safe mode. When the VM is hung like this, if I don't kill it manually within 2-3 minutes the unraid host will hard hang too. The VM needs to be reimaged at this point, Windows seems completely gone (or I can remove the RX 580 pass through). Second, just going with the 17.1.1 drivers: Windows says there's "no speakers or headset connected" device manager shows the HDMI audio driver is installed correctly, but for some reason I looks like the RX 580 never figures out there's an audio capable display attached.... odd, but not a deal breaker. Some applications (discord for example) even show the HDMI monitor as an output device, but no sound will play. Third, Using the 17.1.1 drivers everything appears to work. I can run games, play with the over clocking/voltage settings. Freesync works, etc. If I leave the VM idle for some amount of time (like over night), the unraid host is hard hung the next morning. I haven't recovered any logs or kernel messages as of yet. This is a PowerColor Red Devil RX 580 with this bios: https://www.techpowerup.com/vgabios/198033/198033 Without seeing a kernel panic message I'm really debugging by guessing. I haven't see this type of issue resolved in any forum yet. Any thoughts? <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>001 - Windows 10</name> <uuid>2a62fac2-74fe-ad80-c885-196e74ee5ab8</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>4194304</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>8</vcpu> <cputune> <vcpupin vcpu='0' cpuset='1'/> <vcpupin vcpu='1' cpuset='11'/> <vcpupin vcpu='2' cpuset='3'/> <vcpupin vcpu='3' cpuset='13'/> <vcpupin vcpu='4' cpuset='6'/> <vcpupin vcpu='5' cpuset='16'/> <vcpupin vcpu='6' cpuset='8'/> <vcpupin vcpu='7' cpuset='18'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/2a62fac2-74fe-ad80-c885-196e74ee5ab8_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='4' threads='2'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/disks/INTEL_SSDSA2CW512G3_CVPR129501XZ512NGN/vdisk001.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/Win10_1806_English_x64.iso'/> <target dev='hda' bus='ide'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/virtio-win-0.1.160.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:4e:ae:de'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='5'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x17' slot='0x00' function='0x0'/> </source> <rom file='/mnt/disks/INTEL_SSDSA2CW512G3_CVPR129501XZ512NGN/amd580.dump2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x17' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x0a5c'/> <product id='0x21e8'/> </source> <address type='usb' bus='0' port='1'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x1017'/> <product id='0x900a'/> </source> <address type='usb' bus='0' port='2'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x258a'/> <product id='0x1006'/> </source> <address type='usb' bus='0' port='3'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x3842'/> <product id='0x2410'/> </source> <address type='usb' bus='0' port='4'/> </hostdev> <memballoon model='none'/> </devices> </domain>
  20. My log is being filled with these messages: AA 2018-10-13 20:42:17 ERROR Could not open static file u'/app/sickrage/gui/slick/images/sickchill.png' AA 2018-10-13 20:42:16 ERROR Could not open static file u'/app/sickrage/gui/slick/images/sickchill.png' AA 2018-10-13 20:42:15 ERROR Could not open static file u'/app/sickrage/gui/slick/images/sickchill.png' AA 2018-10-13 20:42:14 ERROR Could not open static file u'/app/sickrage/gui/slick/images/sickchill.png' AA 2018-10-13 20:42:13 ERROR Could not open static file u'/app/sickrage/gui/slick/images/sickchill.png' AA 2018-10-13 20:42:12 ERROR Could not open static file u'/app/sickrage/gui/slick/images/sickchill.png' AA 2018-10-13 20:42:11 ERROR Could not open static file u'/app/sickrage/gui/slick/images/sickchill.png' AA 2018-10-13 20:42:10 ERROR Could not open static file u'/app/sickrage/gui/slick/images/sickchill.png' anyone else seeing this?
  21. I have a fresh install of Win10 on a VM. qemu-system-x86 is hovering around 80% cpu when the guest is idle. My fedora 28 VMs do not have this behavior - have 0% cpu of qemu-system-x86 when the guest is idle. In safe mode the Win10 VM does not cause qemu-system-x86 idles at 1%. In safe mode w/networking qemu-system-x86 idels about 21% when using a usb dongle with a passthrough controller. My config might be a bit messy now as I've been trying numerous suggestions in the many other topics on similar issues. I'm passing through an nvidia gpu and a USB controller. I'm using the virtio-win-0.1.149 drivers. I've tried: hyper-v on/off between 1 and 6 vcpu cores hpet on/off USB dongle networking vs. vrtio networking multiple timers and tick policys i440fx vs Q35 Performance of the VM seems fine. Crystal disk mark has great performance. I can saturate my 100mbit internet connection to stream just fine. The only problem is that qemu-system-x86 cpu usage is 80% when idle and increases disproportionately to what the VM is doing. qemu-system-x86 usage will spike to 400 - 600% when downloading from stream using the vrtio bridge or a usb dongle on the passed through controller (but not when booted to safe mode). Any suggestions? CPU is a i9-7900: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single mbaibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req <domain type='kvm' id='13'> <name>Windows 10</name> <uuid>70e158db-820c-3824-ca51-fbc605a00656</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>2</vcpu> <cputune> <vcpupin vcpu='0' cpuset='4'/> <vcpupin vcpu='1' cpuset='14'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/70e158db-820c-3824-ca51-fbc605a00656_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='1' threads='2'/> </cpu> <clock offset='localtime'> <timer name='pit' present='yes' tickpolicy='discard'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/disks/INTEL_SSDSA2CW512G3_CVPR129501XZ512NGN/vdisk1.img'/> <backingStore/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/disk/by-id/ata-PLEXTOR_DVDR_PX-716A_159923'/> <backingStore/> <target dev='hdd' bus='virtio'/> <alias name='virtio-disk3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='usb' index='0' model='piix3-uhci'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </controller> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-13-Windows 10/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='mouse' bus='ps2'> <alias name='input0'/> </input> <input type='keyboard' bus='ps2'> <alias name='input1'/> </input> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x17' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/mnt/disks/INTEL_SSDSA2CW512G3_CVPR129501XZ512NGN/nvidia750ti.dump'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x17' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <alias name='hostdev2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </memballoon> </devices> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+0:+100</label> <imagelabel>+0:+100</imagelabel> </seclabel> </domain>