Re: Fairly Modern poudriere-devel on fairly modern main gets "mount_nullfs: /usr/local/poudriere/data/.m/NAME/ref/packages: Resource deadlock avoided" when operated in a chroot context.

ports-mgmt/poudriere-devel | > poudriere-devel-3.4.99.20250209 > [00:00:46] [01] [00:00:03] Finished ports-mgmt/poudriere-devel | > poudriere-devel-3.4.99.20250209: Success ending TMPFS: 2.96 GiB > [00:00:47] Stopping 5 builders > [00:00:47] Creating pkg repository > mount

Fairly Modern poudriere-devel on fairly modern main gets "mount_nullfs: /usr/local/poudriere/data/.m/NAME/ref/packages: Resource deadlock avoided" when operated in a chroot context.

t_nullfs: /usr/local/poudriere/data/.m/main-ZNV4-default/ref/packages: Resource deadlock avoided [00:00:47] Error: /usr/local/share/poudriere/bulk.sh:mount_packages:7:Failed to mount the packages directory It later reports: [00:00:47] Unmounting file systems Error: (50608) rm:rm:1: /usr/loc

Re: ZFS deadlock in 14

Martin, The PR was just merged to upstream master. Merge to zfs-2.2-release should follow shortly: https://github.com/openzfs/zfs/pull/15204 , same as some other 2.2 fixes: https://github.com/openzfs/zfs/pull/15205 . Can't wait to get back in sync with ZFS master in FreeBSD main. ;) On 22.0

Re: ZFS deadlock in 14

>> try to diagnose it. At very least it does not look related to the ZIL issue >> discussed in this thread, at least with the information provided, so I am >> not surprised that the mentioned patches do not affect it. > > Thanks for the information. Good to know. I'll

Re: ZFS deadlock in 14

On Aug 23, 2023, at 11:40, Alexander Motin wrote: > On 22.08.2023 14:24, Mark Millard wrote: >> Alexander Motin wrote on >> Date: Tue, 22 Aug 2023 16:18:12 UTC : >>> I am waiting for final test results from George Wilson and then will >>> request quick merge of both to zfs-2.2-release branch. Un

Re: ZFS deadlock in 14

On 22.08.2023 14:24, Mark Millard wrote: Alexander Motin wrote on Date: Tue, 22 Aug 2023 16:18:12 UTC : I am waiting for final test results from George Wilson and then will request quick merge of both to zfs-2.2-release branch. Unfortunately there are still not many reviewers for the PR, since

Re: ZFS deadlock in 14

ally use USE_TMPFS=all but that hides the problem and is why I've no clue when the behavior would have started if I'd been using USE_TMPFS=no instead. I never got so far as testing for the kinds of reports I've seen about the deadlock issue. No one has commented one what I reported

Re: ZFS deadlock in 14

Hi Martin, I am waiting for final test results from George Wilson and then will request quick merge of both to zfs-2.2-release branch. Unfortunately there are still not many reviewers for the PR, since the code is not trivial, but at least with the test reports Brian Behlendorf and Mark Mayb

Re: ZFS deadlock in 14

Hi Alexander, as 15107 is a prerequisite for 15122, would it be possible to have https://github.com/openzfs/zfs/pull/15107 merged into the OpenZFS zfs-2.2-release branch (and of course later 15122)? If the patches help I can cherry-pick them into main. Cheers, mm Alexander Motin wrote:

Re: ZFS deadlock in 14

Dag-Erling_Smørgrav wrote on Date: Sun, 20 Aug 2023 13:00:27 UTC : > Alexander Motin writes: > > Unfortunately I think the current code in main should still suffer > > from this specific deadlock. cd25b0f740 fixes some deadlocks in this > > area, may be that is why you ar

Re: ZFS deadlock in 14 [USE_TMPFS=no poudriere messed up from the start, lots of "vlruwk"]

On Aug 19, 2023, at 16:27, Mark Millard wrote: > On Aug 19, 2023, at 15:41, Mark Millard wrote: > >> On Aug 19, 2023, at 13:41, Mark Millard wrote: >> >>> [I forgot to adjust USE_TMPFS for the purpose of the test. >>> So I'll later be starting over.] >>> >>> . . . >> >> I finally got around

Re: ZFS deadlock in 14 [USE_TMPFS=no poudriere messed up from the start, lots of "vlruwk"]

On Aug 19, 2023, at 15:41, Mark Millard wrote: > On Aug 19, 2023, at 13:41, Mark Millard wrote: > >> [I forgot to adjust USE_TMPFS for the purpose of the test. >> So I'll later be starting over.] >> >> . . . > > I finally got around to starting a from-scratch bulk -a > again (based on USE_TMP

Re: ZFS deadlock in 14 [USE_TMPFS=no poudriere messed up from the start, lots of "vlruwk"]

On Aug 19, 2023, at 13:41, Mark Millard wrote: > [I forgot to adjust USE_TMPFS for the purpose of the test. > So I'll later be starting over.] > > . . . I finally got around to starting a from-scratch bulk -a again (based on USE_TMPFS=no this time). This is with 15107.patch and 15122.patch appl

Re: ZFS deadlock in 14

[I forgot to adjust USE_TMPFS for the purpose of the test. So I'll later be starting over.] On Aug 19, 2023, at 12:18, Mark Millard wrote: > On Aug 19, 2023, at 11:40, Mark Millard wrote: > >> We will see how long the following high load average bulk -a >> configuration survives a build attemp

Re: ZFS deadlock in 14

On Aug 19, 2023, at 11:40, Mark Millard wrote: > We will see how long the following high load average bulk -a > configuration survives a build attempt, using a non-debug kernel > for this test. > > I've applied: > > # fetch -o- https://github.com/openzfs/zfs/pull/15107.patch | git -C > /usr/ma

Re: ZFS deadlock in 14

We will see how long the following high load average bulk -a configuration survives a build attempt, using a non-debug kernel for this test. I've applied: # fetch -o- https://github.com/openzfs/zfs/pull/15107.patch | git -C /usr/main-src/ am --dir=sys/contrib/openzfs -

Re: ZFS deadlock in 14

0 and 28d2e3b5de reverted deadlocks, see attached ddb.txt. I'm going to see if reverting only 28d2e3b5de but not cd25b0f740 changes anything. Yes, it looks like ZIL-related deadlock: ZFS sync thread in zil_sync() is waiting for allocated ZIL zios to complete: Tracing command zfskern pid 5

ZFS deadlock in 14: with ZIL :-)

On 19/08/2023 11:31, Dimitry Andric wrote: On 19 Aug 2023, at 09:36, Graham Perrin wrote: … no ZIL; I never used the feature. The ZIL always exists, but it can be stored on a separate device for performance reasons. See zpoolconc

Re: ZFS deadlock in 14

Dag-Erling Smørgrav writes: > c47116e909 with cd25b0f740 and 28d2e3b5de reverted deadlocks, see > attached ddb.txt. I'm going to see if reverting only 28d2e3b5de but not > cd25b0f740 changes anything. c47116e909 with only 28d2e3b5de reverted also deadlocked, but in both cases it took much longer

Re: ZFS deadlock in 14: without ZIL

On 19 Aug 2023, at 09:36, Graham Perrin wrote: > > On 19/08/2023 00:03, Mark Millard wrote: >> I believe the below quoted messages were reports of deadlocks >> based on after the following 2 MFV being in place in their >> environments: >> >> Thu, 10 Aug 2023 >> . . . >> • git: cd25b0f740f8 -

ZFS deadlock in 14: without ZIL

On 19/08/2023 00:03, Mark Millard wrote: I believe the below quoted messages were reports of deadlocks based on after the following 2 MFV being in place in their environments: Thu, 10 Aug 2023 . . . • git: cd25b0f740f8 - main - zfs: cherry-pick fix from openzfs Martin Matuska • git: 2

Re: ZFS deadlock in 14

0 __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:5 > 9 > #1 doadump (textdump=textdump@entry=1) > at /opt/src/git-src/sys/kern/kern_shutdown.c:407 > #2 0x806c10e0 in kern_reboot (howto=260) > at /opt/src/git-src/sys/kern/kern_shutdown.c:528 > #3 0xf

Re: ZFS deadlock in 14

Dag-Erling Smørgrav writes: > Plot twist: c47116e909 _without_ the patches also appears to be working > fine. The last kernel I know for sure deadlocks is b36f469a15, so I'm > going to test cd25b0f740 and 28d2e3b5de. c47116e909 with cd25b0f740 and 28d2e3b5de reverted deadlocks, see attached ddb.

Re: ZFS deadlock in 14

'off' Yuri Pankov > > But you had written: > > Dag-Erling_Smørgrav > Date: Tue, 15 Aug 2023 17:37:45 UTC > The attached script successfully deadlocks 9228ac3a69c4 > > where: > > Thu, 10 Aug 2023 > . . . >• git: 9228ac3a69c4 - main - ixgbe: Add su

Re: ZFS deadlock in 14

Dag-Erling Smørgrav writes: > A kernel built from c47116e909 plus these two patches has so far built > 2,285 packages without a hitch, whereas normally it would have > deadlocked after well before reaching 500 packages. I'll do another run > without the patches tomorrow just to be sure. Plot twi

Re: ZFS deadlock in 14

Alexander Motin writes: > I don't have a FreeBSD branch, but these two patches apply clean and > build on top of today's FreeBSD main branch: > > https://github.com/openzfs/zfs/pull/15107 > https://github.com/openzfs/zfs/pull/15122 A kernel built from c47116e909 plus these two patches has so far

Re: ZFS deadlock in 14

On 17.08.2023 15:41, Dag-Erling Smørgrav wrote: Alexander Motin writes: Trying to run your test (so far without reproduction) I see it producing a substantial amount of ZIL writes. The range of commits you reduced the scope to so far includes my ZIL locking refactoring, where I know for sure a

Re: ZFS deadlock in 14

Alexander Motin writes: > Dag, That's not my name, Al. > Trying to run your test (so far without reproduction) I see it > producing a substantial amount of ZIL writes. The range of commits > you reduced the scope to so far includes my ZIL locking refactoring, > where I know for sure are some de

Re: ZFS deadlock in 14

On 17.08.2023 14:57, Alexander Motin wrote: On 15.08.2023 12:28, Dag-Erling Smørgrav wrote: Mateusz Guzik writes: Going through the list may or may not reveal other threads doing something in the area and it very well may be they are deadlocked, which then results in other processes hanging on

Re: ZFS deadlock in 14

On 15.08.2023 12:28, Dag-Erling Smørgrav wrote: Mateusz Guzik writes: Going through the list may or may not reveal other threads doing something in the area and it very well may be they are deadlocked, which then results in other processes hanging on them. Just like in your case the process re

Re: ZFS deadlock in 14

The attached script successfully deadlocks 9228ac3a69c4. DES -- Dag-Erling Smørgrav - d...@freebsd.org #!/bin/sh : ${n:=$(nproc)} : ${pool:=zroot} basefs="${pool}/zfsdl" set -eu zfs destroy -r "${basefs}" >/dev/null 2>&1 || true zfs create -o com.sun:auto-snapshot=false "${basefs}" basedir="$

Re: ZFS deadlock in 14

Mateusz Guzik writes: > Going through the list may or may not reveal other threads doing > something in the area and it very well may be they are deadlocked, > which then results in other processes hanging on them. > > Just like in your case the process reported as hung is a random victim > and wh

Re: ZFS deadlock in 14

On 8/15/23, Dag-Erling Smørgrav wrote: > Mateusz Guzik writes: >> Given that the custom reproducer failed I think the most prudent >> course of action is to reproduce again with poudriere, but this time >> arrange to have all stacktraces dumped. > > Why? What more information do you need? > Goi

Re: ZFS deadlock in 14

Mateusz Guzik writes: > Given that the custom reproducer failed I think the most prudent > course of action is to reproduce again with poudriere, but this time > arrange to have all stacktraces dumped. Why? What more information do you need? DES -- Dag-Erling Smørgrav - d...@freebsd.org

Re: ZFS deadlock in 14

On 8/15/23, Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: >> I managed to geat a deadlock with 4e8d558c9d1c. Its predecessor >> 5ca7f02946 appears to be working. I'm going to try to come up with a >> more efficient way to reproduce the deadlock than runnin

Re: ZFS deadlock in 14

Dag-Erling Smørgrav writes: > I managed to geat a deadlock with 4e8d558c9d1c. Its predecessor > 5ca7f02946 appears to be working. I'm going to try to come up with a > more efficient way to reproduce the deadlock than running poudriere. I wrote a script that creates multip

Re: ZFS deadlock in 14

Dag-Erling Smørgrav writes: > Trying to narrow this range down, I did not get a deadlock with > 4e8d558c9d1c (10 June) but I did with b7198dcfc039 (16 June) [...] > Perhaps I should try 4e8d558c9d1c again. I managed to geat a deadlock with 4e8d558c9d1c. Its predecessor 5ca7f02946 appe

Re: ZFS deadlock in 14

On August 12, 2023 7:11:10 AM PDT, "Dag-Erling Smørgrav" wrote: >Dag-Erling Smørgrav writes: >> At some point between 42d088299c (4 May) and f0c9703301 (26 June), a >> deadlock was introduced in ZFS. > >Trying to narrow this range down, I did not get a deadlock w

Re: ZFS deadlock in 14

Dag-Erling Smørgrav writes: > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > deadlock was introduced in ZFS. Trying to narrow this range down, I did not get a deadlock with 4e8d558c9d1c (10 June) but I did with b7198dcfc039 (16 June), albeit after building ~1800 pa

Re: ZFS deadlock in 14

ys/kern/kern_shutdown.c:528 #3 0x806c15df in vpanic ( fmt=0xffff80b6c5f5 "%s: possible deadlock detected for %p (%s), blocked for %d ticks\n", ap=ap@entry=0xfe008e698e90) at /opt/src/git-src/sys/kern/kern_shutdown.c:972 #4 0x806c1383 in panic (fmt=) at /opt/src

Re: ZFS deadlock in 14

On 11/08/2023 04:32, Kevin Bowling wrote: Spoke too soon still seeing zfs lockups Kevin, do you have a log device? (ZIL) under heavy poudriere workload … Can you tell what was building when the problem occurred? For example, qutebrowser /usr/local/poudriere/data/logs/bulk/main-default/la

Re: ZFS deadlock in 14

om/openzfs/zfs/commit/2cb992a99ccadb78d97049b4= > > 0bd4=3D > > > > 42eb4fdc549d > > > > > > > > On Tue, Aug 8, 2023 at 10:08=3DE2=3D80=3DAFAM Dag-Erling > Sm=3DC3=3DB8rg= > > rav > > > sd.org> wrote: > > > > > > &g

Re: ZFS deadlock in 14

b4= > 0bd4=3D > > > 42eb4fdc549d > > > > > > On Tue, Aug 8, 2023 at 10:08=3DE2=3D80=3DAFAM Dag-Erling Sm=3DC3=3DB8rg= > rav > > sd.org> wrote: > > > > > > > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a >

Re: ZFS deadlock in 14

= > > 42eb4fdc549d > > > > On Tue, Aug 8, 2023 at 10:08=E2=80=AFAM Dag-Erling Sm=C3=B8rgrav > sd.org> wrote: > > > > > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > > > deadlock was introduced in ZFS. It is still present as of

Re: ZFS deadlock in 14

and f0c9703301 (26 June), a > > deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 > > August) and is 100% reproducable just by starting poudriere bulk in a > > 16-core VM and waiting a few hours until deadlkres kicks in. In the > > latest instance, deadlk

Re: ZFS deadlock in 14

Hi! > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > > deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 > > August) and is 100% reproducable just by starting poudriere bulk in a > > 16-core VM and waiting a few hours

Re: ZFS deadlock in 14

Hi! > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 > August) and is 100% reproducable just by starting poudriere bulk in a > 16-core VM and waiting a few hours until deadlkres kicks i

Re: ZFS deadlock in 14

Possibly https://github.com/openzfs/zfs/commit/2cb992a99ccadb78d97049b40bd442eb4fdc549d On Tue, Aug 8, 2023 at 10:08 AM Dag-Erling Smørgrav wrote: > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > deadlock was introduced in ZFS. It is still present as of 9c28

Re: ZFS deadlock in 14

maybe. OpenPGP_signature Description: OpenPGP digital signature

Re: ZFS deadlock in 14

Alan Somers writes: > Do you have ZFS block cloning enabled on your pool? There were a lot > of bugs associated with that feature. I think that was merged on > 3-April. No, and this deadlock did not appear until May. DES -- Dag-Erling Smørgrav - d...@freebsd.org

Re: ZFS deadlock in 14

On Tue, Aug 8, 2023 at 10:08 AM Dag-Erling Smørgrav wrote: > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), a > deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 > August) and is 100% reproducable just by starting poudriere bulk in a >

ZFS deadlock in 14

At some point between 42d088299c (4 May) and f0c9703301 (26 June), a deadlock was introduced in ZFS. It is still present as of 9c2823bae9 (4 August) and is 100% reproducable just by starting poudriere bulk in a 16-core VM and waiting a few hours until deadlkres kicks in. In the latest instance

Re: panic in drm or vt or deadlock on mutex or ...

On 2021-02-09 02:20, Emmanuel Vadot wrote: > Alastair: Can you report a bug there : > https://github.com/freebsd/drm-kmod/issues https://github.com/freebsd/drm-kmod/issues/64 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailm

Re: panic in drm or vt or deadlock on mutex or ...

On 3/9/21 9:31 AM, Alastair Hogge wrote: On 2021-02-08 21:01, Hans Petter Selasky wrote: On 2/8/21 1:53 PM, Alastair Hogge wrote: Boot to multi-user; login (getty): $ doas kldload /boot/modules/amdgpu.ko $ sysctl [panic] ..is a guaranteed way to panic my system. Hi, Maybe you could do a hac

Re: panic in drm or vt or deadlock on mutex or ...

On 2021-02-08 21:01, Hans Petter Selasky wrote: > On 2/8/21 1:53 PM, Alastair Hogge wrote: >> Boot to multi-user; login (getty): >> $ doas kldload /boot/modules/amdgpu.ko >> $ sysctl >> [panic] >> >> ..is a guaranteed way to panic my system. > > Hi, > > Maybe you could do a hack and edit the sysc

13.0-CURRENT #22 r369328 - possible deadlock detected

Hi: So I've had a crash - below is the relevant information. FreeBSD firewall.mikej.com 13.0-CURRENT FreeBSD 13.0-CURRENT #22 r369328: Sun Feb 21 09:26:46 EST 2021 mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC

Re: panic in drm or vt or deadlock on mutex or ...

Sorry, please ignore previous reply, the modified sysctl is still running, the output earlier, was from the stock binary. On 2021-02-09 14:25, Alastair Hogge wrote: > On 2021-02-08 21:01, Hans Petter Selasky wrote: >> On 2/8/21 1:53 PM, Alastair Hogge wrote: >>> Boot to multi-user; login (getty):

Re: panic in drm or vt or deadlock on mutex or ...

On 2021-02-08 21:01, Hans Petter Selasky wrote: > On 2/8/21 1:53 PM, Alastair Hogge wrote: >> Boot to multi-user; login (getty): >> $ doas kldload /boot/modules/amdgpu.ko >> $ sysctl >> [panic] >> >> ..is a guaranteed way to panic my system. > > Hi, > > Maybe you could do a hack and edit the sysc

Re: panic in drm or vt or deadlock on mutex or ...

On Mon, 08 Feb 2021 21:05:24 +0300 Greg V wrote: > > > On Mon, Feb 8, 2021 at 04:53, Alastair Hogge wrote: > > On 2021-02-04 17:50, Emmanuel Vadot wrote: > > > > [...] > > > >> Only happens with drm when you do what ? > > > > Boot to multi-user; login (getty): > > $ doas kldload /boot/mod

Re: panic in drm or vt or deadlock on mutex or ...

On Mon, Feb 8, 2021 at 04:53, Alastair Hogge wrote: On 2021-02-04 17:50, Emmanuel Vadot wrote: [...] Only happens with drm when you do what ? Boot to multi-user; login (getty): $ doas kldload /boot/modules/amdgpu.ko $ sysctl [panic] ..is a guaranteed way to panic my system. https:/

Re: panic in drm or vt or deadlock on mutex or ...

On 2/8/21 1:53 PM, Alastair Hogge wrote: Boot to multi-user; login (getty): $ doas kldload /boot/modules/amdgpu.ko $ sysctl [panic] ..is a guaranteed way to panic my system. Hi, Maybe you could do a hack and edit the sysctl source code: 1) print the sysctl before it is queried. 2) sleep 1 se

Re: panic in drm or vt or deadlock on mutex or ...

On 2021-02-04 17:50, Emmanuel Vadot wrote: [...] > Only happens with drm when you do what ? Boot to multi-user; login (getty): $ doas kldload /boot/modules/amdgpu.ko $ sysctl [panic] ..is a guaranteed way to panic my system. ___ freebsd-current@freeb

Re: panic in drm or vt or deadlock on mutex or ...

On Thu, Feb 04, 2021 at 10:50:29AM +0100, Emmanuel Vadot wrote: > On Wed, 3 Feb 2021 08:03:24 -0800 > Steve Kargl wrote: > > > On Wed, Feb 03, 2021 at 10:42:21AM +0200, Andriy Gapon wrote: > > > On 03/02/2021 07:08, Steve Kargl wrote: > > > > Fatal trap 12: page fault while in kernel mode > > > >

Re: panic in drm or vt or deadlock on mutex or ...

On Wed, 3 Feb 2021 08:03:24 -0800 Steve Kargl wrote: > On Wed, Feb 03, 2021 at 10:42:21AM +0200, Andriy Gapon wrote: > > On 03/02/2021 07:08, Steve Kargl wrote: > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0xc374 > > > fa

Re: panic in drm or vt or deadlock on mutex or ...

On Wed, Feb 03, 2021 at 10:42:21AM +0200, Andriy Gapon wrote: > On 03/02/2021 07:08, Steve Kargl wrote: > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0xc374 > > fault code = supervisor read data, page not present > > in

Re: panic in drm or vt or deadlock on mutex or ...

On 03/02/2021 07:08, Steve Kargl wrote: > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xc374 > fault code= supervisor read data, page not present > instruction pointer = 0x20:0xef411f > stack pointer = 0x28:0x4074e97c

panic in drm or vt or deadlock on mutex or ...

% pkg info | grep kmod drm-devel-kmod-5.4.62.g20210128 DRM modules for the linuxkpi-basedr KMS components (development version) gpu-firmware-kmod-g20201213Firmware modules for the linuxkpi-based KMS components mobile dumped core - see /var/crash/vmcore.0 Tue Feb 2 20:56:29 PST 2021 FreeBS

Re: Possible deadlock on IO / page fault

sleepq_switch() at sleepq_switch+0x11a/frame 0xfe00bfd44740 > > > > _cv_wait() at _cv_wait+0x15a/frame 0xfe00bfd447a0 > > > > rangelock_enter() at rangelock_enter+0x306/frame 0xfe00bfd447f0 > > > This call to rangelock_enter() looks suspicious.

Re: Possible deadlock on IO / page fault

h() at sleepq_switch+0x11a/frame 0xfe00bfd44740 > > > _cv_wait() at _cv_wait+0x15a/frame 0xfe00bfd447a0 > > > rangelock_enter() at rangelock_enter+0x306/frame 0xfe00bfd447f0 > > This call to rangelock_enter() looks suspicious. This is a call to ZFS > > o

Re: Possible deadlock on IO / page fault

ngelock_enter() looks suspicious. This is a call to ZFS > own rangelocks, not our rangelocks. Still, if write took rangelock on the > same range, we get a deadlock due to LoR between rangelock and page busy. This was fixed by r361287. In particular zfs_getpages() will no longer block on the ZFS r

Re: Possible deadlock on IO / page fault

n() at fast_syscall_common+0x101/frame > 0xfe00b0708bf0 > --- syscall (33, FreeBSD ELF64, sys_access), rip = 0x800fd0eba, rsp = > 0x7fffe268, rbp = 0x7fffe380 --- > > All other locked threads look more interesting. Thread 100747 is trying to > write > into file a

Possible deadlock on IO / page fault

cked_range due to present writer. I suppose it's deadlock caused all troubles. Tracing command dconf-service pid 2384 tid 100747 td 0xfe00b08cc000 sched_switch() at sched_switch+0x5b2/frame 0xfe00b0d762e0 mi_switch() at mi_switch+0x155/frame 0xfe00b0d76300 slee

Re: zfs deadlock on r360452 relating to busy vm page

se the page busy lock as the single point > > of synchronization for per-page state. As you noted, updates to the > > valid bits were previously interlocked by the object lock, but this is > > coarse-grained and hurts concurrency. I think you are right that the > > range lockin

Re: zfs deadlock on r360452 relating to busy vm page

ts concurrency. I think you are right that the > range locking in getpages was ok before the recent change, but it seems > preferable to try and address this in ZFS. > >>> In illumos (and, I think, in OpenZFS/ZoL) they don't have the range locking >>> in >>&

Re: zfs deadlock on r360452 relating to busy vm page

the > > commit > > message. The general trend has been to use the page busy lock as the single point of synchronization for per-page state. As you noted, updates to the valid bits were previously interlocked by the object lock, but this is coarse-grained and hurts concurrency. I think you

Re: zfs deadlock on r360452 relating to busy vm page

t on my assumptions stated in the > commit > message. > > In illumos (and, I think, in OpenZFS/ZoL) they don't have the range locking in > this corner of the code because of a similar deadlock a long time ago. > >> On 5/12/2020 3:13 PM, Bryan Drewery wrote: &g

Re: zfs deadlock on r360452 relating to busy vm page

e latest VM code better than me can comment on my assumptions stated in the commit message. In illumos (and, I think, in OpenZFS/ZoL) they don't have the range locking in this corner of the code because of a similar deadlock a long time ago. > On 5/12/2020 3:13 PM, Bryan Drewery

Re: zfs deadlock on r360452 relating to busy vm page

x6e #10 0x8106544e at trap_pfault+0x1ee #11 0x81064a9c at trap+0x44c #12 0x8103a978 at calltrap+0x8 On 5/12/2020 3:13 PM, Bryan Drewery wrote: >> panic: deadlres_td_sleep_q: possible deadlock detected for >> 0xfe25eefa2e00 (find), blocked for 1802392 ticks >

zfs deadlock on r360452 relating to busy vm page

> panic: deadlres_td_sleep_q: possible deadlock detected for 0xfe25eefa2e00 > (find), blocked for 1802392 ticks 2 stuck processes from procstat -kk before panic > 72559 101698 tail- mi_switch+0x155 > sleepq_switch+0x11a _cv_wait+0x15a rangelock

Re: Reproducable deadlock in NFS client

On 2019-Oct-03 23:28:07 +, Rick Macklem wrote: >1 - kib@ just put a patch up on phabricator that reorganizes the handling > of vnode_pager_setsize(). > D21883 > (If you could test this patch, that might be the best approach.) That fixes my problem. I've added a note to D21883

re: Reproducable deadlock in NFS client

Hi Peter, You could try a couple of things: 1 - kib@ just put a patch up on phabricator that reorganizes the handling of vnode_pager_setsize(). D21883 (If you could test this patch, that might be the best approach.) or 2 - The only differences between the post r352392 code and th

Reproduceable deadlock in NFS Client

My diskless Rock64 has taken to deadlocking reproduceably whilst building libprivatesqlite3.a as part of buildworld when running r352792. At the time of the deadlock, the relevant running process is: ar -crD libprivatesqlite3.a sqlite3.o And those files are: -rw-r--r--1 root wheel 3178496

Re: Deadlock involving truss -f, pdfork() and wait4()

As Conrad has pointed out, it's an explicit PID. The test completes successfully when not run under truss -f. On Fri, Sep 13, 2019 at 2:37 PM Mark Johnston wrote: > > On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote: > > This gets me a little further but now the wait4 call by the paren

Re: Deadlock involving truss -f, pdfork() and wait4()

On Fri, Sep 13, 2019 at 11:37 AM Mark Johnston wrote: > > On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote: > > This gets me a little further but now the wait4 call by the parent > > never reaps the child and instead blocks forever: > > Does it perform a wildcarded wait(), or does it exp

Re: Deadlock involving truss -f, pdfork() and wait4()

On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote: > This gets me a little further but now the wait4 call by the parent > never reaps the child and instead blocks forever: Does it perform a wildcarded wait(), or does it explicitly specify the PID of the child? By design, the former will

Re: Deadlock involving truss -f, pdfork() and wait4()

). I have a process > > that calls pdfork() and the parent immediately does a wait4() on the > > child pid. This works fine under normal conditions, but if the parent > > is run under truss -f, the three processes deadlock. If I switch out > > pdfork() for fork(), the

Re: Deadlock involving truss -f, pdfork() and wait4()

s a wait4() on the > child pid. This works fine under normal conditions, but if the parent > is run under truss -f, the three processes deadlock. If I switch out > pdfork() for fork(), the deadlock does not occur. > > This C file demonstrates the issue: > > https://people.fr

Deadlock involving truss -f, pdfork() and wait4()

I've hit an issue with a simple use of pdfork(). I have a process that calls pdfork() and the parent immediately does a wait4() on the child pid. This works fine under normal conditions, but if the parent is run under truss -f, the three processes deadlock. If I switch out pdfork() for

deadlock detected in -current (new).. NFS? Anyone with 'amd' knowledge?

Anyone seen these recently? I just got the following: panic: deadlkres: possible deadlock detected for (address)  blocked for (big number) ticks anyone seen similar on very new (yesterday) -current GENERIC. ? there was a prior message that may or may not be related: newnfs: server pid741

deadlock in current (r314698)?

Hi, do we have a known deadlock with r314698? I have a system which locks up and some seconds later the watchdog kicks in and reboots. Sometimes it survives a day or two, sometimes it reboots more than once a day. I'm rebuilding the kernel with WITNESS now, but if someone is aware

Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock

RRENT r271182 I got > > >>> the following panic yesterday: > > >>> > > >>> [...] Unread portion of the kernel message buffer: [6880] > > >>> panic: deadlkres: possible deadlock detected for > > >>> 0xf80015289490, blocked for 1800503 ticks

Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock

gt; > >>> [...] Unread portion of the kernel message buffer: [6880] > >>> panic: deadlkres: possible deadlock detected for > >>> 0xf80015289490, blocked for 1800503 ticks > >> > >> Any chance to get all backtraces (e.g. thread apply al

Re: [patch] deadlock in vm_reserv_reclaim_contig()

On Sat, Apr 11, 2015 at 7:57 PM, Alan Cox wrote: > On 04/10/2015 04:11, Svatopluk Kraus wrote: >> Hi, >> >> my RPI-B has been stuck in vm_reserv_reclaim_contig() due to a bug >> within that function. I can reproduce that easily on my two-core >> pandaboard when I limit all memory in system to 128M

Re: [patch] deadlock in vm_reserv_reclaim_contig()

On 04/10/2015 04:11, Svatopluk Kraus wrote: > Hi, > > my RPI-B has been stuck in vm_reserv_reclaim_contig() due to a bug > within that function. I can reproduce that easily on my two-core > pandaboard when I limit all memory in system to 128MiB and run "make > -j16 kernel-toolchain". It happens in

Re: Panic after USB deadlock followed by kldunload umass.ko

On 12/21/14 14:54, Fabian Keil wrote: #0 sched_switch (td=0xf80015ea0940, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1940 #1 0x805bbf91 in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:492 #2 0x8060126a in sleepq_wait (wchan=0x0, pri=0) at /usr/

Re: Panic after USB deadlock followed by kldunload umass.ko

Fabian Keil wrote: > Hans Petter Selasky wrote: > > > On 10/23/14 16:28, Fabian Keil wrote: > > > > kldunload umass.ko lead to a panic, dumping didn't work. > > > > > > Screenshots are available at: > > > http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r273434-usb/ > > > > > > I've seen l

Re: Panic after USB deadlock followed by kldunload umass.ko

Hans Petter Selasky wrote: > On 10/23/14 16:28, Fabian Keil wrote: > > kldunload umass.ko lead to a panic, dumping didn't work. > > > > Screenshots are available at: > > http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r273434-usb/ > > > > I've seen locked-up usbconfig processes in the past,

Re: Panic after USB deadlock followed by kldunload umass.ko

On 10/23/14 16:28, Fabian Keil wrote: A few days ago a couple of usbconfig processed did not exit: fk@r500 ~ $sudo procstat -kk $(pgrep usbconfig) PIDTID COMM TDNAME KSTACK 1624 100781 usbconfig-mi_switch+0xe1 sleepq_wait+0x3a _sx_xlock_har

Panic after USB deadlock followed by kldunload umass.ko

A few days ago a couple of usbconfig processed did not exit: fk@r500 ~ $sudo procstat -kk $(pgrep usbconfig) PIDTID COMM TDNAME KSTACK 1624 100781 usbconfig-mi_switch+0xe1 sleepq_wait+0x3a _sx_xlock_hard+0x522 _sx_xlock+0

Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock

gt;>>> the following panic yesterday: >>>> >>>> [...] Unread portion of the kernel message buffer: [6880] >>>> panic: deadlkres: possible deadlock detected for >>>> 0xf80015289490, blocked for 1800503 ticks >>> >>> Any cha

  1   2   3   >