Date: Wed, 2 Jan 2019 21:29:53 -0800 From: Mark Millard <marklmi@yahoo.com> To: Kyle Evans <kevans@freebsd.org> Cc: Sean Bruno <sbruno@freebsd.org>, freebsd-emulation@freebsd.org, ports-list freebsd <freebsd-ports@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included] Message-ID: <8EFD9D72-AABD-4AB1-8592-8B78E779F67F@yahoo.com> In-Reply-To: <CACNAnaHRh4cGt%2B800mDeBkmNGsiKzAU4=SUh7RZTe3vNOUAJ_g@mail.gmail.com> References: <51834F45-1EB7-449F-A0EC-7F5EC7CBB12F@yahoo.com> <A9A018B4-FE0C-4ABB-BB36-2E62B889A7BB@yahoo.com> <CACNAnaHRh4cGt%2B800mDeBkmNGsiKzAU4=SUh7RZTe3vNOUAJ_g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Jan-2, at 17:41, Kyle Evans <kevans at freebsd.org> wrote:
> On Wed, Jan 2, 2019 at 3:38 AM Mark Millard via freebsd-ports
> <freebsd-ports@freebsd.org> wrote:
>>=20
>>> . . .
>>=20
>> So (without old line numbers):
>>=20
>> } else if (TARGET_URWLOCK_READER_COUNT(state) !=3D 0) {
>> /* decrement reader count */
>> for (;;) {
>> if (!tcmpset_32(&target_urwlock->rw_state, state, (state =
- 1))) {
>> __get_user(state, &target_urwlock->rw_state);
>> if (TARGET_URWLOCK_READER_COUNT(state) =3D=3D 0) {
>> unlock_user_struct(target_urwlock,
>> target_addr, 1);
>> return -TARGET_EPERM;
>> }
>> } else {
>> break;
>> }
>> }
>>=20
>> This follows the structure of other tcmpset_32 use in the source =
file.
>>=20
>> 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):
>>=20
>=20
> 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.
>=20
> [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_t filter;
> uint16_t flags;
> uint32_t fflags;
> abi_long data;
> abi_ulong udata;
> } ; // __packed;
>=20
> struct target_freebsd_kevent {
> abi_ulong ident;
> int16_t filter;
> 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.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8EFD9D72-AABD-4AB1-8592-8B78E779F67F>