therapist

I primarily use the NUT plugin for UPS control, and leave the baked in UPS monitor alone, however have had two instances now where I wake up to emails/errors about UPS lost communication. System was last started up/reset on 4/6/19 and first saw the issue on 4/14: Apr 14 04:40:04 OCHO apcupsd[547]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded Apr 14 04:40:04 OCHO apcupsd[547]: NIS server startup succeeded Apr 14 04:40:04 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:09 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:14 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:19 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:24 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:29 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:34 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:39 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:44 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:49 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:54 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:40:59 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 14 04:41:04 OCHO apcupsd[547]: Communications with UPS lost. The usbfs error continues on w/ the communications lost notification until I addressed the issue. Found my dashboard had the UPS plugin running, went into settings and found it started w/ gui setting set to off. a quick toggle of the settings and all was well again & dashboard panel went away. Now again last night (4/21/19) Apr 21 04:40:04 OCHO apcupsd[2116]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded Apr 21 04:40:04 OCHO apcupsd[2116]: NIS server startup succeeded Apr 21 04:40:04 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:09 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:14 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:19 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:24 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:29 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:34 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:39 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:44 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:49 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:54 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:40:59 OCHO kernel: usb 2-1.1: usbfs: interface 0 claimed by usbfs while 'apcupsd' sets config #1 Apr 21 04:41:04 OCHO apcupsd[2116]: Communications with UPS lost. Exactly 7 days to the second, we get another myster startup. I dont have any user scripts running that would call apcupsd, but i do see my "fixed schedules" set to run daily scripts at 440a. But apcupsd doesnt start up daily, only weekly which is set to run at 430a on Sundays.

Version: 6.7.0-rc7 Seeing random segfaults related to musl recently: Apr 8 23:59:32 OCHO kernel: python[34253]: segfault at 6e6f68747988 ip 000014ed29501411 sp 000014ed226c2d38 error 6 in ld-musl-x86_64.so.1[14ed294f4000+45000] Apr 8 23:59:32 OCHO kernel: Code: 48 8b 47 10 48 39 47 18 75 14 89 f1 48 c7 c0 fe ff ff ff 48 d3 c0 f0 48 21 05 1b b6 06 00 48 8b 57 18 48 8b 47 10 48 89 42 10 <48> 89 50 18 48 8b 47 08 48 89 c2 48 83 e0 fe 48 83 ca 01 48 89 57 Apr 9 00:12:33 OCHO kernel: python[2565]: segfault at 561700000090 ip 000014ed2950140d sp 000014ed226c2f08 error 6 in ld-musl-x86_64.so.1[14ed294f4000+45000] Apr 9 00:12:33 OCHO kernel: Code: 83 c0 10 c3 48 8b 47 10 48 39 47 18 75 14 89 f1 48 c7 c0 fe ff ff ff 48 d3 c0 f0 48 21 05 1b b6 06 00 48 8b 57 18 48 8b 47 10 <48> 89 42 10 48 89 50 18 48 8b 47 08 48 89 c2 48 83 e0 fe 48 83 ca have unifi-controller / ombi / nextcloud / resilio-sync / tautulli / duplicati installed from linuxserver repo how do I go about identifying the culprit container? Its not like its happening with any kind of frequency ocho-diagnostics-20190409-1212.zip

Running 6.7.0-rc6 on a supermicro x9dri-ln4f w/ 2x E5-2670v2 & 128gb ECC ram 1x 9211-8i -- 6x drives on array (slot 4) 1x 9207-8i -- 5x non array SSDs + 1x cache SSD (slot 6) 1x 9207-8e -- 4x array drives + 2x non array drives (slot 1) gigabyte gtx 1070 (slot 3) 11 array drives -- 6tb parity Upgraded from x8dti-f w/ 2x l6540 in late January / early February -- had no issues with this system other than lacking a little grunt for PLEX transcoding Ive been having recent issues with call traces which seem to be occurring during parity checks. Noticed them during the previous month's scheduled partiy check (2/28) I had my tunables set to: Tunable (nr_requests): 128 Tunable (md_num_stripes): 4096 Tunable (md_sync_window): 2048 Tunable (md_sync_thresh): 2000 And I've lowered sync_thresh to 192 which alleviated a number of the call traces I was seeing but don't understand why this became an issue after the upgrade when I re-used all hardware other than the mobo/cpu Also, still getting a KVM related call trace at the onset of the parity check -- and NIC dropouts while parity check is running Easy answer is to do parity checks less (I'm on UPS & SONNEN battery) but I'd like to fix the problem... Any advice on where to go? ocho-diagnostics-20190401-1838.zip

there was in fact.... I have: Tunable (nr_requests): 128 default Tunable (md_num_stripes): 4096 user-set Tunable (md_sync_window): 2048 user-set Tunable (md_sync_thresh): 2000 user-set been set this way for quite some time. why would parity check cause KVM lock up?

started getting call traces, which seem to occur when previously functional VMs are running Feb 28 13:58:53 OCHO kernel: CPU: 33 PID: 17724 Comm: unraidd Not tainted 4.18.20-unRAID #1 Feb 28 13:58:53 OCHO kernel: Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.2 03/04/2015 Feb 28 13:58:53 OCHO kernel: Call Trace: Feb 28 13:58:53 OCHO kernel: <IRQ> Feb 28 13:58:53 OCHO kernel: dump_stack+0x5d/0x79 Feb 28 13:58:53 OCHO kernel: nmi_cpu_backtrace+0x71/0x83 Feb 28 13:58:53 OCHO kernel: ? lapic_can_unplug_cpu+0x8e/0x8e Feb 28 13:58:53 OCHO kernel: nmi_trigger_cpumask_backtrace+0x57/0xd7 Feb 28 13:58:53 OCHO kernel: rcu_dump_cpu_stacks+0x91/0xbb Feb 28 13:58:53 OCHO kernel: rcu_check_callbacks+0x23f/0x5ca Feb 28 13:58:53 OCHO kernel: ? tick_sched_handle.isra.5+0x2f/0x2f Feb 28 13:58:53 OCHO kernel: update_process_times+0x23/0x45 Feb 28 13:58:53 OCHO kernel: tick_sched_timer+0x36/0x64 Feb 28 13:58:53 OCHO kernel: __hrtimer_run_queues+0xb1/0x105 Feb 28 13:58:53 OCHO kernel: hrtimer_interrupt+0xf4/0x20d Feb 28 13:58:53 OCHO kernel: smp_apic_timer_interrupt+0x79/0x91 Feb 28 13:58:53 OCHO kernel: apic_timer_interrupt+0xf/0x20 Feb 28 13:58:53 OCHO kernel: </IRQ> Feb 28 13:58:53 OCHO kernel: RIP: 0010:xor_avx_5+0x1c5/0x352 Feb 28 13:58:53 OCHO kernel: Code: c5 fd 7f 98 e0 00 00 00 c4 c1 7d 6f 82 00 01 00 00 c4 c1 7c 57 83 00 01 00 00 c5 fc 57 83 00 01 00 00 c5 fc 57 85 00 01 00 00 <c5> fc 57 80 00 01 00 00 c5 fd 7f 80 00 01 00 00 c4 c1 7d 6f 8a 20 Feb 28 13:58:53 OCHO kernel: RSP: 0018:ffffc9000b6cfc68 EFLAGS: 00000287 ORIG_RAX: ffffffffffffff13 Feb 28 13:58:53 OCHO kernel: RAX: ffff880e118ada00 RBX: ffff880e118a5a00 RCX: ffff880e118a5000 Feb 28 13:58:53 OCHO kernel: RDX: 0000000000000000 RSI: ffff880e118ad000 RDI: 0000000000001000 Feb 28 13:58:53 OCHO kernel: RBP: ffff880e118a4a00 R08: ffff880e118a6000 R09: ffff880e118a7000 Feb 28 13:58:53 OCHO kernel: R10: ffff880e118a7a00 R11: ffff880e118a6a00 R12: 0000000000000a00 Feb 28 13:58:53 OCHO kernel: R13: ffff880e118ad000 R14: ffff880e118a4000 R15: ffff880e118a5000 Feb 28 13:58:53 OCHO kernel: ? xor_avx_5+0x2d/0x352 Feb 28 13:58:53 OCHO kernel: check_parity+0x118/0x349 [md_mod] Feb 28 13:58:53 OCHO kernel: handle_stripe+0xe8a/0x1226 [md_mod] Feb 28 13:58:53 OCHO kernel: unraidd+0xbc/0x123 [md_mod] Feb 28 13:58:53 OCHO kernel: ? md_open+0x2c/0x2c [md_mod] Feb 28 13:58:53 OCHO kernel: md_thread+0xcc/0xf1 [md_mod] Feb 28 13:58:53 OCHO kernel: ? wait_woken+0x68/0x68 Feb 28 13:58:53 OCHO kernel: kthread+0x10b/0x113 Feb 28 13:58:53 OCHO kernel: ? kthread_flush_work_fn+0x9/0x9 Feb 28 13:58:53 OCHO kernel: ret_from_fork+0x35/0x40 Feb 28 14:01:53 OCHO kernel: INFO: rcu_sched self-detected stall on CPU Feb 28 14:01:53 OCHO kernel: 33-....: (1140023 ticks this GP) idle=92a/1/4611686018427387906 softirq=714962/714976 fqs=282448 Feb 28 14:01:53 OCHO kernel: (t=1140024 jiffies g=275169 c=275168 q=9034795) Feb 28 14:01:53 OCHO kernel: NMI backtrace for cpu 33 Feb 28 14:01:53 OCHO kernel: CPU: 33 PID: 17724 Comm: unraidd Not tainted 4.18.20-unRAID #1 Feb 28 14:01:53 OCHO kernel: Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.2 03/04/2015 Feb 28 14:01:53 OCHO kernel: Call Trace: Feb 28 14:01:53 OCHO kernel: <IRQ> Feb 28 14:01:53 OCHO kernel: dump_stack+0x5d/0x79 Feb 28 14:01:53 OCHO kernel: nmi_cpu_backtrace+0x71/0x83 Feb 28 14:01:53 OCHO kernel: ? lapic_can_unplug_cpu+0x8e/0x8e Feb 28 14:01:53 OCHO kernel: nmi_trigger_cpumask_backtrace+0x57/0xd7 Feb 28 14:01:53 OCHO kernel: rcu_dump_cpu_stacks+0x91/0xbb Feb 28 14:01:53 OCHO kernel: rcu_check_callbacks+0x23f/0x5ca Feb 28 14:01:53 OCHO kernel: ? tick_sched_handle.isra.5+0x2f/0x2f Feb 28 14:01:53 OCHO kernel: update_process_times+0x23/0x45 Feb 28 14:01:53 OCHO kernel: tick_sched_timer+0x36/0x64 Feb 28 14:01:53 OCHO kernel: __hrtimer_run_queues+0xb1/0x105 Feb 28 14:01:53 OCHO kernel: hrtimer_interrupt+0xf4/0x20d Feb 28 14:01:53 OCHO kernel: smp_apic_timer_interrupt+0x79/0x91 Feb 28 14:01:53 OCHO kernel: apic_timer_interrupt+0xf/0x20 Feb 28 14:01:53 OCHO kernel: </IRQ> Feb 28 14:01:53 OCHO kernel: RIP: 0010:unraidd+0xb1/0x123 [md_mod] Feb 28 14:01:53 OCHO kernel: Code: 48 89 12 48 89 52 08 f0 80 62 20 fe f0 ff 42 28 8b 42 28 ff c8 74 02 0f 0b 48 89 df c6 07 00 0f 1f 40 00 fb 66 0f 1f 44 00 00 <4c> 89 ff 41 ff c5 e8 1e ed ff ff 4c 89 ff e8 69 e1 ff ff 48 89 df Feb 28 14:01:53 OCHO kernel: RSP: 0018:ffffc9000b6cfe50 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 Feb 28 14:01:53 OCHO kernel: RAX: 0000000000000000 RBX: ffff880e27bf6268 RCX: ffff880e1643d818 Feb 28 14:01:53 OCHO kernel: RDX: ffff880e129489d8 RSI: 0000000000000046 RDI: ffff880e27bf6268 Feb 28 14:01:53 OCHO kernel: RBP: ffffc9000b6cfeb8 R08: 0000000000000000 R09: ffffc9000b6cfdb8 Feb 28 14:01:53 OCHO kernel: R10: 0000000000000001 R11: ffff880e19d36000 R12: ffff880e27bf6000 Feb 28 14:01:53 OCHO kernel: R13: 0000000001ebd7e8 R14: ffff880e27bf6220 R15: ffff880e129489c8 Feb 28 14:01:53 OCHO kernel: ? md_open+0x2c/0x2c [md_mod] Feb 28 14:01:53 OCHO kernel: md_thread+0xcc/0xf1 [md_mod] Feb 28 14:01:53 OCHO kernel: ? wait_woken+0x68/0x68 Feb 28 14:01:53 OCHO kernel: kthread+0x10b/0x113 Feb 28 14:01:53 OCHO kernel: ? kthread_flush_work_fn+0x9/0x9 Feb 28 14:01:53 OCHO kernel: ret_from_fork+0x35/0x40 can I get some guidance on what I may be looking at here? EDIT: running 6.6.6 diagnostics attached ocho-diagnostics-20190228-1409.zip

@johnnie.black I have a UD RAID0 array currently & have been considering changing to RAID5 Can btrfs balance -dconvert be done on the fly w/ data existing or must the disks be cleared beforehand?

6.6.6 is current stable the releases are Release Candidates which are technically beyond beta but before full release. I'd imagine that since @limetech can only test so many configurations themselves, they rely on the community to see if there are glitches with the thousands of different hardware options people use. Personally, I stick to stable releases...only installing them after they have been in the wild for 2+ weeks Theres nobody twisting arms to run RC software, so no need to be up in arms about the testing process

I have an x9dri-ln4f+ which has a dedicated onboard Intel 602 controller for the "SCU" port which I am trying to pass through to a Win10 VM. I set up a RAID0 array at boot in the controller interface, and after passing through the controller with vfio-id the windows 10 installer doesnt see any drives. I tried using the virtio drivers & even brought in a copy of intel 602 drivers but no love. Any pointers on where to go next? Goal is to pass through a 4 drive RAID0 for a gaming VM.

my apologies, misread that!

I tried again with an Intel PRO 2500 SSD w/ the same results on a 9207-8e w/ expander & a 9211-8i w/ passthrough backplane

That's a nice find I just verified my 860 EVO also supports DRAT Also got my hands on a few Intel Pro 2300 SSDs which also support DRAT Do you have your 860s going through a backplane or expander @Trunkz

Thank you!

Seems pretty straightforward to make a BASH script to extract last LBA address and run sg_unmap When I run the command in 6.6.6 console I get command not found...is it something in Nerd Pack perhaps it came with?

Well there you go Next question is, can sg_unmap be used in place for TRIM on HBAs? does not look like unRAID has the sg_unmap command baked in

I was under the impression that HBAs in IT mode worked exactly like this, but somewhere along the line the mpt2SAS has reduced compatibility. There is a whole plugin dedicated to TRIM automation, I wonder how many users are out there & just don't realize it isn't working anymore. Not that it is the end of the world, but simply relying on internal GC for an SSD is not the best course.