15:00:40 #startmeeting Fedora ARM and AArch64 Status Meeting 15:00:40 Meeting started Tue Jul 2 15:00:40 2019 UTC. 15:00:40 This meeting is logged and archived in a public location. 15:00:40 The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:40 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:40 The meeting name has been set to 'fedora_arm_and_aarch64_status_meeting' 15:00:40 #chair pwhalen pbrobinson jlinton 15:00:40 #topic roll call 15:00:40 Current chairs: jlinton pbrobinson pwhalen 15:00:50 * pbrobinson o/ 15:00:53 good morning folks, who's here today? 15:00:54 * jlinton waves 15:01:48 hey jlinton 15:02:36 * pwhalen gives it a minute for others to join 15:05:06 #topic 1) ==== Userspace Status ==== 15:05:20 nothing of real note here 15:05:23 I don't we have anything new here 15:05:39 yesterday was the deadline for any features needing mass rebuild 15:05:44 Looks like PAC got put on hold 15:06:23 * jonmasters here 15:06:26 morning jonmasters 15:06:26 howdy jonmasters 15:06:36 figured I'd turn up for a change, morning! 15:07:01 #info No issues reported. 15:07:07 #topic 2) ==== Kernel Status ==== 15:07:16 jonmasters: you may as well start here 15:07:18 Just in time 15:07:31 well, I can add a note about the builders if you like 15:07:43 #info Fedorn 29 armv7 guests "pause" from time to time on rhel-alt 7.6 kernel-4.14.0-115.2.2.el7a.aarch64 kernel 15:07:43 #link https://bugzilla.redhat.com/show_bug.cgi?id=1576593 15:07:49 jonmasters: yes, that's was I was intending 15:07:50 That would be great 15:08:00 yea so I looked at https://bugzilla.redhat.com/show_bug.cgi?id=1576593 15:08:18 I am suspecting that it's actually a hardware errata in the X-Gene1 processor 15:08:43 it happens when you have a guest that takes a trap while walking its page tables 15:09:07 and the HPFAR_EL2 register that contains the faulting address (LAPE) seems truncated in *that* case 15:09:12 so you'll only see this if: 15:09:20 1). You're running a guest with 32-bit LPAE 15:09:44 2). It takes a trap on a page table page while walking them AND that page is outside of the 4GB 32-bit range 15:09:58 so you'll boot ok, and run fine for a while, but eventually, boom 15:10:14 thanks pwhalen for setting up a builder, I'm still using it btw :) 15:10:38 I ran multiple crash sessions on the guest/host and was going all day/night over the weekend, but I did report what I think is a hw errata yesterday 15:10:44 if I'm right, there's a nasty workaround 15:10:46 so we're awaiting confirmation if it is a errata? 15:10:49 two actually, or maybe more: 15:11:06 1). You could make sure guest page table pages were allocated low on LPAE (nasty) 15:11:38 2). During fault handling on the host, manually do an AT (address translation) and walk the page tables and look to see if any of the addresses almost match the reporting fault address 15:11:51 if they do, assume it's an errata and handle 15:11:58 waiting yea 15:12:07 the silicon team are currently checking 15:12:26 coolio 15:12:28 but there were known issues with 32-bit emulation at the time and I doubt LPAE ever really got validated 15:12:31 thanks 15:12:37 I'll poke possible hacks to workaround 15:13:05 jonmasters, np, thanks for working on it (sorry it took your weekend) 15:13:07 jonmasters++ awesome, thanks for the work on digging into this, I know you love a good challenge ;-) 15:13:08 pbrobinson: Karma for jcm changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:13:13 it was fun ;) 15:13:22 awesome, nirik ^ 15:13:39 jonmasters++ 15:13:39 brb 15:13:41 pwhalen: Karma for jcm changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:13:56 awesome! great news... thanks for the work! 15:14:46 #info arm-smmu e0800000.smmu: Unexpected global fault, this could be serious 15:14:46 #link https://bugzilla.redhat.com/show_bug.cgi?id=1724276 15:15:27 opened this last week for the seattle, msalter offered to take a look (thanks Mark!) 15:15:32 so I haven't been able to reproduce this 15:15:49 but I'm using "different" firmware 15:16:10 I have to find a copy of the old firmware and try that 15:16:18 right, I was about to ask. Should I just update? 15:17:01 but I think the answer is going to be a command line arg to avoid it on seattle 15:17:15 I think there was some reason I stayed on the older firmware 15:18:01 msalter, thanks 15:18:05 np 15:18:19 any other kernel issues? 15:18:32 #info F31: kernel-5.2.0-0.rc7.git0.1.fc31 15:18:32 #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1306512 15:18:55 I've not started to test rc7 15:19:10 I've done some testing, no real change to rc6 15:19:30 there's a few minor fixes, both from upstream and from me, but nothing of huge note 15:20:38 #info Please test and report any issues to the list or #fedora-arm. 15:20:52 #topic 3) ==== Bootloader Status ==== 15:21:03 #info uboot-tools-2019.07-0.1.rc4 15:21:03 #link https://koji.fedoraproject.org/koji/taskinfo?taskID=35612902 15:21:10 #undo 15:21:10 Removing item from minutes: 15:21:11 #undo 15:21:11 Removing item from minutes: INFO by pwhalen at 15:21:03 : uboot-tools-2019.07-0.1.rc4 15:21:38 #info uboot-tools-2019.07-0.2.rc4.fc31 15:21:45 #link https://koji.fedoraproject.org/koji/buildinfo?buildID=1300621 15:22:00 there's not a lot of difference between the two TBH 15:22:27 ah, ok.. I see from the changelog.. 15:22:39 I think we should have rc5 from upstream today/tomorrow 15:22:41 any other bootloader news? issues? 15:23:00 I spent some time over the weekend looking at the Rockchips stuff 15:23:32 I did a few patches to improve primarily the Rock960, although others will be added to that too 15:24:19 I think we should have at least a bunch of rk3399 devices in reasonable shape for F-31, plus some others 15:25:18 very nice, I know they've been painful for me 15:25:47 I think I have at least some of it sorted out, I'm trying to work out why the display isn't powering up in U-Boot 15:26:07 that would give us a reasonable experience for a bunch of devices 15:26:28 there are a few rk3399 edk2 ports people have been hacking too 15:27:02 jlinton: yea, I've seen a few around. I'm still avoiding edk2.... someone else can do that 15:27:28 jlinton: speaking of which, did you have any luck with the inconsistent console in ekd2 for virt? 15:28:40 I think when I changed the virtio/etc config (trying to remember what the solution was) it ran consistently 15:29:10 my initial graphics config wasn't quite right though 15:30:04 (I thought I mentioned in the defect the change between virtio/QLX or some such fixing it) 15:30:32 jlinton: let me know if you have a issue or something I can follow? Or a patch I can test 15:33:20 #topic 4) ==== Fedora 31 ==== 15:33:26 #info Latest nominated nightly - https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test 15:34:10 I've not had a chance to start testing this 15:35:07 the previous nominated nightly had some issues on the rpi3 and the new firmware 15:35:33 yes, I think upstream is nearly to the bottom of the issue there, and the fact they damn well shouldn't regress 15:36:43 it actually works fine if you have a display plugged in 15:37:56 aha 15:38:29 but I expect a new firmware later this week with the fixes with luck 15:38:42 and it looks like you untagged the problem build? 15:38:49 yes 15:39:42 the other issue was with the display on the rpi3, that has also been reported upstream 15:40:08 yea, it's upstream, I have not got to it further yet 15:40:17 any other issues in recent f31 nightlies? 15:41:10 I think it's mostly looking OK with my testing 15:41:23 agreed 15:41:26 there's a few bits and pieces here and there but nothing particularly frightful 15:41:51 #topic 5) == Open Floor == 15:42:08 I got one 15:42:25 jonmasters: go! 15:42:40 on the builder issues - do we have any firm plans for other hardware lined up yet? I think not currently, right? 15:42:56 so a workaround is something you're actually interested in seeing developed? 15:43:31 jonmasters: yes, there's budget for it, not sure the timeframe, if I remember Fedora gets 14 of the new Lenovo boxes 15:43:35 if it won't be a waste of time (unlikely to get upstream, might be a way to finagle into RHEL for the host) then I'll make something 15:43:43 and then CentOS 6 for a total of 20 15:43:48 ok, so we need to find out if eMAG has the same problem :) 15:43:53 that's also on my todo 15:44:12 and that silicon team is checking 15:44:17 thanks, got what I need 15:44:17 jonmasters: I figure you have one to be able to test, and an install of presumably el8 to test? 15:44:23 yea 15:44:28 got one here at home 15:44:32 thanks 15:44:46 so let us know if you need any config bits for testing 15:44:52 will do 15:45:12 I'll keep the existing builder for now that Paul setup, then setup my own this week at home to check eMAG 15:45:16 that's it - thanks 15:45:34 thanks jonmasters 15:46:16 anything else for open floor? 15:47:05 #endmeeting