Re: FreeBSD 11.1-BETA1 Now Available

[Warner Losh]

On Sun, Jun 11, 2017 at 5:04 PM, Jonathan Chen  wrote:

> On 11 June 2017 at 00:34, Glen Barber  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > The first BETA build of the 11.1-RELEASE release cycle is now available.
> >
> > Installation images are available for:
> >
> > o 11.1-BETA1 amd64 GENERIC
> > o 11.1-BETA1 i386 GENERIC
> > o 11.1-BETA1 powerpc GENERIC
> > o 11.1-BETA1 powerpc64 GENERIC64
> > o 11.1-BETA1 sparc64 GENERIC
> > o 11.1-BETA1 armv6 BANANAPI
> > o 11.1-BETA1 armv6 BEAGLEBONE
> > o 11.1-BETA1 armv6 CUBIEBOARD
> > o 11.1-BETA1 armv6 CUBIEBOARD2
> > o 11.1-BETA1 armv6 CUBOX-HUMMINGBOARD
> > o 11.1-BETA1 armv6 GUMSTIX
> > o 11.1-BETA1 armv6 RPI-B
> > o 11.1-BETA1 armv6 RPI2
> > o 11.1-BETA1 armv6 PANDABOARD
> > o 11.1-BETA1 armv6 WANDBOARD
> > o 11.1-BETA1 aarch64 GENERIC
> >
> > Note regarding arm/armv6 images: For convenience for those without
> > console access to the system, a freebsd user with a password of
> > freebsd is available by default for ssh(1) access.  Additionally,
> > the root user password is set to root.  It is strongly recommended
> > to change the password for both users after gaining access to the
> > system.
> [...]
>
> I was hoping for an aarch64 RPI3 image for SD cards to try out FreeBSD
> 11.1. There's a memstick image, but I don't think that will work for
> the RPI3?
>

aarch64 support isn't completely integrated into FreeBSD 11 yet.

Warner
___
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.1-BETA1 Now Available

[Jonathan Chen]

On 11 June 2017 at 00:34, Glen Barber  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> The first BETA build of the 11.1-RELEASE release cycle is now available.
>
> Installation images are available for:
>
> o 11.1-BETA1 amd64 GENERIC
> o 11.1-BETA1 i386 GENERIC
> o 11.1-BETA1 powerpc GENERIC
> o 11.1-BETA1 powerpc64 GENERIC64
> o 11.1-BETA1 sparc64 GENERIC
> o 11.1-BETA1 armv6 BANANAPI
> o 11.1-BETA1 armv6 BEAGLEBONE
> o 11.1-BETA1 armv6 CUBIEBOARD
> o 11.1-BETA1 armv6 CUBIEBOARD2
> o 11.1-BETA1 armv6 CUBOX-HUMMINGBOARD
> o 11.1-BETA1 armv6 GUMSTIX
> o 11.1-BETA1 armv6 RPI-B
> o 11.1-BETA1 armv6 RPI2
> o 11.1-BETA1 armv6 PANDABOARD
> o 11.1-BETA1 armv6 WANDBOARD
> o 11.1-BETA1 aarch64 GENERIC
>
> Note regarding arm/armv6 images: For convenience for those without
> console access to the system, a freebsd user with a password of
> freebsd is available by default for ssh(1) access.  Additionally,
> the root user password is set to root.  It is strongly recommended
> to change the password for both users after gaining access to the
> system.
[...]

I was hoping for an aarch64 RPI3 image for SD cards to try out FreeBSD
11.1. There's a memstick image, but I don't think that will work for
the RPI3?

Cheers.
-- 
Jonathan Chen 
___
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: post ino64: lockd no runs?

[David Wolfskill]

On Sun, Jun 11, 2017 at 09:58:30PM +0300, Konstantin Belousov wrote:
> On Sun, Jun 11, 2017 at 11:12:25AM -0700, David Wolfskill wrote:
> >   2811 rpc.lockd CALL  nlm_syscall(0,0x1e,0x4,0x801015040)
> >   2811 rpc.lockd RET   nlm_syscall -1 errno 14 Bad address
> 
> If you revert r319614 on stable/11, does the problem go away ?
> 

As it happens, apparently so.

I was able to reproduce the symptom on my build machine:

freebeast(11.1)[1] uname -a && service lockd status 
FreeBSD freebeast.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #366  
r319823M/319823:1100514: Sun Jun 11 03:55:49 PDT 2017 
r...@freebeast.catwhisker.org:/co
mmon/S1/obj/usr/src/sys/GENERIC  amd64
lockd is not running.
freebeast(11.1)[2] 

I then "cloned" slice 1 to slice 3, and on slice 3's /usr/src, I
used "svn diff" and "svn patch --reverse-diff" to effectively revert
r319614, then rebooted from slice 3, did a normal src-based update;
rebooted, and:

freebeast(11.1)[1] uname -a && service lockd status
FreeBSD freebeast.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #367  
r319823M/319823:1100514: Sun Jun 11 13:31:49 PDT 2017 
r...@freebeast.catwhisker.org:/co
mmon/S3/obj/usr/src/sys/GENERIC  amd64
lockd is running as pid 600.
freebeast(11.1)[2]


If there's a patch someone would like me to try that's a bit more
involved than just reverting r319614, I'm up for it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Looking forward to telling Mr. Trump: "You're fired!"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: post ino64: lockd no runs?

[Konstantin Belousov]

On Sun, Jun 11, 2017 at 11:12:25AM -0700, David Wolfskill wrote:
>   2811 rpc.lockd CALL  nlm_syscall(0,0x1e,0x4,0x801015040)
>   2811 rpc.lockd RET   nlm_syscall -1 errno 14 Bad address

If you revert r319614 on stable/11, does the problem go away ?
___
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: post ino64: lockd no runs?

[Cy Schubert]

In message <20170611172022.ga3...@albert.catwhisker.org>, David Wolfskill 
write
s:
> 
> --0eh6TmSyL6TZE2Uz
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote:
> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any
> > of my systems after a full rebuild of src and ports. No log entries
> > offer any insight as to why :-(
> >=20
> > imb
> 
> I don't tend to use NFS on my systems that are running head, so I
> haven't had occasion to test this as stated.
> 
> However, I just completed my weekly update of the "prooduction" systems
> here at home, running stable/11.  And I find that lockd seems to be ...
> claiming that all is well, but declining to run (for long).
> 
> To the best of my knowledge, that was not the case until this last
> update, which was from:
> 
> FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 =
>  r319566M/319569:1100514: Sun Jun  4 03:54:41 PDT 2017 root@freebeast.c=
> atwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64
> 
> to
> 
> FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322  r319823M/=
> 319823:1100514: Sun Jun 11 03:56:10 PDT 2017 root@freebeast.catwhisker.=
> org:/common/S1/obj/usr/src/sys/ALBERT  amd64
> 
> The "glaringly obvious" symptom in my case is that I am now unable
> to (directly) save an email message from within mutt(1) by appending
> it to an NFS-resident file.  (Saving it to a local file, then using
> cat(1) to append that to the NFS- resident file & removing the local
> copy works)
> 
> After a few variations on a theme of:
> 
> albert(11.1)[5] sudo service lockd restart
> lockd not running?
> Starting lockd.
> albert(11.1)[6] echo $?
> 0
> albert(11.1)[7] service lockd status
> lockd is not running.
> 
> I finally(!) thought to ask ktrace what's going on (as tailing
> /var/log/messages was completely unproductive, even after enabling
> rc_debug).
> 
> So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of
> the output of kdump(1), I see that the trace ends with:
> 
>   ...
>   2811 rpc.lockd NAMI  "/var/run/logpriv"
>   2786 sh   CALL  read(0xa,0x627fc0,0x400)
>   2786 sh   GIO   fd 10 read 0 bytes
>""
>   2811 rpc.lockd RET   connect 0
>   2786 sh   RET   read 0
>   2811 rpc.lockd CALL  sendto(0x3,0x7fffe2c0,0x27,0,0,0)
>   2786 sh   CALL  exit(0)
>   2811 rpc.lockd GIO   fd 3 wrote 39 bytes
>"<30>Jun 11 15:43:10 rpc.lockd: Starting"
>   2811 rpc.lockd RET   sendto 39/0x27
>   2811 rpc.lockd CALL  sigaction(SIGALRM,0x7fffec20,0)
>   2811 rpc.lockd RET   sigaction 0
>   2811 rpc.lockd CALL  nlm_syscall(0,0x1e,0x4,0x801015040)
>   2811 rpc.lockd RET   nlm_syscall -1 errno 14 Bad address
>   2811 rpc.lockd CALL  sigprocmask(SIG_BLOCK,0x800830c78,0x7fffea40)
>   2811 rpc.lockd RET   sigprocmask 0
>   2811 rpc.lockd CALL  sigprocmask(SIG_SETMASK,0x800830c8c,0)
>   2811 rpc.lockd RET   sigprocmask 0
>   2811 rpc.lockd CALL  sigprocmask(SIG_BLOCK,0x800830c78,0x7fffe5b0)
>   2811 rpc.lockd RET   sigprocmask 0
>   2811 rpc.lockd CALL  sigprocmask(SIG_SETMASK,0x800830c8c,0)
>   2811 rpc.lockd RET   sigprocmask 0
>   2811 rpc.lockd CALL  sigprocmask(SIG_BLOCK,0x800830c78,0x7fffe5b0)
>   2811 rpc.lockd RET   sigprocmask 0
>   2811 rpc.lockd CALL  sigprocmask(SIG_SETMASK,0x800830c8c,0)
>   2811 rpc.lockd RET   sigprocmask 0
>   2811 rpc.lockd CALL  sigprocmask(SIG_BLOCK,0x800830c78,0x7fffe5b0)
>   2811 rpc.lockd RET   sigprocmask 0
>   2811 rpc.lockd CALL  sigprocmask(SIG_SETMASK,0x800830c8c,0)
>   2811 rpc.lockd RET   sigprocmask 0
>   2811 rpc.lockd CALL  exit(0x1)
> 
> Then, when I tried to send this message, I started getting more whines
> =66rom mutt(1).  I finall gave up and rebooted from the previous
> environment:
> 
> FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316 =
>  r319566M/319569:1100514: Sun Jun  4 03:54:41 PDT 2017 root@freebeast.c=
> atwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64
> 
> and lockd is running:
> 
> albert(11.1-P)[2] service lockd status
> lockd is running as pid 629.
> albert(11.1-P)[3]=20
> 
> so mutt(1) is not pitchng a hisssy-fit every time I try to save or
> send a message.
> 
> 
> In light of the above, I have Bcced: this message to current@ (where
> the thread originated) and sent it (and set replies) to stable@.
> 
> 
> I have a test system, last updated to stable/11 as of mid-October
> last year; lockd was running on it, as well (which is why I tried
> going back to last week's image).  I'm happy to update it to points
> where lockd may be broken, if it might help figure out what's broken
> and how to fix it.

I'm running lockd on recent -CURRENT systems. No issues so far. Locking 
works as expected.



-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  

Re: Can't boot (zfs-on-root) with "options EARLY_AP_STARTUP" and "device pf"

[Eric A. Borisch]

FWIW, it appears to be crashing for an integer divide fault in
pf_purge_thread in the 'pf_purge' process. If i turn on INVARIAINTS and
INVARIANT_SUPPORT, it boots. Perhaps a race?

 - Eric

On Fri, Jun 9, 2017 at 5:04 PM, Eric A. Borisch  wrote:

> Good afternoon,
>
> I tried to update the kernel on my Lenovo x230 (stable/11), and I would
> get crashes on boot. *I am running a non-GENERIC kernel.* Bisecting the
> changes from last-known-good, I found that I couldn't boot on any kernel
> past after r318752. The next change to the kernel, r318763 [1], turned on
> EARLY_AP_STARTUP by default.
>
> I've narrowed it down to what appears to be a conflict with 'options
> EARLY_AP_STARTUP' and 'device pf'. I can build a farily vanilla kernel with
> these set, and it crashes on boot. (I have a few other options set to
> enable root-on-zfs-on-geli.)
>
> Any suggestions, other than 'don't do that?',
>  - Eric
>
> [1] https://svnweb.freebsd.org/base?view=revision=318763
>
___
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: post ino64: lockd no runs?

[David Wolfskill]

On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote:
> It seems that {rpc.}lockd no longer runs after the ino64 changes on any
> of my systems after a full rebuild of src and ports. No log entries
> offer any insight as to why :-(
> 
>   imb

I don't tend to use NFS on my systems that are running head, so I
haven't had occasion to test this as stated.

However, I just completed my weekly update of the "prooduction" systems
here at home, running stable/11.  And I find that lockd seems to be ...
claiming that all is well, but declining to run (for long).

To the best of my knowledge, that was not the case until this last
update, which was from:

FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316  
r319566M/319569:1100514: Sun Jun  4 03:54:41 PDT 2017 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64

to

FreeBSD albert.catwhisker.org 11.1-BETA1 FreeBSD 11.1-BETA1 #322  
r319823M/319823:1100514: Sun Jun 11 03:56:10 PDT 2017 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64

The "glaringly obvious" symptom in my case is that I am now unable
to (directly) save an email message from within mutt(1) by appending
it to an NFS-resident file.  (Saving it to a local file, then using
cat(1) to append that to the NFS- resident file & removing the local
copy works)

After a few variations on a theme of:

albert(11.1)[5] sudo service lockd restart
lockd not running?
Starting lockd.
albert(11.1)[6] echo $?
0
albert(11.1)[7] service lockd status
lockd is not running.

I finally(!) thought to ask ktrace what's going on (as tailing
/var/log/messages was completely unproductive, even after enabling
rc_debug).

So I tried: "sudo ktrace -di service lockd restart"; upon exanimation of
the output of kdump(1), I see that the trace ends with:

  ...
  2811 rpc.lockd NAMI  "/var/run/logpriv"
  2786 sh   CALL  read(0xa,0x627fc0,0x400)
  2786 sh   GIO   fd 10 read 0 bytes
   ""
  2811 rpc.lockd RET   connect 0
  2786 sh   RET   read 0
  2811 rpc.lockd CALL  sendto(0x3,0x7fffe2c0,0x27,0,0,0)
  2786 sh   CALL  exit(0)
  2811 rpc.lockd GIO   fd 3 wrote 39 bytes
   "<30>Jun 11 15:43:10 rpc.lockd: Starting"
  2811 rpc.lockd RET   sendto 39/0x27
  2811 rpc.lockd CALL  sigaction(SIGALRM,0x7fffec20,0)
  2811 rpc.lockd RET   sigaction 0
  2811 rpc.lockd CALL  nlm_syscall(0,0x1e,0x4,0x801015040)
  2811 rpc.lockd RET   nlm_syscall -1 errno 14 Bad address
  2811 rpc.lockd CALL  sigprocmask(SIG_BLOCK,0x800830c78,0x7fffea40)
  2811 rpc.lockd RET   sigprocmask 0
  2811 rpc.lockd CALL  sigprocmask(SIG_SETMASK,0x800830c8c,0)
  2811 rpc.lockd RET   sigprocmask 0
  2811 rpc.lockd CALL  sigprocmask(SIG_BLOCK,0x800830c78,0x7fffe5b0)
  2811 rpc.lockd RET   sigprocmask 0
  2811 rpc.lockd CALL  sigprocmask(SIG_SETMASK,0x800830c8c,0)
  2811 rpc.lockd RET   sigprocmask 0
  2811 rpc.lockd CALL  sigprocmask(SIG_BLOCK,0x800830c78,0x7fffe5b0)
  2811 rpc.lockd RET   sigprocmask 0
  2811 rpc.lockd CALL  sigprocmask(SIG_SETMASK,0x800830c8c,0)
  2811 rpc.lockd RET   sigprocmask 0
  2811 rpc.lockd CALL  sigprocmask(SIG_BLOCK,0x800830c78,0x7fffe5b0)
  2811 rpc.lockd RET   sigprocmask 0
  2811 rpc.lockd CALL  sigprocmask(SIG_SETMASK,0x800830c8c,0)
  2811 rpc.lockd RET   sigprocmask 0
  2811 rpc.lockd CALL  exit(0x1)

Then, when I tried to send this message, I started getting more whines
from mutt(1).  I finall gave up and rebooted from the previous
environment:

FreeBSD albert.catwhisker.org 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #316  
r319566M/319569:1100514: Sun Jun  4 03:54:41 PDT 2017 
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT  amd64

and lockd is running:

albert(11.1-P)[2] service lockd status
lockd is running as pid 629.
albert(11.1-P)[3] 

so mutt(1) is not pitchng a hisssy-fit every time I try to save or
send a message.


In light of the above, I have Bcced: this message to current@ (where
the thread originated) and sent it (and set replies) to stable@.


I have a test system, last updated to stable/11 as of mid-October
last year; lockd was running on it, as well (which is why I tried
going back to last week's image).  I'm happy to update it to points
where lockd may be broken, if it might help figure out what's broken
and how to fix it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Looking forward to telling Mr. Trump: "You're fired!"

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

panic: Memory modified after free in zio_create, passthru in use [Was: 11.1-pre runtime Undefined symbol "xdr_accepted_reply" /lib/libc.so.7]

[Harry Schmalzbauer]

 Bezüglich Harry Schmalzbauer's Nachricht vom 06.06.2017 14:03 (localtime):
>  Hello,
>
> suddenly, I'm getting this error:
> /lib/libc.so.7: Undefined symbol "xdr_accepted_reply"
>
> Very mysterious: It showed up on a running system, which worked
> flawlessly for some hours. And that host has root-fs (/) mounted
> readonly from a memorydisk. So to my understanding, it's completely
> impossible that /lib/libc.so.7 is corrupted since last boot.
>
> I'm completely out of ideas what could cause this strange error during
> "normal" operation.
>
> Normal operation in this case is serving as a bhyve test machine.
> I first noticed that error after one guest - with passthru device
> attached - was shut down.
>
> My suspicion is some undiscovered passthru interference... Since I
> noticed one other _very_ strange passthru-effect:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215740

Hello,

this time I caught a panic with a debuging kernel under 11.1-BETA1,
which again occured after shuting down a VM which had ppt in use:
cpuid = 5
KDB: stack backtrace:
#0 0x805bf327 at kdb_backtrace+0x67
#1 0x8057f266 at vpanic+0x186
#2 0x8057f2e3 at panic+0x43
#3 0x8082eaeb at trash_ctor+0x4b
#4 0x8082aaec at uma_zalloc_arg+0x52c
#5 0x813b54a6 at zio_add_child+0x26
#6 0x813b5a05 at zio_create+0x385
#7 0x813b6de2 at zio_vdev_child_io+0x232
#8 0x81396be0 at vdev_mirror_io_start+0x370
#9 0x813bc629 at zio_vdev_io_start+0x4a9
#10 0x813b76bc at zio_execute+0x36c
#11 0x813b6868 at zio_nowait+0xb8
#12 0x81396bec at vdev_mirror_io_start+0x37c
#13 0x813bc383 at zio_vdev_io_start+0x203
#14 0x813b76bc at zio_execute+0x36c
#15 0x805d10dd at taskqueue_run_locked+0x13d
#16 0x805d1e78 at taskqueue_thread_loop+0x88
#17 0x80543844 at fork_exit+0x84

#0  doadump (textdump=) at pcpu.h:222
#1  0x8057ece0 in kern_reboot (howto=260) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:366
#2  0x8057f2a0 in vpanic (fmt=, ap=)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:759
#3  0x8057f2e3 in panic (fmt=) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:690
#4  0x8082eaeb in trash_ctor (mem=,
size=, arg=, flags=)
at /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/uma_dbg.c:80
#5  0x8082aaec in uma_zalloc_arg (zone=0xf8001febc680,
udata=0xf8001ad5f340, flags=)
at /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/uma_core.c:2152
#6  0x813b54a6 in zio_add_child (pio=0xf8026f350b88,
cio=0xf8002478b7b0)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:460
#7  0x813b5a05 in zio_create (pio=0xf8026f350b88, spa=, txg=433989, bp=,
data=0xfe0058afa000,
size=1024, type=,
priority=ZIO_PRIORITY_ASYNC_WRITE, flags=,
vd=,
offset=, zb=,
pipeline=)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:690
#8  0x813b6de2 in zio_vdev_child_io (pio=0xf8026f350b88,
bp=, vd=, offset=325398016,
data=, size=1024, type=,
flags=1048704, done=)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1141
#9  0x81396be0 in vdev_mirror_io_start (zio=0xf8026f350b88)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:488
#10 0x813bc629 in zio_vdev_io_start (zio=0xf8026f350b88)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3143
#11 0x813b76bc in zio_execute (zio=)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1681
#12 0x813b6868 in zio_nowait (zio=0xf8026f350b88)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1739
#13 0x81396bec in vdev_mirror_io_start (zio=0xf8026f7a7b88)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c:488
#14 0x813bc383 in zio_vdev_io_start (zio=0xf8026f7a7b88)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3021
#15 0x813b76bc in zio_execute (zio=)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1681
#16 0x805d10dd in taskqueue_run_locked
(queue=0xf8001ab5a700) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/subr_taskqueue.c:454
#17 0x805d1e78 in taskqueue_thread_loop (arg=) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/subr_taskqueue.c:741
#18 0x80543844 in fork_exit (callout=0x805d1df0
, arg=0xf8001aa90720, frame=0xfe043f609ac0)
at