Thanks for reporting. Seems like it got better at least, which is a good sign. Hope we can fix it for good soon.
Yeah the first few were working, but over the last 3 days it’s been hit or miss for me too. In case it helps…
v2017.01.31.2207 didn’t restart
v2017.02.01.0203 did restart
v2017.02.01.2149 did restart
v2017.02.02.0208 didn’t restart
v2017.02.02.2018 didn’t restart
Maybe I can come up with a workaround in the meantime, to restart the DVR automatically when it crashes.
On an unrelated note, can anyone with an Intel CPU in their FreeNAS setup run ls -alh /dev/dri
and paste the output here. I want to see if we can support hardware accelerated transcoding on FreeBSD.
ls -alh /dev/dri
ls: /dev/dri: No such file or directory
I don’t see a “dri” (?) in the /dev/. This is an Intel FreeNas box.
OSFreebsd
10.3-stable (kernel: 10.3-stable)
CPU
4 cores / Intel® Core™ i5-2400 CPU @ 3.10GHz
load averages: 1.46 0.98 0.64
RAM16.67 GB
68.2% free
Trying to circle back to this upgrade issue on FreeNAS… I assume it’s still happening?
Can someone run this command and post output:
sysctl -a | grep core
I finally managed to get my development VM for FreeNAS working again, and sure enough the first upgrade I tried this hit bug.
Also discovered that the coredump folder doesn’t exist by default inside the jail (after jexec customplugin_1
):
$ sysctl kern.corefile
kern.corefile: /var/db/system/cores/%N.core
$ ls -alh /var/db/system/cores
ls: /var/db/system/cores: No such file or directory
$ mkdir -p /var/db/system/cores
After creating the dir, the crash now coredumps so I can analyze it:
$ dmesg | tail -1
pid 13406 (channels-dvr), uid 0: exited on signal 4 (core dumped)
$ ls -lh /var/db/system/cores
total 1100
-rw------- 1 root wheel 14M Mar 7 18:12 channels-dvr.core
I’m loading the coredump into a debugger now so hopefully I can squash this once and for all soon.
Thanks - I do still see it from time to time. Do you still need the output of that command after getting a coredump? I can try it when I get home tonight.
I am able to reproduce this issue locally (on both FreeNAS 9.10.2 and the latest FreeBSD 11.0) so I don’t need anyone to run any commands anymore.
The bug itself is particularly nasty, but hopefully it can be squashed soon.
I think I finally tracked this down and fixed it. The changes could use a little more testing before I push them out to everyone via automatic update. If you want to help test run the command in Volunteers to test new DVR build?
I’m considering moving my DVR install back to FreeNAS. Is this update/restart issue resolved now? Are there any other known issues on FreeNAS? My DVR install on macOS has been rock solid and want to make sure moving back to FreeNAS will not be a big hassle.
Also, it’s been a while since I installed the FreeNAS plugin. The early versions named the jail with the generic “customplugin_1” name. Is this still the case? If so, would you mind updating the plugin to name the jail something a little more Channels DVR specific? I tried renaming it manually but apparently it is a known issue that this is a bad idea to manually rename jails after they have been created.
The upgrade bug has been fixed.
I’m not sure how to change the jail name, but I can look into it.
I couldn’t find a way to specify what the jail name should be. Appears to be chosen by FreeNAS when installing a plugin.
Ok, thanks for checking into it.
Can someone try running these commands on their Intel-based FreeNAS:
kldstat
kldload dri
ls -ah /dev/dri
[root@lr-nas] /# kldstat
Id Refs Address Size Name
1 86 0xffffffff80200000 1903000 kernel
2 1 0xffffffff81de6000 ffd7c ispfw.ko
3 1 0xffffffff82011000 10677 geom_mirror.ko
4 1 0xffffffff82022000 4681 geom_stripe.ko
5 1 0xffffffff82027000 ffbe geom_raid3.ko
6 1 0xffffffff82037000 ec6a geom_raid5.ko
7 1 0xffffffff82046000 5752 geom_gate.ko
8 1 0xffffffff8204c000 4a2c geom_multipath.ko
9 1 0xffffffff82051000 571a fdescfs.ko
10 1 0xffffffff82057000 891 dtraceall.ko
11 10 0xffffffff82058000 3acf8 dtrace.ko
12 1 0xffffffff82093000 465f dtmalloc.ko
13 1 0xffffffff82098000 224f dtnfscl.ko
14 1 0xffffffff8209b000 63fd fbt.ko
15 1 0xffffffff820a2000 5799a fasttrap.ko
16 1 0xffffffff820fa000 49f0 lockstat.ko
17 1 0xffffffff820ff000 1620 sdt.ko
18 1 0xffffffff82101000 d8f1 systrace.ko
19 1 0xffffffff8210f000 d4b1 systrace_freebsd32.ko
20 1 0xffffffff8211d000 4dc6 profile.ko
21 1 0xffffffff82122000 7f72 ipmi.ko
22 1 0xffffffff8212a000 ec0 smbus.ko
23 1 0xffffffff8212b000 1a632 hwpmc.ko
24 1 0xffffffff82146000 c28a t3_tom.ko
25 2 0xffffffff82153000 42c7 toecore.ko
26 1 0xffffffff82158000 12afb t4_tom.ko
27 1 0xffffffff8216b000 2b4f uhid.ko
28 2 0xffffffff8216e000 2b82 vboxnetflt.ko
29 2 0xffffffff82171000 4e416 vboxdrv.ko
30 1 0xffffffff821c0000 41d5 ng_ether.ko
31 1 0xffffffff821c5000 3fd4 vboxnetadp.ko
32 1 0xffffffff821c9000 1fbc daemon_saver.ko
[root@lr-nas] /# kldload dri
kldload: can't load dri: No such file or directory
[root@lr-nas] /# ls -ah /dev/dri
ls: /dev/dri: No such file or directory
[root@lr-nas] /#
FreeNAS Info:
OS
Freebsd
10.3-stable (kernel: 10.3-stable)
CPU
4 cores / Intel® Core™ i5-2400 CPU @ 3.10GHz
load averages: 0.05 0.16 0.19
RAM
16.67 GB
35.1% free
Looks like FreeNAS does not ship with drm.ko
driver required for hardware acceleration.
Any update on FreeNAS hardware transcoding support? I just got an Intel NUC BOXNUC6CAYH running and installed FreeNAS with Channels, but the software encoding can't keep up real-time on the web interface. This is my first time using Channels DVR and first time installing FreeNAS/FreeBSD, and I kind of like it. Should I go with a Linux NAS server such as OpenMediaVault or something else?
It’s unclear if FreeBSD supports hardware transcoding at this time. You’re better off on Linux.