= 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
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
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?
Replying to [comment:2 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 [https://lists.fedoraproject.org/pipermail/devel/2009-August/036796.html this thread]; was there more?
The long discussion is probably this one: [http://lists.fedoraproject.org/pipermail/devel/2009-June/032604.html Changing the default 32-bit x86 arch for Fedora 12]
The discussion about the changed proposal starts here: [https://www.redhat.com/archives/fedora-devel-list/2009-June/msg01506.html Changing the default 32-bit x86 arch for Fedora 12 (#2)]
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.
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.
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.
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.
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.
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:
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.
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.
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
Sorry for the delay. Patch now posted at https://bugzilla.redhat.com/show_bug.cgi?id=579838#c19
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
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.
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
We are defering this another week from todays 2010-07-06 meeting.
Replying to [comment:23 kevin]:
Why? Apparently according to the bug it was fixed yesterday.
Oh indeed. Too much bugzilla email. I guess we can close this now?
Can the reporters confirm the update works for them?
Replying to [comment:25 kevin]:
So can we add to the release criteria that the Geode LX is supported or document it somewhere else?
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.
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.
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.
Login to comment on this ticket.