Date: Wed, 23 Mar 2022 08:34:31 -0700 From: Mark Millard <marklmi@yahoo.com> To: Kristof Provost <kp@FreeBSD.org>, bob prohaska <fbsd@www.zefox.net> Cc: "grembo@freebsd.org" <grembo@FreeBSD.org>, Free BSD <freebsd-arm@freebsd.org> Subject: Re: /usr/src/sys/net/if_epair.c:181:6: error: ... Message-ID: <F57B9660-6559-45CF-A0F8-0604E499F19B@yahoo.com> In-Reply-To: <4782B40F-EEB3-4051-A345-FE73708C51E4@FreeBSD.org> References: <20220323012657.GA82109@www.zefox.net> <43A846B1-4AD4-48C7-ADAB-82D1CAFF6DDB@yahoo.com> <3049B57B-CDEC-4EE8-A33D-97B833BB4A78@yahoo.com> <4782B40F-EEB3-4051-A345-FE73708C51E4@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Mar-23, at 03:51, Kristof Provost <kp@FreeBSD.org> wrote: > Hi Mark, Hello. > On 23 Mar 2022, at 4:23, Mark Millard wrote: >> On 2022-Mar-22, at 20:16, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >>> [Trying again after getting material from the wrong >>> commit the first time.] >>>=20 >>> On 2022-Mar-22, at 18:26, bob prohaska <fbsd@www.zefox.net> wrote: >>>=20 >>>> A Pi2 running >>>> FreeBSD www.zefox.net 12.3-STABLE FreeBSD 12.3-STABLE r371495 = GENERIC arm >>>>=20 >>>> stops buildkernel with: >>>> --- if_epair.o --- >>>> /usr/src/sys/net/if_epair.c:181:6: error: implicit declaration of = function 'atomic_testandclear_long' is invalid in C99 = [-Werror,-Wimplicit-function-declaration] >>>> if (atomic_testandclear_long(&q->state, BIT_MBUF_QUEUED)) >>>> ^ >>>>=20 >>>> Not sure if this is specific to the Raspberry Pi 2, it didn't show = up on a pair of Pi3's >>>> and a single Pi4. The system is still using svnlite, info reports >>>> root@www:/usr/src # svnlite info >>>> Path: . >>>> Working Copy Root Path: /usr/src >>>> URL: svn://svn.freebsd.org/base/stable/12 >>>> Relative URL: ^/stable/12 >>>> Repository Root: svn://svn.freebsd.org/base >>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>> Revision: 371771 >>>> Node Kind: directory >>>> Schedule: normal >>>> Last Changed Author: 0mp >>>> Last Changed Rev: 371771 >>>> Last Changed Date: 2022-03-22 15:28:40 -0700 (Tue, 22 Mar 2022) >>>>=20 >>>>=20 >>>> Didn't see anything similar on bugs.freebsd.org, if it's worth a = bug report or >>>> there's a workaround please post. It was built using WITH_META_MODE = if that >>>> matters. >>>=20 >>> QUOTE >>> author Kristof Provost <kp@FreeBSD.org> 2022-03-17 = 02:35:13 +0000 >>> committer Kristof Provost <kp@FreeBSD.org> 2022-03-20 = 00:25:06 +0000 >>> commit b1a3f8dccb6203036b7ee81201fd5b5a8de36f0d (patch) >>> . . . >>> if_epair: build fix >>> 66acf7685b failed to build on riscv (and mips). This is because the >>> atomic_testandset_int() (and friends) functions do not exist there. >>> Happily those platforms do have the long variant, so switch to that. >>> END QUOTE >>>=20 >>> broke things for stable/12 by adding the atomic_testandclear_long >>> usage without defining it as well. >>>=20 >>> It goes like this: >>>=20 >>> path: root/sys/arm/include/atomic.h >>> Commit message (Expand) Author Age Files Lines >>> * MFC r341787 by hselasky: Implement atomic_swap_xxx() for all = platforms. Andriy Gapon 2019-10-24 1 -0/+7 >>> * Remove arm-specific implementations of atomic_load/store_xxx() = now that Ian Lepore 2017-12-20 1 -27/+0 >>> . . . >>>=20 >>> So not updated in a long time. But for armv7 and the like, it = includes: >>>=20 >>> path: root/sys/arm/include/atomic-v6.h >>> Commit message (Expand) Author Age Files Lines >>> * MFC r352938: Ian Lepore 2019-12-07 1 = -100/+256 >>> * MFC r341679: Michal Meloun 2018-12-14 1 -1/+1 >>> . . . >>>=20 >>> Also not updated in a long time. >>>=20 >>> sys/arm/include/atomic-v6.h has various "atomic_testand" >>> examples ( sys/arm/include/atomic.h does not ): >>>=20 >>> atomic_testandset_32 >>> atomic_testandset_int >>> atomic_testandset_long >>> atomic_testandset_64 >>>=20 >>> But no examples of "atomic_testandclear" >>>=20 >>>=20 >>=20 >> The slightly older commit: >>=20 >> QUOTE >> author Michael Gmelin <grembo@FreeBSD.org> 2022-03-16 = 22:08:55 +0000 >> committer Kristof Provost <kp@FreeBSD.org> 2022-03-20 = 00:24:51 +0000 >> commit fb3644ab2afe777fdd2539bc996a390443f052f1 (patch) >> . . . >> if_epair: fix race condition on multi-core systems >> END QUOTE >>=20 >> has a use of "atomic_testandclear_int" as well. >>=20 >>=20 > Thanks for the report. >=20 > Can you try the attached patch? I=E2=80=99m not going to argue with = the MI code about the atomic_testandclear_int, but instead revert the = new if_epair code (in stable/12 only, of course). We will see if Bob P. can try it. (But his builds take time, given the machine type involved.) I'm not set up to build anything for 12. I just looked up what was going on in Bob's report and commented. Ultimately, if needed, I could deal with setting up a temporary context for building stable/12 on aarch64. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F57B9660-6559-45CF-A0F8-0604E499F19B>