[Bug 222248] lldb is missing ObjectFile plugin to write cores

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48

--- Comment #2 from gergely.czu...@harmless.hu ---
The LLVM bug report: https://bugs.llvm.org/show_bug.cgi?id=34590

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222259] 11.1-R crashing in sendfile syscall, as used by a uwsgi process

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=59

--- Comment #4 from mark.marti...@ijs.si ---
> Rebuilding kernel now with  "makeoptions DEBUG=-g" ...

Looks like an improvement. Tonight there were four more crashes like this.

# ll /boot/kernel/kernel /var/crash/vmcore.8
-r-xr-xr-x  1 root  wheel26852240 Sep 13 00:26 /boot/kernel/kernel
-rw---  1 root  wheel  1039286272 Sep 13 08:00 /var/crash/vmcore.8

# kgdb /boot/kernel/kernel /var/crash/vmcore.8  
GNU gdb (GDB) 8.0 [GDB v8.0 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:
[15738] 
[15738] 
[15738] Fatal trap 12: page fault while in kernel mode
[15738] cpuid = 1; apic id = 01
[15738] fault virtual address   = 0xe8
[15738] fault code  = supervisor write data, page not present
[15738] instruction pointer = 0x20:0x80afefb2
[15738] stack pointer   = 0x28:0xfe02391355a0
[15738] frame pointer   = 0x28:0xfe02391355e0
[15738] code segment= base 0x0, limit 0xf, type 0x1b
[15738] = DPL 0, pres 1, long 1, def32 0, gran 1
[15738] processor eflags= interrupt enabled, resume, IOPL = 0
[15738] current process = 90843 (uwsgi)
[15738] trap number = 12
[15738] panic: page fault
[15738] cpuid = 1
[15738] KDB: stack backtrace:
[15738] #0 0x80aada97 at kdb_backtrace+0x67
[15738] #1 0x80a6bb76 at vpanic+0x186
[15738] #2 0x80a6b9e3 at panic+0x43
[15738] #3 0x80edf832 at trap_fatal+0x322
[15738] #4 0x80edf889 at trap_pfault+0x49
[15738] #5 0x80edf0c6 at trap+0x286
[15738] #6 0x80ec3641 at calltrap+0x8
[15738] #7 0x80a6a2af at sendfile_iodone+0xbf
[15738] #8 0x80a69eae at vn_sendfile+0x124e
[15738] #9 0x80a6a4dd at sendfile+0x13d
[15738] #10 0x80ee0394 at amd64_syscall+0x6c4
[15738] #11 0x80ec392b at Xfast_syscall+0xfb
[15738] Uptime: 4h22m18s
[15738] Dumping 991 out of 8129
MB:..2%..12%..21%..31%..41%..51%..62%..72%..81%..91%

__curthread () at ./machine/pcpu.h:222
222 __asm("movq %%gs:%1,%0" : "=r" (td)


(kgdb) bt

#0  __curthread () at ./machine/pcpu.h:222
#1  doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:298
#2  0x80a6b6f1 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:366
#3  0x80a6bbb0 in vpanic (fmt=, ap=0xfe0239135240)
at /usr/src/sys/kern/kern_shutdown.c:759
#4  0x80a6b9e3 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:690
#5  0x80edf832 in trap_fatal (frame=0xfe02391354e0, eva=232) at
/usr/src/sys/amd64/amd64/trap.c:801
#6  0x80edf889 in trap_pfault (frame=0xfe02391354e0, usermode=0) at
/usr/src/sys/amd64/amd64/trap.c:655
#7  0x80edf0c6 in trap (frame=0xfe02391354e0) at
/usr/src/sys/amd64/amd64/trap.c:421
#8  
#9  0x80afefb2 in atomic_fcmpset_long (dst=0xe8, expect=, src=) at ./machine/atomic.h:224
#10 uipc_ready (so=, m=0xf80014fb8800, count=4) at
/usr/src/sys/kern/uipc_usrreq.c:1075
#11 0x80a6a2af in sendfile_iodone (arg=0xf800344f5c00,
pg=, count=, error=0)
at /usr/src/sys/kern/kern_sendfile.c:293
#12 0x80a69eae in vn_sendfile (fp=, sockfd=, hdr_uio=0x0, trl_uio=, offset=,
nbytes=, sent=, flags=,
td=) at /usr/src/sys/kern/kern_sendfile.c:851
#13 0x80a6a4dd in fo_sendfile (fp=0x81d1d388
, sockfd=88170496, hdr_uio=0x1, trl_uio=0x1, offset=0,
nbytes=18446735281999667200, sent=0x1fff8, flags=4,
td=0xf80105416000) at /usr/src/sys/sys/file.h:378
#14 sendfile (td=0xf80105416000, uap=0xfe0239135a30, compat=0) at
/usr/src/sys/kern/kern_sendfile.c:977
#15 0x80ee0394 in syscallenter (td=, sa=)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#16 amd64_syscall (td=0xf80105416000, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:902
#17 
#18 0x00080221761a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffc868

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.

[Bug 222277] Don't (try to) build qlnx if the user objects to binary blobs

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=77

--- Comment #1 from commit-h...@freebsd.org ---
A commit references this bug:

Author: emaste
Date: Wed Sep 13 12:16:27 UTC 2017
New revision: 323539
URL: https://svnweb.freebsd.org/changeset/base/323539

Log:
  qlnx: exclude if WITHOUT_SOURCELESS_UCODE set

  PR:   77
  Submitted by: Fabian Keil
  Obtained from:ElectroBSD
  MFC after:1 week

Changes:
  head/sys/modules/Makefile

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222259] 11.1-R crashing in sendfile syscall, as used by a uwsgi process

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=59

--- Comment #5 from Steven Hartland  ---
Could you try compiling with WITNESS?

I'm wondering if it might be related to:
http://freebsd.1045724.x6.nabble.com/r315684-panic-sleepq-add-td-0xf80003c01a40-to-sleep-on-wchan-0xf80006f0873c-with-sleeping-prd-td6176029.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222277] Don't (try to) build qlnx if the user objects to binary blobs

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=77

Ed Maste  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|ema...@freebsd.org
 CC||ema...@freebsd.org
 Status|New |In Progress

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222248] lldb is missing ObjectFile plugin to write cores

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48

Ed Maste  changed:

   What|Removed |Added

 Status|New |Open
   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=34590

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222288] g_bio leak after zfs ABD commit

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=88

Bug ID: 88
   Summary: g_bio leak after zfs ABD commit
   Product: Base System
   Version: 11.1-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: dnel...@allantgroup.com

It looks like the ABD commit may have introduced a leak of geom bio structs. 
It's a slow leak so it's not obvious, but after a few weeks of uptime, one of
my 8GB-RAM systems had accumulated a couple million g_bio objects according to
vmstat (over 2GB of RAM) and was starting to swap.  I rebooted it, and after 11
hours, I'm up to 310182:

# uptime
 9:55AM  up 11:08, 11 users, load averages: 0.50, 0.54, 0.55
# vmstat -z | egrep 'ITEM|g_bio' 
ITEM   SIZE   LIMIT USED FREE   REQ   FAIL SLEEP
g_bio:  376,  0,  310182, 818, 38182778, 0,   0

Looking at base r321610 itself, it looks like there's a g_bio_destroy() call
that got relocated from vdev_geom_io_intr() to vdev_geom_io_done(); maybe there
are cases where vdev_geom_io_intr is called, but vdev_geom_io_done isn't?  I
don't know enough about ZFS internals to get any farther than this.

Rolling the kernel back to r321609 makes the leak stop, and updating to r321610
makes it appear again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222288] g_bio leak after zfs ABD commit

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=88

Andriy Gapon  changed:

   What|Removed |Added

 Status|New |Open
 CC||freebsd...@freebsd.org
   Assignee|freebsd-bugs@FreeBSD.org|a...@freebsd.org

--- Comment #1 from Andriy Gapon  ---
(In reply to Dan Nelson from comment #0)
Thank you very much for the report!
As soon as I read it I noticed that I have the same kind of issue.  I dug
through the biozone to examine the leaked bio-s and they all seem to have
bio_cmd = 5 and bio_flags = 8.  So, they seem to be BIO_FLUSH bio-s.  Their
zio-s must have been ZIO_TYPE_IOCTL.

Now, those zio-s use ZIO_IOCTL_PIPELINE and it is defined as:
#define ZIO_IOCTL_PIPELINE  \
(ZIO_INTERLOCK_STAGES | \
ZIO_STAGE_VDEV_IO_START |   \
ZIO_STAGE_VDEV_IO_ASSESS)

So, ZIO_STAGE_VDEV_IO_START is in the pipeline, but ZIO_STAGE_VDEV_IO_DONE is
not as you have correctly theorised.
The normal I/O pipelines always include ZIO_VDEV_IO_STAGES
#define ZIO_VDEV_IO_STAGES  \
(ZIO_STAGE_VDEV_IO_START |  \
ZIO_STAGE_VDEV_IO_DONE |\
ZIO_STAGE_VDEV_IO_ASSESS)
so the problem does not affect them.

I will double-check why the ioctl pipeline omitted ZIO_STAGE_VDEV_IO_DONE and
will test adding that stage.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222259] 11.1-R crashing in sendfile syscall, as used by a uwsgi process

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=59

Gleb Smirnoff  changed:

   What|Removed |Added

 Status|New |Open
 CC||gleb...@freebsd.org
   Assignee|freebsd-bugs@FreeBSD.org|gleb...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222308] ip_multicast: Panic due to VNET being invalid on lagg during SIOCDELMULTI

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222308

Bug ID: 222308
   Summary: ip_multicast: Panic due to VNET being invalid on lagg
during SIOCDELMULTI
   Product: Base System
   Version: 11.1-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: br...@beanfield.com

Issue is detailed in a patch to FreeNAS by Chris Torek, seen here:
https://github.com/freenas/os/commit/34462da8e3b1089311dd4627953d558929cc04fc#diff-c9065ed6e74837c7cb1ded9eb39e7fb9

I believe this panic is currently affecting me on nas4free 11.1.0.4 which
utilizes FreeBSD 11.1-RELEASE-P1

Copying his comments:

In in_leavegroup_locked(), when we're shedding a multicast
group, we may (or may not) delete it from an interface via
the igmp_change_state() call.  This is where we currently
set the multicast's vnet, and then restore the old vnet on
return.

However, a few lines later we use inm_release_locked() to
release the inet multicast data structure, and that in turn
may -- not necessarily will, only if the inm really is being
freed -- call if_delmulti_ifma(), which may -- not necessarily
will, again -- call the interface's SIOCDELMULTI ioctl
(if and only if there is an interface and this was the last
ref to this multicast address).

For (at least) the lagg interface, we still need the current
vnet to be valid during the SIOCDELMULTI.  So, don't restore
the old vnet until we've not only finished the IGMP code but
also inm_release_locked().

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222308] ip_multicast: Panic due to VNET being invalid on lagg during SIOCDELMULTI

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222308

--- Comment #1 from br...@beanfield.com ---
I'll mention as well that Chris has two other fixes for issues in the
in_mcast.c code that are worth looking at:

"Turning on multicast debug made multicast failure worse
because the strings and #define values no longer matched
up.  Fix them, and make sure they stay matched-up.":

https://github.com/freenas/os/commit/f768c70f166fb547bfa5559c934ddd41fe4dcc4e#diff-c9065ed6e74837c7cb1ded9eb39e7fb9

"During if_detach(), we get a race where a closing socket is
releasing multicast data (via inp_freemoptions()) at the same
time as igmp_ifdetach() is releasing all multicast data for
the interface, resulting in a potential double teardown and
double free. ...":

https://github.com/freenas/os/commit/83854288f897f0e886a2a6f17d2583081b8e25cb#diff-c9065ed6e74837c7cb1ded9eb39e7fb9

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 221991] i915kms: constant DRM errors

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221991

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #2 from Ed Maste  ---
The common errors from the log:

4352 t520 kernel: error: [drm:pid1064:__gen6_gt_force_wake_get] *ERROR* Timed
out waiting for forcewake to ack request.
4155 t520 kernel: error: [drm:pid1064:__gen6_gt_wait_for_thread_c0] *ERROR* GT
thread status wait timed out
4145 t520 kernel: error: [drm:pid1064:gen6_gt_check_fifodbg] *ERROR* MMIO read
or write has been dropped 3

Does this happen before / after suspend+resume (or both)?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 221550] kern.bootfile returns only /kernel on mips64 (ERL) platform

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221550

--- Comment #1 from Kurt Lidl  ---
It's probably obvious, but I'll post a workaround here too -
since the edgerouter pretty much always boots the same
kernel file...

Most people setup the boot command to do something like this:

boot_freebsd=fatload usb 0 $loadaddr kernel/kernel ; bootoctlinux $loadaddr
coremask=0x3

And then they have the msdos filesystem holding the kernel mounted as
/boot:

The right thing for kern.bootfile ought to be set to
/boot/kernel/kernel, so just do the following:

echo 'kern.bootfile=/boot/kernel/kernel' >> /etc/sysctl.conf
sysctl kern.bootfile=/boot/kernel/kernel

And then 'make installkernel' will do the right thing...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 218911] [uma] Memory corruption with certain item sizes

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218911

--- Comment #6 from commit-h...@freebsd.org ---
A commit references this bug:

Author: markj
Date: Wed Sep 13 21:54:38 UTC 2017
New revision: 323564
URL: https://svnweb.freebsd.org/changeset/base/323564

Log:
  Widen uk_pgoff, the slab header offset field.

  16 bits is only wide enough for kegs with an item size of up to 64KB.
  At that size or larger, slab headers are typically offpage because the
  item size is a multiple of the page size, but there is no requirement
  that this be the case.

  We can widen the field without affecting the layout of struct uma_keg
  since the removal of uk_slabsize in r315077 left an adjacent hole.

  PR:   218911
  MFC after:2 weeks

Changes:
  head/sys/vm/uma_int.h

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219689] [PATCH] systat segfault when invoked with some invalid arguments

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219689

Ed Maste  changed:

   What|Removed |Added

 Status|New |Open
 CC||ema...@freebsd.org

--- Comment #1 from Ed Maste  ---
Confirmed reproducible on 12-current r321400

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 221991] i915kms: constant DRM errors

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221991

--- Comment #3 from verma...@interia.pl ---
Both.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222258] renameat(2) capability error with absolute path names outside of a sandbox

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=58

t...@develop-help.com changed:

   What|Removed |Added

 CC||t...@develop-help.com

--- Comment #2 from t...@develop-help.com ---
Yes, the code grabs a handle to the cwd when opening the file for -i and uses
that handle when cleaning up when the file is closed, in this specific case
when renaming the original file to a backup file, or renaming the work file
over the original file.

If we were passing AT_FDCWD we could just call rename().

I have a workaround patch (for perl) that calls rename() for absolute paths on
FreeBSD if Mathieu wants to try it on the tonyc/127663-freebsd-renameat branch
in the perl5 git at git://perl5.git.perl.org/perl.git

I do wonder if renameat() will behave correctly in a container on FreeBSD.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222314] VNET jail panics kernel (arm64)

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222314

Bug ID: 222314
   Summary: VNET jail panics kernel (arm64)
   Product: Base System
   Version: 11.1-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: he...@project-fifo.net

Starting a jail with vnets panics the kernel, this is not a duplicate of
#213896 as the patch mentioned there was applied to the kernel in question.

I'm not sure weather or not it is a arm64 related issue or not, it is a arm64
system but the nic used is a normal intel nic.

login: lock order reversal:
 1st 0xfd0094344418 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:849
 2nd 0xfd0094344240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2533
stack backtrace:
#0 0x002eee98 at witness_debugger+0x64
#1 0x0026ad88 at lockmgr_lock_fast_path+0x1b4
#2 0x00590634 at VOP_LOCK1_APV+0xcc
#3 0x0035cf3c at _vn_lock+0x6c
#4 0x0034e98c at vget+0x78
#5 0x0017d6a8 at devfs_allocv+0xdc
#6 0x0017d1e0 at devfs_root+0x44
#7 0x00345d2c at vfs_donmount+0x102c
#8 0x00344ccc at sys_nmount+0x68
#9 0x00573404 at do_el0_sync+0x8c8
#10 0x0055c9f4 at handle_el0_sync+0x74
panic: vm_fault: fault on nofault entry, addr: 999ee000
cpuid = 18
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
 pc = 0x0055ae28  lr = 0x0005eb10
 sp = 0x00061d8dae40  fp = 0x00061d8db050

db_trace_self_wrapper() at vpanic+0x170
 pc = 0x0005eb10  lr = 0x0029346c
 sp = 0x00061d8db060  fp = 0x00061d8db0e0

vpanic() at panic+0x48
 pc = 0x0029346c  lr = 0x002934f8
 sp = 0x00061d8db0f0  fp = 0x00061d8db170

panic() at vm_fault_hold+0x1ab0
 pc = 0x002934f8  lr = 0x0052f1dc
 sp = 0x00061d8db180  fp = 0x00061d8db2d0

vm_fault_hold() at vm_fault+0x70
 pc = 0x0052f1dc  lr = 0x0052d6dc
 sp = 0x00061d8db2e0  fp = 0x00061d8db310

vm_fault() at data_abort+0xd8
 pc = 0x0052d6dc  lr = 0x005729dc
 sp = 0x00061d8db320  fp = 0x00061d8db3d0

data_abort() at handle_el1h_sync+0x74
 pc = 0x005729dc  lr = 0x0055c874
 sp = 0x00061d8db3e0  fp = 0x00061d8db4f0

handle_el1h_sync() at vnet_epair_init+0x2c
 pc = 0x0055c874  lr = 0x5996674c
 sp = 0x00061d8db500  fp = 0x00061d8db580

vnet_epair_init() at vnet_register_sysinit+0x100
 pc = 0x5996674c  lr = 0x0039e000
 sp = 0x00061d8db590  fp = 0x00061d8db5b0

vnet_register_sysinit() at linker_load_module+0xaac
 pc = 0x0039e000  lr = 0x00266a68
 sp = 0x00061d8db5c0  fp = 0x00061d8db8e0

linker_load_module() at kern_kldload+0xec
 pc = 0x00266a68  lr = 0x00268120
 sp = 0x00061d8db8f0  fp = 0x00061d8db920

kern_kldload() at sys_kldload+0x64
 pc = 0x00268120  lr = 0x00268278
 sp = 0x00061d8db930  fp = 0x00061d8db950

sys_kldload() at do_el0_sync+0x8c8
 pc = 0x00268278  lr = 0x00573404
 sp = 0x00061d8db960  fp = 0x00061d8dba80

do_el0_sync() at handle_el0_sync+0x74
 pc = 0x00573404  lr = 0x0055c9f4
 sp = 0x00061d8dba90  fp = 0x00061d8dbba0

handle_el0_sync() at 0x21278
 pc = 0x0055c9f4  lr = 0x00021278
 sp = 0x00061d8dbbb0  fp = 0xe2d0

KDB: enter: panic
[ thread pid 1053 tid 101161 ]
Stopped at  kdb_enter+0x40: undefined   d420

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222314] ifconfig epair create panics the kernel (arm64)

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222314

Heinz N. Gies  changed:

   What|Removed |Added

Summary|VNET jail panics kernel |ifconfig epair create
   |(arm64) |panics the kernel (arm64)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222314] ifconfig epair create panics the kernel (arm64)

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222314

--- Comment #1 from Heinz N. Gies  ---
I changed the description as this can be introduced by the simple command:

ifconfig epair create

that it was called as part of a vnet jail seems to have been coincidence (or a
second bug?)

I feel like this is more likely arm specific so I'll move it to the arm
component rather than the kern one since I've created epairs successfully in
the past - OTOH it might be more related to 48 cores then the architecture?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 222314] ifconfig epair create panics the kernel (arm64)

2017-09-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222314

Heinz N. Gies  changed:

   What|Removed |Added

  Component|kern|arm

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"