On Wed, Nov 09, 2022 at 04:14:10PM +, Martin Pieuchot wrote:
> On 09/09/22(Fri) 14:41, Martin Pieuchot wrote:
> > On 09/09/22(Fri) 12:25, Theo Buehler wrote:
> > > > Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same
> > > > assert. Here's an rebased diff for the bug
On 09/09/22(Fri) 14:41, Martin Pieuchot wrote:
> On 09/09/22(Fri) 12:25, Theo Buehler wrote:
> > > Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same
> > > assert. Here's an rebased diff for the bug discussed in this thread,
> > > could you try again and let us know? Thanks!
>
On Fri, Sep 09, 2022 at 02:41:30PM +0200, Martin Pieuchot wrote:
> On 09/09/22(Fri) 12:25, Theo Buehler wrote:
> > > Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same
> > > assert. Here's an rebased diff for the bug discussed in this thread,
> > > could you try again and let us
On 09/09/22(Fri) 12:25, Theo Buehler wrote:
> > Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same
> > assert. Here's an rebased diff for the bug discussed in this thread,
> > could you try again and let us know? Thanks!
>
> This seems to be stable now. It's been running for
> Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same
> assert. Here's an rebased diff for the bug discussed in this thread,
> could you try again and let us know? Thanks!
This seems to be stable now. It's been running for nearly 5 days.
Without gnezdo's fix it would blow up
On Tue, Sep 06, 2022 at 05:17:56AM +, Miod Vallat wrote:
> > On Thu, Sep 01, 2022 at 02:57:27PM +0200, Martin Pieuchot wrote:
> > > Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same
> > > assert. Here's an rebased diff for the bug discussed in this thread,
> > > could you
> On Thu, Sep 01, 2022 at 02:57:27PM +0200, Martin Pieuchot wrote:
> > Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same
> > assert. Here's an rebased diff for the bug discussed in this thread,
> > could you try again and let us know? Thanks!
>
> Wow! With this diff I
On Thu, Sep 01, 2022 at 02:57:27PM +0200, Martin Pieuchot wrote:
> Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same
> assert. Here's an rebased diff for the bug discussed in this thread,
> could you try again and let us know? Thanks!
Wow! With this diff I finished make
On 29/07/22(Fri) 14:22, Theo Buehler wrote:
> On Mon, Jul 11, 2022 at 01:05:19PM +0200, Martin Pieuchot wrote:
> > On 11/07/22(Mon) 07:50, Theo Buehler wrote:
> > > On Fri, Jun 03, 2022 at 03:02:36PM +0200, Theo Buehler wrote:
> > > > > Please do note that this change can introduce/expose other
On Mon, Jul 11, 2022 at 01:05:19PM +0200, Martin Pieuchot wrote:
> On 11/07/22(Mon) 07:50, Theo Buehler wrote:
> > On Fri, Jun 03, 2022 at 03:02:36PM +0200, Theo Buehler wrote:
> > > > Please do note that this change can introduce/expose other issues.
> > >
> > > It seems that this diff causes
> It's hard for me to tell what's going on. I believe the interesting
> trace is the one from cpu0 that we don't have. Can you easily reproduce
> this? I'm trying on amd64 without luck. I'd glad if you could gather
> more infos.
It is not hard to reproduce on my m1 mini, but it takes time -
On 11/07/22(Mon) 07:50, Theo Buehler wrote:
> On Fri, Jun 03, 2022 at 03:02:36PM +0200, Theo Buehler wrote:
> > > Please do note that this change can introduce/expose other issues.
> >
> > It seems that this diff causes occasional hangs when building snapshots
> > on my mac M1 mini. This happened
On Fri, Jun 03, 2022 at 03:02:36PM +0200, Theo Buehler wrote:
> > Please do note that this change can introduce/expose other issues.
>
> It seems that this diff causes occasional hangs when building snapshots
> on my mac M1 mini. This happened twice in 10 builds, both times in
> xenocara.
> Please do note that this change can introduce/expose other issues.
It seems that this diff causes occasional hangs when building snapshots
on my mac M1 mini. This happened twice in 10 builds, both times in
xenocara. Unfortunately, both times the machine became entirely
unresponsive and as I
On 02/06/22(Thu) 13:54, Sebastien Marie wrote:
> On Tue, May 24, 2022 at 02:16:44PM +0200, Martin Pieuchot wrote:
> > On 19/05/22(Thu) 13:33, Alexander Bluhm wrote:
> > > On Tue, May 17, 2022 at 05:43:02PM +0200, Martin Pieuchot wrote:
> > > > Andrew, Alexander, could you test this and report
On 02/06/22(Thu) 07:29, Theo de Raadt wrote:
> So this basically converts the flag into a proper reference?
It completely gets rid of the extra reference. UVM objects related to a
vnode are no longer kept alive after uvn_detach() has been called.
> If you go back to 4.4BSD, there's another
So this basically converts the flag into a proper reference?
If you go back to 4.4BSD, there's another aspect which was different:
I believe vnodes weren't allocated dynamically, but came out of a fixed
and therefore the recycling behaviour was different. Or maybe some
kernel code had a subtle
On Tue, May 24, 2022 at 02:16:44PM +0200, Martin Pieuchot wrote:
> On 19/05/22(Thu) 13:33, Alexander Bluhm wrote:
> > On Tue, May 17, 2022 at 05:43:02PM +0200, Martin Pieuchot wrote:
> > > Andrew, Alexander, could you test this and report back?
> >
> > Panic "vref used where vget required" is
On Tue, May 31, 2022 at 04:40:32PM +0200, Martin Pieuchot wrote:
> Any of you got the chance to try this diff? Could you reproduce the
> panic with it?
With this diff I could build a release. It worked twice.
Usually it crashes after a day. This time it finished release after
30 hours.
bluhm
On 24/05/22(Tue) 14:16, Martin Pieuchot wrote:
> On 19/05/22(Thu) 13:33, Alexander Bluhm wrote:
> > On Tue, May 17, 2022 at 05:43:02PM +0200, Martin Pieuchot wrote:
> > > Andrew, Alexander, could you test this and report back?
> >
> > Panic "vref used where vget required" is still there. As
On 19/05/22(Thu) 13:33, Alexander Bluhm wrote:
> On Tue, May 17, 2022 at 05:43:02PM +0200, Martin Pieuchot wrote:
> > Andrew, Alexander, could you test this and report back?
>
> Panic "vref used where vget required" is still there. As usual it
> needs a day to reproduce. This time I was running
On Tue, May 17, 2022 at 05:43:02PM +0200, Martin Pieuchot wrote:
> Andrew, Alexander, could you test this and report back?
Panic "vref used where vget required" is still there. As usual it
needs a day to reproduce. This time I was running without the vref
history diff.
bluhm
> Index:
On 06/05/22(Fri) 22:16, Alexander Bluhm wrote:
> Same with this diff.
Thanks for testing. Here's a possible fix. The idea is to call
uvm_vnp_terminate() when recycling a vnode. This will flush any
pending pages that are still associated with the vnode. Ironically that
is what the comment
Same with this diff.
On Wed, May 04, 2022 at 05:58:14PM +0200, Martin Pieuchot wrote:
> Index: nfs/nfs_serv.c
> ===
> RCS file: /cvs/src/sys/nfs/nfs_serv.c,v
> retrieving revision 1.120
> diff -u -p -r1.120 nfs_serv.c
> ---
On 04/05/22(Wed) 18:30, Alexander Bluhm wrote:
> On Wed, May 04, 2022 at 05:58:14PM +0200, Martin Pieuchot wrote:
> > I don't understand the mechanism around UVM_VNODE_CANPERSIST. I looked
> > for missing uvm_vnp_uncache() and found the following two. I doubt
> > those are the one triggering the
On 04/05/22(Wed) 18:23, Mark Kettenis wrote:
> > Date: Wed, 4 May 2022 17:58:14 +0200
> > From: Martin Pieuchot
> >
> > On 04/05/22(Wed) 09:16, Sebastien Marie wrote:
> > > [...]
> > > we don't have any vclean label ("vclean (inactive)" or "vclean
> > > (active)"), so
> > > vclean() was not
On Wed, May 04, 2022 at 05:58:14PM +0200, Martin Pieuchot wrote:
> I don't understand the mechanism around UVM_VNODE_CANPERSIST. I looked
> for missing uvm_vnp_uncache() and found the following two. I doubt
> those are the one triggering the bug because they are in NFS & softdep.
It crashes
> Date: Wed, 4 May 2022 17:58:14 +0200
> From: Martin Pieuchot
>
> On 04/05/22(Wed) 09:16, Sebastien Marie wrote:
> > [...]
> > we don't have any vclean label ("vclean (inactive)" or "vclean (active)"),
> > so
> > vclean() was not called in this timeframe.
>
> So we are narrowing down the
On 04/05/22(Wed) 09:16, Sebastien Marie wrote:
> [...]
> we don't have any vclean label ("vclean (inactive)" or "vclean (active)"), so
> vclean() was not called in this timeframe.
So we are narrowing down the issue:
1. A file is opened
2. Then mmaped
3. Some of its pages are swapped to disk
4.
On Tue, May 03, 2022 at 07:52:16PM +0200, Alexander Bluhm wrote:
> On Mon, May 02, 2022 at 06:53:08AM +0200, Sebastien Marie wrote:
> > New diff, with new iteration on vnode_history_*() functions. I added a
> > label in
> > the record function. I also changed when showing the stacktrace. powerpc
On Mon, May 02, 2022 at 06:53:08AM +0200, Sebastien Marie wrote:
> New diff, with new iteration on vnode_history_*() functions. I added a label
> in
> the record function. I also changed when showing the stacktrace. powerpc has
> poor backtrace support, but now it will at least print some infos
On Thu, Apr 28, 2022 at 08:47:53PM +0200, Martin Pieuchot wrote:
> On 28/04/22(Thu) 16:54, Sebastien Marie wrote:
> > On Thu, Apr 28, 2022 at 04:04:41PM +0200, Alexander Bluhm wrote:
> > > On Wed, Apr 27, 2022 at 09:16:48AM +0200, Sebastien Marie wrote:
> > > > Here a new diff (sorry for the
Still panics with the latest uvm fixes.
http://bluhm.genua.de/release/results/2022-04-30T21%3A55%3A03Z/bsdcons-ot26.txt
[-- MARK -- Sun May 1 14:40:00 2022]
uvn_io: start: 0x25452b58, type VREG, use 0, write 0, hold 834, flags
(VBIOONFREELIST)
tag VT_UFS, ino 469309, on dev 0, 10 flags
On Thu, Apr 28, 2022 at 08:47:53PM +0200, Martin Pieuchot wrote:
> On 28/04/22(Thu) 16:54, Sebastien Marie wrote:
> > On Thu, Apr 28, 2022 at 04:04:41PM +0200, Alexander Bluhm wrote:
> > > On Wed, Apr 27, 2022 at 09:16:48AM +0200, Sebastien Marie wrote:
> > > > Here a new diff (sorry for the
On 28/04/22(Thu) 16:54, Sebastien Marie wrote:
> On Thu, Apr 28, 2022 at 04:04:41PM +0200, Alexander Bluhm wrote:
> > On Wed, Apr 27, 2022 at 09:16:48AM +0200, Sebastien Marie wrote:
> > > Here a new diff (sorry for the delay) which add a new
> > > vnode_history_record()
> > > point inside
On Thu, Apr 28, 2022 at 04:04:41PM +0200, Alexander Bluhm wrote:
> On Wed, Apr 27, 2022 at 09:16:48AM +0200, Sebastien Marie wrote:
> > Here a new diff (sorry for the delay) which add a new vnode_history_record()
> > point inside uvn_detach() (when 'uvn' object has UVM_VNODE_CANPERSIST flag
> >
On Wed, Apr 27, 2022 at 09:16:48AM +0200, Sebastien Marie wrote:
> Here a new diff (sorry for the delay) which add a new vnode_history_record()
> point inside uvn_detach() (when 'uvn' object has UVM_VNODE_CANPERSIST flag
> sets).
[-- MARK -- Thu Apr 28 14:10:00 2022]
uvn_io: start: 0x23ae1400,
On Tue, Apr 19, 2022 at 11:59:05AM +0200, Martin Pieuchot wrote:
> On 14/04/22(Thu) 18:29, Alexander Bluhm wrote:
> > [...]
> > vn_lock: v_usecount == 0: 0x23e6b910, type VREG, use 0, write 0, hold 0,
> > flags (VBIOONFREELIST)
> > tag VT_UFS, ino 703119, on dev 0, 10 flags 0x100,
On 14/04/22(Thu) 18:29, Alexander Bluhm wrote:
> [...]
> vn_lock: v_usecount == 0: 0x23e6b910, type VREG, use 0, write 0, hold 0,
> flags (VBIOONFREELIST)
> tag VT_UFS, ino 703119, on dev 0, 10 flags 0x100, effnlink 1, nlink 1
> mode 0100660, owner 21, group 21, size 13647873
>
On Wed, Apr 13, 2022 at 02:16:51PM +0200, Sebastien Marie wrote:
> Here a new diff which will record a bit more information.
>
> It keep track of the last 10 v_usecount changes with:
> - pid and ps_comm
> - usecount value (before and after)
> - stacktrace
[-- MARK -- Thu Apr 14 17:30:00 2022]
On Wed, Apr 13, 2022 at 02:16:51PM +0200, Sebastien Marie wrote:
Andrew,
Here a new diff which will record a bit more information.
It keep track of the last 10 v_usecount changes with:
- pid and ps_comm
- usecount value (before and after)
- stacktrace
We will need:
- the vnode_history
Andrew,
Here a new diff which will record a bit more information.
It keep track of the last 10 v_usecount changes with:
- pid and ps_comm
- usecount value (before and after)
- stacktrace
We will need:
- the vnode_history (without offsets)
- the panic and the backtrace of it
but keep also
On 12/04/22(Tue) 14:58, Sebastien Marie wrote:
> [...]
> uvn_io: start: 0x8000ffab9688, type VREG, use 0, write 0, hold 0, flags
> (VBIOONFREELIST)
> tag VT_UFS, ino 14802284, on dev 4, 30 flags 0x100, effnlink 1, nlink 1
> mode 0100644, owner 858, group 1000, size 345603015
> =>
On Tue, Apr 12, 2022 at 02:58:15PM +0200, Sebastien Marie wrote:
As you have a good way to reproduce it on amd64, i might ask you to test some
additionnal patches. For now, we need to properly understand the problem.
Yes, of course, no problem. I will be happy to test any necessary
patches.
On Tue, Apr 12, 2022 at 09:46:24AM +0300, Andrew Krasavin wrote:
> On Tue, Apr 12, 2022 at 06:44:09AM +0200, Sebastien Marie wrote:
> > On Mon, Apr 11, 2022 at 10:35:37PM +0300, Andrew Krasavin wrote:
> > >
> > > Unfortunately, I didn't have a chance to get to my home computer last
> > > week and
On Tue, Apr 12, 2022 at 06:44:09AM +0200, Sebastien Marie wrote:
On Mon, Apr 11, 2022 at 10:35:37PM +0300, Andrew Krasavin wrote:
Unfortunately, I didn't have a chance to get to my home computer last
week and provide you with the information you need. My apologies.
It isn't a problem. but I
On Mon, Apr 11, 2022 at 10:35:37PM +0300, Andrew Krasavin wrote:
>
> Unfortunately, I didn't have a chance to get to my home computer last
> week and provide you with the information you need. My apologies.
>
It isn't a problem. but I will be still interested by result on your computer,
as it
On Fri, Apr 08, 2022 at 10:16:01AM +0200, Sebastien Marie wrote:
On Fri, Apr 08, 2022 at 06:38:47AM +0200, Sebastien Marie wrote:
On Thu, Apr 07, 2022 at 02:53:07PM +0200, Alexander Bluhm wrote:
I have a diff for adding some stacktrace history for vnode (keeping track of
lasts
On 28/03/22(Mon) 13:35, Alexander Bluhm wrote:
> Hi,
>
> There was a discussion about file system bugs with macppc. My dual
> core macppc never completed a make release. I get various panics.
> One of them is below.
>
> bluhm
>
> panic: vref used where vget required
> Stopped at
On Fri, Apr 08, 2022 at 11:37:43AM +0200, Sebastien Marie wrote:
> and I hope to infer possible problematic codepath with stacktrace history.
Here we go
[-- MARK -- Sat Apr 9 14:10:00 2022]
uvn_io: start: 0xe85497a8, type VREG, use 0, write 0, hold 0, flags
(VBIOONFREELIST)
tag VT_UFS,
On Fri, Apr 08, 2022 at 11:07:22AM +0200, Alexander Bluhm wrote:
> On Fri, Apr 08, 2022 at 06:38:47AM +0200, Sebastien Marie wrote:
> > I have a diff for adding some stacktrace history for vnode (keeping track of
> > lasts vref/vrele/vget/vput). but I am not sure it would be efficient to
> >
On Fri, Apr 08, 2022 at 06:38:47AM +0200, Sebastien Marie wrote:
> On Thu, Apr 07, 2022 at 02:53:07PM +0200, Alexander Bluhm wrote:
> > On Wed, Apr 06, 2022 at 03:23:55PM +0200, Sebastien Marie wrote:
> > > > panic: vref used where vget required
> > >
> > > could you try to reproduce with the
On Wed, Apr 06, 2022 at 03:23:55PM +0200, Sebastien Marie wrote:
> > panic: vref used where vget required
>
> could you try to reproduce with the following kernel diff ?
My machine is still building release, before it took a day or two
to crash. But it has already printed some of your warnings.
On Thu, Apr 07, 2022 at 12:23:11PM +0200, Sebastien Marie wrote:
On Thu, Apr 07, 2022 at 12:06:45PM +0300, Andrew Krasavin wrote:
On Wed, Apr 06, 2022 at 03:23:55PM +0200, Sebastien Marie wrote:
uvn_io: start: 0xfd834f678210, type VREG, use 0, write 0, hold 0, flags
(VBIOONFREELIST)
On Wed, Apr 06, 2022 at 03:23:55PM +0200, Sebastien Marie wrote:
could you try to reproduce with the following kernel diff ?
as first step, it adds some KERNEL_ASSERT_LOCKED() on v_usecount modification,
and some vprint() inside uvn_io().
the vprint() inside uvn_io() should trigger only before
On Thu, Apr 07, 2022 at 12:06:45PM +0300, Andrew Krasavin wrote:
> On Wed, Apr 06, 2022 at 03:23:55PM +0200, Sebastien Marie wrote:
>
> uvn_io: start: 0xfd834f678210, type VREG, use 0, write 0, hold 0, flags
> (VBIOONFREELIST)
> tag: VT_UFS, ino 19627621, on dev 4, 30 flags 0x100,
On Wed, Apr 06, 2022 at 03:23:55PM +0200, Sebastien Marie wrote:
could you try to reproduce with the following kernel diff ?
as first step, it adds some KERNEL_ASSERT_LOCKED() on v_usecount modification,
and some vprint() inside uvn_io().
the vprint() inside uvn_io() should trigger only before
On Mon, Mar 28, 2022 at 01:35:48PM +0200, Alexander Bluhm wrote:
> Hi,
>
> There was a discussion about file system bugs with macppc. My dual
> core macppc never completed a make release. I get various panics.
> One of them is below.
>
> bluhm
>
> panic: vref used where vget required
>
On Mon, Mar 28, 2022 at 01:35:48PM +0200, Alexander Bluhm wrote:
Hi,
There was a discussion about file system bugs with macppc. My dual
core macppc never completed a make release. I get various panics.
One of them is below.
bluhm
panic: vref used where vget required
Stopped at
On Mon, 28 Mar 2022 13:35:48 +0200
Alexander Bluhm wrote:
> Hi,
>
> There was a discussion about file system bugs with macppc. My dual
> core macppc never completed a make release. I get various panics.
> One of them is below.
>
> bluhm
I have a macppc of the same model (dual G5
Hi,
There was a discussion about file system bugs with macppc. My dual
core macppc never completed a make release. I get various panics.
One of them is below.
bluhm
panic: vref used where vget required
Stopped at db_enter+0x24: lwz r11,12(r1)
TIDPIDUID PRFLAGS PFLAGS
61 matches
Mail list logo
