On Thu, 3 Oct 2013, Andriy Gapon wrote:
on 02/10/2013 20:59 Keith White said the following:
On Wed, 2 Oct 2013, Andriy Gapon wrote:
on 30/09/2013 02:11 kwh...@site.uottawa.ca said the following:
Sorry, debugging this is *way* beyond me. Any hints, patches to try?
Please share the stack tr
on 02/10/2013 20:59 Keith White said the following:
> On Wed, 2 Oct 2013, Andriy Gapon wrote:
>
>> on 30/09/2013 02:11 kwh...@site.uottawa.ca said the following:
>>> Sorry, debugging this is *way* beyond me. Any hints, patches to try?
>>
>> Please share the stack trace.
>>
>> --
>> Andriy Gapon
On Wed, 2 Oct 2013, Andriy Gapon wrote:
on 30/09/2013 02:11 kwh...@site.uottawa.ca said the following:
Sorry, debugging this is *way* beyond me. Any hints, patches to try?
Please share the stack trace.
--
Andriy Gapon
There's now a pr for this panic: kern/182570
Here's the stack trace:
on 30/09/2013 02:11 kwh...@site.uottawa.ca said the following:
> Sorry, debugging this is *way* beyond me. Any hints, patches to try?
Please share the stack trace.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/m
I get the following reproducible panic when doing a zfs send -R | zfs recv
of a well churned file system (snapshots of the ports tree before and
after libiconv update) running a recent current:
panic: solaris assert: dn->dn_maxblkid == 0 &&
(BP_IS_HOLE(&dn->dn_phys->dn_blkptr[0]) || dnode_block_fr
