On 07/11/2020 19:00, Mateusz Guzik wrote:
> Fixed as of r367454 (also see r367453).
Thank you!
> On 11/6/20, Mateusz Guzik wrote:
>> I think I have an idea how to keep this. In the meantime you can just
>> comment it out.
>>
>> On 11/6/20, Mateusz Guzik wrote:
>>> On 11/6/20, Andriy Gapon wrot
Fixed as of r367454 (also see r367453).
On 11/6/20, Mateusz Guzik wrote:
> I think I have an idea how to keep this. In the meantime you can just
> comment it out.
>
> On 11/6/20, Mateusz Guzik wrote:
>> On 11/6/20, Andriy Gapon wrote:
>>> On 06/11/2020 22:58, Mateusz Guzik wrote:
Note the
I think I have an idea how to keep this. In the meantime you can just
comment it out.
On 11/6/20, Mateusz Guzik wrote:
> On 11/6/20, Andriy Gapon wrote:
>> On 06/11/2020 22:58, Mateusz Guzik wrote:
>>> Note the underlying primitive was recently replaced.
>>>
>>> One immediate thing to check woul
On 11/6/20, Andriy Gapon wrote:
> On 06/11/2020 22:58, Mateusz Guzik wrote:
>> Note the underlying primitive was recently replaced.
>>
>> One immediate thing to check would be exact state of the lock.
>> READ_HELD checks for reading only, fails if you have this
>> write-locked, which is a plausibl
On 06/11/2020 22:58, Mateusz Guzik wrote:
> Note the underlying primitive was recently replaced.
>
> One immediate thing to check would be exact state of the lock.
> READ_HELD checks for reading only, fails if you have this
> write-locked, which is a plausible explanation if you are coming in
> fr
Note the underlying primitive was recently replaced.
One immediate thing to check would be exact state of the lock.
READ_HELD checks for reading only, fails if you have this
write-locked, which is a plausible explanation if you are coming in
from less likely codepath.
iow what's the backtrace and
The subject panic happens for me with r367410 when mounting root filesystem.
The panic is in zfs_freebsd_cached_lookup -> zfs_lookup -> zfs_dirlook.
I have a picture of the screen with a little bit more details, I'll share it
later.
--
Andriy Gapon
_
