Date: Wed, 8 Jan 2020 21:13:42 -0800 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, Ed Maste <emaste@freebsd.org> Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Message-ID: <8941BB3B-457B-4E33-A667-836DB6879178@yahoo.com> In-Reply-To: <B6479587-0563-4CA3-A99A-C02EE29B732E@yahoo.com> References: <B6479587-0563-4CA3-A99A-C02EE29B732E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Turns out that 32-bit powerpc can not complete
a kyua run and I'd forgotten that the debug
kernel is catching something, stopping normal
boots.]
On 2020-Jan-6, at 10:52, Mark Millard <marklmi at yahoo.com> wrote:
> Warner Losh imp at bsdimp.com wrote on
> Mon Jan 6 06:56:06 UTC 2020 :
>=20
>> . . .
>> Second, all other platforms still have the original deadlines to sort =
out
>> the last lingering issues with the external toolchain and/or clang. =
mips is
>> a bit up in the air right now since both the external toolchain and =
clang
>> have issues (though different issues). powerpc 32-bit is sorting out =
issues
>> as well. arm 32-bit still needs libunwind from gcc. An end of May =
deadline
>> is ample time for works in progress to get to the point where =
everything
>> boots and runs sufficiently well to show the platforms are still =
viable.
>> . . .
>=20
> The reference to 32-bit powerpc surprised me,
> unless it is really powerpcspe specific.
>=20
> 32-bit FreeBSD is booting the 32-bit powerpc's
> that I have access to, all the way to multi-user:
> Old 32-bit PowerMacs (from 2 socket G4's to an
> old iMac G3.) It is still based on the old ld.
> [All at head -r356187 currently.]
>=20
> (I do not have access to a powerpcspe context.)
>=20
> True that using 32-bit FreeBSD to boot 64-bit
> PowerPCs that have bridge mode is not working,
> but I'd have expected that to be more of a
> nice-to-have instead of a tier 2 vs. tier 4
> issue. Power-ISA-3/Power9 removed bridge mode,
> if I understand right. So progress on the
> "Can you buy a new one?" scale has started for
> bridge mode.
>=20
> May be there is some significant bridge mode
> booting use that I'm not imagining but that
> exists? (I've used it some but would not
> call it required.)
>=20
> I am able to put a 32-bit world in a 64-bit G5
> directory tree and use it via poudriere to build
> 32-bit ports under 64-bit FreeBSD. And lib32 is
> working so I can also directly execute the 32-bit
> code under the 64-bit FreeBSD . (I've not tried
> any kyua passes yet, 64-bit or 32-bit.)
>=20
> Other things I've seen from Ed Maste left the
> impression that the old ld would not be a
> cause-tier-4 issue if lld does not make it in
> time for some reason. (Nice to delete old ld for
> 13, not required to?)
>=20
> Of course, it might be that 32-bit powerpc
> (non-spe) just fails the "Can you buy a new
> one?" test. But, if applied, that would mean
> that sorting anything out might still leave it
> tier 4.
>=20
> Are there could-cause-tier-4 types of problems
> that I'm not aware of for 32-bit powerpc
> (non-spe)?
>=20
> For me, tier-4 for the old 32-bit PowerMac's
> would just mean that I no longer use them,
> even when I could have access. My use is not
> something that would drive FreeBSD choices.
> But I'm still interested in what the choices
> will end up being and so am tracking.
I have run into something that is broken
for both non-debug and debug kernels for
32-bit powerpc, at least for the old
PowerMac contexts that I have access to.
The kyua test:
sys/vm/mlock_test:mlock__copy_on_write_vnode
never completes, using a cpu nearly full time.
The stuck process can not be killed. (This
blocks making a complete kyua test set run.)
It appears to be stuck during the test's
ATF_REQUIRE(ptrace(PT_WRITE_D, pid, addr, val) =3D=3D 0);
I've other details that I've sent out notes
on in other messages.
It has been a long time since I've run kyua
on 32-bit powerpc. I've no clue if this is
fairly new or not.
I do not know if being able to run a kyua
test pass to completion (or even stricter
kyua criteria) are considered or not.
I had also forgotten that the debug kernel
stops a normal boot, complaining of memory
that is modified after being freed. (In my
contexts, boot -v has side stepped the
issue. boot -s has in some contexts, but
not in others.) I do not know how new this
issue is. (I rarely use a debug kernel.)
=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?8941BB3B-457B-4E33-A667-836DB6879178>