Bug 215000 - webcamd panic
Summary: webcamd panic
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.0-STABLE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-02 12:19 UTC by Anton Shterenlikht
Modified: 2019-04-10 18:22 UTC (History)
2 users (show)

See Also:

Attachments
core.txt (99.25 KB, text/plain)
2016-12-02 12:19 UTC, Anton Shterenlikht 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Shterenlikht 2016-12-02 12:19:54 UTC 
Created attachment 177600 [details]
core.txt

FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24 06:55:27 UTC 2016
    root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

# cat /boot/loader.conf 
if_iwm_load="YES"
iwm3160fw_load="YES"
iwm7260fw_load="YES"
iwm7265fw_load="YES"
linux_load="YES"
cuse4bsd_load="YES"

Panics every time when webcamd_enable="YES" is added to
rc.conf. If webcamd is started manually, panic does not happen
immediately, and for a while the camera works, checked with pvcview.

See core.txt.7 attached.

Briefly:

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0x100000019
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80b4392e
stack pointer           = 0x28:0xfffffe0234b714f0
frame pointer           = 0x28:0xfffffe0234b71540
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 378 (webcamd)
trap number             = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0xffffffff80b24077 at kdb_backtrace+0x67
#1 0xffffffff80ad93e2 at vpanic+0x182
#2 0xffffffff80ad9253 at panic+0x43
#3 0xffffffff80fa0d51 at trap_fatal+0x351
#4 0xffffffff80fa0f43 at trap_pfault+0x1e3
#5 0xffffffff80fa04ec at trap+0x26c
#6 0xffffffff80f84141 at calltrap+0x8
#7 0xffffffff82581318 at cuse_server_close+0x178
#8 0xffffffff80985a35 at devfs_close+0x5e5
#9 0xffffffff8110ade9 at VOP_CLOSE_APV+0x89
#10 0xffffffff80bbdcce at vn_close+0x13e
#11 0xffffffff80bbc77a at vn_closefile+0x4a
#12 0xffffffff8098665c at devfs_close_f+0x2c
#13 0xffffffff80a735ca at _fdrop+0x1a
#14 0xffffffff80a770a4 at closef+0x2d4
#15 0xffffffff80a76b3d at fdescfree_fds+0x7d
#16 0xffffffff80a766f2 at fdescfree+0x6a2
#17 0xffffffff80a8855a at exit1+0x73a
Comment 1 Anton Shterenlikht 2016-12-07 10:28:33 UTC 
Suggested by scf@ in a private mail:

"I do suspect it is the specific cuse module you are loading.  It is possible that you are loading a module compiled for 10 when you are running 11.  Regardless, you should not be loading cuse4bsd any longer.  cuse(4) is part of FreeBSD 11 now. cuse_load="YES" is what you want."

Indeed changing to
cuse_load="YES"

fixed to the problem.

I think this PR can be closed.

However, the webcamd man page needs updating
because it still points to cuse4bsd:

WEBCAMD(8)              FreeBSD System Manager's Manual             WEBCAMD(8)

     webcamd requires the cuse4bsd(3) kernel module. To load the driver as a
     module at boot time, place the following line in loader.conf(5):

            cuse4bsd_load="YES"
Comment 2 Walter Schwarzenfeld freebsd_triage 2018-01-13 22:18:18 UTC 
Is this still relevant?