June 2018 - X86 - Fedora mailing-lists

Looking for x86-related fires
by Jeff Backus 17 Jul '18

17 Jul '18

Hi folks, I'm going to take a whack at triaging x86-related bugs. I see a few listed on the x86 tracker bug and the x86 exclude arch bug, which I'll take a closer look at. Before I start searching for anything i686-related, are there any issues you'd like us to take a look at first? jeff -- Jeff Backus jeff.backus(a)gmail.com http://github.com/jsbackus

5 18

Checking In
by Jeff Backus 28 Jun '18

28 Jun '18

Hi folks, I apologize for disappearing for so long. 1 project has turned into 4, with about half the resources. :) I'm going to work on better keeping up with the SIG. I'm also going to try to make time to keep an eye on bug reports. Since I've been living under the proverbial rock for a while, are there any big issues I should know about? I'm aware of the kernel build failures issue that recently happened. By the way, Alex, thank you for your efforts to help get things resolved and to submit a patch upstream. Any other thoughts or concerns we should discuss? jeff -- Jeff Backus jeff.backus(a)gmail.com http://github.com/jsbackus

2 1

Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
by Stephen John Smoogen 24 Jun '18

24 Jun '18

On 22 June 2018 at 05:29, Daniel P. Berrangé <berrange(a)redhat.com> wrote: >> I encourage you to file a ticket with FESCO. > > I was hoping this mail would generate some more discussion perhaps with > other ideas than I've come up with. > > If there's continued silence and i686 kernel doesn't get fixed soon, > I'll file ticket with FESCO asking for i686 arch to be removed from > main koji and relegated to a secondary koji instance, so i686 doesn't > block maintainers going forward... > There is no secondary koji, and releng has said in the past they don't want to go back to dealing with it. Dropping i686 is dropping i686 completely for both lib and multilib. The same will be with any other architecture which causes such blockages in the future. -- Stephen J Smoogen.

2 1

Fwd: i686 kernel missing on rawhide / disabling archs in critical path pkgs
by Stephen John Smoogen 21 Jun '18

21 Jun '18

Forwarding the mails from devel ---------- Forwarded message ---------- From: Daniel P. Berrangé <berrange(a)redhat.com> Date: 21 June 2018 at 04:50 Subject: i686 kernel missing on rawhide / disabling archs in critical path pkgs To: devel(a)lists.fedoraproject.org Fedora rawhide has not had any kernel build available for i686 for a week now. It was disabled in a rebase due to part of the build process segfaulting. commit 861ae54010f0dae5c988105b6179a8f2442851e7 Author: Laura Abbott <labbott(a)redhat.com> Date: Thu Jun 14 10:57:47 2018 -0700 Don't build for i686 There is a segfault on i686 + ./process_configs.sh -n -c kernel 4.18.0 ~/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686 ~/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs Processing /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config ... /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config:5814:warning: override: SPARSEMEM_MANUAL changes choice state /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config:6846:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state make[1]: *** [scripts/kconfig/Makefile:64: olddefconfig] Segmentation fault (core dumped) No idea why but we don't want to stop other arches. Disable it for now. There is a message posted to the x86 SIG at the same time as it was disabled: https://lists.fedoraproject.org/archives/list/x86@lists.fedoraproject.org/t… Now, i686 is an alternative architecture, so IIUC, it is currently allowed by our package maint guidelines to disable packages on i686 when there are build problems. The kernel, however, is a critical path component that is a dependancy of many other RPMs in Fedora. Personally I'm impacted by inability to build QEMU in rawhide, because it needs systemtap and systemtap needs the kernel-devel package. The same impacts libvirt. https://bugzilla.redhat.com/show_bug.cgi?id=1592374 The GFS userspace is showing similar problems https://bugzilla.redhat.com/show_bug.cgi?id=1593411 which again impacts parts of the virt stack. IOW, the result of disabling i686 in the kernel has to be pass on pain to countless downstream package maintainers who are now blocked unless they also disable i686, which will in turn break further downstream packages which depend on them, rinse repeat. Based on this ripple effect, I think the package maint policy here is flawed with respect to packages that are on the critical path. We have a root cause here that's there's a i686 build issue to be addressed. No debate there. Simply disabling an architecture doesn't fix the problem - it actually expands the problem out to more & more packages/maintainers, making it worse than it was to start with. IMHO for packages that are in the critical and/or an upstream dependancy of many other packages in Fedora, we should *NOT* disable architectures except as a last resort, and certainly not before giving time to identify what has caused the problem & fix it. The kernel change that introduced the i686 build problem was just a rebase between 2 arbitrary pre-release git snapshots. I don't really a compelling justification to rebase to a known broken snapshot, without allowing time for x86 SIG to resolve it first. AFAIK there was no prior warning or request for help - i686 was just disabled immediately and other package maintainers left to deal with the consequences of broken deps. A more pragmatic approach would have been to report the problem to the x86 SIG and then *not* do the rebase for some reasonable period of time (perhaps 1 week grace period), to allow for the problem to be addressed. Only disable the i686 build if there is no solution is forthcoming, thus avoiding causing this pain for a whole chain of packages/maintainers in Fedora. Having said all this, the message about brokenness on x86 SIG mailing list doesn't appear to be treated with the urgency I think it needs, givin the ripple effect it has from a critical path package. There were a few messages the day after it was reported, and then nothing until Wednesday. For a package that is critical path like the kernel, I'd expect this to be a top priority item to resolve with immediate effect because of the broad impact it has on other maintainers. Maybe this has been happening in the background, with no activity visible on the mailing list, if so I apologize in advance. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… -- Stephen J Smoogen.

1 0

Fwd: No kernel on i686
by Stephen John Smoogen 21 Jun '18

21 Jun '18

Forwarding the mails from devel. ---------- Forwarded message ---------- From: Richard W.M. Jones <rjones(a)redhat.com> Date: 21 June 2018 at 04:49 Subject: No kernel on i686 To: devel(a)lists.fedoraproject.org Just wanted to bring this to wider attention: https://bugzilla.redhat.com/show_bug.cgi?id=1592374 https://bugzilla.redhat.com/show_bug.cgi?id=1593411 https://lists.fedoraproject.org/archives/list/x86@lists.fedoraproject.org/t… There is no kernel being built on i686. This breaks several assumptions: (1) Any package which depends on a kernel module by requiring ‘kmod(foo.ko)’ will no longer be installable on i686. If it BuildRequires the package it will FTBFS. Packages affected: - batctl - floppy-support - gfs2-utils - joystick-support - snapd - usbip - xl2tpd (2) Any package which depends on ‘kernel-devel’ or ‘kernel-devel-uname-r’ will no longer be installable. If it BuildRequires the package it will FTBFS. Packages affected (some of these may be from rpmfusion): - akmods - bcc-tools - dkms - systemtap-devel [this causes lots of packages to FTBFS] My real question: Is this going to be a long-term state of affairs? Should I start dropping dependencies / stop building stuff which needs a kernel on i686? Or should we wait it out? (I have no need for i686 nor any particular desire to actually investigate or fix the problems on this obsolete hardware.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… -- Stephen J Smoogen.

1 0

Segfault when building the kernel for i686
by Laura Abbott 20 Jun '18

20 Jun '18

Hi, Rawhide builds of the kernel for x86 have started failing with a segfault: https://koji.fedoraproject.org/koji/taskinfo?taskID=27618835 + ./process_configs.sh -n -c kernel 4.18.0 ~/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686 ~/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs Processing /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config ... /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config:5814:warning: override: SPARSEMEM_MANUAL changes choice state /builddir/build/BUILD/kernel-4.17.fc29/linux-4.18.0-0.rc0.git9.1.fc29.i686/configs/kernel-4.18.0-aarch64.config:6846:warning: override: VIRT_CPU_ACCOUNTING_NATIVE changes choice state make[1]: *** [scripts/kconfig/Makefile:64: olddefconfig] Segmentation fault (core dumped) I don't have a setup to try and debug this so I've disabled building on i686 for now. I know the kernel can be a bit of a PITA to deal with so I'm happy to answer questions about how things work for whoever wants to take a swing at fixing this.

5 11

Re: F29 System Wide Change: i686 Is For x86-64
by Florian Weimer 15 Jun '18

15 Jun '18

I clarified some aspects of this proposal. After consulting with Jakub Jelinek, I'm now proposing to use “-march=i686 -msse2 -mtune=generic -mfpmath=sse -mstackrealign”. This is very close to previous proposal. Only a few preprocessor macros are different: @@ -142,3 +142,2 @@ #define __FLT_RADIX__ 2 -#define __FXSR__ 1 #define __GCC_ASM_FLAG_OUTPUTS__ 1 @@ -174,2 +173,4 @@ #define i386 1 +#define __i686 1 +#define __i686__ 1 #define __INT16_C(c) c @@ -219,4 +220,2 @@ #define __INT_WIDTH__ 32 -#define __k8 1 -#define __k8__ 1 #define __LDBL_DECIMAL_DIG__ 21 @@ -247,2 +246,4 @@ #define __ORDER_PDP_ENDIAN__ 3412 +#define __pentiumpro 1 +#define __pentiumpro__ 1 #define __PRAGMA_REDEFINE_EXTNAME 1 We still do not have a way to automatically test for the avoidance of post-SSE2 CPU features (be it on i686 or x86_64), and i686 remains an alternative architecture. Like before, unless the x86 SIG wants to support non-SSE2 CPUs, they will not have to rebuild the i686 for the i686 alternative architecture. They can use the existing builds we create in Koji for the x86_64 multilib compose. Thanks, Florian

1 0

Fwd: F29 System Wide Change: i686 Is For x86-64
by Florian Weimer 07 Jun '18

07 Jun '18

FYI. Please discuss this on the devel list. -------- Forwarded Message -------- Subject: F29 System Wide Change: i686 Is For x86-64 Date: Mon, 4 Jun 2018 10:35:34 +0200 From: Jan Kurik <jkurik(a)redhat.com> Reply-To: devel(a)lists.fedoraproject.org To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>, devel-announce(a)lists.fedoraproject.org = Proposed System Wide Change: i686 Is For x86-64 = https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64 Owner(s): * Florian Weimer <fweimer at redhat dot com> Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs. == Detailed description == Currently, the i686 RPM packages are built in such a way that they are compatible with very old i686 systems, such as the Pentium III. The only addition over the i686/Pentium Pro baseline is a requirement to support long NOPs, for Intel CET. However, the majority of installations of i686 packages is for use on x86_64 systems, as multi-lib RPMs. Furthermore, there are reports that the i686 kernel does not run stable on old hardware which is not x86-64-capable ( https://lists.fedoraproject.org/archives/list/x86@lists.fedoraproject.org/t… ). This proposal suggests to accept this reality and build the i686 packages in such a way that they require the ISA level of (early) x86-64 CPUs. == Scope == * Proposal owners: Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the new compiler flags. Except for mstackrealign, there is substantial experience with this configuration downstream. * Other developers: Other developers can enable SSE2 optimization in their packages if they want, where this has been a compile-time option only. * Release engineering: https://pagure.io/releng/issues/7543 #7543 ** List of deliverables: TBD * Policies and guidelines: i686 is no longer a primary architecture. The Packaging Guidelines do not currently require support for non-SSE2 x86 systems, so no change is required there. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…

16 34

Re: F29 System Wide Change: i686 Is For x86-64
by Adam Jackson 06 Jun '18

06 Jun '18

On Mon, 2018-06-04 at 10:35 +0200, Jan Kurik wrote: > == Scope == > * Proposal owners: > Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the > new compiler flags. Except for mstackrealign, there is substantial > experience with this configuration downstream. Does this change include changing the kernel configuration for i686 to a higher baseline, and if so, which? - ajax

2 1

Numerous segfaults with f28 on a PIII
by Ralf Corsepius 05 Jun '18

05 Jun '18

Hi, seems to me as if f28 has become unusable on non-pae systems. At least, an attempt to upgrade my PIII from f27 (functional!) to f28 ended up with numerous segfaults, originating from cron, mount.nfs, automount and NetworkManager (and likely more) all similar to this: ...: segfault at bf44bfc4 at b79e35ac sp bf44bfc0 error 6 in libc-2.27.so[b787c000+19000] I currently don't have any time to investigate any further, but my gut feeling is RHBZ#1482798 might have returned. Ralf

4 8

2024

2023

2022

2021

2020

2019

2018

2017

X86 June 2018