Jump to content

SiNtEnEl

Members
  • Content count

    47
  • Joined

  • Last visited

Community Reputation

4 Neutral

About SiNtEnEl

  • Rank
    Advanced Member

Recent Profile Visitors

242 profile views
  1. SiNtEnEl

    Call Traces found

    Jul 8 18:45:22 DeusVult kernel: Call Trace: Jul 8 18:45:22 DeusVult kernel: local_pci_probe+0x3c/0x7a Jul 8 18:45:22 DeusVult kernel: pci_device_probe+0x11b/0x154 Jul 8 18:45:22 DeusVult kernel: driver_probe_device+0x142/0x2a6 Jul 8 18:45:22 DeusVult kernel: __driver_attach+0x68/0x88 Jul 8 18:45:22 DeusVult kernel: ? driver_probe_device+0x2a6/0x2a6 Jul 8 18:45:22 DeusVult kernel: bus_for_each_dev+0x63/0x7a Jul 8 18:45:22 DeusVult kernel: bus_add_driver+0xe1/0x1c6 Jul 8 18:45:22 DeusVult kernel: driver_register+0x7d/0xaf Jul 8 18:45:22 DeusVult kernel: ? 0xffffffffa02dc000 Jul 8 18:45:22 DeusVult kernel: do_one_initcall+0x89/0x11e Jul 8 18:45:22 DeusVult kernel: ? kmem_cache_alloc+0x9f/0xe8 Jul 8 18:45:22 DeusVult kernel: do_init_module+0x51/0x1be Jul 8 18:45:22 DeusVult kernel: load_module+0x1854/0x1e3f Jul 8 18:45:22 DeusVult kernel: ? SyS_init_module+0xba/0xe0 Jul 8 18:45:22 DeusVult kernel: SyS_init_module+0xba/0xe0 Jul 8 18:45:22 DeusVult kernel: do_syscall_64+0x6d/0xfe Jul 8 18:45:22 DeusVult kernel: entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Jul 8 18:45:22 DeusVult kernel: RIP: 0033:0x14bb588958aa Jul 8 18:45:22 DeusVult kernel: RSP: 002b:00007ffeacc548c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af Jul 8 18:45:22 DeusVult kernel: RAX: ffffffffffffffda RBX: 0000000000625e50 RCX: 000014bb588958aa Jul 8 18:45:22 DeusVult kernel: RDX: 0000000000629be0 RSI: 00000000002202e8 RDI: 0000000000f1fa80 Jul 8 18:45:22 DeusVult kernel: RBP: 0000000000629be0 R08: ffffffffffffffe0 R09: 00007ffeacc52a68 Jul 8 18:45:22 DeusVult kernel: R10: 0000000000623010 R11: 0000000000000246 R12: 0000000000f1fa80 Jul 8 18:45:22 DeusVult kernel: R13: 0000000000625f80 R14: 0000000000040000 R15: 0000000000000000 Jul 8 18:45:22 DeusVult kernel: Code: 00 e8 6a c7 e7 ff 8b 83 28 06 00 00 83 e8 16 83 e0 fd 0f 84 16 02 00 00 48 c7 c6 aa cf 4c a0 48 c7 c7 a7 c9 4c a0 e8 d4 32 c6 e0 <0f> 0b e9 fc 01 00 00 66 3d 00 a3 75 4e 48 c7 c2 49 d0 4c a0 be Jul 8 18:45:22 DeusVult kernel: ---[ end trace 3f2b0267604ec704 ]--- I'm getting also call traces on the i915, noticed since 6.5.3 series. Did a post here: https://lime-technology.com/forums/topic/72427-call-trace-on-653-series/ Looks like the i915 driver / module is funky after 6.5.2 for more users other then me on unraid. Since hardware transcoding is still working properly, i muted the error.
  2. SiNtEnEl

    Call trace on 6.5.3 series

    Hi all, Well if been struggling with this issue, since the introduction of the 6.5.3 series of Unraid. Since im not sure if its a user, kernel or firmware issue due to Unraid i'm posting this in general support. I have been reading similar issues on various linux distro's on the DC state mismatch, but not quite sure how to combine this with Unraid. Anyone got idea's? If full diagnostics log is needed let me know, i will upload it. Thanks! Jun 24 08:23:08 UnNASty kernel: ------------[ cut here ]------------ Jun 24 08:23:08 UnNASty kernel: WARNING: CPU: 0 PID: 3 at drivers/gpu/drm/i915/intel_runtime_pm.c:614 skl_enable_dc6+0x76/0xf2 [i915] Jun 24 08:23:08 UnNASty kernel: Modules linked in: i915(+) iosf_mbi drm_kms_helper drm intel_gtt agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops nct6775 hwmon_vid bonding igb i2c_algo_bit e1000e ptp pps_core 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 glue_helper cryptd intel_cstate intel_uncore intel_rapl_perf i2c_i801 i2c_core ahci libahci wmi video backlight fan acpi_pad thermal button [last unloaded: pps_core] Jun 24 08:23:08 UnNASty kernel: CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.14.49-unRAID #1 Jun 24 08:23:08 UnNASty kernel: Hardware name: Supermicro Super Server/X11SAE-M, BIOS 2.2 12/13/2017 Jun 24 08:23:08 UnNASty kernel: Workqueue: events i915_hpd_poll_init_work [i915] Jun 24 08:23:08 UnNASty kernel: task: ffff880460189a00 task.stack: ffffc900018f8000 Jun 24 08:23:08 UnNASty kernel: RIP: 0010:skl_enable_dc6+0x76/0xf2 [i915] Jun 24 08:23:08 UnNASty kernel: RSP: 0018:ffffc900018fbd38 EFLAGS: 00010292 Jun 24 08:23:08 UnNASty kernel: RAX: 0000000000000025 RBX: ffff88045e428000 RCX: 0000000000000000 Jun 24 08:23:08 UnNASty kernel: RDX: ffff88047241d001 RSI: ffff8804724164b8 RDI: ffff8804724164b8 Jun 24 08:23:08 UnNASty kernel: RBP: ffff88045e428000 R08: 0000000000000003 R09: ffffffff81fefe00 Jun 24 08:23:08 UnNASty kernel: R10: ffff880461896be8 R11: 00000000000104b4 R12: 0000000020000000 Jun 24 08:23:08 UnNASty kernel: R13: ffff88045e42ca98 R14: ffffffffa043195f R15: 0000000000000001 Jun 24 08:23:08 UnNASty kernel: FS: 0000000000000000(0000) GS:ffff880472400000(0000) knlGS:0000000000000000 Jun 24 08:23:08 UnNASty kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 24 08:23:08 UnNASty kernel: CR2: 000000000076c8a8 CR3: 0000000001c0a004 CR4: 00000000003606f0 Jun 24 08:23:08 UnNASty kernel: Call Trace: Jun 24 08:23:08 UnNASty kernel: intel_display_power_put+0xa9/0xc7 [i915] Jun 24 08:23:08 UnNASty kernel: intel_dp_detect+0x428/0x43c [i915] Jun 24 08:23:08 UnNASty kernel: drm_helper_probe_detect_ctx+0x54/0xb8 [drm_kms_helper] Jun 24 08:23:08 UnNASty kernel: ? __switch_to_asm+0x24/0x60 Jun 24 08:23:08 UnNASty kernel: drm_helper_hpd_irq_event+0x6c/0xeb [drm_kms_helper] Jun 24 08:23:08 UnNASty kernel: i915_hpd_poll_init_work+0xb3/0xc0 [i915] Jun 24 08:23:08 UnNASty kernel: process_one_work+0x155/0x237 Jun 24 08:23:08 UnNASty kernel: ? rescuer_thread+0x275/0x275 Jun 24 08:23:08 UnNASty kernel: worker_thread+0x1d5/0x2ad Jun 24 08:23:08 UnNASty kernel: kthread+0x111/0x119 Jun 24 08:23:08 UnNASty kernel: ? kthread_create_on_node+0x3a/0x3a Jun 24 08:23:08 UnNASty kernel: ret_from_fork+0x35/0x40 Jun 24 08:23:08 UnNASty kernel: Code: 55 04 00 48 89 df e8 b6 b9 46 e1 a8 02 74 1e 80 3d 29 dd 0d 00 00 75 15 48 c7 c7 6e 15 43 a0 c6 05 19 dd 0d 00 01 e8 0a 7e ce e0 <0f> 0b 48 89 df e8 53 e5 ff ff 48 c7 c2 95 15 43 a0 be 04 00 00 Jun 24 08:23:08 UnNASty kernel: ---[ end trace 238ac015519e427b ]--- Jun 24 08:23:08 UnNASty kernel: [drm:gen9_set_dc_state [i915]] *ERROR* DC state mismatch (0x0 -> 0x2) Jun 24 08:23:08 UnNASty kernel: [drm] Initialized i915 1.6.0 20170818 for 0000:00:02.0 on minor 0 Jun 24 08:23:08 UnNASty kernel: ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) Jun 24 08:23:08 UnNASty kernel: acpi device:0f: registered as cooling_device10 Jun 24 08:23:08 UnNASty kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5 Jun 24 08:23:08 UnNASty kernel: [drm] Cannot find any crtc or sizes Jun 24 08:23:08 UnNASty root: Starting emhttpd Jun 24 08:23:08 UnNASty emhttpd: unRAID System Management Utility version 6.5.3 Jun 24 08:23:08 UnNASty emhttpd: Copyright (C) 2005-2018, Lime Technology, Inc.
  3. I'm very content with the RC releases, incremental releases have been fairly well tested and stable and i have not seen any breaking issues so far. Normally i'm not a guy that runs release candidates on systems that involve data, since recovery and restoring takes to much of my precious time. But the quality of the releases in the candidate pipeline are like u said stable, and that's why i haven't missed a release candidate release on unRAID. We often add new features in our release candidates as well, so i don't mind that either. Mostly when it's needed or demanded by our costumers. Would the releases go the fully "beta" state, i would certainly not run it. Setting up a extra machine for testing would not be worth the effort for me. For the size of your company your doing a amazing job, supporting the range of platforms and trying to solve issues on certain hardware platforms. Surely in my opinion not deserving some of the comments that i have read on the forum, for most because of the complexity of the (sub)systems. Maybe publishing a issue tracker / roadmap / backlog dashboard would give more insight to people where the development is going towards or what you are working on. I'm not sure the forums are the right tool for that. But on the other hand managing a system like that would give a lot of extra overhead for a small company like yours. So i would understand that if it's not a option to maintain.
  4. Kingston VR ECC UDIMM DDR4-2400 16GB Micron, had to upgrade my memory due to memory starvation related crashes.
  5. My guess would be network related, network interface or configuration? Hard to say with out the full diagnostics.
  6. SiNtEnEl

    Think my server got breached

    Got the same behavior on my plex instance, the use 32400 or what ever port u use in your configuration. https://support.plex.tv/articles/200484543-enabling-remote-access-for-a-server/
  7. Just tested the docker approach by running dd from a container and i'm getting same disk performance as the alpha version of diskspeed. Was concerned it may influence the benchmarks.
  8. SiNtEnEl

    (Solved) Unraid OS not booting correctly

    Glad you found the issue, well at least u confirmed the memory is OK.
  9. SiNtEnEl

    (Solved) Unraid OS not booting correctly

    Memtest cycle can run a while, if its running a memtest it won't show up in the network. If memtest is OK, boot the OS with out the new disks see if its OK. Then add the disks one for one. (offline and then see if it boots)
  10. SiNtEnEl

    (Solved) Unraid OS not booting correctly

    I would do a Memtest, and check if the memory is working correctly. If that doesnt work, disconnect the new drives and try a Memtest. Proceed from that if it's ok.
  11. Supermicro boards have a long history of not having a correct scaling lm-sensors and need to be offset. I had this in the past on other linux distribution, but this probably would be the case with your machine. You can correct this by setting the correct offset values in the sensors configuration. Guide for this u can find here, not for Unraid but should do the same with sensors 3.4 on Unraid: https://wiki.archlinux.org/index.php/lm_sensors#Example_1._Adjusting_temperature_offsets (If it does not correct it directly after placing the file, it could be that u need to run sensors -s.) Some configs u can find here: https://github.com/groeck/lm-sensors/tree/master/configs/SuperMicro Mainly for the older boards, u could try supermicro support as well to get a config solution. Some boards don't report to well with out superdoctor being installed on the system. But i would try the offset route first, and see if that corrects the issue your having.
  12. SiNtEnEl

    HW transcoding

    There is some difference in iGPU performance with in some Intel series, like the Intel HD 630 and Intel HD P630. But for most apply the processor generation. What series supports what is easy to read in this list: https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Hardware_decoding_and_encoding
  13. SiNtEnEl

    No DNS for Docker VLAN [Solved]

    Glad we found the root cause, i used the cli mostly as well. For me is was a good docker documentation recap. My wifi vlan has internet access and can access google trough the vpn tunnel.
  14. SiNtEnEl

    Build(log): UnNASty

    Currently cheapest "dumpster" drives are €0,026 per gigabyte, still would hit me for 850 euro in disks. (need to by a extra disk due to overlap) Cheapest NAS capable disks that i would consider are €0,029 per gigabyte, so i rather save a bit more and do a larger NAS solution. Older disks will be kept for offline backup, what i'm doing at the moment, but that is always less then the size of my current storage.
  15. SiNtEnEl

    No DNS for Docker VLAN [Solved]

    https://docs.docker.com/engine/userguide/networking/configure-dns/ In the absence of the --dns=IP_ADDRESS..., --dns-search=DOMAIN..., or --dns-opt=OPTION... options, Docker uses the /etc/resolv.conf of the host machine (where the docker daemon runs). While doing so the daemon filters out all localhost IP address nameserver entries from the host’s original file. The information in this section covers the embedded DNS server operation for containers in user-defined networks. DNS lookup for containers connected to user-defined networks works differently compared to the containers connected to default bridge network. if there are no more nameserver entries left in the container’s /etc/resolv.conf file, the daemon adds public Google DNS nameservers (8.8.8.8 and 8.8.4.4) to the container’s DNS configuration. If IPv6 is enabled on the daemon, the public IPv6 Google DNS nameservers are also added (2001:4860:4860::8888 and 2001:4860:4860::8844). The embedded DNS server provides service discovery (i.e. it allows you to resolve hostnames of other containers on the same network), and acts as a forwarder for external DNS servers you configured. So if there is nothing left, its forwared to google, but that should be reachable from your VLAN i presume. My host config has a internal and external backup address in it, that is reachable from my VLAN. Wonder if this could be the case, in your setup @mifronte