15:01:57 <pbrobinson> #startmeeting Fedora arm SIG meeting
15:01:57 <zodbot> Meeting started Tue Jun 29 15:01:57 2021 UTC.
15:01:57 <zodbot> This meeting is logged and archived in a public location.
15:01:57 <zodbot> The chair is pbrobinson. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:57 <zodbot> The meeting name has been set to 'fedora_arm_sig_meeting'
15:01:57 <pbrobinson> #chair pwhalen pbrobinson
15:01:57 <zodbot> Current chairs: pbrobinson pwhalen
15:01:57 <pbrobinson> #topic roll call
15:02:21 <pbrobinson> so you have to put up with me today as pwhalen is AFK so don't be too harsh
15:02:22 * coremodule is here
15:02:25 <pbrobinson> but who do we have
15:02:42 * jlinton waves
15:05:42 <pbrobinson> let's get started
15:05:59 <pbrobinson> #topic stable release issues and notes
15:06:13 <pbrobinson> any one with any issues around f33/f34?
15:06:40 <pbrobinson> we're currently well into 5.12 on those releases and I'm not aware of any major issues
15:08:35 <coremodule> nothing major to note here
15:08:54 <pbrobinson> #topic rawhide
15:09:06 <jlinton> Don't upgrade right now?
15:09:32 <pbrobinson> jlinton: I have a device on rawhide, it was about a week out of date and it updated ok this morning
15:09:35 <jlinton> One of my rawhide machines ate itself yesterday, presumably because glibc got pulled in.
15:10:33 <pbrobinson> there was an issue with glibc which came to light around mesa and particular functionality
15:10:46 <pbrobinson> the bug is eluding me ATM
15:11:26 <jlinton> Yes, this didn't look anything at all like that, I got into a situation where part of my packages required the new glibc (rpmlib/python) and some required the old to boot, apparently
15:11:56 <jlinton> missing symbols mostly
15:12:40 * pwhalen is here
15:13:32 <pbrobinson> jlinton: right, that was part of the issue and I've no idea why it was allowed to change
15:13:34 <jlinton> I ended up reinstalling, so by itself the current images work/upgrade, although I have a copy of the image that ate itself if needed.
15:15:13 <pwhalen> I filed this on systemd for armhfp - https://bugzilla.redhat.com/show_bug.cgi?id=1977042
15:15:45 <pwhalen> for the most part, system works ok, restarting journald works
15:17:29 <pbrobinson> pwhalen: is this more of the y2038 issue?
15:17:46 <pwhalen> it looked like it might be
15:18:32 <pwhalen> Also this one - The other issue is for the rpis - Rawhide arm/aarch64 disk images fail to boot on Raspberry Pi SBCs -  https://bugzilla.redhat.com/show_bug.cgi?id=1975375
15:19:03 <pwhalen> The efi partition is Fat 32 on the rawhide images
15:19:36 <pbrobinson> pwhalen: well it's ef not id 6
15:19:44 <jlinton> Hmm that one keeps striking, did you happen to notice if there was a /sys/firmware/efi on the machine that created the image?
15:19:55 <pbrobinson> pwhalen: someone will need to dig out what changed in anaconda there
15:19:56 <pwhalen> works ok on other hw, pine64 boots fine as well as the jetson nx
15:20:43 <pbrobinson> right, I tried changing this in the past, rpi explicitly wants a partition type of id 6
15:21:09 <pbrobinson> where as the pine64 reads and offset so it's irrelevent and then u-boot doesn't care
15:21:09 <pwhalen> jlinton: I would think so, I can try to spin one and see what happens
15:22:10 <jlinton> pbrobinson: type 6 is fat16, which AFAIK was fixed in the vc4 firmware recently, so that it supports ESP
15:22:33 <jlinton> type EF
15:22:57 <pbrobinson> jlinton: I think it was fixed for the rpi4 firmware that is on SPI but for < rpi4 it's in the PBL on silicon?
15:23:41 <pbrobinson> and if people haven't updated the firmware on the SPI it probably doesn't work still. I for one have never updated that because the util isn't open and it's a bit shit
15:26:04 <pwhalen> That is all I have for Rawhide. New nominated compose today - https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
15:27:22 <pwhalen> hrm, anyone seen this - https://openqa.fedoraproject.org/tests/918376#step/base_service_manipulation/18
15:28:05 <pwhalen> worked today though
15:28:36 <pbrobinson> pwhalen: I just nominated that bug for a blocker which should add some eyes on it
15:28:45 <pbrobinson> #topic kernel
15:28:54 <pwhalen> ok, thanks!
15:29:18 <pwhalen> Kernel has been looking ok, will test the 5.13 GA today
15:29:26 <pbrobinson> so 5.13 was tagged and we have a fedora branch for starting on stable, rawhide will be 5.14 moving forward
15:30:15 <pbrobinson> in the move to 5.14 they also did a rebase in kernel-ark and a cleanup of some of the patches, if people have MR/PRs against kernel-ark they'll need a rebase
15:30:47 <pbrobinson> I would expect 5.13 to go stable in the later half of July probably in ~ 3 weeks or so
15:31:22 <pwhalen> ok, good to know. Please test on your favourite devices
15:31:46 <pbrobinson> anything else for kernel?
15:32:03 <jlinton> So, far its looking fine on the couple machines I use for development. There was a change to the MSI behavior that might throw a nasty looking warning if the pcie root port isn't marked as not supporting MSI's and a PCIe card asks for one.
15:32:46 <pbrobinson> jlinton: fun, is that intended to highlight issues to be fixed or is it an unintended bug?
15:33:16 <jlinton> Yah, I think its intended to encourage people to document where MSI's won't work, the system continues as before (falls back to legacy/whatever).
15:34:47 <pbrobinson> OK, out of interest what was the HW/card combo you saw that on so I can keep an eye out
15:35:21 <jlinton> PI4, with UEFI, although I suspect it might show up on some other platforms depending on what is plugged in.
15:36:05 <jlinton> The default pi4 settings won't show it though because the XHCI normally isn't on a PCIe root port.
15:36:25 <pbrobinson> the ACPI network stuff for MDIO and friends on the LA2160A/honeycomb is landing upstream for 5.14 which is great
15:36:53 <pbrobinson> still needs a unique tool for some of the network config though, can't yet use ethtool/ip to configure the interfaces, but the 1gb port works OOTB
15:37:03 <jlinton> Yes, and we should be getting the MDWE problem finally closed off too, since Mark Browns patch seems to solve that last remaining hole.
15:37:16 <pbrobinson> MDWE?
15:37:34 <jlinton> systemd, MemoryDenyWriteExecute on services.
15:37:45 <pbrobinson> is that the arm-smmu.disable_bypass=0 "fix"
15:38:00 <jlinton> No, I still get that one on the honeycomb.
15:38:27 <pbrobinson> apparently that's due to be fixed in 5.14 + a recent firmware too
15:39:46 <pwhalen> nice, too bad my seattle died so I won't see the benefit
15:40:46 <pbrobinson> not sure what seattle has to do with that
15:41:10 <pwhalen> needed the 'arm-smmu.disable_bypass=0 '
15:41:38 <pwhalen> ah, needs fw fix too, nm :)
15:41:43 <jlinton> tinaocore or the AMI?
15:41:57 <pwhalen> it was on tianocore
15:42:14 <jlinton> ah, so it can probably be fixed too.
15:43:54 <pbrobinson> anything else for kernel?
15:44:19 <pbrobinson> #topic firmware and early boot
15:44:24 <pbrobinson> nothing of real note here
15:44:29 <pbrobinson> uboot-tools-2021.07-0.6.rc5.fc35 is available
15:44:39 <pwhalen> nice, thanks, will test
15:44:46 <pbrobinson> I expect 2021.07 GA next week so it would be good to get some wider testing
15:45:13 <pbrobinson> just so we know if anything regressed from 2021.04 as we moved towards 2021.10
15:47:04 <pwhalen> so far it looked ok, but will test everything with rc5 to make sure no surprises for GA
15:47:12 <pbrobinson> #topic general business
15:47:28 <pbrobinson> anyone have anything
15:47:34 <pbrobinson> I think jlinton might
15:48:13 <jlinton> Yes, I was going to introduce rbutler1728, who will be helping with fedora/aarch64 work.
15:48:30 <rbutler1728> hello everyone
15:49:17 <pwhalen> howdy rbutler1728, welcome! :)
15:52:56 <pbrobinson> hey rbutler1728, welcome
15:53:25 <pbrobinson> anyone have anything else?
15:54:24 * pwhalen does not
15:54:34 <pbrobinson> #endmeeting