Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included]

2019-01-02 Thread Mark Millard via freebsd-ports
On 2019-Jan-2, at 17:41, Kyle Evans  wrote:

> On Wed, Jan 2, 2019 at 3:38 AM Mark Millard via freebsd-ports
>  wrote:
>> 
>>> . . .
>> 
>> So (without old line numbers):
>> 
>>} else if (TARGET_URWLOCK_READER_COUNT(state) != 0) {
>>/* decrement reader count */
>>for (;;) {
>>if (!tcmpset_32(_urwlock->rw_state, state, (state  - 1))) {
>>__get_user(state, _urwlock->rw_state);
>>if (TARGET_URWLOCK_READER_COUNT(state) == 0) {
>>unlock_user_struct(target_urwlock,
>>target_addr, 1);
>>return -TARGET_EPERM;
>> }
>>} else {
>>break;
>>}
>>}
>> 
>> This follows the structure of other tcmpset_32 use in the source file.
>> 
>> With this change poudriere-devel's bulk worked for graphics/poppler-qt5
>> as a amd64->armv7 cross-build (FreeBSD head -r341836 based, under Hyper-V,
>> with 28 logical-processors assigned):
>> 
> 
> Ah, thanks for that! I think your analysis is correct, and I've
> created a pull request [1] for Sean. This should fix the apparent
> hangs reported by many across armv7/aarch64.
> 
> [1] https://github.com/seanbruno/qemu-bsd-user/pull/72

There is also the issue that the __packed use for target_freebsd_kevent
and target_freebsd11_kevent cause the wrong size and field offsets for
armv7 (and armv6) when translating to or from the host (amd64)
struct kevent vs. the target struct kevent. These hangs show up as
in the kqread state or other such implying kevent is hung-up,
unlike for the above.

I'm using the following for now:

> struct target_freebsd11_kevent {
>   abi_ulong  ident;
>   int16_tfilter;
>   uint16_t   flags;
>   uint32_t   fflags;
>   abi_long   data;
>   abi_ulong  udata;
> } ; // __packed;
> 
> struct target_freebsd_kevent {
>   abi_ulong  ident;
>   int16_tfilter;
>   uint16_t   flags;
>   uint32_t   fflags;
>   int64_t data;
>   abi_ulong  udata;
>   uint64_t  ext[4];
> } ; // __packed;

With these I was finally able to build lumina for armv7 via
a cross-build (amd64->armv7). Sean is aware of this.



However, I still get other hang-ups for targeting aarch64.
I've started trying to gather evidence for the one I currently
get.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included]

2019-01-02 Thread Kyle Evans
On Wed, Jan 2, 2019 at 3:38 AM Mark Millard via freebsd-ports
 wrote:
>
> On 2019-Jan-1, at 18:43, Mark Millard  wrote:
>
> > The below showed up for poudiere-devel bulk getting stuck using one FreeBSD
> > cpu while building graphics/poppler-qt5 . This is not a kevent hang-up, 
> > unlike
> > the last hang-up that I analyzed. I do not yet know how repeatable this is
> > but the original hang-up and the one experiment the below is from.
> >
> > From top:
> >
> >  PID USERNAMETHR PRI NICE   SIZERES SWAP STATEC   TIME CPU 
> > COMMAND
> > 12789 root  4  520   166M33M0 uwait6  36:06  97.22% 
> > /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
> > /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0
> >
> > Note: The vast margority of the 36:06 has been stuck in the uwait loop 
> > involved.
> >
> > From ps -auxd:
> >
> > root   940750.0  0.0  12932  3552  1  S+   10:420:01.21 |   
> > `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> > graphics/poppler-qt5
> > root19440.0  0.0  12932  3540  1  I+   10:420:00.00 |   
> >   |-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 
> > -w graphics/poppler-qt5
> > root19570.0  0.0  12932  3556  1  I10:420:00.04 |   
> >   |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
> > (poppler-qt5-0.72.0) (sh)
> > root   123280.0  0.0  12932  3548  1  I10:490:00.00 |   
> >   | `-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
> > (poppler-qt5-0.72.0) (sh)
> > root   123290.0  0.0  10328  1756  1  IJ   10:490:00.01 |   
> >   |   `-- /usr/bin/make -C /usr/ports/graphics/poppler-qt5 stage
> > root   123500.0  0.0   9860  1248  1  IJ   10:490:00.00 |   
> >   | `-- /usr/bin/make -f Makefile 
> > DESTDIR=/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install
> > root   123530.0  0.0  10236  1664  1  IJ   10:490:00.05 |   
> >   |   `-- /nxb-bin/usr/bin/make -f CMakeFiles/Makefile2 qt5/all
> > root   127870.0  0.0   9856  1236  1  IJ   10:500:00.00 |   
> >   | `-- /nxb-bin/usr/bin/make -f 
> > qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make qt5/test
> > root   12789  100.0  0.0 169868 33528  1  IJ   10:50   36:35.26 |   
> >   |   `-- /usr/local/bin/qemu-arm-static 
> > /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/graphics/
> > root   944230.0  0.0  12932  3484  1  S+   10:420:12.91 |   
> >   `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 
> > -w graphics/poppler-qt5
> >
> >
> > (gdb) attach 12789
> > Attaching to process 12789
> > Reading symbols from 
> > /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qemu-arm-static...done.
> > [New LWP 101168 of process 12789]
> > [New LWP 101178 of process 12789]
> > [New LWP 101499 of process 12789]
> > [Switching to LWP 100304 of process 12789]
> > _umtx_op () at _umtx_op.S:3
> > 3 RSYSCALL(_umtx_op)
> > (gdb) info threads
> >  Id   Target Id   Frame
> > * 1LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3
> >  2LWP 101168 of process 12789 _umtx_op_err () at 
> > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
> >  3LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3
> >  4LWP 101499 of process 12789 0x60051c26 in atomic_cmpset_int 
> > (dst=, expect=, src=536870912) at 
> > /usr/include/machine/atomic.h:220
> > (gdb) thread 4
> > [Switching to thread 4 (LWP 101499 of process 12789)]
> > #0  0x60051c26 in atomic_cmpset_int (dst=, 
> > expect=, src=536870912) at /usr/include/machine/atomic.h:220
> > 220   ATOMIC_CMPSET(int);
> >
> > (gdb) bt
> > #0  0x60051c26 in atomic_cmpset_int (dst=, 
> > expect=, src=536870912) at /usr/include/machine/atomic.h:220
> > #1  tcmpset_32 (addr=, a=, b=536870912) at 
> > /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:178
> > #2  freebsd_rw_unlock (target_addr=4108246528) at 
> > /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:1264
> > #3  0x6004ab33 in do_freebsd__umtx_op (obj=, 
> > op=536870912, val=, uaddr=, 
> > target_time=)
> >at 
> > /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.h:474
> > #4  0x60041b83 in do_freebsd_syscall (cpu_env=0x86159b118, num=454, 
> > arg1=, arg2=, arg3=, arg4=0, 
> > arg5=0, arg6=-184411592, arg7=-199471616,
> >arg8=-1622188640) at 
> > /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall.c:1364
> > #5  0x600392f0 in target_cpu_loop (env=0x86159b118) at 
> > 

Re: sysutils/915resolution

2019-01-02 Thread Niclas Zeising

On 2019-01-02 16:37, Matthias Apitz wrote:

El día miércoles, enero 02, 2019 a las 04:24:09p. m. +0100, Niclas Zeising 
escribió:


On 2019-01-02 14:09, Matthias Apitz wrote:


Hello,

I've updated a FreeBSD on an Acer C720 laptop to 13.0-CURRENT (r342378)
and port sysutils/915resolution to r488233. This says now on boot:

 Jan  1 07:06:41 c720-r342378 kernel: Intel chipset detected.  However, 
915resolution was unable to determine the chipset type.
 Jan  1 07:06:41 c720-r342378 kernel: Chipset Id: a048086
 Jan  1 07:06:41 c720-r342378 kernel: Please report this problem to 
stoml...@yahoo.com

and KDE does not start anymore in Xorg.



Which graphics driver are you using?
Regards


Please find attached the /var/log/Xorg.0.log
Thanks




Looks like you're using the VESA xorg ddx.  On FreeBSD 13-current you 
need to install the kernel graphics drivers from ports, I can't answer 
for exactly how 915resolution works, but having the kernel graphics card 
driver is a first step I assume.


Install it from graphics/drm-kmod.  On 13-CURRENT it's best to build it 
from ports instead of using packages, so that it matches your kernel 
version.  Then follow the instructions in the pkg-message to have the 
right driver loaded.


Regards
--
Niclas


--
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: sysutils/915resolution

2019-01-02 Thread Matthias Apitz
El día miércoles, enero 02, 2019 a las 04:24:09p. m. +0100, Niclas Zeising 
escribió:

> On 2019-01-02 14:09, Matthias Apitz wrote:
> > 
> > Hello,
> > 
> > I've updated a FreeBSD on an Acer C720 laptop to 13.0-CURRENT (r342378)
> > and port sysutils/915resolution to r488233. This says now on boot:
> > 
> > Jan  1 07:06:41 c720-r342378 kernel: Intel chipset detected.  However, 
> > 915resolution was unable to determine the chipset type.
> > Jan  1 07:06:41 c720-r342378 kernel: Chipset Id: a048086
> > Jan  1 07:06:41 c720-r342378 kernel: Please report this problem to 
> > stoml...@yahoo.com
> > 
> > and KDE does not start anymore in Xorg.
> > 
> 
> Which graphics driver are you using?
> Regards

Please find attached the /var/log/Xorg.0.log
Thanks

matthias


-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, 
Druschba
instead of Nazis, to live instead of to survive.
[   117.660] 
X.Org X Server 1.18.4
Release Date: 2016-07-19
[   117.660] X Protocol Version 11, Revision 0
[   117.660] Build Operating System: FreeBSD 13.0-CURRENT amd64 
[   117.660] Current Operating System: FreeBSD c720-r342378 13.0-CURRENT 
FreeBSD 13.0-CURRENT r342378 GENERIC amd64
[   117.661] Build Date: 24 December 2018  08:29:11PM
[   117.661]  
[   117.661] Current version of pixman: 0.34.0
[   117.661]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   117.661] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   117.661] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan  2 11:27:03 
2019
[   117.665] (II) Loader magic: 0x41b010
[   117.665] (II) Module ABI versions:
[   117.665]X.Org ANSI C Emulation: 0.4
[   117.665]X.Org Video Driver: 20.0
[   117.665]X.Org XInput driver : 22.1
[   117.665]X.Org Server Extension : 9.0
[   117.666] (--) PCI:*(0:0:2:0) 8086:0a06:1025:0a11 rev 9, Mem @ 
0xe000/4194304, 0xd000/268435456, I/O @ 0x1800/64, BIOS @ 
0x/65536
[   117.667] (==) Using default built-in configuration (39 lines)
[   117.667] (==) --- Start of built-in configuration ---
[   117.667]Section "Device"
[   117.667]Identifier  "Builtin Default intel Device 0"
[   117.667]Driver  "intel"
[   117.667]EndSection
[   117.667]Section "Screen"
[   117.667]Identifier  "Builtin Default intel Screen 0"
[   117.667]Device  "Builtin Default intel Device 0"
[   117.667]EndSection
[   117.667]Section "Device"
[   117.667]Identifier  "Builtin Default modesetting Device 0"
[   117.667]Driver  "modesetting"
[   117.667]EndSection
[   117.667]Section "Screen"
[   117.667]Identifier  "Builtin Default modesetting Screen 0"
[   117.667]Device  "Builtin Default modesetting Device 0"
[   117.667]EndSection
[   117.667]Section "Device"
[   117.667]Identifier  "Builtin Default scfb Device 0"
[   117.667]Driver  "scfb"
[   117.667]EndSection
[   117.667]Section "Screen"
[   117.667]Identifier  "Builtin Default scfb Screen 0"
[   117.667]Device  "Builtin Default scfb Device 0"
[   117.667]EndSection
[   117.667]Section "Device"
[   117.667]Identifier  "Builtin Default vesa Device 0"
[   117.667]Driver  "vesa"
[   117.667]EndSection
[   117.667]Section "Screen"
[   117.667]Identifier  "Builtin Default vesa Screen 0"
[   117.667]Device  "Builtin Default vesa Device 0"
[   117.667]EndSection
[   117.667]Section "ServerLayout"
[   117.667]Identifier  "Builtin Default Layout"
[   117.667]Screen  "Builtin Default intel Screen 0"
[   117.667]Screen  "Builtin Default modesetting Screen 0"
[   117.667]Screen  "Builtin Default scfb Screen 0"
[   117.667]Screen  "Builtin Default vesa Screen 0"
[   117.667]EndSection
[   117.667] (==) --- End of built-in configuration ---
[   117.667] (==) ServerLayout "Builtin Default Layout"
[   117.667] (**) |-->Screen "Builtin Default intel Screen 0" (0)
[   117.667] (**) |   |-->Monitor ""
[   117.668] (**) |   |-->Device "Builtin Default intel Device 0"
[   117.668] (==) No monitor specified for screen "Builtin Default intel Screen 
0".
Using a default monitor configuration.
[   117.668] (**) |-->Screen "Builtin Default modesetting Screen 0" (1)
[   117.668] (**) |   |-->Monitor ""
[   117.668] (**) |   |-->Device "Builtin Default modesetting Device 0"
[   117.668] (==) No monitor specified for screen "Builtin Default modesetting 
Screen 0".

Re: sysutils/915resolution

2019-01-02 Thread Niclas Zeising

On 2019-01-02 14:09, Matthias Apitz wrote:


Hello,

I've updated a FreeBSD on an Acer C720 laptop to 13.0-CURRENT (r342378)
and port sysutils/915resolution to r488233. This says now on boot:

Jan  1 07:06:41 c720-r342378 kernel: Intel chipset detected.  However, 
915resolution was unable to determine the chipset type.
Jan  1 07:06:41 c720-r342378 kernel: Chipset Id: a048086
Jan  1 07:06:41 c720-r342378 kernel: Please report this problem to 
stoml...@yahoo.com

and KDE does not start anymore in Xorg.



Which graphics driver are you using?
Regards
--
Niclas
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: vim - GTK2 or GTK3?

2019-01-02 Thread Niclas Zeising

On 2019-01-02 10:42, Lars Engels wrote:

On Tue, Jan 01, 2019 at 01:07:24PM -0700, Adam Weinberger wrote:

I'm curious whether the default Vim port should use GTK2 or GTK3 as
its UI toolkit, but I use neither so I need input from people here.

Right now it defaults to GTK2, but I'm suspecting that more people use
GTK3 these days. I haven't run X in about 10 years, so I don't really
know one way or the other. If anybody on this list has thoughts about
GTK2 vs GTK3 (or something else!) as the default, I'd love to hear it.

The Vim choices are currently a mess, but it'll get better once
subpackages land.


Firefox and Chromium both depend on GTK3, so it's highly likely that a
typical desktop user has GTK3 installed.


+1, GTK3 is probably the best choice.

As a side note, it looks like libreoffice defaults to GTK2 as well, 
perhaps it should be switched to GTK3 also?

Regards
--
Niclas
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


FreeBSD ports you maintain which are out of date

2019-01-02 Thread portscout
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
audio/py-pylast | 2.4.0   | 3.0.0
+-+
devel/mingw32-pdcurses  | 3.4 | 3.7
+-+
net-mgmt/mk-livestatus  | 1.2.8p20| 1.2.8p22
+-+
www/libjwt  | 1.9.0   | v1.10.1
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


sysutils/915resolution

2019-01-02 Thread Matthias Apitz

Hello,

I've updated a FreeBSD on an Acer C720 laptop to 13.0-CURRENT (r342378)
and port sysutils/915resolution to r488233. This says now on boot:

   Jan  1 07:06:41 c720-r342378 kernel: Intel chipset detected.  However, 
915resolution was unable to determine the chipset type.
   Jan  1 07:06:41 c720-r342378 kernel: Chipset Id: a048086
   Jan  1 07:06:41 c720-r342378 kernel: Please report this problem to 
stoml...@yahoo.com

and KDE does not start anymore in Xorg.

Thanks

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, 
Druschba
instead of Nazis, to live instead of to survive.


signature.asc
Description: PGP signature


Re: vim - GTK2 or GTK3?

2019-01-02 Thread Lars Engels
On Tue, Jan 01, 2019 at 01:07:24PM -0700, Adam Weinberger wrote:
> I'm curious whether the default Vim port should use GTK2 or GTK3 as
> its UI toolkit, but I use neither so I need input from people here.
> 
> Right now it defaults to GTK2, but I'm suspecting that more people use
> GTK3 these days. I haven't run X in about 10 years, so I don't really
> know one way or the other. If anybody on this list has thoughts about
> GTK2 vs GTK3 (or something else!) as the default, I'd love to hear it.
> 
> The Vim choices are currently a mess, but it'll get better once
> subpackages land.

Firefox and Chromium both depend on GTK3, so it's highly likely that a
typical desktop user has GTK3 installed.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included]

2019-01-02 Thread Mark Millard via freebsd-ports
On 2019-Jan-1, at 18:43, Mark Millard  wrote:

> The below showed up for poudiere-devel bulk getting stuck using one FreeBSD
> cpu while building graphics/poppler-qt5 . This is not a kevent hang-up, unlike
> the last hang-up that I analyzed. I do not yet know how repeatable this is
> but the original hang-up and the one experiment the below is from.
> 
> From top:
> 
>  PID USERNAMETHR PRI NICE   SIZERES SWAP STATEC   TIME CPU 
> COMMAND
> 12789 root  4  520   166M33M0 uwait6  36:06  97.22% 
> /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
> /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0
> 
> Note: The vast margority of the 36:06 has been stuck in the uwait loop 
> involved.
> 
> From ps -auxd:
> 
> root   940750.0  0.0  12932  3552  1  S+   10:420:01.21 | 
>   `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> graphics/poppler-qt5
> root19440.0  0.0  12932  3540  1  I+   10:420:00.00 | 
> |-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> graphics/poppler-qt5
> root19570.0  0.0  12932  3556  1  I10:420:00.04 | 
> |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
> (poppler-qt5-0.72.0) (sh)
> root   123280.0  0.0  12932  3548  1  I10:490:00.00 | 
> | `-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
> (poppler-qt5-0.72.0) (sh)
> root   123290.0  0.0  10328  1756  1  IJ   10:490:00.01 | 
> |   `-- /usr/bin/make -C /usr/ports/graphics/poppler-qt5 stage
> root   123500.0  0.0   9860  1248  1  IJ   10:490:00.00 | 
> | `-- /usr/bin/make -f Makefile 
> DESTDIR=/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install
> root   123530.0  0.0  10236  1664  1  IJ   10:490:00.05 | 
> |   `-- /nxb-bin/usr/bin/make -f CMakeFiles/Makefile2 qt5/all
> root   127870.0  0.0   9856  1236  1  IJ   10:500:00.00 | 
> | `-- /nxb-bin/usr/bin/make -f 
> qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make qt5/test
> root   12789  100.0  0.0 169868 33528  1  IJ   10:50   36:35.26 | 
> |   `-- /usr/local/bin/qemu-arm-static /usr/local/bin/cmake 
> -E cmake_autogen /wrkdirs/usr/ports/graphics/
> root   944230.0  0.0  12932  3484  1  S+   10:420:12.91 | 
> `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> graphics/poppler-qt5
> 
> 
> (gdb) attach 12789
> Attaching to process 12789
> Reading symbols from 
> /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qemu-arm-static...done.
> [New LWP 101168 of process 12789]
> [New LWP 101178 of process 12789]
> [New LWP 101499 of process 12789]
> [Switching to LWP 100304 of process 12789]
> _umtx_op () at _umtx_op.S:3
> 3 RSYSCALL(_umtx_op)
> (gdb) info threads
>  Id   Target Id   Frame 
> * 1LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3
>  2LWP 101168 of process 12789 _umtx_op_err () at 
> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
>  3LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3
>  4LWP 101499 of process 12789 0x60051c26 in atomic_cmpset_int 
> (dst=, expect=, src=536870912) at 
> /usr/include/machine/atomic.h:220
> (gdb) thread 4
> [Switching to thread 4 (LWP 101499 of process 12789)]
> #0  0x60051c26 in atomic_cmpset_int (dst=, 
> expect=, src=536870912) at /usr/include/machine/atomic.h:220
> 220   ATOMIC_CMPSET(int);
> 
> (gdb) bt
> #0  0x60051c26 in atomic_cmpset_int (dst=, 
> expect=, src=536870912) at /usr/include/machine/atomic.h:220
> #1  tcmpset_32 (addr=, a=, b=536870912) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:178
> #2  freebsd_rw_unlock (target_addr=4108246528) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:1264
> #3  0x6004ab33 in do_freebsd__umtx_op (obj=, 
> op=536870912, val=, uaddr=, 
> target_time=)
>at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.h:474
> #4  0x60041b83 in do_freebsd_syscall (cpu_env=0x86159b118, num=454, 
> arg1=, arg2=, arg3=, arg4=0, 
> arg5=0, arg6=-184411592, arg7=-199471616, 
>arg8=-1622188640) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall.c:1364
> #5  0x600392f0 in target_cpu_loop (env=0x86159b118) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/arm/target_arch_cpu.h:207
> #6  0x60038c99 in cpu_loop (env=0xf4dede80) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/main.c:121
> #7  0x60050c1a in