15:00:06 <pwhalen> #startmeeting Fedora ARM and AArch64 Status Meeting
15:00:06 <zodbot> Meeting started Tue May  5 15:00:06 2020 UTC.
15:00:06 <zodbot> This meeting is logged and archived in a public location.
15:00:06 <zodbot> The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:06 <zodbot> The meeting name has been set to 'fedora_arm_and_aarch64_status_meeting'
15:00:07 <pwhalen> #chair pwhalen pbrobinson jlinton
15:00:07 <zodbot> Current chairs: jlinton pbrobinson pwhalen
15:00:07 <pwhalen> #topic roll call
15:00:07 <pwhalen> good morning folks, who's here today?
15:01:54 * pbrobinson is here
15:08:20 * jlinton waves
15:09:01 <pwhalen> howdy jlinton, lets get started
15:09:03 <pwhalen> #topic 1) ==== Userspace Status  ====
15:09:13 <pwhalen> Any new user space issues?
15:10:15 <pbrobinson> none that I'm aware of, there was an issue with a gcc update for aarch64 but the maintainer has fixed it
15:10:51 <pwhalen> right saw that one, think its in process
15:11:50 <pbrobinson> fixed in rawhide, was awaiting the f32 build to complete
15:12:51 <pwhalen> #info No new issues reported.
15:13:24 <pwhalen> #topic 2) ==== Kernel Status ====
15:13:24 <pwhalen> #info Latest kernel-5.7.0-0.rc4.1.fc33
15:13:24 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1503100
15:14:01 <pwhalen> I've not tested yet, but will do. We have another issue in Rawhide for armhfp. I filed against the kernel but I think its systemd
15:14:13 <pwhalen> https://bugzilla.redhat.com/show_bug.cgi?id=1831239
15:14:45 <jlinton> The usbfs/libusb/rtl-sdr patch has been merged https://www.spinics.net/lists/linux-usb/msg194403.html
15:14:59 <pwhalen> jlinton, nice
15:15:16 <pwhalen> jlinton++
15:15:16 <zodbot> pwhalen: Karma for jlinton changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:15:57 <pbrobinson> jlinton: so that will head to 5.7?
15:17:23 <jlinton> Thats not really clear, but it looks like its heading that way.
15:18:02 <pbrobinson> jlinton: cool, I'll pull it in for 5.6
15:18:58 <pwhalen> any other kernel news?
15:19:06 <pbrobinson> please test 5.7
15:19:12 <pwhalen> #info Please test and report any issues to the list or #fedora-arm.
15:19:18 <pwhalen> #topic 3) ==== Bootloader Status ====
15:19:28 <pwhalen> #info New U-Boot available for testing - uboot-tools-2020.07-0.1.rc1.fc33
15:19:28 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1499727
15:20:06 <pbrobinson> new release for u-boot, we'll likely target 2020.10 for F-33 like usual, but there's a few new devices
15:21:26 <pwhalen> #topic 4) ==== Fedora 33 Planning ====
15:22:31 <jlinton> I'm putting the ARM sig on PAC systemwide change as a supporter, since i'm betting there will be build breaks since i've only built a small fraction of the total packages.
15:24:00 <jlinton> Also, i've been told the outline atomics change was merged to gcc 10.1, so we will get that for "free"
15:24:27 <jlinton> (to be clear the change was enabling the flag by default)
15:24:42 <pwhalen> jlinton, funny, we were just chatting about that one
15:24:48 <pwhalen> good to know, thanks
15:26:22 <pbrobinson> jlinton: is there any possible perf issues/regressions with PAC?
15:26:49 <jlinton> Possible on 8.2+ hardware that implements it, due to extra work being done.
15:27:59 <jlinton> I guess all the extra nops could cause problems as well, or due to changes in BTB/cache utilization/etc. but most of that should be in the noise.
15:28:48 <jlinton> But the kernel can disable it on 8.2 hardware too, so worse case we end up doing that on a machine that does a poor job of handling the sig verification
15:30:53 <jlinton> Given that its a model only feature at this point, its hard to know what the effect will be. OTOH, the provider of the early hardware is the one pushing for the support.
15:31:08 <pbrobinson> jlinton: would the nvidia jetson AGX be affected by it?
15:31:40 <jlinton> Offhand, I don't think it supports PAC, but I would have to double check.
15:31:47 <pbrobinson> or is it vendor specific implementations as opposed to 8.2 in general
15:32:05 <jlinton> (well its actually an 8.3 feature)
15:32:17 <pbrobinson> is it reported in /proc/cpuinfo
15:32:26 <jlinton> No, syscaps
15:33:52 <pbrobinson> jlinton: so can we disable it on a soc by soc basis if it's an issue?
15:34:29 <jlinton> Yes, i'm assuming we could quirk it off in the kernel/etc. Thats sort of an upstream decision though unless we carry a patch.
15:35:30 <jlinton> I also typed syscap, there when I meant hwcap.
15:36:18 <pbrobinson> jlinton: sure, but I suspect we're going to be one of the first distros to enable it widely so it would be an upstream discussion as a result of what we see right
15:36:48 <pbrobinson> but overall I think it's the right thing to enable, there will no doubt be optimisations upstream as it starts to settle out
15:36:49 <jlinton> Yes,
15:37:13 <jlinton> some of the more "embedded" distro's are also looking at it in the same timeframe AFAIK (yocto)
15:38:48 <pbrobinson> yocto isn't a distro, it's a build your own mechanism ;-)
15:39:05 * jlinton nods
15:41:33 <pwhalen> anything else for F33?
15:41:54 <pwhalen> #topic 5)  == Open Floor ==
15:43:44 * pwhalen leave this open for a few minutes
15:46:14 <pwhalen> #endmeeting