bdowden

It ended up being my HBA overheating. Those low rpm Noctuas don’t move enough air. I got better 120mm’s and put active cooling on my HBA and things have been fine.

I'm using Supermicro chasses, one 12 bay which hosts the server itself, then a 45 bay JBOD chassis, both using 2 of the supermicro server PSU's (4 PSU's total). I'm going to try connecting the new parity to the motherboard sata port and see if that helps things. The only power splitters I'm using are for the u2 to m2 converters (sata power splitters), so nothing for any other molex power connectors. I haven't run a memtest but this is the first time I've gotten reboots while doing a parity rebuild in my 14 years of using Unraid; not saying it's NOT memory related, but I find it odd the issue just happened when I went to upgrade my parity drive.

I'm trying to upgrade my parity drive from 14TB to 26. I reach 14+ rebuilt and then my server reboots. I set up a syslog server and have it logging but there's nothing in the logs for the reboot time (even an hour beforehand), which I found odd. The latest rebuild attempt I saw 15.6TB ten minutes (approx) before the server rebooted. Attached are diagnostics; I think I did it correctly. tower-diagnostics-20250628-1729.zip

Ah, that makes sense. One is called Pro.key and the other Pro2.key. Thanks everyone!

Is there a way to determine which unraid license key is being used? I purchased 2 licenses in 2011 and through a few different servers I ended up with both key files on the same USB. Is there a way to see which key is being used so I can set up another (backup) unraid server?

Yes there was. I had some docker app data directories on disk2 instead of on cache. Once I moved that to cache the parity check speeds are averaging 100MB/s. From what I've read that's about what I should be getting. Thanks for your help!

Here are the diagnostics. From what I saw in the smart reports I see Device-to-host register FISes sent due to a COMRESET in almost all of them. I'm not sure which drives are in the 45 bay and which are in the main chassis, but the fact that the majority have this listed I'm going to assume it's the LSI HBA. This weekend I'll try to swap it out for the H200e and see if that fixes it. And yes, I know some of the SSD's have smart errors - I'm slowly migrating off of those old SSD's but I haven't made my way to get rid of all of them. tower2-diagnostics-20221012-1846.zip

Ok. When I get back home I plan on removing the 2.5” chassis and replacing the LSI with the h200e; while I’m at it I’ll replace a drive that I’ve been meaning to. but I’m general there shouldn’t be issues with unassigned drives and parity speeds as long as the hardware is good without issues?

Hi all. I’ve been trying to figure out why my parity check speeds go from 65-70 MBps to 5, seemingly at random times. all of my drives are shucked 14tb WD element drives, 260TB total, with 2 parity. I have at least 25 drives not in the array, mainly for farming chia (20 or so), and then a few for other things. My specs: Supermicro MotherBoard MBD-X11DPI-NT-O 256gb ddr4 Supermicro CSE-847 45 bay chassis (JBOD) Supermicro CSE-846A chassis (main server) LSI-9201-16e HBA Suoermicro CSE-216E26 2.5” chassis most drives are in the JBOD enclosure but 5 are in the 846, including one parity drive, connected to the motherboard sata ports. The two chassis are connected via an external SFF8088 from the LSI to the 8088 connectors on the 847. there are only 2 drives in the 216. No drives have smart errors and disk speed tests are fine. Where my mind is going is the LSI adapter isn’t the best and I should switch to the PERC H200e. I think also the constant spin of the chia drives going over the same 8088 cables are causing a slow down of speeds for parity checks. Is there anything else I should look at? Every time a parity check starts I dread seeing those super slow speeds.

Ok cool. I had removed the Mellanox when I installed the daughter card. Do you have any suggestions on next steps? I'm still a linux noob (even though I've been using Unraid for almost a decade).

Hi everyone. I switched the server that I have unraid running on from a custom built Norco case with a mellanox 10g card to a dell R720xd with the 57800S 2 port SFP+ daughter card. I had also installed a Quadro P2000 for plex transcodings at the same time. I also have a 9102-16E HBA card that is connected to a 45 bay supermicro chassis (with the built in port expander backplane) and a 24 bay sff supermicro chassis with a standard backplane (6x SAS connectors) that is connected via a SFF-8088 to SFF-8087 pass-through bracket. I'm now getting kernel panics at random times of the day but at least twice a week and I need to perform a hard reboot. I finally got diagnostics where I THINK it's caused by the network driver but I can't be 100% sure. Can anyone verify? If you require more logs let me know. I'm new to storage chassis and SFF--8088 cards/cables, but I think everything is ok there. Mar 11 21:24:15 Tower2 kernel: WARNING: CPU: 24 PID: 24271 at lib/vsprintf.c:2556 vsnprintf+0x30/0x4ef Mar 11 21:24:15 Tower2 kernel: Modules linked in: nfsd lockd grace sunrpc md_mod nvidia_drm(PO) nvidia_modeset(PO) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops nvidia(PO) drm backlight agpgart ip6table_filter ip6_tables iptable_filter ip_tables x_tables bnx2x mdio sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd ipmi_ssif i2c_core glue_helper rapl intel_cstate input_leds mpt3sas intel_uncore nvme acpi_power_meter led_class raid_class scsi_transport_sas nvme_core wmi ipmi_si button [last unloaded: mdio] Mar 11 21:24:15 Tower2 kernel: CPU: 24 PID: 24271 Comm: ethtool Tainted: P O 5.10.28-Unraid #1 Mar 11 21:24:15 Tower2 kernel: Hardware name: Dell Inc. PowerEdge R720xd/0020HJ, BIOS 2.9.0 12/06/2019 Mar 11 21:24:15 Tower2 kernel: RIP: 0010:vsnprintf+0x30/0x4ef Mar 11 21:24:15 Tower2 kernel: Code: 41 54 55 53 48 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 48 81 fe ff ff ff 7f 48 c7 44 24 08 00 00 00 00 76 07 <0f> 0b e9 94 04 00 00 48 89 fd 49 89 fc 49 89 f5 48 01 f5 49 89 d0 Mar 11 21:24:15 Tower2 kernel: RSP: 0018:ffffc900285e7a90 EFLAGS: 00010296 Mar 11 21:24:15 Tower2 kernel: RAX: 0000000000000000 RBX: 0000000000070a0b RCX: ffffc900285e7ae0 Mar 11 21:24:15 Tower2 kernel: RDX: ffffffffa00cba0f RSI: fffffffffffffff8 RDI: ffffc900285e7bc8 Mar 11 21:24:15 Tower2 kernel: RBP: ffffc900285e7b30 R08: 000000000000000a R09: 000000000000000b Mar 11 21:24:15 Tower2 kernel: R10: 0000000000000007 R11: 0000000000000000 R12: 0000000000000020 Mar 11 21:24:15 Tower2 kernel: R13: ffffc900285e7b54 R14: ffff888124299db8 R15: 00000000ffffffed Mar 11 21:24:15 Tower2 kernel: FS: 0000149bb1295740(0000) GS:ffff889fffb00000(0000) knlGS:0000000000000000 Mar 11 21:24:15 Tower2 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 11 21:24:15 Tower2 kernel: CR2: 0000000000428670 CR3: 0000000144506005 CR4: 00000000000606e0 Mar 11 21:24:15 Tower2 kernel: Call Trace: Mar 11 21:24:15 Tower2 kernel: snprintf+0x49/0x60 Mar 11 21:24:15 Tower2 kernel: ? prep_new_page+0x25/0x71 Mar 11 21:24:15 Tower2 kernel: bnx2x_fill_fw_str+0xc7/0xf9 [bnx2x] Mar 11 21:24:15 Tower2 kernel: ? get_page_from_freelist+0x8e0/0xbd4 Mar 11 21:24:15 Tower2 kernel: bnx2x_get_drvinfo+0xf1/0x14c [bnx2x] Mar 11 21:24:15 Tower2 kernel: ethtool_get_drvinfo+0x6e/0x1b5 Mar 11 21:24:15 Tower2 kernel: dev_ethtool+0x59a/0x2126 Mar 11 21:24:15 Tower2 kernel: ? ___slab_alloc+0x23a/0x4aa Mar 11 21:24:15 Tower2 kernel: ? sk_prot_alloc.isra.0+0x26/0xad Mar 11 21:24:15 Tower2 kernel: ? inet_ioctl+0x17d/0x1a6 Mar 11 21:24:15 Tower2 kernel: ? page_add_file_rmap+0xc9/0xd4 Mar 11 21:24:15 Tower2 kernel: ? set_pte+0x5/0x8 Mar 11 21:24:15 Tower2 kernel: ? alloc_set_pte+0x2f0/0x301 Mar 11 21:24:15 Tower2 kernel: ? full_name_hash+0x12/0x6c Mar 11 21:24:15 Tower2 kernel: ? dev_name_hash+0x23/0x3a Mar 11 21:24:15 Tower2 kernel: dev_ioctl+0x2d7/0x3d5 Mar 11 21:24:15 Tower2 kernel: sock_do_ioctl+0xd9/0x12a Mar 11 21:24:15 Tower2 kernel: ? __do_sys_copy_file_range+0x178/0x18f Mar 11 21:24:15 Tower2 kernel: sock_ioctl+0x314/0x33b Mar 11 21:24:15 Tower2 kernel: ? alloc_file_pseudo+0xba/0xfd Mar 11 21:24:15 Tower2 kernel: vfs_ioctl+0x19/0x26 Mar 11 21:24:15 Tower2 kernel: __do_sys_ioctl+0x51/0x74 Mar 11 21:24:15 Tower2 kernel: do_syscall_64+0x5d/0x6a Mar 11 21:24:15 Tower2 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Mar 11 21:24:15 Tower2 kernel: RIP: 0033:0x149bb13a4417 Mar 11 21:24:15 Tower2 kernel: Code: 00 00 90 48 8b 05 79 2a 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 49 2a 0d 00 f7 d8 64 89 01 48 Mar 11 21:24:15 Tower2 kernel: RSP: 002b:00007fff8c5cfd28 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 Mar 11 21:24:15 Tower2 kernel: RAX: ffffffffffffffda RBX: 00007fff8c5cffa8 RCX: 0000149bb13a4417 Mar 11 21:24:15 Tower2 kernel: RDX: 00007fff8c5cfe30 RSI: 0000000000008946 RDI: 0000000000000003 Mar 11 21:24:15 Tower2 kernel: RBP: 00007fff8c5cfe20 R08: 00007fff8c5cfe30 R09: 0000000000000003 Mar 11 21:24:15 Tower2 kernel: R10: 0000000000401387 R11: 0000000000000206 R12: 000000000040abe0 Mar 11 21:24:15 Tower2 kernel: R13: 0000000000000001 R14: 0000000000435043 R15: 000000000043504b Mar 11 21:24:15 Tower2 kernel: ---[ end trace 033002dfefbd6b3e ]---