Jump to content

unCoreX

Members
 View Profile  See their activity

  • Posts

    93

  • Joined

 Content Type 

Posts posted by unCoreX

    [PLUGIN] GPU Statistics

    in Plugin Support

    Posted

    After updating to version 2023.10.29 I start receiving this error:

      

    Oct 29 22:38:36 Tower nginx: 2023/10/29 22:38:36 [error] 17053#17053: *10094889 open() "/usr/local/emhttp/plugins/gpustat/images/Threadfin.png" failed (2: No such file or directory) while sending to client, client: 10.15.10.20, server: , request: "GET /plugins/gpustat/images/Threadfin.png HTTP/2.0", host: "10.15.20.100:5001", referrer: "https://10.15.20.100:5001/Dashboard"

     

    Unraid OS version 6.12.4 available

    in Announcements

    Posted · Edited by CiscoCoreX

    5 hours ago, JorgeB said:

    Those can still happen if you still use macvlan with bridging, either use ipvlan, or if you really require macvlan disable bridging, see the release notes.

    This going to be a problem for me. I'm running VM's on my unraid with Network Source: br0. So I can give every VM a static ip address.  So I can RDP to my Windows 10 VM. So how do I gonna resolve this with bridging disable?

    image.png.4e63e60cace1094690867e2b0f8e3228.png

     

    My win 10 vm:

    image.png.8f72646387f90c8cf6453023eaea0df3.png

    Unraid OS version 6.12.4 available

    in Announcements

    Posted · Edited by CiscoCoreX

    9 minutes ago, strike said:

    Not yet, gonna update during next week.

    I took the risk and updated now,. Seems to my everything went smoothly. Only one thing i noticed, the DOCKER page took much longer time to open, hmmm

     

    That's probably why? It took 12 sec top open the DOCKER tap.
    image.png.05c1e13cfde62175d2995f99fa039004.png
     

    Unraid OS version 6.12.4 available

    in Announcements

    Posted

    4 hours ago, strike said:

    Correct me if I'm wrong anyone, but as I understand it you can still use macvlan, but instead of br0 it will now be eth0 and everything should work as before. That's what I read when I skimmed through the release notes anyway. I'm also using macvlan and will continue to do so if I can.

    Hi, did you upgrade? :)

    Unraid OS version 6.12.4 available

    in Announcements

    Posted · Edited by CiscoCoreX

    Hi,

    Is this update gonna make some problems for me when I'm running like this?
    I do have ab firewall that don't like when I use IPVLAN... when you have over 30 containers and all of the came up with same MAC address with different IP, I had problems to access my containers. That's why I use MACVLAN. Never hade any CALL TRACES error before.

    Almost all my containers are using br0 network.

    image.thumb.png.1766d0a71481a0d11e891697df4d0679.png

     

    image.png.1c9202d964b7402cbe6823a3f1d9bf83.png

    ML350p Gen8 Barebones

    in Hardware

    Posted · Edited by CiscoCoreX

    Hi,
    Anyone still using ML350p G8 with Unraid? Is it working?

     

    I've got my hands on an ML350p G8 with 2 x E2697v2 with 128GB ECC memory with P420i controller with HBA mode enabled.

    Adaptec 71605 16i SATA port HBA card for ~$50 review and how to fix write cache disabled

    in Storage Devices and Controllers

    Posted

    On 8/3/2020 at 1:09 AM, TexasUnraid said:

    Interestingly, I recently stopped and started the array and when it restarted the write cache was disabled on a few drives again. I know this was not the cards fault since the computer was not restarted and it happened with the array restart. So it must be something about how unraid interacts with the card that is causing the write cache to be disabled.

     

    Luckily it is not an issue, performance is only minorly effected in some quick tests I did with the write cache off and fixing it is very simple with the above smartctl command.

     

    I went ahead and made up this script that runs hourly to ensure I don't have to mess with this again, I will leave it here in case someone else wants to use it. It prints the starting status of the drive, it then enables the cache and then prints the status of the write cache again to make sure it changed.

     

    It is perfectly fine to run it on all the drives.

     


    Hi, do you see the temperatures from all of your disk with this controller?

    pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0

    in General Support

    Posted · Edited by CiscoCoreX

    I have been receiving this error message after upgrading to 6.11.5. Never seen it before on previous unraid versions.
    It's so random. But here is the error:

      

    Feb 19 15:33:32 Pegasus root: Reloading Nginx configuration...
Feb 19 16:52:34 Pegasus kernel: pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
Feb 19 16:52:34 Pegasus kernel: pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Feb 19 16:52:34 Pegasus kernel: pcieport 0000:00:01.0:   device [8086:1901] error status/mask=00000001/00002000
Feb 19 16:52:34 Pegasus kernel: pcieport 0000:00:01.0:    [ 0] RxErr

Feb 19 22:30:27 Pegasus  ool www[6361]: Successful logout user root from XX.XX.XX:XX
Feb 20 02:21:52 Pegasus kernel: pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
Feb 20 02:21:52 Pegasus kernel: pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Feb 20 02:21:52 Pegasus kernel: pcieport 0000:00:01.0:   device [8086:1901] error status/mask=00000001/00002000
Feb 20 02:21:52 Pegasus kernel: pcieport 0000:00:01.0:    [ 0] RxErr

Feb 21 19:21:31 Pegasus kernel: eth0: renamed from vetha3980df
Feb 21 23:01:47 Pegasus kernel: pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
Feb 21 23:01:47 Pegasus kernel: pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Feb 21 23:01:47 Pegasus kernel: pcieport 0000:00:01.0:   device [8086:1901] error status/mask=00000001/00002000
Feb 21 23:01:47 Pegasus kernel: pcieport 0000:00:01.0:    [ 0] RxErr

Feb 21 23:01:58 Pegasus kernel: pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
Feb 21 23:01:58 Pegasus kernel: pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Feb 21 23:01:58 Pegasus kernel: pcieport 0000:00:01.0:   device [8086:1901] error status/mask=00000001/00002000
Feb 21 23:01:58 Pegasus kernel: pcieport 0000:00:01.0:    [ 0] RxErr


    image.png.dc43dc626fc50fca839dc3930e4e956b.png

    image.png.d8d2820114a7f523c44e7d1ebbf4445c.png

    Any idea what this ism any why only in unraid version 6.11.5?

     

    Unraid Crashes almost every day

    in General Support

    Posted · Edited by CiscoCoreX

    1 hour ago, ds1414 said:

    Hi,

    I looked through there as well and I could not see any eye pocking things, I though maybe someone with more experience than me would spot something.  

     

    Anyway, thanks for the help on this. I will take your advice and try to pinpoint the error using safemode.  

     

    I will post findings in a few days time.

     

    Take care

    Your first log look very similar to my log and problem.
    I never had this problem before. I figured out it has something to do with my torrent program, because everytime this happens, i have no access to my torrent web gui and same problem with unraid gui. All other containers are running fine.
    All this start happening after upgrading unraid to v.6.11.0. 

    Sep 27 22:07:18 Pegasus kernel: BUG: kernel NULL pointer dereference, address: 0000000000000056
Sep 27 22:07:18 Pegasus kernel: #PF: supervisor read access in kernel mode
Sep 27 22:07:18 Pegasus kernel: #PF: error_code(0x0000) - not-present page
Sep 27 22:07:18 Pegasus kernel: PGD 0 P4D 0 
Sep 27 22:07:18 Pegasus kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI
Sep 27 22:07:18 Pegasus kernel: CPU: 18 PID: 27462 Comm: Disk Tainted: P           O      5.19.9-Unraid #1
Sep 27 22:07:18 Pegasus kernel: Hardware name: ASUS System Product Name/PRIME B560M-K, BIOS 1605 05/13/2022
Sep 27 22:07:18 Pegasus kernel: RIP: 0010:folio_try_get_rcu+0x0/0x21
Sep 27 22:07:18 Pegasus kernel: Code: e8 84 5e 63 00 48 8b 84 24 80 00 00 00 65 48 2b 04 25 28 00 00 00 74 05 e8 15 95 64 00 48 81 c4 88 00 00 00 5b c3 cc cc cc cc <8b> 57 34 85 d2 74 10 8d 4a 01 89 d0 f0 0f b1 4f 34 74 04 89 c2 eb
Sep 27 22:07:18 Pegasus kernel: RSP: 0000:ffffc9000ea57cc0 EFLAGS: 00010246
Sep 27 22:07:18 Pegasus kernel: RAX: 0000000000000022 RBX: 0000000000000022 RCX: 0000000000000022
Sep 27 22:07:18 Pegasus kernel: RDX: 0000000000000001 RSI: ffff88853b93eda0 RDI: 0000000000000022
Sep 27 22:07:18 Pegasus kernel: RBP: 0000000000000000 R08: 000000000000000c R09: ffffc9000ea57cd0
Sep 27 22:07:18 Pegasus kernel: R10: ffffc9000ea57cd0 R11: ffffc9000ea57d48 R12: 0000000000000000
Sep 27 22:07:18 Pegasus kernel: R13: ffff888010febab8 R14: 000000000000340d R15: ffff888010febac0
Sep 27 22:07:18 Pegasus kernel: FS:  0000145db2182640(0000) GS:ffff88883c480000(0000) knlGS:0000000000000000
Sep 27 22:07:18 Pegasus kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 27 22:07:18 Pegasus kernel: CR2: 0000000000000056 CR3: 000000063ded2005 CR4: 00000000007726e0
Sep 27 22:07:18 Pegasus kernel: PKRU: 55555554
Sep 27 22:07:18 Pegasus kernel: Call Trace:
Sep 27 22:07:18 Pegasus kernel: <TASK>
Sep 27 22:07:18 Pegasus kernel: __filemap_get_folio+0x98/0x1ff
Sep 27 22:07:18 Pegasus kernel: ? _raw_spin_unlock+0x14/0x29
Sep 27 22:07:18 Pegasus kernel: filemap_fault+0x6e/0x524
Sep 27 22:07:18 Pegasus kernel: __do_fault+0x2d/0x6e
Sep 27 22:07:18 Pegasus kernel: __handle_mm_fault+0x9a5/0xc7d
Sep 27 22:07:18 Pegasus kernel: handle_mm_fault+0x113/0x1d7
Sep 27 22:07:18 Pegasus kernel: do_user_addr_fault+0x36a/0x514
Sep 27 22:07:18 Pegasus kernel: exc_page_fault+0xfc/0x11e
Sep 27 22:07:18 Pegasus kernel: asm_exc_page_fault+0x22/0x30
Sep 27 22:07:18 Pegasus kernel: RIP: 0033:0x145db6bd2e8d
Sep 27 22:07:18 Pegasus kernel: Code: 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 83 fa 20 72 23 <c5> fe 6f 06 48 83 fa 40 0f 87 a5 00 00 00 c5 fe 6f 4c 16 e0 c5 fe
Sep 27 22:07:18 Pegasus kernel: RSP: 002b:0000145db2181798 EFLAGS: 00010202
Sep 27 22:07:18 Pegasus kernel: RAX: 0000145b9400b6d0 RBX: 0000145b940062f8 RCX: 0000145db21819d0
Sep 27 22:07:18 Pegasus kernel: RDX: 0000000000004000 RSI: 000014566580d691 RDI: 0000145b9400b6d0
Sep 27 22:07:18 Pegasus kernel: RBP: 0000000000000000 R08: 0000000000000104 R09: 0000000000000000
Sep 27 22:07:18 Pegasus kernel: R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000000
Sep 27 22:07:18 Pegasus kernel: R13: 0000145db2181a50 R14: 0000000000000104 R15: 0000145b94004e90
Sep 27 22:07:18 Pegasus kernel: </TASK>
Sep 27 22:07:18 Pegasus kernel: Modules linked in: nvidia_uvm(PO) veth cmac cifs asn1_decoder cifs_arc4 cifs_md4 oid_registry dns_resolver xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat macvlan iptable_mangle vhost_net tun vhost vhost_iotlb tap xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs md_mod nct6775 nct6775_core hwmon_vid efivarfs ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge stp llc bonding tls ipv6 e1000e r8169 realtek nvidia_drm(PO) nvidia_modeset(PO) i915 iosf_mbi drm_buddy i2c_algo_bit nvidia(PO) ttm drm_display_helper x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel wmi_bmof kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel drm_kms_helper aesni_intel crypto_simd drm cryptd rapl intel_cstate intel_gtt i2c_i801 agpgart i2c_smbus ahci intel_uncore libahci i2c_core input_leds syscopyarea
Sep 27 22:07:18 Pegasus kernel: led_class joydev sysfillrect corsair_psu sysimgblt fb_sys_fops thermal fan wmi tpm_crb tpm_tis video tpm_tis_core backlight tpm acpi_tad acpi_pad button unix [last unloaded: e1000e]
Sep 27 22:07:18 Pegasus kernel: CR2: 0000000000000056
Sep 27 22:07:18 Pegasus kernel: ---[ end trace 0000000000000000 ]---
Sep 27 22:07:18 Pegasus kernel: RIP: 0010:folio_try_get_rcu+0x0/0x21
Sep 27 22:07:18 Pegasus kernel: Code: e8 84 5e 63 00 48 8b 84 24 80 00 00 00 65 48 2b 04 25 28 00 00 00 74 05 e8 15 95 64 00 48 81 c4 88 00 00 00 5b c3 cc cc cc cc <8b> 57 34 85 d2 74 10 8d 4a 01 89 d0 f0 0f b1 4f 34 74 04 89 c2 eb
Sep 27 22:07:18 Pegasus kernel: RSP: 0000:ffffc9000ea57cc0 EFLAGS: 00010246
Sep 27 22:07:18 Pegasus kernel: RAX: 0000000000000022 RBX: 0000000000000022 RCX: 0000000000000022
Sep 27 22:07:18 Pegasus kernel: RDX: 0000000000000001 RSI: ffff88853b93eda0 RDI: 0000000000000022
Sep 27 22:07:18 Pegasus kernel: RBP: 0000000000000000 R08: 000000000000000c R09: ffffc9000ea57cd0
Sep 27 22:07:18 Pegasus kernel: R10: ffffc9000ea57cd0 R11: ffffc9000ea57d48 R12: 0000000000000000
Sep 27 22:07:18 Pegasus kernel: R13: ffff888010febab8 R14: 000000000000340d R15: ffff888010febac0
Sep 27 22:07:18 Pegasus kernel: FS:  0000145db2182640(0000) GS:ffff88883c480000(0000) knlGS:0000000000000000
Sep 27 22:07:18 Pegasus kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 27 22:07:18 Pegasus kernel: CR2: 0000000000000056 CR3: 000000063ded2005 CR4: 00000000007726e0
Sep 27 22:07:18 Pegasus kernel: PKRU: 55555554

     

     

    [Support] binhex - qBittorrentVPN

    in Docker Containers

    Posted

    Is it normal that any qbittorrent are eating up all your memory?
    And the reason why I ask, is that for some reason it make my unraid unresponsive. I can't login into the web gui.
    And qbittorrent is not responding, can't sign into qbit web gui. One time i did see the qbittorrent was using all my memory.
    This time i managed to restart it by the using SSH: diocker restart binhex-qbittorrent
    Other times i can't restart or kill it. I need to restart my unraid server.
    When this happening, all other containers are working normally, it's only qbittorrent i have this problem with.
    Yesterday i only had max 12 torrents running.

    This picture are with only 6 torrents.

    image.png.c412ae04473fb837f8f8fd668daf15bc.png

×
×
  • Create New...