On Fri, Oct 13, 2017 at 08:48:11AM -0700, Matt Joras wrote:
> On 10/13/2017 05:33, David Wolfskill wrote:
> > On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote:
> >> ...
> >>> panic: UNR inconsistency: items 0 found 7 (line 361)
> >>>
> >> Revert r324542 and try again.
> >>
> >> T
On 10/13/2017 05:33, David Wolfskill wrote:
> On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote:
>> ...
>>> panic: UNR inconsistency: items 0 found 7 (line 361)
>>>
>> Revert r324542 and try again.
>>
>> This revision was not tested with DIAGNOSTIC enabled.
> OK; I believe we have
On 10/10/17 8:33 pm, Rick Macklem wrote:
Julian Elischer wrote:
[stuff snipped]
On 10/10/17 4:25 am, Rick Macklem wrote:
--> As such, having a fixed reasonable # of threads is probably the best
that can be done.
- The current patch has the # of threads as a sysctl with a default
On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote:
> ...
> > panic: UNR inconsistency: items 0 found 7 (line 361)
> >
> Revert r324542 and try again.
>
> This revision was not tested with DIAGNOSTIC enabled.
OK; I believe we have a winner! Thanks! :-)
I copied the head slice
On Fri, Oct 13, 2017 at 02:44:50PM +0300, Konstantin Belousov wrote:
> ...
> > panic: UNR inconsistency: items 0 found 7 (line 361)
> >
> Revert r324542 and try again.
Will do; but I have a few things to get done first, so it may be an hour
or so before I can report results.
> This revision was
On Fri, Oct 13, 2017 at 04:36:34AM -0700, David Wolfskill wrote:
> This occurred after I had booted & smoke-tested my laptop, then
> issued "sudo shutdown -r now"; it's *possible* that there was also
> a (similar?) problem shutting down yesterday (@r324542), but the
> screen had gone dark and decli
This occurred after I had booted & smoke-tested my laptop, then
issued "sudo shutdown -r now"; it's *possible* that there was also
a (similar?) problem shutting down yesterday (@r324542), but the
screen had gone dark and declined to shed any light, so I'm not
sure on that point.
uname strings (yes
On Thu, Oct 12, 2017 at 11:15 AM, John Baldwin wrote:
> In this case the panic is separate from the LOR, and
> for a panic we really
> need the panic message in addition to the stack trace.
With release kernels stack trace appears with this
message, then it sits in ddb, forget how to print panic
On Wed, Oct 11, 2017 at 5:18 PM, grarpamp wrote:
> Let 12.0-current r324306 amd64 efi boot from usb to installer screen,
Another way to trigger this one is
boot snapshot install media single user verbose
mdmfs -s 10m md /mnt
umount -v /mnt
[LOR stack backtrace, remains usable]
___
