Re: stable/11 -r308135 Build for RPI2 failed for: . . ./bcm2835_ft5406.c:65:10: fatal error: 'mbox_if.h' file not found [Fixed]

2016-11-14 Thread Mark Millard 
On 2016-Nov-2, at 12:16 PM, Mark Millard  wrote:

> Quick top post reporting that a build-order-race for -j use seems likely: the 
> clean-then-build sequence
> 
>> Command: env __MAKE_CONF=/root/src.configs/make.conf 
>> SRC_ENV_CONF=/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host 
>> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/rpi2_clang make cleanworld
>> 
>> Command: env __MAKE_CONF=/root/src.configs/make.conf 
>> SRC_ENV_CONF=/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host 
>> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/rpi2_clang make -j 5 buildworld 
>> buildkernel
> 
> that used -j 5 for buildworld buildkernel got the problem again. But 
> following that failure by doing just buildkernel without the -j 5:
> 
>> Command: env __MAKE_CONF=/root/src.configs/make.conf 
>> SRC_ENV_CONF=/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host 
>> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/rpi2_clang make buildkernel
> 
> completed the rest of the build just fine, creating the previously-missing 
> file before trying to use it.
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2016-Nov-2, at 3:13 AM, Mark Millard  wrote:
> 
>> Lack of dependency? Race? (I've not isolated why this happened yet but I was 
>> using -j 5 for buildworld buildkernel .)
>> 
>> This was a cross-build attempt from an amd64 context:
>> 
>> # uname -apKU
>> FreeBSD FreeBSDx64 11.0-STABLE FreeBSD 11.0-STABLE #1 r308135M: Tue Nov  1 
>> 23:48:47 PDT 2016 
>> root@FreeBSDx64:/usr/obj/amd64_clang/amd64.amd64/usr/src/sys/GENERIC-NODBG  
>> amd64 amd64 1100506 1100506
>> 
>> # svnlite info /usr/src/ | grep "Re[lv]"
>> Relative URL: ^/stable/11
>> Revision: 308135
>> Last Changed Rev: 308135
>> 
>> # find /usr/src/sys/ -name "*files*" -exec grep mbox_if {} \; -print | more
>> dev/mbox/mbox_if.m  standard
>> /usr/src/sys/arm/broadcom/bcm2835/files.bcm283x
>> dev/mbox/mbox_if.m  optionalti_mbox
>> /usr/src/sys/arm/ti/files.ti
>> 
>> # find /usr/obj/rpi2_clang/arm.armv6/ -name mbox_if.h -print | more  
>>  
>>  
>>   
>> #
>> 
>> (So no mbox_if.h file is present in the build tree.)
>> 
>> # head 
>> ~/sys_typescripts/typescript_make_rpi2_nodebug_clang_bootstrap-amd64-host-2016-11-02:00:59:43
>> Script started on Wed Nov  2 00:59:43 2016
>> Command: env __MAKE_CONF=/root/src.configs/make.conf 
>> SRC_ENV_CONF=/root/src.configs/src.conf.rpi2-clang-bootstrap.amd64-host 
>> WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/rpi2_clang make -j 5 buildworld 
>> buildkernel
>> . . .
>> --- all_subdir_rpi_ft5406 ---
>> --- bcm2835_ft5406.o ---
>> /usr/src/sys/modules/rpi_ft5406/../../arm/broadcom/bcm2835//bcm2835_ft5406.c:65:10:
>>  fatal error: 'mbox_if.h' file not found
>> #include "mbox_if.h"
>>^
>> 1 error generated.
>> *** [bcm2835_ft5406.o] Error code 1
. . .

Looks like stable/11 -r308655 fix this. (-r308581 for head.) :

Author: gonzo
Date: Mon Nov 14 22:39:33 2016
New Revision: 308655
URL: 
https://svnweb.freebsd.org/changeset/base/308655


Log:
  MFC r308581:
  
  [rpi_ft5406] Add missing dependency on mbox_if.h
  
  Submitted by: hselasky

Modified:
  stable/11/sys/modules/rpi_ft5406/Makefile
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/modules/rpi_ft5406/Makefile
==
--- stable/11/sys/modules/rpi_ft5406/Makefile   Mon Nov 14 22:33:57 2016
(r308654)
+++ stable/11/sys/modules/rpi_ft5406/Makefile   Mon Nov 14 22:39:33 2016
(r308655)
@@ -5,6 +5,6 @@
 KMOD=  rpi_ft5406
 SRCS=  bcm2835_ft5406.c
 
-SRCS+= bus_if.h device_if.h ofw_bus_if.h
+SRCS+= bus_if.h device_if.h mbox_if.h ofw_bus_if.h
 
 .include 


===
Mark Millard
markmi at dsl-only.net


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with Dell external USB DVD drive

2016-11-14 Thread Felix Johnson 
Hi Kevin,

The drive was plugged in when I used usbconfig.

When I plug the drive in, the drive makes a powering-up noise, as if it's
trying to align with a disk that may be inside it.
Unfortunately, there are no console messages. I've tried the USB 2 and USB
3 ports, with no change -
the device powers up but there is no console message.

Besides usbconfig, is there another command I can try to probe individual
USB ports?

Felix Johnson

On Sun, Nov 13, 2016 at 9:10 PM, Kevin Oberman  wrote:

> On Sun, Nov 13, 2016 at 5:56 PM, Felix Johnson 
> wrote:
>
>> Hello,
>>
>> I have a Dell Inspiron 7547, which lacks an internal CD/DVD drive.
>> I purchased a Dell DW514 external USB DVD drive, which works in Windows,
>> but can't be located in FreeBSD 11.0-p2. I am looking for help in getting
>> FreeBSD
>> to recognize the device.
>>
>> Any help is appreciated, since this is an important step to using this
>> laptop
>> full-time as a FreeBSD workstation.
>>
>> Here is the information I have on my system:
>>
>> [fjohnson@laptop /usr/home/fjohnson]$ uname -a
>> FreeBSD laptop 11.0-RELEASE-p2 FreeBSD 11.0-RELEASE-p2 #0: Mon Oct 24
>> 06:55:27 UTC 2016
>> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
>>  amd64
>>
>> [fjohnson@laptop /usr/home/fjohnson]$ sudo usbconfig
>> ugen0.1:  at usbus0, cfg=0 md=HOST spd=SUPER
>> (5.0Gbps) pwr=SAVE (0mA)
>> ugen1.1:  at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
>> pwr=SAVE (0mA)
>> ugen0.2:  at usbus0, cfg=0 md=HOST spd=HIGH
>> (480Mbps) pwr=SAVE (100mA)
>> ugen1.2:  at usbus1, cfg=0 md=HOST spd=HIGH
>> (480Mbps) pwr=SAVE (0mA)
>> ugen0.3:  at usbus0, cfg=0 md=HOST spd=FULL
>> (12Mbps)
>> pwr=ON (98mA)
>> ugen0.4:  at usbus0, cfg=0 md=HOST spd=HIGH
>> (480Mbps) pwr=ON (450mA)
>> ugen0.5:  at usbus0, cfg=0 md=HOST spd=HIGH
>> (480Mbps) pwr=ON (500mA)
>> ugen0.6:  at usbus0, cfg=0 md=HOST spd=HIGH
>> (480Mbps) pwr=ON (500mA)
>> ugen0.7:  at usbus0, cfg=0 md=HOST spd=FULL (12Mbps)
>> pwr=ON (100mA)
>>
>> [...]
>>
>
>
>> Thank you!
>> Felix Johnson
>>
>
> Can I assume that the drive was plugged in when the usbconfig command was
> issued? I don't see any indication of it in the output. I was expecting a
> vendor/product that was not known to the system, but that does nto appear
> to be the case. the only two not identified have and the first in an Intel
> vendor ID and the second appears to be an Asix Ethernet controller, though
> the information on that is sketchy.
>
> When you plug in the drive, the console should show a message. A similar
> message should be sent when it is unplugged. Can you try that and report
> the message? It should include the vendor and product IDs.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Freebsd 11.0 RELEASE - ZFS deadlock

2016-11-14 Thread Henri Hennebert 



On 11/14/2016 12:45, Andriy Gapon wrote:

On 14/11/2016 11:35, Henri Hennebert wrote:



On 11/14/2016 10:07, Andriy Gapon wrote:

Hmm, I've just noticed another interesting thread:
Thread 668 (Thread 101245):
#0  sched_switch (td=0xf800b642aa00, newtd=0xf8000285f000, flags=) at /usr/src/sys/kern/sched_ule.c:1973
#1  0x80561ae2 in mi_switch (flags=, newtd=0x0) at
/usr/src/sys/kern/kern_synch.c:455
#2  0x805ae8da in sleepq_wait (wchan=0x0, pri=0) at
/usr/src/sys/kern/subr_sleepqueue.c:646
#3  0x805614b1 in _sleep (ident=, lock=, priority=, wmesg=0x809c51bc
"vmpfw", sbt=0, pr=, flags=) at
/usr/src/sys/kern/kern_synch.c:229
#4  0x8089d1c1 in vm_page_busy_sleep (m=0xf800df68cd40, wmesg=) at /usr/src/sys/vm/vm_page.c:753
#5  0x8089dd4d in vm_page_sleep_if_busy (m=0xf800df68cd40,
msg=0x809c51bc "vmpfw") at /usr/src/sys/vm/vm_page.c:1086
#6  0x80886be9 in vm_fault_hold (map=, vaddr=, fault_type=4 '\004', fault_flags=0, m_hold=0x0) at
/usr/src/sys/vm/vm_fault.c:495
#7  0x80885448 in vm_fault (map=0xf80011d66000, vaddr=, fault_type=4 '\004', fault_flags=) at
/usr/src/sys/vm/vm_fault.c:273
#8  0x808d3c49 in trap_pfault (frame=0xfe0101836c00, usermode=1) at
/usr/src/sys/amd64/amd64/trap.c:741
#9  0x808d3386 in trap (frame=0xfe0101836c00) at
/usr/src/sys/amd64/amd64/trap.c:333
#10 0x808b7af1 in calltrap () at 
/usr/src/sys/amd64/amd64/exception.S:236


This tread is another program from the news system:
668 Thread 101245 (PID=49124: innfeed)  sched_switch (td=0xf800b642aa00,
newtd=0xf8000285f000, flags=) at
/usr/src/sys/kern/sched_ule.c:1973



I strongly suspect that this is thread that we were looking for.
I think that it has the vnode lock in the shared mode while trying to fault in a
page.



--clip--



Okay.  Luckily for us, it seems that 'm' is available in frame 5.  It also
happens to be the first field of 'struct faultstate'.  So, could you please go
to frame and print '*m' and '*(struct faultstate *)m' ?


(kgdb) fr 4
#4  0x8089d1c1 in vm_page_busy_sleep (m=0xf800df68cd40, 
wmesg=) at /usr/src/sys/vm/vm_page.c:753

753 msleep(m, vm_page_lockptr(m), PVM | PDROP, wmesg, 0);
(kgdb) print *m
$1 = {plinks = {q = {tqe_next = 0xf800dc5d85b0, tqe_prev = 
0xf800debf3bd0}, s = {ss = {sle_next = 0xf800dc5d85b0},
  pv = 0xf800debf3bd0}, memguard = {p = 18446735281313646000, v 
= 18446735281353604048}}, listq = {tqe_next = 0x0,
tqe_prev = 0xf800dc5d85c0}, object = 0xf800b62e9c60, pindex 
= 11, phys_addr = 3389358080, md = {pv_list = {
  tqh_first = 0x0, tqh_last = 0xf800df68cd78}, pv_gen = 426, 
pat_mode = 6}, wire_count = 0, busy_lock = 6, hold_count = 0,
  flags = 0, aflags = 2 '\002', oflags = 0 '\0', queue = 0 '\0', psind 
= 0 '\0', segind = 3 '\003', order = 13 '\r',

  pool = 0 '\0', act_count = 0 '\0', valid = 0 '\0', dirty = 0 '\0'}
(kgdb) print *(struct faultstate *)m
$2 = {m = 0xf800dc5d85b0, object = 0xf800debf3bd0, pindex = 0, 
first_m = 0xf800dc5d85c0,
  first_object = 0xf800b62e9c60, first_pindex = 11, map = 
0xca058000, entry = 0x0, lookup_still_valid = -546779784,

  vp = 0x601aa}
(kgdb)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Freebsd 11.0 RELEASE - ZFS deadlock

2016-11-14 Thread Andriy Gapon 
On 14/11/2016 11:35, Henri Hennebert wrote:
> 
> 
> On 11/14/2016 10:07, Andriy Gapon wrote:
>> Hmm, I've just noticed another interesting thread:
>> Thread 668 (Thread 101245):
>> #0  sched_switch (td=0xf800b642aa00, newtd=0xf8000285f000, 
>> flags=> optimized out>) at /usr/src/sys/kern/sched_ule.c:1973
>> #1  0x80561ae2 in mi_switch (flags=, newtd=0x0) 
>> at
>> /usr/src/sys/kern/kern_synch.c:455
>> #2  0x805ae8da in sleepq_wait (wchan=0x0, pri=0) at
>> /usr/src/sys/kern/subr_sleepqueue.c:646
>> #3  0x805614b1 in _sleep (ident=, lock=> optimized out>, priority=, wmesg=0x809c51bc
>> "vmpfw", sbt=0, pr=, flags=) at
>> /usr/src/sys/kern/kern_synch.c:229
>> #4  0x8089d1c1 in vm_page_busy_sleep (m=0xf800df68cd40, 
>> wmesg=> optimized out>) at /usr/src/sys/vm/vm_page.c:753
>> #5  0x8089dd4d in vm_page_sleep_if_busy (m=0xf800df68cd40,
>> msg=0x809c51bc "vmpfw") at /usr/src/sys/vm/vm_page.c:1086
>> #6  0x80886be9 in vm_fault_hold (map=, 
>> vaddr=> optimized out>, fault_type=4 '\004', fault_flags=0, m_hold=0x0) at
>> /usr/src/sys/vm/vm_fault.c:495
>> #7  0x80885448 in vm_fault (map=0xf80011d66000, vaddr=> optimized out>, fault_type=4 '\004', fault_flags=) at
>> /usr/src/sys/vm/vm_fault.c:273
>> #8  0x808d3c49 in trap_pfault (frame=0xfe0101836c00, usermode=1) 
>> at
>> /usr/src/sys/amd64/amd64/trap.c:741
>> #9  0x808d3386 in trap (frame=0xfe0101836c00) at
>> /usr/src/sys/amd64/amd64/trap.c:333
>> #10 0x808b7af1 in calltrap () at 
>> /usr/src/sys/amd64/amd64/exception.S:236
> 
> This tread is another program from the news system:
> 668 Thread 101245 (PID=49124: innfeed)  sched_switch (td=0xf800b642aa00,
> newtd=0xf8000285f000, flags=) at
> /usr/src/sys/kern/sched_ule.c:1973
> 
>>
>> I strongly suspect that this is thread that we were looking for.
>> I think that it has the vnode lock in the shared mode while trying to fault 
>> in a
>> page.
>>
>> Could you please check that by going to frame 6 and printing 'fs' and 
>> '*fs.vp'?
>> It'd be interesting to understand why this thread is waiting here.
>> So, please also print '*fs.m' and '*fs.object'.
> 
> No luck :-(
> (kgdb) fr 6
> #6  0x80886be9 in vm_fault_hold (map=, 
> vaddr= optimized out>, fault_type=4 '\004',
> fault_flags=0, m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:495
> 495vm_page_sleep_if_busy(fs.m, "vmpfw");
> (kgdb) print fs
> Cannot access memory at address 0x1fa0
> (kgdb)

Okay.  Luckily for us, it seems that 'm' is available in frame 5.  It also
happens to be the first field of 'struct faultstate'.  So, could you please go
to frame and print '*m' and '*(struct faultstate *)m' ?

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Freebsd 11.0 RELEASE - ZFS deadlock

2016-11-14 Thread Henri Hennebert 



On 11/14/2016 10:07, Andriy Gapon wrote:

On 13/11/2016 15:28, Henri Hennebert wrote:

On 11/13/2016 11:06, Andriy Gapon wrote:

On 12/11/2016 14:40, Henri Hennebert wrote:



[snip]

Could you please show 'info local' in frame 14?
I expected that 'nd' variable would be defined there and it may contain some
useful information.


No luck there:

(kgdb) fr 14
#14 0x80636838 in kern_statat (td=0xf80009ba0500, 
flag=, fd=-100, path=0x0,
pathseg=, sbp=, 
hook=0x800e2a388) at /usr/src/sys/kern/vfs_syscalls.c:2160

2160if ((error = namei()) != 0)
(kgdb) info local
rights = 
nd = 
error = 
sb = 
(kgdb)



I also try to get information from the execve of the other treads:

for tid 101250:
(kgdb) fr 10
#10 0x80508ccc in sys_execve (td=0xf800b6429000,
uap=0xfe010184fb80) at /usr/src/sys/kern/kern_exec.c:218
218error = kern_execve(td, , NULL);
(kgdb) print *uap
$4 = {fname_l_ = 0xfe010184fb80 "`\220\217\002\b", fname = 0x8028f9060
,
  fname_r_ = 0xfe010184fb88 "`¶ÿÿÿ\177", argv_l_ = 0xfe010184fb88
"`¶ÿÿÿ\177", argv = 0x7fffb660,
  argv_r_ = 0xfe010184fb90 "\bÜÿÿÿ\177", envv_l_ = 0xfe010184fb90
"\bÜÿÿÿ\177", envv = 0x7fffdc08,
  envv_r_ = 0xfe010184fb98 ""}
(kgdb)

for tid 101243:

(kgdb) f 15
#15 0x80508ccc in sys_execve (td=0xf800b642b500,
uap=0xfe010182cb80) at /usr/src/sys/kern/kern_exec.c:218
218error = kern_execve(td, , NULL);
(kgdb) print *uap
$5 = {fname_l_ = 0xfe010182cb80 "ÀÏ\205\002\b", fname = 0x80285cfc0 ,
  fname_r_ = 0xfe010182cb88 "`¶ÿÿÿ\177", argv_l_ = 0xfe010182cb88
"`¶ÿÿÿ\177", argv = 0x7fffb660,
  argv_r_ = 0xfe010182cb90 "\bÜÿÿÿ\177", envv_l_ = 0xfe010182cb90
"\bÜÿÿÿ\177", envv = 0x7fffdc08,
  envv_r_ = 0xfe010182cb98 ""}
(kgdb)


I think that you see garbage in those structures because they contain pointers
to userland data.

Hmm, I've just noticed another interesting thread:
Thread 668 (Thread 101245):
#0  sched_switch (td=0xf800b642aa00, newtd=0xf8000285f000, flags=) at /usr/src/sys/kern/sched_ule.c:1973
#1  0x80561ae2 in mi_switch (flags=, newtd=0x0) at
/usr/src/sys/kern/kern_synch.c:455
#2  0x805ae8da in sleepq_wait (wchan=0x0, pri=0) at
/usr/src/sys/kern/subr_sleepqueue.c:646
#3  0x805614b1 in _sleep (ident=, lock=, priority=, wmesg=0x809c51bc
"vmpfw", sbt=0, pr=, flags=) at
/usr/src/sys/kern/kern_synch.c:229
#4  0x8089d1c1 in vm_page_busy_sleep (m=0xf800df68cd40, wmesg=) at /usr/src/sys/vm/vm_page.c:753
#5  0x8089dd4d in vm_page_sleep_if_busy (m=0xf800df68cd40,
msg=0x809c51bc "vmpfw") at /usr/src/sys/vm/vm_page.c:1086
#6  0x80886be9 in vm_fault_hold (map=, vaddr=, fault_type=4 '\004', fault_flags=0, m_hold=0x0) at
/usr/src/sys/vm/vm_fault.c:495
#7  0x80885448 in vm_fault (map=0xf80011d66000, vaddr=, fault_type=4 '\004', fault_flags=) at
/usr/src/sys/vm/vm_fault.c:273
#8  0x808d3c49 in trap_pfault (frame=0xfe0101836c00, usermode=1) at
/usr/src/sys/amd64/amd64/trap.c:741
#9  0x808d3386 in trap (frame=0xfe0101836c00) at
/usr/src/sys/amd64/amd64/trap.c:333
#10 0x808b7af1 in calltrap () at 
/usr/src/sys/amd64/amd64/exception.S:236


This tread is another program from the news system:
668 Thread 101245 (PID=49124: innfeed)  sched_switch 
(td=0xf800b642aa00, newtd=0xf8000285f000, flags=out>) at /usr/src/sys/kern/sched_ule.c:1973




I strongly suspect that this is thread that we were looking for.
I think that it has the vnode lock in the shared mode while trying to fault in a
page.

Could you please check that by going to frame 6 and printing 'fs' and '*fs.vp'?
It'd be interesting to understand why this thread is waiting here.
So, please also print '*fs.m' and '*fs.object'.


No luck :-(
(kgdb) fr 6
#6  0x80886be9 in vm_fault_hold (map=, 
vaddr=, fault_type=4 '\004',

fault_flags=0, m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:495
495 vm_page_sleep_if_busy(fs.m, 
"vmpfw");
(kgdb) print fs
Cannot access memory at address 0x1fa0
(kgdb)

Henri
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Freebsd 11.0 RELEASE - ZFS deadlock

2016-11-14 Thread Andriy Gapon 
On 13/11/2016 15:28, Henri Hennebert wrote:
> On 11/13/2016 11:06, Andriy Gapon wrote:
>> On 12/11/2016 14:40, Henri Hennebert wrote:
>>> I attatch it
>>
>> Thank you!
>> So, these two threads are trying to get the lock in the exclusive mode:
>> Thread 687 (Thread 101243):
>> #0  sched_switch (td=0xf800b642b500, newtd=0xf8000285ea00, 
>> flags=> optimized out>) at /usr/src/sys/kern/sched_ule.c:1973
>> #1  0x80561ae2 in mi_switch (flags=, newtd=0x0) 
>> at
>> /usr/src/sys/kern/kern_synch.c:455
>> #2  0x805ae8da in sleepq_wait (wchan=0x0, pri=0) at
>> /usr/src/sys/kern/subr_sleepqueue.c:646
>> #3  0x8052f854 in sleeplk (lk=, flags=> optimized out>, ilk=, wmesg=0x813be535 "zfs",
>> pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222
>> #4  0x8052f39d in __lockmgr_args (lk=, 
>> flags=> optimized out>, ilk=, wmesg=,
>> pri=, timo=, file=> out>, line=) at /usr/src/sys/kern/kern_lock.c:958
>> #5  0x80616a8c in vop_stdlock (ap=) at 
>> lockmgr.h:98
>> #6  0x8093784d in VOP_LOCK1_APV (vop=, a=> optimized out>) at vnode_if.c:2087
>> #7  0x8063c5b3 in _vn_lock (vp=, flags=548864,
>> file=, line=) at vnode_if.h:859
>> #8  0x8062a5f7 in vget (vp=0xf80049c2c000, flags=548864,
>> td=0xf800b642b500) at /usr/src/sys/kern/vfs_subr.c:2523
>> #9  0x806118b9 in cache_lookup (dvp=, vpp=> optimized out>, cnp=, tsp=,
>> ticksp=) at /usr/src/sys/kern/vfs_cache.c:686
>> #10 0x806133dc in vfs_cache_lookup (ap=) at
>> /usr/src/sys/kern/vfs_cache.c:1081
>> #11 0x80935777 in VOP_LOOKUP_APV (vop=, a=> optimized out>) at vnode_if.c:127
>> #12 0x8061cdf1 in lookup (ndp=) at vnode_if.h:54
>> #13 0x8061c492 in namei (ndp=) at
>> /usr/src/sys/kern/vfs_lookup.c:306
>> #14 0x80509395 in kern_execve (td=, args=> optimized out>, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443
>> #15 0x80508ccc in sys_execve (td=0xf800b642b500,
>> uap=0xfe010182cb80) at /usr/src/sys/kern/kern_exec.c:218
>> #16 0x808d449e in amd64_syscall (td=, traced=0) 
>> at
>> subr_syscall.c:135
>> #17 0x808b7ddb in Xfast_syscall () at
>> /usr/src/sys/amd64/amd64/exception.S:396
>>
>> Thread 681 (Thread 101147):
>> #0  sched_switch (td=0xf80065f4e500, newtd=0xf8000285f000, 
>> flags=> optimized out>) at /usr/src/sys/kern/sched_ule.c:1973
>> #1  0x80561ae2 in mi_switch (flags=, newtd=0x0) 
>> at
>> /usr/src/sys/kern/kern_synch.c:455
>> #2  0x805ae8da in sleepq_wait (wchan=0x0, pri=0) at
>> /usr/src/sys/kern/subr_sleepqueue.c:646
>> #3  0x8052f854 in sleeplk (lk=, flags=> optimized out>, ilk=, wmesg=0x813be535 "zfs",
>> pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222
>> #4  0x8052f39d in __lockmgr_args (lk=, 
>> flags=> optimized out>, ilk=, wmesg=,
>> pri=, timo=, file=> out>, line=) at /usr/src/sys/kern/kern_lock.c:958
>> #5  0x80616a8c in vop_stdlock (ap=) at 
>> lockmgr.h:98
>> #6  0x8093784d in VOP_LOCK1_APV (vop=, a=> optimized out>) at vnode_if.c:2087
>> #7  0x8063c5b3 in _vn_lock (vp=, flags=548864,
>> file=, line=) at vnode_if.h:859
>> #8  0x8062a5f7 in vget (vp=0xf80049c2c000, flags=548864,
>> td=0xf80065f4e500) at /usr/src/sys/kern/vfs_subr.c:2523
>> #9  0x806118b9 in cache_lookup (dvp=, vpp=> optimized out>, cnp=, tsp=,
>> ticksp=) at /usr/src/sys/kern/vfs_cache.c:686
>> #10 0x806133dc in vfs_cache_lookup (ap=) at
>> /usr/src/sys/kern/vfs_cache.c:1081
>> #11 0x80935777 in VOP_LOOKUP_APV (vop=, a=> optimized out>) at vnode_if.c:127
>> #12 0x8061cdf1 in lookup (ndp=) at vnode_if.h:54
>> #13 0x8061c492 in namei (ndp=) at
>> /usr/src/sys/kern/vfs_lookup.c:306
>> #14 0x80509395 in kern_execve (td=, args=> optimized out>, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443
>> #15 0x80508ccc in sys_execve (td=0xf80065f4e500,
>> uap=0xfe01016b8b80) at /usr/src/sys/kern/kern_exec.c:218
>> #16 0x808d449e in amd64_syscall (td=, traced=0) 
>> at
>> subr_syscall.c:135
>> #17 0x808b7ddb in Xfast_syscall () at
>> /usr/src/sys/amd64/amd64/exception.S:396
> 
> This 2 threads are innd processes. In core.txt.4:
> 
>8 14789 29165   0   24  4   40040   6612 zfs  DN- 0:00.00 [innd]
>8 29165 1   0   20  0   42496   6888 select   Ds- 0:01.33 [innd]
>8 49778 29165   0   24  4   40040   6900 zfs  DN- 0:00.00 [innd]
>8 82034 29165   0   24  4 132  0 zfs  DN- 0:00.00 [innd]
> 
> the corresponding info treads are:
> 
>   687 Thread 101243 (PID=49778: innd)  sched_switch (td=0xf800b642b500,
> newtd=0xf8000285ea00, flags=) at
> /usr/src/sys/kern/sched_ule.c:1973
>   681 Thread 101147 (PID=14789: innd)  sched_switch (td=0xf80065f4e500,
> newtd=0xf8000285f000, flags=) at
> /usr/src/sys/kern/sched_ule.c:1973
>   669 Thread 101250 (PID=82034: innd)  sched_switch (td=0xf800b6429000,
>