15:00:24 <pwhalen> #startmeeting Fedora ARM and AArch64 Status Meeting
15:00:24 <zodbot> Meeting started Tue Apr 10 15:00:24 2018 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:24 <zodbot> The meeting name has been set to 'fedora_arm_and_aarch64_status_meeting'
15:00:24 <pwhalen> #chair pwhalen pbrobinson
15:00:24 <zodbot> Current chairs: pbrobinson pwhalen
15:00:25 <pwhalen> #topic roll call
15:00:31 <pwhalen> morning folks, whos here today?
15:02:11 * pbrobinson o/
15:03:36 * pwhalen gives it a few minutes
15:06:49 <pwhalen> lets start, hopefully others show up
15:06:57 * jlinton waves
15:07:00 <pwhalen> #topic 1) ==== Userspace Status  ====
15:07:11 <pwhalen> howdy jlinton
15:07:21 <pwhalen> #info [abrt] firefox: raise(): firefox killed by SIGSEGV
15:07:21 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=1564204
15:07:32 <pbrobinson> so I think we're mostly OK here, from an ARM perspective, there's a firefox crash
15:07:46 <pwhalen> filed this after Beta, unfortunate, but not really a blocker for server
15:08:31 <jlinton> I think there was some movement on the FF x28 bug a few weeks ago too.
15:09:03 <pbrobinson> yea, I saw that
15:10:00 <pwhalen> anything else?
15:10:16 <pwhalen> #topic 2) ==== Kernel Status ====
15:10:29 <pwhalen> #info kernel-4.16.1-300.fc28
15:10:29 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1067657
15:10:42 <pbrobinson> there's a FTBFS in elfutils that's a test failure in aarch64 if anyone has some time to investigate
15:10:56 <jlinton> That FF bug looks like stack corruption again...
15:11:37 * pbrobinson has been going through non upgraded packages on various systems during meetings today
15:14:39 <pwhalen> #info elfutils FTBFS due to test failure. If anyone can help investigate. https://koji.fedoraproject.org/koji/taskinfo?taskID=25394458
15:14:46 <pwhalen> any known kernel issues?
15:15:40 <pbrobinson> pwhalen: is kernel not a new topic?
15:16:34 <pwhalen> its the current topic
15:16:51 * pbrobinson missed that
15:16:57 <pbrobinson> so we have two issues I'm aware of
15:17:15 <pbrobinson> 1) issue with the bbone booting post rc6 (git3.1 in fact)
15:17:52 <pbrobinson> 2) issue with the nouveau module on the Jetson TK1, I have a possible patch to test for this when I get out of all these damn meetings
15:18:20 <pbrobinson> there's likely some more tweaks and improvements needed for the RPi 3+
15:18:47 <pbrobinson> and I have a massive bunch of stuff on my "need to deal with X" list
15:20:44 <pwhalen> that sums it up, thanks
15:20:58 <pwhalen> #info Please test and report any issues to the list or #fedora-arm.
15:21:17 <pwhalen> #topic 3) ==== Bootloader Status ====
15:21:54 <pwhalen> #info uboot-tools-2018.03-4.fc28
15:22:00 <pwhalen> #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1066876
15:22:25 <pwhalen> #info Known issue on Raspberry Pi 2/3/3+.
15:23:18 <pwhalen> #info Improvement to MMC speed on Allwinner Devices.
15:25:10 <pwhalen> anything else for bootloaderS?
15:25:37 <pbrobinson> yes, know issues with RPi which is why it's not pushed to updates as yet
15:25:56 <pwhalen> #topic 4)  == F28 Testing ==
15:26:24 <pwhalen> noted the rpi issues above
15:26:41 <pwhalen> #info Latest nominated nightly - Fedora 28 20180407.n.0
15:26:41 <pwhalen> #link https://fedoraproject.org/wiki/Test_Results:Fedora_28_Branched_20180407.n.0_Installation
15:27:08 <pwhalen> #info OpenQA AArch64 Server Tests
15:27:08 <pwhalen> #link https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora&version=28&build=Fedora-28-20180407.n.0&groupid=6
15:27:25 <jlinton> The F28 builds are generally working ok (there are still networking issues) on the mcbin
15:28:06 <pwhalen> nice, thanks
15:28:12 <jlinton> Yes, it would be nice to enable the workstation/atomic tests, as mentioned in fedora-arm
15:28:13 <pbrobinson> jlinton: I now have a mcbin, I just need to get around to getting a working firmware for it
15:28:40 <jlinton> I've been building from the repo, and putting it on a sd card
15:28:57 <jlinton> (edk2 that is)
15:29:43 <pbrobinson> I asked solid run, they
15:30:18 <pbrobinson> they're due to do a new release for edk2 with luck, I'd sooner they support it that way it's a single place to point everyone
15:31:04 <jlinton> Yes, building it can be a bit hit/miss when picking a cross compiler.
15:31:36 <pbrobinson> I've got enough to deal with currently, and I don't want to have to support firmware for others
15:33:44 <pwhalen> #topic 5) == Open Floor ==
15:33:49 <pwhalen> anything else for today?
15:33:54 <jlinton> Anyone want to talk about zlib?
15:34:21 <pbrobinson> jlinton: yes! I meant to do that in userspace
15:34:48 <jlinton> Basically, i'm finishing up running zlib-bench against it..
15:35:02 <jlinton> (there is a build here https://koji.fedoraproject.org/koji/taskinfo?taskID=26291722)
15:35:23 <jlinton> but its looking like ~20-30% on average across the board (deompress & compress)
15:35:25 <pbrobinson> jlinton: so from what you mentioned 20% on A72, more on A53?
15:35:51 <jlinton> it should be more on A53 although i'm not running it on anything with A53's at the moment
15:36:26 <pbrobinson> yep, no issues, and we can't pull in the patches to use the HW CRC as there's no run time detection of the feature?
15:36:28 <jlinton> I tossed a couple of my patches, and picked up the ones from Adenilson, who has been pushing them to his git repo as he ports them
15:36:54 <jlinton> I told everyone to ignore the CRC ones due to lack of a good method for runtime detection already being in the patches
15:37:18 <jlinton> (don't want to have to deal with that too, and that seems to be a fairly isolated optimization)
15:38:02 <jlinton> I've got an additional "build" patch, since the android guys are using cmake, and the fedora package is using the configure/makefile.in (no its not autotools)
15:38:36 <jlinton> anyway I wrapped it all in a aarch64 stanza in the .spec to avoid breaking !arm machines
15:39:03 <jlinton> Right now, the overall perf looks better than zlib-ng...
15:39:19 <pbrobinson> I'd sooner we didn't have to wrap it in that, is it pure aarch64 or is there possible benefit for v7 too?
15:40:02 <pbrobinson> then general rule of thumb is it should apply to all so there's no platform specials
15:40:03 <jlinton> Its depending on neon, which is optional on armv7
15:40:12 <jlinton> and there isn't any runtime detection...
15:40:25 <pbrobinson> right, so no run time detection of that either....
15:40:41 <pbrobinson> seems they will generally need some more improvement before they go upstream overall
15:40:52 <jlinton> Yah, they are all a bit hacky at the moment
15:41:16 <jlinton> but looking at the core zlib repo, there are a lot of similar patches for x86 that have been in a holding pattern for a while too
15:41:29 <pbrobinson> yep
15:41:36 <pbrobinson> I don't disagree there
15:42:47 <pbrobinson> which is why this library likely should go into core infra initiative or similar (obv out of scope for this discussion)
15:42:48 <jlinton> (seems the zlib bench finished, without the CRC optimization it seems zlib-ng is still better in the png tests)
15:45:34 <pwhalen> #endmeeting