Looking for x86-related fires
by Jeff Backus
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
4 years, 10 months
Checking In
by Jeff Backus
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
4 years, 11 months
Re: i686 kernel missing on rawhide / disabling archs in critical path pkgs
by Stephen John Smoogen
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.
4 years, 11 months
Fwd: i686 kernel missing on rawhide / disabling archs in critical path pkgs
by Stephen John Smoogen
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...
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.o...
--
Stephen J Smoogen.
4 years, 11 months
Segfault when building the kernel for i686
by Laura Abbott
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.
4 years, 11 months
Re: F29 System Wide Change: i686 Is For x86-64
by Florian Weimer
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
4 years, 11 months
Fwd: F29 System Wide Change: i686 Is For x86-64
by Florian Weimer
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...
).
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.fedora...
5 years
Re: F29 System Wide Change: i686 Is For x86-64
by Adam Jackson
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
5 years
Numerous segfaults with f28 on a PIII
by Ralf Corsepius
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
5 years