date:20161113

Re: Problems with Dell external USB DVD drive

2016-11-13 Thread Kevin Oberman

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"

Problems with Dell external USB DVD drive

2016-11-13 Thread Felix Johnson

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)

[fjohnson@laptop /usr/home/fjohnson]$ dmesg | grep -i usb
xhci0:  mem 0xf7d0-0xf7d0
irq 16 at device 20.0 on pci0
usbus0 on xhci0
ehci0:  mem
0xf7d23000-0xf7d233ff irq 23 at device 29.0 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci0
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 480Mbps High Speed USB v2.0
ugen0.1: <0x8086> at usbus0
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
ugen1.1:  at usbus1
uhub1:  on usbus1
Root mount waiting for: usbus1 usbus0
Root mount waiting for: usbus1 usbus0
ugen0.2:  at usbus0
uhub2:  on
usbus0
ugen1.2:  at usbus1
uhub3:  on
usbus1
Root mount waiting for: usbus1 usbus0
ugen0.3:  at usbus0
ukbd0:  on usbus0
Root mount waiting for: usbus0
ugen0.4:  at usbus0
Root mount waiting for: usbus0
ugen0.5:  at usbus0
umass0:  on
usbus0
Root mount waiting for: usbus0
ugen0.6:  at usbus0
Root mount waiting for: usbus0
ugen0.7:  at usbus0
Root mount waiting for: usbus0
usb_alloc_device: set address 8 failed (USB_ERR_TIMEOUT, ignored)
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 8 failed,
USB_ERR_TIMEOUT
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_TIMEOUT,
ignored)
usbd_setup_device_desc: getting device descriptor at addr 8 failed,
USB_ERR_TIMEOUT
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_TIMEOUT,
ignored)
Root mount waiting for: usbus0
usbd_setup_device_desc: getting device descriptor at addr 8 failed,
USB_ERR_TIMEOUT
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_TIMEOUT,
ignored)
usbd_setup_device_desc: getting device descriptor at addr 8 failed,
USB_ERR_TIMEOUT
Root mount waiting for: usbus0
Root mount waiting for: usbus0
usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_TIMEOUT,
ignored)
usbd_setup_device_desc: getting device descriptor at addr 8 failed,
USB_ERR_TIMEOUT
ugen0.8:  at usbus0 (disconnected)
ums0:  on usbus0
uhid0:  on usbus0
uhid1:  on usbus0
axe0:  on usbus0
ue0:  on axe0
[fjohnson@laptop /usr/home/fjohnson]$

Thank you!
Felix Johnson
___
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"

FreeBSD Quarterly Status Report - Third Quarter 2016

2016-11-13 Thread Benjamin Kaduk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

FreeBSD Project Quarterly Status Report - 3rd Quarter 2016

   As focused as we are on the present and what is happening now, it is
   sometimes useful to take a fresh look at where we have come from, and
   where we are going. This quarter, we had our newest doc committer
   working to trace through the tangled history of many utilities, and we
   also get a glimpse looking forward at what may come in FreeBSD 12.

   Though 11.0-RELEASE was not finalized until after the period covered in
   this report, we can still have some anticipatory excitement for the
   features that will be coming in 12.0. The possibilities are
   tantalizing: a base system with no GPL components, arm64 as a Tier-1
   architecture, capsicum protection for common utilities, and the
   CloudABI for custom software are just a few.

   The work of the present is no less exciting, with 11.0 making its way
   out just after the end of Q3, the new core coming into its own, and
   much more that you'll have to read and find out.

   --Benjamin Kaduk
 __

   Please submit status reports for the fourth quarter of 2016 by January 7.
 __

FreeBSD Team Reports

 * FreeBSD Release Engineering Team
 * Ports Collection
 * The FreeBSD Core Team
 * The FreeBSD Foundation

Projects

 * Capsicum Update
 * ClonOS: New FreeBSD-Based Free/Open Hosting Platform
 * CloudABI: Running Untrusted Programs Directly on top of FreeBSD
 * Improvements to Non-Transparent Bridge Subsystem
 * The Graphics Stack on FreeBSD
 * Using lld, the LLVM Linker, to Link FreeBSD
 * VirtualBox Shared Folders Filesystem
 * ZFS Code Sync with Latest OpenZFS/Illumos

Kernel

 * evdev Support
 * FreeBSD Driver for the Annapurna Labs ENA
 * FreeBSD on Hyper-V and Azure
 * Timekeeping Code Improvements

Google Summer of Code

 * Google Summer of Code 2016
 * Non-BSM to BSM Conversion Tools
 * ptnet Driver and bhyve Device Model

Architectures

 * FreeBSD on Annapurna Labs Alpine
 * FreeBSD on Marvell Armada38x
 * FreeBSD/arm64
 * UEFI Runtime Services

Ports

 * KDE on FreeBSD
 * LXQt on FreeBSD
 * Xfce on FreeBSD

Documentation

 * Documenting the History of Utilities in /bin and /sbin
 __

FreeBSD Team Reports

FreeBSD Release Engineering Team

   Links
   FreeBSD 11.0-RELEASE schedule
URL: https://www.FreeBSD.org/releases/11.0R/schedule.html

   Contact: FreeBSD Release Engineering Team 

   The FreeBSD Release Engineering Team is responsible for setting and
   publishing release schedules for official project releases of FreeBSD,
   announcing code freezes, and maintaining the respective branches, among
   other things.

   The FreeBSD Release Engineering Team continued the 11.0-RELEASE cycle
   which was planned to be released in September, but as a result of
   several last-minute issues, the final release announcement was delayed.

   This project was sponsored by The FreeBSD Foundation.
 __

Ports Collection

   Links
   FreeBSD Ports Website
URL: https://www.FreeBSD.org/ports/
   How to Contribute
URL: 
https://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html
   Ports Monitoring Website
URL: http://portsmon.FreeBSD.org/index.html
   Ports Management Team Website
URL: https://www.FreeBSD.org/portmgr/index.html
   Ports Management Team on Twitter
URL: https://twitter.com/FreeBSD_portmgr/
   Ports Management Team on Facebook
URL: https://www.facebook.com/portmgr
   Ports Management Team on Google+
URL: https://plus.google.com/communities/108335846196454338383

   Contact: René Ladan 
   Contact: FreeBSD Ports Management Team 

   The Ports Tree currently contains over 26,300 ports, with the PR count
   around 2,150. Of these PRs, 516 are unassigned. The last quarter saw
   5,295 commits by 117 active committers. Compared to the preceding
   quarter, there is both a slight increase in the number of PRs and the
   number of unassigned PRs, and a slight decrease in the number of
   committers.

   In the last quarter, four commits bits were taken in for safe keeping:
   erwin, miwi, and sem left by their own request and jase was inactive
   for more than 18 months. We welcomed two new committers: Tobias Berner
   (tcberner) and Joseph Mingrone (jrm).

   On the management side, erwin and miwi left portmgr. bapt also left
   portmgr but is still the liaison for core.

   On the infrastructure side, three new USES (grantlee, kde, linux) and
   one new Keyword (javavm) were introduced. The default version of the
   Linux ports is

Re: Freebsd 11.0 RELEASE - ZFS deadlock

2016-11-13 Thread Henri Hennebert


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

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, newtd=0xf8000285ea00, flags=) at /usr/src/sys/kern/sched_ule.c:1973
  665 Thread 101262 (PID=29165: innd)  sched_switch
(td=0xf800b6b54a00, newtd=0xf8000285ea00, flags=) at /usr/src/sys/kern/sched_ule.c:1973


In case it may help, I have a look at innd. This processes use 2 execv:

one to execute /bin/sh and the other to execute itself:

/*
**  Re-exec ourselves.
*/
static const char *
CCxexec(char *av[])
{
char*innd;
char*p;
int i;

if (CCargv == NULL)
return "1 no argv!";

innd = concatpath(innconf->pathbin, "innd");
/* Get the pathname. */
p = av[0];
if (*p == '\0' || strcmp(p, "innd") == 0)
CCargv[0] = innd;
else
return "1 Bad value";

#ifdef DO_PERL
PLmode(Mode, OMshutdown, av[0]);
#endif
#ifdef DO_PYTHON
PYmode(Mode, OMshutdown, av[0]);
#endif
JustCleanup();
syslog(L_NOTICE, "%s execv %s", LogName, CCargv[0]);

/* Close all fds to protect possible fd leaking accross successive 
innds. */

for (i=3; i<30; i++)
close(i);

execv(CCargv[0], CCargv);
syslog(L_FATAL, "%s cant execv %s %m", LogName, CCargv[0]);
_exit(1);
/* NOTREACHED */
return "1 Exit failed";
}

The culprit may be /usr/local/news/bin/innd,

remember that find is locked in /usr/local/news/bin

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-13 Thread Henri Hennebert


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=) 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=, ilk=, wmesg=0x813be535 "zfs",
pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222
#4  0x8052f39d in __lockmgr_args (lk=, flags=, ilk=, wmesg=,
pri=, timo=, file=, 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=) 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=, 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=) 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=, 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=) 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=, ilk=, wmesg=0x813be535 "zfs",
pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222
#4  0x8052f39d in __lockmgr_args (lk=, flags=, ilk=, wmesg=,
pri=, timo=, file=, 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=) 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=, 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=) 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=, 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=out>) at /usr/src/sys/kern/sched_ule.c:1973
  681 Thread 101147 (PID=14789: innd)  sched_switch 
(td=0xf80065f4e500, newtd=0xf8000285f000, flags=out>) at /usr/src/sys/kern/sched_ule.c:1973
  669 Thread 101250 (PID=82034: innd)  sched_switch 
(td=0xf800b6429000, newtd=0xf8000285ea00, flags=out>) at /usr/src/sys/kern/sched_ule.c:1973
  665 Thread 101262 (PID=29165: innd)  sched_switch 
(td=0xf800b6b54a00, newtd=0xf8000285ea00, flags=out>) at /usr/src/sys/kern/sched_ule.c:1973


So your missing tread must be 101250:

(kgdb) tid 101250
[Switching to thread 669 (Thread 101250)]#0  sched_switch 
(td=0xf800b6429000, newtd=0xf8000285ea00,

flags=) at /usr/src/sys/kern/sched_ule.c:1973
1973cpuid = PCPU_GET(cpuid);
Current language:  auto; currently minimal
(kgdb) bt

Re: Freebsd 11.0 RELEASE - ZFS deadlock

2016-11-13 Thread Andriy Gapon

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=) 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=, ilk=, wmesg=0x813be535 "zfs",
pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222
#4  0x8052f39d in __lockmgr_args (lk=, flags=, ilk=, wmesg=,
pri=, timo=, file=, 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=) 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=, 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=) 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=, 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=) 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=, ilk=, wmesg=0x813be535 "zfs",
pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222
#4  0x8052f39d in __lockmgr_args (lk=, flags=, ilk=, wmesg=,
pri=, timo=, file=, 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=) 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=, 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=) 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=, 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

And the original stuck thread wants to get the lock in the shared mode.
And there should be another thread that already holds the lock in the shared
mode.  But I am not able to identify it.  I wonder if the original thread could
be trying to get the lock recursively...

It would be interesting to get more details from thread 101112.
You can switch to it using tid command, you can use 'fr' to select frames, 'info
local' and 'info args' to see what variables are available (not optimized out)
and the you can print any that look interesting.  It would be nice to get a file
path and a directory vnode where the lookup is called.

Thank you.

-- 
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: Problems with Dell external USB DVD drive

Problems with Dell external USB DVD drive

FreeBSD Quarterly Status Report - Third Quarter 2016

Re: Freebsd 11.0 RELEASE - ZFS deadlock

Re: Freebsd 11.0 RELEASE - ZFS deadlock

Re: Freebsd 11.0 RELEASE - ZFS deadlock

6 matches

Site Navigation

Mail list logo

Footer information