Ticket #387 (closed task: fixed)

Opened 4 years ago

Last modified 4 years ago

compile list of supported CPUs and react to recent loss of support for Geode LX on F13

Reported by: till Owned by:
Priority: major Keywords: meeting
Cc: pbrobinson@…, robatino, bruno, sdz, rjones, dsd Blocked By:
Blocking:

Description

Proposal topic

There is no clear definition of which CPUs are primary supported by Fedora and with Fedora 13 Geode LX support was silently dropped. Therefore it would be nice to avoid confusion and unexpected change by agreeing on which CPUs are supported.

Overview

Create a list of supported CPUs and make it a release criterion that Fedora actually works on all supported CPUs, i.e. if any other test case does not work because of the CPU, i.e. the kernel does not boot, then Fedora is not ready for release.

Problem space

In F13, gcc changed to not support the Geode LX anymore: A bug report was closed as NOTABUG: https://bugzilla.redhat.com/show_bug.cgi?id=579838

There is no feature about this and it is not mentioned on the release notes or the F13 common bugs.

Solution Overview

Decide the CPU list, document it and add it to the release criteria. If the Geode LX is decoded to still be supported, change gcc or the kernel (or whatever is needed) to support it again and until it is resolved, document this in the F13 common bugs wiki page. If it is decided to drop support, then document it in the release notes.

Active Ingredients

Fesco to discuss, QA to update the release criteria, gcc/kernel maintainer to restore support or docs to document it in the release notes.

Owners

Till Maas

Change History

comment:1 Changed 4 years ago by pbrobinson

  • Cc pbrobinson@… added

comment:2 follow-up: ↓ 5 Changed 4 years ago by pbrobinson

The support of the Geode LX was discussed extensively during the proposed changes to the supported CPUs in the Fedora 12 development time frame. It erupted into a massive fedora-devel thread (around 200 odd posts from memory). It was decided then that it was worthwhile to support this. With that decision having been made it was a bit of a shock to find that the support was dropped without even a heads up to the fedora-devel mailing list.

The OLPC XO-1 runs Fedora and has an installed base of around 1.4 million units with plans to support these units for another 3+ years. One of the major reasons for a push to upstream all the OLPC stuff into Fedora is the ability to use mainline and have all the support we need for such an large install base rather than spinning our own stuff with our own build systems and the maintenance overhead that would involve, which OLPC/SugarLabs don't have the resources to be able to maintain.

Apparently the single offending instruction can be emulated within the kernel, although I'm not sure what the performance impact would be, but the patch linked won't be accepted until there's a generic way to do this within the kernel. Again I'm not aware of what is required to achieve this.

http://marc.info/?l=linux-kernel&m=126748102722641&w=2

comment:3 Changed 4 years ago by robatino

  • Cc robatino added

comment:4 Changed 4 years ago by bruno

  • Cc bruno added

Fixing this now might end up being painful, depending on the solution. It really would have been nice to have caught this before release, when we could have more easily rebuilt packages that have binaries that make use of that instruction. Maybe there is something that can be added to the QA process to check that supported CPUs actually work at some times where we can more easily fix things?

comment:5 in reply to: ↑ 2 Changed 4 years ago by mattmccutchen

Replying to pbrobinson:

The support of the Geode LX was discussed extensively during the proposed changes to the supported CPUs in the Fedora 12 development time frame. It erupted into a massive fedora-devel thread (around 200 odd posts from memory).

Links considered helpful. I found this thread; was there more?

comment:6 Changed 4 years ago by till

The long discussion is probably this one: Changing the default 32-bit x86 arch for Fedora 12

The discussion about the changed proposal starts here: Changing the default 32-bit x86 arch for Fedora 12 (#2)

comment:7 Changed 4 years ago by sdz

  • Cc sdz added

comment:8 Changed 4 years ago by tuxbrewr

I am one of the maintainers of "Fedora on the XO". Currently our releases are based on F11 which is about to go EOL. F13 was to be our next bump. It is vital that the current 1.4 million XO continue to be supported. The preferred solution would be to get F13 support, however if we had to wait for F14 IMO that is doable.

comment:9 Changed 4 years ago by robatino

What about a utility to test whether a CPU is compatible? This would help for people with rare CPUs and also make it easier to compile a list. For example, I have a machine that is running F12 but has a kernel panic in the F13 installer:

https://bugzilla.redhat.com/show_bug.cgi?id=594660

and currently there's no easy way to tell whether the NOPL instruction is the problem. I don't even know whether it's possible to find documentation for the CPU (Cyrix M II) that would answer the question, or if I could figure out how to interpret it.

comment:10 Changed 4 years ago by notting

I suspect that due to not having samples of all CPUs on hand, the default definition will have to be in terms of 'what gcc defines to be an i686'. Exceptions to that (via kernel emulation, or whatever) would have to be then discussed.

comment:11 Changed 4 years ago by dsd

Outside of the (not yet cooked) kernel-side project to emulate missing instructions for Geode and falsify it as an i686, I think the only complete solution would be to change base arch to i586 again.

Judging from the mailing list threads, the problem seems to have originated around the invalid assumption that "cmov" will be the only i686-specific instruction ever used in an i686 build environment. (perhaps that was true for the gcc version at the time, but it's certainly not a safe assumption for future versions, nor for code that might include handwritten asm)

There may be other i686 instructions missing from Geode too, in addition to nopl. I've asked this question to people possibly in the know about this before, and we've never come up with a solid answer that I've seen.

comment:12 Changed 4 years ago by till

  • Summary changed from compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13 to compile list of supported CPUs and react to recent loss of support for Geode LX on F13

comment:13 Changed 4 years ago by rjones

  • Cc rjones added

comment:14 Changed 4 years ago by kevin

SMParrish is going to contact the gcc maintainer and see what we can do here. We agree that we should support this cpu, and if possible fix it in f13.

comment:15 Changed 4 years ago by dsd

  • Cc dsd added

In the last meeting we were unable to reach a decision because we realised we did not have an understanding of the F13-level problem - why has glibc grown lots of nopl instructions in F13 over F12?

I have the answer here: https://bugzilla.redhat.com/show_bug.cgi?id=579838#c10

In a nutshell, glibc's compile process is now enabling optimizations at the assembler level (in addition to gcc/binutils usual optimizations at the compile and link level). When assembler optimizations are enabled, nopl instructions are emitted frequently. Enabling assembler optimizations is evidently not something that happens often (and gcc doesn't do it by default).

With this information, I'd like to add this topic to the agenda of the next meeting.

My suggestions for the way forward:

  • For F13, make a small change to glibc's makefile so that it does not enable assembler optimizations. Reach an agreement that we'll try and remove nopl from other packages if we spot them.
  • For F14, reiterate that Geode LX is supported, and accept that it is not a 686. Change compiler flags to -march=i586 -mtune=atom and rebuild all packages.

comment:16 Changed 4 years ago by robatino

Does this mean that the Live image subarch (which has been i686 since F7) should be changed to i586 as well? Judging by my affected Cyrix M II ( https://bugzilla.redhat.com/show_bug.cgi?id=594660 ) the same issue exists there.

comment:17 Changed 4 years ago by notting

I don't like the suggestion of stating -march=i586, because, if the point is to *just* support the Geode LX, that then opens the door for a variety of other CPUs (see the immediate comment about older MediaGX.

comment:18 Changed 4 years ago by kevin

From the 2010-06-15 meeting:

AGREED: dsd_ to post a patch to disable 686 assembler optimisations for glibc for f13 AGREED: more research on the details of building i586 separately to be carried out before deciding on f14

comment:19 Changed 4 years ago by dsd

Sorry for the delay. Patch now posted at https://bugzilla.redhat.com/show_bug.cgi?id=579838#c19

comment:20 Changed 4 years ago by mclasen

Quick update on some fact finding I did wrt to longer-term options. I had a brief chat with dgilmore about what koji can or can't do:

1) whether we can do 586 and 686 separately within koji as primaries

  • no
  • but could build things as i586+i686 in the same arch (some things will be potentially wrong then, such as static linking and arch-specific requires)

2) what running a secondary would really entail

  • resources: a koji instance + 3/4 builders + 2T+ storage
  • people to keep it running

comment:21 Changed 4 years ago by kevin

Kylem is going to talk to glibc maintainers and see if the patch is acceptable or they can find a better way to reach our goal of LX support.

comment:22 Changed 4 years ago by kevin

We deffered this this week since Kylem is out. Will visit next week.

Current patch at: http://bombadil.infradead.org/~kyle/add-processor-i686.diff

comment:23 follow-up: ↓ 24 Changed 4 years ago by kevin

We are defering this another week from todays 2010-07-06 meeting.

comment:24 in reply to: ↑ 23 Changed 4 years ago by pbrobinson

Replying to kevin:

We are defering this another week from todays 2010-07-06 meeting.

Why? Apparently according to the bug it was fixed yesterday.

comment:25 follow-ups: ↓ 26 ↓ 27 Changed 4 years ago by kevin

Oh indeed. Too much bugzilla email. I guess we can close this now?

Can the reporters confirm the update works for them?

comment:26 in reply to: ↑ 25 Changed 4 years ago by till

Replying to kevin:

Oh indeed. Too much bugzilla email. I guess we can close this now?

So can we add to the release criteria that the Geode LX is supported or document it somewhere else?

comment:27 in reply to: ↑ 25 Changed 4 years ago by pbrobinson

Replying to kevin:

Oh indeed. Too much bugzilla email. I guess we can close this now?

No, we I believe we need some reasonable testing to confirm it. Pushing it to testing I don't believe it enough, we need confirmation from OLPC.

comment:28 Changed 4 years ago by dsd

It looks like F13 will be fixed pending testing, thanks.

Have we decided upon a solution for F14+? That is the other half of this issue.

comment:29 Changed 4 years ago by kevin

  • Status changed from new to closed
  • Resolution set to fixed

Fesco agreed at the 2010-07-13 meeting that we wish to make sure that OX-1.0 is a supported platform moving forward. CJB is going to ping the test list and see about adding a release test critera for this moving forward.

Closing this now, thanks for everyones hard work on it.

Note: See TracTickets for help on using tickets.