On Tue, Feb 18, 2014 at 03:43:28PM +0200, Andriy Gapon wrote:
> on 18/02/2014 15:39 Jeremie Le Hen said the following:
> > On Tue, Feb 18, 2014 at 03:31:53PM +0200, Andriy Gapon wrote:
> >>
> >> So, VV_ROOT is indeed set in v_vflag.
> >> Thank you.
> >
> > So there's no need for me to reboot with
he.c:1330
> #28 0x806f4906 in kern___getcwd (td=0xf80061c26490,
> buf=0x7fffcc18 ,
> bufseg=UIO_USERSPACE, buflen=Cannot access memory at address
> 0x400
> ) at /usr/src-svn/sys/kern/vfs_cache.c:1094
> #29 0xffff809b1af5 in amd64_syscall (td=0xf
ff8099640b in Xfast_syscall ()
at /usr/src-svn/sys/amd64/amd64/exception.S:390
On Mon, Feb 10, 2014 at 09:56:07PM +0100, Jeremie Le Hen wrote:
> Hi,
>
> I run 11.0-CURRENT r260696 on amd64.
>
> I've got the following panic:
>
> panic: LK_RETRY set with incomp
on 18/02/2014 15:39 Jeremie Le Hen said the following:
> On Tue, Feb 18, 2014 at 03:31:53PM +0200, Andriy Gapon wrote:
>>
>> So, VV_ROOT is indeed set in v_vflag.
>> Thank you.
>
> So there's no need for me to reboot with kib's patch, right?
You better ask kib. I do not see any misbehavior in ZF
on 15/02/2014 22:02 Konstantin Belousov said the following:
> On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote:
>> on 14/02/2014 21:18 Jeremie Le Hen said the following:
>>> I've just got another occurence of the exact same panic. Any clue how
>>> to debug this?
>>
>> Could you pleas
On Tue, Feb 18, 2014 at 03:31:53PM +0200, Andriy Gapon wrote:
>
> So, VV_ROOT is indeed set in v_vflag.
> Thank you.
So there's no need for me to reboot with kib's patch, right?
--
Jeremie Le Hen
Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Mor
on 18/02/2014 15:18 Jeremie Le Hen said the following:
> On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote:
>> on 14/02/2014 21:18 Jeremie Le Hen said the following:
>>> I've just got another occurence of the exact same panic. Any clue how
>>> to debug this?
>>
>> Could you please obtai
On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote:
> on 14/02/2014 21:18 Jeremie Le Hen said the following:
> > I've just got another occurence of the exact same panic. Any clue how
> > to debug this?
>
> Could you please obtain *vp from frame 12 ?
Sure:
$1 = {v_tag = 0x81501
On Sat, Feb 15, 2014 at 10:02:59PM +0200, Konstantin Belousov wrote:
> On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote:
> > on 14/02/2014 21:18 Jeremie Le Hen said the following:
> > > I've just got another occurence of the exact same panic. Any clue how
> > > to debug this?
> >
> >
Andriy Gapon wrote:
> on 14/02/2014 21:18 Jeremie Le Hen said the following:
> > I've just got another occurence of the exact same panic. Any clue
> > how
> > to debug this?
>
> Could you please obtain *vp from frame 12 ?
>
> The problem seems to be happening in this piece of ZFS code:
>
On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote:
> on 14/02/2014 21:18 Jeremie Le Hen said the following:
> > I've just got another occurence of the exact same panic. Any clue how
> > to debug this?
>
> Could you please obtain *vp from frame 12 ?
>
> The problem seems to be happenin
on 14/02/2014 21:18 Jeremie Le Hen said the following:
> I've just got another occurence of the exact same panic. Any clue how
> to debug this?
Could you please obtain *vp from frame 12 ?
The problem seems to be happening in this piece of ZFS code:
if (cnp->cn_flags & ISDOTDOT) {
On Tue, Feb 11, 2014 at 10:35:29AM +0100, Jeremie Le Hen wrote:
> On Mon, Feb 10, 2014 at 11:48:19PM +0200, Andriy Gapon wrote:
> >
> > stack trace from kgdb could be a good middle ground between ddb stack trace
> > and
> > a full vmcore file...
>
> Here we go:
>
> #1 0x80302ca5 in db_
On Mon, Feb 10, 2014 at 11:48:19PM +0200, Andriy Gapon wrote:
>
> stack trace from kgdb could be a good middle ground between ddb stack trace
> and
> a full vmcore file...
Here we go:
#1 0x80302ca5 in db_fncall (dummy1=,
dummy2=, dummy3=,
dummy4=) at /usr/src-svn/sys/ddb/db_c
stack trace from kgdb could be a good middle ground between ddb stack trace and
a full vmcore file...
on 10/02/2014 22:56 Jeremie Le Hen said the following:
> Hi,
>
> I run 11.0-CURRENT r260696 on amd64.
>
> I've got the following panic:
>
> panic: LK_RETRY s
Hi,
I run 11.0-CURRENT r260696 on amd64.
I've got the following panic:
panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00e5e53980
kdb_backtrace() at kdb_back
on 08/02/2013 01:41 Rick Macklem said the following:
> Sounds good. I've attached a slightly updated patch with Andriy's
> suggested addition of a check for zfsvfs->z_shares_dir != 0.
>
> I can't do any commits until April, so if one of you guys is comfortable
> enough with the patch to commit it,
Sergey Kandaurov wrote:
> Sergey Kandaurov wrote:
> > On 7 February 2013 19:42, Andriy Gapon wrote:
> > > on 07/02/2013 17:36 Sergey Kandaurov said the following:
> > >> I tested the patch without the (*vpp != dvp) change.
> > >> It works well.
> > >>
> > >> It's something unrelated but when doing
Sergey Kandaurov wrote:
> On 7 February 2013 19:42, Andriy Gapon wrote:
> > on 07/02/2013 17:36 Sergey Kandaurov said the following:
> >> I tested the patch without the (*vpp != dvp) change.
> >> It works well.
> >>
> >> It's something unrelated but when doing ls -l
> >> on server (patched) and cl
Andriy Gapon wrote:
> on 07/02/2013 17:04 Rick Macklem said the following:
> > The other thing I wondered about is "can zfsvfs->z_shares_dir ever
> > not
> > fit in 32bits?".
>
> Usually it should be one of the first objects created in a new
> filesystem, so it
> should have a small ID (typically
On 7 February 2013 19:42, Andriy Gapon wrote:
> on 07/02/2013 17:36 Sergey Kandaurov said the following:
>> I tested the patch without the (*vpp != dvp) change.
>> It works well.
>>
>> It's something unrelated but when doing ls -l
>> on server (patched) and client (unpatched) sides,
>> I found som
on 07/02/2013 17:36 Sergey Kandaurov said the following:
> I tested the patch without the (*vpp != dvp) change.
> It works well.
>
> It's something unrelated but when doing ls -l
> on server (patched) and client (unpatched) sides,
> I found some inconsistency in returned stats.
> Or more precisely
On 7 February 2013 17:43, Andriy Gapon wrote:
> on 07/02/2013 04:13 Rick Macklem said the following:
>> Andriy Gapon wrote:
>>> on 06/02/2013 17:15 Rick Macklem said the following:
Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server
knows to
switch over to using VOP_LOOK
on 07/02/2013 17:04 Rick Macklem said the following:
> The other thing I wondered about is "can zfsvfs->z_shares_dir ever not
> fit in 32bits?".
Usually it should be one of the first objects created in a new filesystem, so it
should have a small ID (typically 7).
> I notice it is a uint64_t, but
Andriy Gapon wrote:
> on 07/02/2013 04:13 Rick Macklem said the following:
> > Andriy Gapon wrote:
> >> on 06/02/2013 17:15 Rick Macklem said the following:
> >>> Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server
> >>> knows to
> >>> switch over to using VOP_LOOKUP(). If the .zfs/snap
on 07/02/2013 04:13 Rick Macklem said the following:
> Andriy Gapon wrote:
>> on 06/02/2013 17:15 Rick Macklem said the following:
>>> Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server
>>> knows to
>>> switch over to using VOP_LOOKUP(). If the .zfs/snapshot and
>>> .zfs/share
>>> do t
Andriy Gapon wrote:
> on 06/02/2013 17:15 Rick Macklem said the following:
> > Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server
> > knows to
> > switch over to using VOP_LOOKUP(). If the .zfs/snapshot and
> > .zfs/share
> > do the same thing, that should be fine, at least for the NFS
on 06/02/2013 17:15 Rick Macklem said the following:
> Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server knows to
> switch over to using VOP_LOOKUP(). If the .zfs/snapshot and .zfs/share
> do the same thing, that should be fine, at least for the NFS server,
> I think.
Ah, right, but
Andriy Gapon wrote:
> on 06/02/2013 03:30 Rick Macklem said the following:
> > Since I don't understand ZFS, I have just posted a query on
> > freebsd-fs@, which I hope will get noticed by people who
> > may know why ZFS is doing this.
>
> Actually I think I have an explanation, just been busy pas
on 06/02/2013 03:30 Rick Macklem said the following:
> Since I don't understand ZFS, I have just posted a query on
> freebsd-fs@, which I hope will get noticed by people who
> may know why ZFS is doing this.
Actually I think I have an explanation, just been busy past couple of days.
The problem is
Sergey Kandaurov wrote:
> On 5 February 2013 04:13, Rick Macklem wrote:
> > Sergey Kandaurov wrote:
> >> On 4 February 2013 06:32, Rick Macklem
> >> wrote:
> >> > Konstantin Belousov wrote:
> >> >> On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote:
> >> >> > Andriy Gapon wrote:
> >> >>
On 5 February 2013 04:13, Rick Macklem wrote:
> Sergey Kandaurov wrote:
>> On 4 February 2013 06:32, Rick Macklem wrote:
>> > Konstantin Belousov wrote:
>> >> On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote:
>> >> > Andriy Gapon wrote:
>> >> > > on 31/01/2013 15:29 Sergey Kandaurov s
Sergey Kandaurov wrote:
> On 4 February 2013 06:32, Rick Macklem wrote:
> > Konstantin Belousov wrote:
> >> On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote:
> >> > Andriy Gapon wrote:
> >> > > on 31/01/2013 15:29 Sergey Kandaurov said the following:
> >> > > > Hi.
> >> > > >
> >> > >
Sergey Kandaurov wrote:
> On 4 February 2013 16:30, Sergey Kandaurov wrote:
> > On 4 February 2013 16:13, Sergey Kandaurov
> > wrote:
> >> On 4 February 2013 16:06, Andriy Gapon wrote:
> >>> on 04/02/2013 13:49 Sergey Kandaurov said the following:
> Hi, Rick! Here is the requested info rega
On 4 February 2013 06:32, Rick Macklem wrote:
> Konstantin Belousov wrote:
>> On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote:
>> > Andriy Gapon wrote:
>> > > on 31/01/2013 15:29 Sergey Kandaurov said the following:
>> > > > Hi.
>> > > >
>> > > > Got this assertion on idle NFS server
On 4 February 2013 16:30, Sergey Kandaurov wrote:
> On 4 February 2013 16:13, Sergey Kandaurov wrote:
>> On 4 February 2013 16:06, Andriy Gapon wrote:
>>> on 04/02/2013 13:49 Sergey Kandaurov said the following:
Hi, Rick! Here is the requested info regarding witness, and a bit more.
Th
On 4 February 2013 16:13, Sergey Kandaurov wrote:
> On 4 February 2013 16:06, Andriy Gapon wrote:
>> on 04/02/2013 13:49 Sergey Kandaurov said the following:
>>> Hi, Rick! Here is the requested info regarding witness, and a bit more.
>>> The triggered KASSERT is now different though.
>>
>> It's e
On 4 February 2013 16:06, Andriy Gapon wrote:
> on 04/02/2013 13:49 Sergey Kandaurov said the following:
>> Hi, Rick! Here is the requested info regarding witness, and a bit more.
>> The triggered KASSERT is now different though.
>
> It's exactly the same problem though :-)
> Do you have a crashdu
ETRY) == 0 || error == 0,
>> > > > ("LK_RETRY set with incompatible flags
>> > > > (0x%x) or
>> > > > an error occured (%d)",
>> > > >
>> > > > panic: LK_RETRY set
on 04/02/2013 13:49 Sergey Kandaurov said the following:
> Hi, Rick! Here is the requested info regarding witness, and a bit more.
> The triggered KASSERT is now different though.
It's exactly the same problem though :-)
Do you have a crashdump?
If yes, please print **vpp.
> Full witness is at ht
On 4 February 2013 05:07, Rick Macklem wrote:
> Andriy Gapon wrote:
>> on 03/02/2013 18:36 Rick Macklem said the following:
>> > I can think of two possibilities:
>> > 1 - ZFS isn't setting VV_ROOT on the root vnode under some
>> > condition.
>> > or
>> > 2 - The vnode was left locked from some pr
np->cn_flags & ISDOTDOT) && *vpp != dvp)
and see what happens?
rick
> > > > kern/vfs_vnops.c:_vn_lock()
> > > > KASSERT((flags & LK_RETRY) == 0 || error == 0,
> > > > ("LK_RETRY set with incompatible flags
>
while `ls -la
> > > > /.zfs/shares/'
> > > > issued on NFS client.
> > > > kern/vfs_vnops.c:_vn_lock()
> > > > KASSERT((flags & LK_RETRY) == 0 || error == 0,
> > > > ("LK_RETRY set with i
Andriy Gapon wrote:
> on 03/02/2013 18:36 Rick Macklem said the following:
> > I can think of two possibilities:
> > 1 - ZFS isn't setting VV_ROOT on the root vnode under some
> > condition.
> > or
> > 2 - The vnode was left locked from some previous operation that
> > happened
> > to be done b
on 03/02/2013 18:36 Rick Macklem said the following:
> I can think of two possibilities:
> 1 - ZFS isn't setting VV_ROOT on the root vnode under some condition.
> or
> 2 - The vnode was left locked from some previous operation that happened
> to be done by this thread. Doesn't seem likely, but?
while `ls -la
> > > > /.zfs/shares/'
> > > > issued on NFS client.
> > > > kern/vfs_vnops.c:_vn_lock()
> > > > KASSERT((flags & LK_RETRY) == 0 || error == 0,
> > > > ("LK_RETRY set with i
ued on NFS client.
> > > kern/vfs_vnops.c:_vn_lock()
> > > KASSERT((flags & LK_RETRY) == 0 || error == 0,
> > > ("LK_RETRY set with incompatible flags (0x%x) or
> > > an error occured (%d)",
> > >
> >
ASSERT((flags & LK_RETRY) == 0 || error == 0,
> > ("LK_RETRY set with incompatible flags (0x%x) or
> > an error occured (%d)",
> >
> > panic: LK_RETRY set with incompatible flags (0x200400) or an error
> > occured (11)
> >
> > What does
("LK_RETRY set with incompatible flags (0x%x) or
> an error occured (%d)",
>
> panic: LK_RETRY set with incompatible flags (0x200400) or an error occured
> (11)
>
> What does that mean and how is it possible? As you can see, both parts
> of assertion failed.
Hi.
Got this assertion on idle NFS server while `ls -la /.zfs/shares/'
issued on NFS client.
kern/vfs_vnops.c:_vn_lock()
KASSERT((flags & LK_RETRY) == 0 || error == 0,
("LK_RETRY set with incompatible flags (0x%x) or
an error occured (%d)",
50 matches
Mail list logo
