Re: Alternative option for solving Fedora i686 vs geode problems
On Tue, Jun 8, 2010 at 5:27 AM, Daniel Drake d...@laptop.org wrote: On 7 June 2010 20:05, James Cameron qu...@laptop.org wrote: You are placing far more trust in a trivial rebuild than I would. Once Fedora ceases testing the actual instruction streams we will be using, we will be providing the testing instead. There are some interesting classes of bugs that this would influence. After years of working with Gentoo linux where practically every user has their own CFLAGS, I can say that problems like this are uncommon, at least in my experience. The only cases where CFLAGS differences cause miscompilations that I've seen have been related to using the more exotic CFLAGS, or users being downright stupid. I don't imagine we'd see any issues from changing from -march=i686 to -march=i586. Gentoo does one thing Fedora won't(I think), which is to filter out harmless CFLAGS that cause problems with some packages. You could always look into Gentoo's ebuilds if an error like that is suspected but I agree that it will be mostly a non-issue. The biggest similar problem I faced was using a 3.4 compiler where a package only compiled well to 4.1+. Best regards, Tiago Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
Ups, I missed the last part. As you say, leaving CFLAGS intact will probably make -i586 problem free. Tiago On Wed, Jun 9, 2010 at 11:38 PM, Tiago Marques tiago...@gmail.com wrote: On Tue, Jun 8, 2010 at 5:27 AM, Daniel Drake d...@laptop.org wrote: On 7 June 2010 20:05, James Cameron qu...@laptop.org wrote: You are placing far more trust in a trivial rebuild than I would. Once Fedora ceases testing the actual instruction streams we will be using, we will be providing the testing instead. There are some interesting classes of bugs that this would influence. After years of working with Gentoo linux where practically every user has their own CFLAGS, I can say that problems like this are uncommon, at least in my experience. The only cases where CFLAGS differences cause miscompilations that I've seen have been related to using the more exotic CFLAGS, or users being downright stupid. I don't imagine we'd see any issues from changing from -march=i686 to -march=i586. Gentoo does one thing Fedora won't(I think), which is to filter out harmless CFLAGS that cause problems with some packages. You could always look into Gentoo's ebuilds if an error like that is suspected but I agree that it will be mostly a non-issue. The biggest similar problem I faced was using a 3.4 compiler where a package only compiled well to 4.1+. Best regards, Tiago Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Tue, Jun 8, 2010 at 5:31 AM, John Gilmore g...@toad.com wrote:
2) FESCo (Fedora Engineering Steering Committee) is dealing with the
issue upstream [1][2] in Fedora with the view of getting it fixed
upstream for F-14 or at the very least clarified. It was agreed in
F-12 that the Geode LX would be supported and that decision wasn't
discussed otherwise. Please add to the conversation on the ticket or
the list. It might be worth seeing the outcome of this before we go
and reinvent the wheel again.
Peter
[1] http://lists.fedoraproject.org/pipermail/devel/2010-June/137070.html
(but thread goes back to April)
[2] https://fedorahosted.org/fesco/ticket/387
It's nice to know we have the attention of the right folks. But there's
some useful info we could give them for tomorrow's FESCo meeting.
You can attend. Its an open IRC meeting [1]. It might be worthwhile
showing up as you can probably give more constructive details.
Do we know which i386/i686 packages in F13 actually contain NOPL
instructions? Apparently, glibc does contain them, due to the report
here from the beta:
https://bugzilla.redhat.com/show_bug.cgi?id=579838
If fixing F13 would only require rebuilding five, ten, or twenty
packages, then fixing it in the F13 repos (for everybody, not just for
OLPC) is totally doable. If it requires a total rebuild, then the fix
could only occur in the next Fedora release.
Reading below it looks like it just needs one.
This message suggested that the NOPL instruction doesn't appear in any
of the coreutils programs:
http://lists.fedoraproject.org/pipermail/devel/2010-June/137144.html
To figure this out, I downloaded and booted the F13 i686 LiveCD and
did this:
for x in {,/usr}{/bin,/sbin,/lib}/* ; do
echo $x
objdump -d $x | grep nopl
done
It shows nopl's in:
snip
There are no nopl's anywhere under /lib/modules. objdump couldn't
examine the mashed kernel image in /boot, but I bet it's free or
almost free of nopl's.
Virtually all of these files are generated from the libc sources
(except two executables statically-linked with libc). In short, this
is almost exclusively a glibc problem. It's probably just a bug
introduced into the glibc configuration or makefile in F13.
Or in the new major 2.12 version of glibc shipped with Fedora? Well
its not hard to rebuild a scratch build of glibc in Fedora build
systems. Is it possible for someone to workout what changes we should
try and test? If someone can work it out I'll quite happily push
scratch builds through the build system if no one else can to allow
testing and verification of the problem. Changes to the way it was
built during F-13 can be found in the rpm cvs [2] if you want to be
able to compare changes.
Fedora Bug 579838 should be reopened -- it was inappropriately closed
by Andreas Schwab on 2010-04-07. (Jakub's comment wasn't pretty, but
he didn't close the bug - Andreas did. But closing bugs
inappropriately to make your bug stats look good is rampant in every
development org - e.g. I regularly complain to Ubuntu about this.)
This is not a dead issue for F13, and we should seek solutions within
F13 as well as outside it.
Feel free to reopen it, if you can't let me know and I will.
Oddly, F13 offers release CDs and DVDs only for i386 (and x86-64),
but offers live CDs only for i686 (and x86-64). It is completely
unclear from the documentation (which suggests using these
interchangeably) whether the i386 DVD is really compiled for i686 or
i386. See:
It is i686, I'll file a bug to get it verified on the site. Thanks.
http://fedoraproject.org/en/get-fedora-options
(hover over the Download Now buttons to see which ISO image each
one offers.)
http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/ch-new-users.html#sn-which-arch
John
[1] https://fedoraproject.org/wiki/FESCO#Meetings
[2] http://cvs.fedoraproject.org/viewvc/rpms/glibc/F-13/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Wed, Jun 2, 2010 at 10:19 PM, Daniel Drake d...@laptop.org wrote: In another thread, we've been discussing the issue that Fedora 12 changed base architecture from i586 to i686. The XO-1 processor (Geode LX) is a i586. Fedora 12 seems to run OK (although I suspect there will be a few broken packages), but Fedora 13 is more obviously broken (for a start, glibc doesn't work). The approach we've been musing about is modifying the kernel to fill in the gaps, where the Geode does not support a particular i686 instruction we can emulate it. (unfortunately this kernel-side project is a bit slow moving, although we could find some resources to boost it maybe) I just thought of another option that we could consider looking at, once we've finished off the F11-based release when we're ready to think about moving forward. Fedora's build tools are good and consistent, so we could simply rebuild the parts of Fedora that we use. 1. Do a regular OS build (for i686) The build system outputs a package list, e.g. http://build.laptop.org/10.2.0/os122/os122.packages.txt 2. Download the SRPMs for each package in the list (using yumdownloader --source for example) 3. Pass each SRPM to mock, using a modified config which sets config_opts['target_arch'] to i586 4. Take all of mock's output, conveniently compiled for i586, putting the RPMs in a repository 5. Do a build using the i586 repository Comments/suggestions/refinements? Two comments. 1) I thought we'd moved away from rolling our own distro due to the amount of time and engineering resources it required that OLPC no longer had. Has this changed? IE is there an internal thing that has changed that hasn't been announced externally? 2) FESCo (Fedora Engineering Steering Committee) is dealing with the issue upstream [1][2] in Fedora with the view of getting it fixed upstream for F-14 or at the very least clarified. It was agreed in F-12 that the Geode LX would be supported and that decision wasn't discussed otherwise. Please add to the conversation on the ticket or the list. It might be worth seeing the outcome of this before we go and reinvent the wheel again. Peter [1] http://lists.fedoraproject.org/pipermail/devel/2010-June/137070.html (but thread goes back to April) [2] https://fedorahosted.org/fesco/ticket/387 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
2) FESCo (Fedora Engineering Steering Committee) is dealing with the issue upstream [1][2] in Fedora with the view of getting it fixed upstream for F-14 or at the very least clarified. It was agreed in F-12 that the Geode LX would be supported and that decision wasn't discussed otherwise. Please add to the conversation on the ticket or the list. It might be worth seeing the outcome of this before we go and reinvent the wheel again. I think sitting around and waiting to see the outcome of a very unclear situation is possibly disastrous. Why not hash out a few ideas while there is still wiggle room in the decision making process? The way I see it we have a few uncertainties right now. 1) Will there be actual support for the Geode processor in F14? The official stance is yes, however after reading that thread there seems to be some dissension in the ranks. 2) If it is supported, what is the performance impact of using emulated instructions? 3) Will this all get solidified in time-frame that gives OLPC a warm fuzzy feeling about basing their next release on F14? The way I see it, OLPC and SugarLabs need some automated performance testing to verify that using emulated instructions do not slow things down an unacceptable amount. Even for this testing to be done the patches and recompilation of at least core packages need to be done. We don't need all the bells and whistles but the short-list is kernel, glibc, gstreamer, xorg, alsa, python, sugar. Fedora's dev cycle is 6 months so if it is going to take longer than 2 months ( of course this can be discussed ) it is probably worth the effort to scope out some alternative paths forward. I am at the point where I already need some GUI testing tools to move forward in my graphics card performance development. I will definitely need some help putting together use case scenarios. Anyone else have any time to work on this? -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On 7 June 2010 18:33, Peter Robinson pbrobin...@gmail.com wrote: 1) I thought we'd moved away from rolling our own distro due to the amount of time and engineering resources it required that OLPC no longer had. Has this changed? IE is there an internal thing that has changed that hasn't been announced externally? Depends what you mean by rolling our own distro. In some respects OLPC has always rolled its own distro, using its own build tools and adding custom packages. From the other point of view, the majority of packages have come from Fedora in every release to date, is this really our own distro? In this case, the Fedora packages are now unusable, so rebuilding them would be needed. I'm not sure that this counts as progressing to rolling our own distro since the rebuild would be fully automatic, and that the end result would only have trivial differences. (unless I'm missing something in my untested proposal, it wouldn't require any significant change in engineering resources from OLPC's side) Glad to see some interest in reviving support in future versions of Fedora, thanks for pointing that out. Fingers crossed. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Mon, Jun 7, 2010 at 4:33 PM, Peter Robinson pbrobin...@gmail.com wrote: 2) FESCo (Fedora Engineering Steering Committee) is dealing with the issue upstream [1][2] in Fedora with the view of getting it fixed upstream for F-14 or at the very least clarified. Good to hear there's a good chance that F14 will support XO-1. At least we need some XOs running rawhide to keep track of it... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Mon, Jun 7, 2010 at 11:12 PM, Jon Nettleton jon.nettle...@gmail.comwrote: 2) FESCo (Fedora Engineering Steering Committee) is dealing with the issue upstream [1][2] in Fedora with the view of getting it fixed upstream for F-14 or at the very least clarified. It was agreed in F-12 that the Geode LX would be supported and that decision wasn't discussed otherwise. Please add to the conversation on the ticket or the list. It might be worth seeing the outcome of this before we go and reinvent the wheel again. I think sitting around and waiting to see the outcome of a very unclear situation is possibly disastrous. Why not hash out a few ideas while there is still wiggle room in the decision making process? The way I see it we have a few uncertainties right now. 1) Will there be actual support for the Geode processor in F14? The official stance is yes, however after reading that thread there seems to be some dissension in the ranks. 2) If it is supported, what is the performance impact of using emulated instructions? 3) Will this all get solidified in time-frame that gives OLPC a warm fuzzy feeling about basing their next release on F14? The way I see it, OLPC and SugarLabs need some automated performance testing to verify that using emulated instructions do not slow things down an unacceptable amount. Even for this testing to be done the patches and recompilation of at least core packages need to be done. We don't need all the bells and whistles but the short-list is kernel, glibc, gstreamer, xorg, alsa, python, sugar. Fedora's dev cycle is 6 months so if it is going to take longer than 2 months ( of course this can be discussed ) it is probably worth the effort to scope out some alternative paths forward. I am at the point where I already need some GUI testing tools to move forward in my graphics card performance development. I will definitely need some help putting together use case scenarios. Anyone else have any time to work on this? I'd sure love to see better graphics support on the XO 1.5. Not that I have free time on a schedulle but when I do find it, how can I help you? Best regards, Tiago -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Mon, Jun 7, 2010 at 11:28 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Jun 7, 2010 at 4:33 PM, Peter Robinson pbrobin...@gmail.com wrote: 2) FESCo (Fedora Engineering Steering Committee) is dealing with the issue upstream [1][2] in Fedora with the view of getting it fixed upstream for F-14 or at the very least clarified. Good to hear there's a good chance that F14 will support XO-1. At least we need some XOs running rawhide to keep track of it... I had XO-1s running F-12 during that release process. I plain ran out of time to do that during the F-13 release cycle and that's why I missed it. I would like to get that in place for both the XO-1 (when we get support back) and 1.5s moving forward. The kernel causes issues here but its workable. EG with the latest F-12 updates (boot strapped of mtd's SoaS v2 for XO-1 beta build from eons ago) the black icons in Sugar are back again. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Mon, Jun 7, 2010 at 11:19 PM, Daniel Drake d...@laptop.org wrote: On 7 June 2010 18:33, Peter Robinson pbrobin...@gmail.com wrote: 1) I thought we'd moved away from rolling our own distro due to the amount of time and engineering resources it required that OLPC no longer had. Has this changed? IE is there an internal thing that has changed that hasn't been announced externally? Depends what you mean by rolling our own distro. In some respects OLPC has always rolled its own distro, using its own build tools and adding custom packages. From the other point of view, the majority of packages have come from Fedora in every release to date, is this really our own distro? In this case, the Fedora packages are now unusable, so rebuilding them would be needed. I'm not sure that this counts as progressing to rolling our own distro since the rebuild would be fully automatic, and that the end result would only have trivial differences. (unless I'm missing something in my untested proposal, it wouldn't require any significant change in engineering resources from OLPC's side) OK, so what your actually proposing is essentially becoming a Secondary Arch [1] of Fedora with some compiler flags to optimise it for the platforms we need to support? That would be a lot less work but we'd still need to put a koji builder instance or two in place. Who will be providing and maintaining that infrastructure? Glad to see some interest in reviving support in future versions of Fedora, thanks for pointing that out. Fingers crossed. Agreed. I felt a little kicked in the teeth after the massive flame fest during the F-12 devel process. Peter [1] https://fedoraproject.org/wiki/Architectures ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
I looked at the kernel patch for emulating the missing instruction (long NOP). It looks like it works, and only needs minor patching-up for security enforcement. The big argument on the Linux kernel list was about not having a little kludge like this, which is likely to grow to emulate many other things and become unmaintainable; some people would rather use the whole virtual-CPU emulation mechanism for this, which is much more heavyweight, but also a lot easier to test and validate. If having to maintain a 20- or 50-line kernel patch is the price of being able to move forward onto using unmodified modern Fedora release repositories, I'd say the choice for OLPC is very clear - do it. The change that introduced the use of this instruction was in the binutils (assembler) rather than in gcc. I believe it is used when a .align directive is given in an executable segment. When optimizing, GCC has been aligning some loops on cache line boundaries for some time (by inserting nop padding BEFORE the loop), but previously, the assembler was filling with various N-byte NOPs that would work on any x86. It has been improved to pick faster ones on modern hardware. The relevant code is in gas/config/tc-i386.c, function i386_align_code(). I haven't pinned down the actual code change that bit us, and perhaps it's just the change in -march and/or -mtune options used by Fedora when calling gcc. Gas is careful to only use NOPs that are compatible with the specified instruction set, if one is specified -- but Fedora is specifying the wrong one for our purposes. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Mon, Jun 07, 2010 at 07:19:43PM -0300, Daniel Drake wrote: In this case, the Fedora packages are now unusable, so rebuilding them would be needed. I'm not sure that this counts as progressing to rolling our own distro since the rebuild would be fully automatic, and that the end result would only have trivial differences. You are placing far more trust in a trivial rebuild than I would. Once Fedora ceases testing the actual instruction streams we will be using, we will be providing the testing instead. There are some interesting classes of bugs that this would influence. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
john wrote: I looked at the kernel patch for emulating the missing instruction (long NOP). It looks like it works, and only needs minor patching-up for security enforcement. The big argument on the Linux kernel list was about not having a little kludge like this, which is likely to grow to emulate many other things and become unmaintainable; some people would rather use the whole virtual-CPU emulation mechanism for this, which is much more heavyweight, but also a lot easier to test and validate. If having to maintain a 20- or 50-line kernel patch is the price of being able to move forward onto using unmodified modern Fedora release repositories, I'd say the choice for OLPC is very clear - do it. The change that introduced the use of this instruction was in the binutils (assembler) rather than in gcc. I believe it is used when a .align directive is given in an executable segment. When optimizing, GCC has been aligning some loops on cache line boundaries for some time (by inserting nop padding BEFORE the loop), but previously, the assembler was filling with various N-byte NOPs that would work on any x86. It has been improved to pick faster ones on modern hardware. there's a wonderful irony in that, given all of the performance issues our laptops face, our big worry this week is the cost of doing nothing at all. :-) i agree with john -- we should definitely try the kernel emulation, and try and gather some statistics on how often it fires, or other easy metric. i'll bet the cost is low. paul The relevant code is in gas/config/tc-i386.c, function i386_align_code(). I haven't pinned down the actual code change that bit us, and perhaps it's just the change in -march and/or -mtune options used by Fedora when calling gcc. Gas is careful to only use NOPs that are compatible with the specified instruction set, if one is specified -- but Fedora is specifying the wrong one for our purposes. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Mon, Jun 07, 2010 at 10:07:07PM -0400, Paul Fox wrote: i agree with john -- we should definitely try the kernel emulation, and try and gather some statistics on how often it fires, or other easy metric. i'll bet the cost is low. Cool, please provide a kernel RPM for testing. ;-) -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Tue, Jun 8, 2010 at 1:49 AM, John Gilmore g...@toad.com wrote: I looked at the kernel patch for emulating the missing instruction (long NOP). It looks like it works, and only needs minor patching-up for security enforcement. The big argument on the Linux kernel list was about not having a little kludge like this, which is likely to grow to emulate many other things and become unmaintainable; some people would rather use the whole virtual-CPU emulation mechanism for this, which is much more heavyweight, but also a lot easier to test and validate. If having to maintain a 20- or 50-line kernel patch is the price of being able to move forward onto using unmodified modern Fedora release repositories, I'd say the choice for OLPC is very clear - do it. The change that introduced the use of this instruction was in the binutils (assembler) rather than in gcc. I believe it is used when a .align directive is given in an executable segment. When optimizing, GCC has been aligning some loops on cache line boundaries for some time (by inserting nop padding BEFORE the loop), but previously, the assembler was filling with various N-byte NOPs that would work on any x86. It has been improved to pick faster ones on modern hardware. The relevant code is in gas/config/tc-i386.c, function i386_align_code(). I haven't pinned down the actual code change that bit us, and perhaps it's just the change in -march and/or -mtune options used by Fedora when calling gcc. Gas is careful to only use NOPs that are compatible with the specified instruction set, if one is specified -- but Fedora is specifying the wrong one for our purposes. The mail -march and/or -mtune options to compile the whole of Fedora wasn't changed from F-12 to F-13 release so it was something else that changed that triggered the issues. It was mentioned somewhere it was a change in glibc. Whether it was glibc or something or if it was by luck or something else that changed which meant it was seen only in F-13 and not F-12 I don't have the deep technical understanding to make that judgement. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On 7 June 2010 17:58, Peter Robinson pbrobin...@gmail.com wrote: In this case, the Fedora packages are now unusable, so rebuilding them would be needed. I'm not sure that this counts as progressing to rolling our own distro since the rebuild would be fully automatic, and that the end result would only have trivial differences. (unless I'm missing something in my untested proposal, it wouldn't require any significant change in engineering resources from OLPC's side) OK, so what your actually proposing is essentially becoming a Secondary Arch [1] of Fedora with some compiler flags to optimise it for the platforms we need to support? That would be a lot less work but we'd still need to put a koji builder instance or two in place. Who will be providing and maintaining that infrastructure? That would be a lot of work. My suggestion is more simplistic. Look at the package set included in an OLPC build, rebuild them for i586 using mock, and then run a build using that repo. (the process does have its similarities for what would happen for a 2ndary arch, but at a fraction of the scale, with no infra/political overhead) Hopefully none of this will be necessary--nevertheless I thought it would be worthwhile to push an alternative idea out. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On 7 June 2010 20:05, James Cameron qu...@laptop.org wrote: You are placing far more trust in a trivial rebuild than I would. Once Fedora ceases testing the actual instruction streams we will be using, we will be providing the testing instead. There are some interesting classes of bugs that this would influence. After years of working with Gentoo linux where practically every user has their own CFLAGS, I can say that problems like this are uncommon, at least in my experience. The only cases where CFLAGS differences cause miscompilations that I've seen have been related to using the more exotic CFLAGS, or users being downright stupid. I don't imagine we'd see any issues from changing from -march=i686 to -march=i586. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
2) FESCo (Fedora Engineering Steering Committee) is dealing with the
issue upstream [1][2] in Fedora with the view of getting it fixed
upstream for F-14 or at the very least clarified. It was agreed in
F-12 that the Geode LX would be supported and that decision wasn't
discussed otherwise. Please add to the conversation on the ticket or
the list. It might be worth seeing the outcome of this before we go
and reinvent the wheel again.
Peter
[1] http://lists.fedoraproject.org/pipermail/devel/2010-June/137070.html
(but thread goes back to April)
[2] https://fedorahosted.org/fesco/ticket/387
It's nice to know we have the attention of the right folks. But there's
some useful info we could give them for tomorrow's FESCo meeting.
Do we know which i386/i686 packages in F13 actually contain NOPL
instructions? Apparently, glibc does contain them, due to the report
here from the beta:
https://bugzilla.redhat.com/show_bug.cgi?id=579838
If fixing F13 would only require rebuilding five, ten, or twenty
packages, then fixing it in the F13 repos (for everybody, not just for
OLPC) is totally doable. If it requires a total rebuild, then the fix
could only occur in the next Fedora release.
This message suggested that the NOPL instruction doesn't appear in any
of the coreutils programs:
http://lists.fedoraproject.org/pipermail/devel/2010-June/137144.html
To figure this out, I downloaded and booted the F13 i686 LiveCD and
did this:
for x in {,/usr}{/bin,/sbin,/lib}/* ; do
echo $x
objdump -d $x | grep nopl
done
It shows nopl's in:
/sbin/ldconfig
/sbin/mdadm.static,
/sbin/sln
/lib/ld-2.12.so
/lib/ld-linux.so.2,
/lib/libanl-2.12.so
/lib/libanl.so.1
/lib/libc-2.12.so
/lib/libcidn-2.12.so
/lib/libcidn.so.1
/lib/libcrypt-2.12.so
/lib/libcrypt.so.1
/lib/libc.so.6
/lib/libdl-2.12.so
/lib/libdl.so.2
/lib/libm-2.12.so
/lib/libm.so.6
/lib/libnsl-2.12.so
/lib/libnsl.so.1
/lib/libnss_compat-2.12.so
/lib/libnss_compat.so.2
/lib/libnss_dns-2.12.so
/lib/libnss_dns.so.2
/lib/libnss_files-2.12.so
/lib/libnss_files.so.2
/lib/libnss_hesiod-2.12.so
/lib/libnss_hesiod.so.2
/lib/libnss_nis-2.12.so
/lib/libnss_nisplus-2.12.so
/lib/libnss_nisplus.so.2
/lib/libnss_nis.so.2
/lib/libpthread-2.12.so
/lib/libpthread.so.0
/lib/libresolv-2.12.so
/lib/libresolv.so.2
/lib/librt-2.12.so
/lib/librt.so.1
/lib/libSegFault.so
/lib/libthread_db-1.0.so
/lib/libthread_db.so.1
/lib/libutil-2.12.so
/lib/libutil.so.1
/usr/bin/gencat
/usr/bin/getconf
/usr/bin/getent
/usr/bin/iconv
/usr/bin/locale
/usr/bin/localedef
/usr/bin/rpcgen
/usr/bin/sprof
/usr/sbin/build-locale-archive
/usr/sbin/glibc_post_upgrade.i686
/usr/sbin/iconvconfig
/usr/sbin/iconvconfig.i686
/usr/sbin/nscd
/usr/sbin/prelink
/usr/sbin/zdump
/usr/sbin/zic
There are no nopl's anywhere under /lib/modules. objdump couldn't
examine the mashed kernel image in /boot, but I bet it's free or
almost free of nopl's.
Virtually all of these files are generated from the libc sources
(except two executables statically-linked with libc). In short, this
is almost exclusively a glibc problem. It's probably just a bug
introduced into the glibc configuration or makefile in F13.
Fedora Bug 579838 should be reopened -- it was inappropriately closed
by Andreas Schwab on 2010-04-07. (Jakub's comment wasn't pretty, but
he didn't close the bug - Andreas did. But closing bugs
inappropriately to make your bug stats look good is rampant in every
development org - e.g. I regularly complain to Ubuntu about this.)
This is not a dead issue for F13, and we should seek solutions within
F13 as well as outside it.
Oddly, F13 offers release CDs and DVDs only for i386 (and x86-64),
but offers live CDs only for i686 (and x86-64). It is completely
unclear from the documentation (which suggests using these
interchangeably) whether the i386 DVD is really compiled for i686 or
i386. See:
http://fedoraproject.org/en/get-fedora-options
(hover over the Download Now buttons to see which ISO image each
one offers.)
http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/ch-new-users.html#sn-which-arch
John
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Fri, Jun 4, 2010 at 8:48 PM, Daniel Drake d...@laptop.org wrote: On 4 June 2010 21:48, Tiago Marques tiago...@gmail.com wrote: If you're planning on doing a repository exclusively for the XO-1, Gentoo is simple to setup and, from what I read on this mailing list, thicks all your boxes: I'm a Gentoo fan myself. But you're talking about a whole new project here. Packaging all the OLPC technologies and packages. Breaking many field-deployed processes. etc. The steps I outline above will (I believe) result in a usable OLPC OS distro similar to what goes out to the field today. To use any other OS, a lot more work is needed before you end up something which can be used at scale. Will CentOS still be supporting the older architectures? It was previously discussed on the mailing list that it may be easier to rebase a long term support release, especially for aging hardware, on a RHEL base and then just manage a repo for the specific packages that a SUGAR distro really needs. I can probably throw together a test CentOS image with updated gstreamer/xorg/olpc-kernel pretty quick. Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Sat, Jun 5, 2010 at 10:44 AM, Jon Nettleton jon.nettle...@gmail.com wrote: On Fri, Jun 4, 2010 at 8:48 PM, Daniel Drake d...@laptop.org wrote: On 4 June 2010 21:48, Tiago Marques tiago...@gmail.com wrote: If you're planning on doing a repository exclusively for the XO-1, Gentoo is simple to setup and, from what I read on this mailing list, thicks all your boxes: I'm a Gentoo fan myself. But you're talking about a whole new project here. Packaging all the OLPC technologies and packages. Breaking many field-deployed processes. etc. The steps I outline above will (I believe) result in a usable OLPC OS distro similar to what goes out to the field today. To use any other OS, a lot more work is needed before you end up something which can be used at scale. Will CentOS still be supporting the older architectures? It was previously discussed on the mailing list that it may be easier to rebase a long term support release, especially for aging hardware, on a RHEL base and then just manage a repo for the specific packages that a SUGAR distro really needs. I can probably throw together a test CentOS image with updated gstreamer/xorg/olpc-kernel pretty quick. Just checked the RHEL 6 beta and they are also only supporting i686 as their x86 architecture. That really doesn't help us then. Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
There is also an old project on a version of gentoo for the xo 1 on http://www.gentooxo.org I tested it sometimes ago and even it is using the gentoo with gnome it is a lot faster than Fedora 11 on xo. -- Ahmed Mansour http://olpc-maroc.blogspot.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On Wed, Jun 2, 2010 at 10:19 PM, Daniel Drake d...@laptop.org wrote: In another thread, we've been discussing the issue that Fedora 12 changed base architecture from i586 to i686. The XO-1 processor (Geode LX) is a i586. Fedora 12 seems to run OK (although I suspect there will be a few broken packages), but Fedora 13 is more obviously broken (for a start, glibc doesn't work). The approach we've been musing about is modifying the kernel to fill in the gaps, where the Geode does not support a particular i686 instruction we can emulate it. (unfortunately this kernel-side project is a bit slow moving, although we could find some resources to boost it maybe) Even slower? AFAIK there were some sugestions from the GCC team - I think - that the Geode runs faster with the i486 compilation and not i586. I never put that claim to test though. I just thought of another option that we could consider looking at, once we've finished off the F11-based release when we're ready to think about moving forward. Fedora's build tools are good and consistent, so we could simply rebuild the parts of Fedora that we use. 1. Do a regular OS build (for i686) The build system outputs a package list, e.g. http://build.laptop.org/10.2.0/os122/os122.packages.txt 2. Download the SRPMs for each package in the list (using yumdownloader --source for example) 3. Pass each SRPM to mock, using a modified config which sets config_opts['target_arch'] to i586 Perhaps a quick test with compiler options before deciding on any. I can help with this. 4. Take all of mock's output, conveniently compiled for i586, putting the RPMs in a repository 5. Do a build using the i586 repository Comments/suggestions/refinements? If you're planning on doing a repository exclusively for the XO-1, Gentoo is simple to setup and, from what I read on this mailing list, thicks all your boxes: - You can upgrade GCC and glibc when you want to(or don't) - Compile properly compiler optimized packages - Keep network-manager up to date, upgrade it whenever you want (CentOS doesn't, right?) - Update involves issuing a bunch of emerge commands for your binary packages hosted on the repository, compile once like with Fedora. - glsa-check -tv all shows you what you need to fix security wise, when you're in maintenance mode. - Portage can be put on a squashfs filesystem and take just ~50MB of disk instead of 700+(I've done this on my XO) - There's already a* sugar overlay available* with ebuilds - Get a lower memory footprint from building packages using just the necessary features through USE flags I have this setup at home and can also give you a hand with this. Best regards, Tiago Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Alternative option for solving Fedora i686 vs geode problems
On 4 June 2010 21:48, Tiago Marques tiago...@gmail.com wrote: If you're planning on doing a repository exclusively for the XO-1, Gentoo is simple to setup and, from what I read on this mailing list, thicks all your boxes: I'm a Gentoo fan myself. But you're talking about a whole new project here. Packaging all the OLPC technologies and packages. Breaking many field-deployed processes. etc. The steps I outline above will (I believe) result in a usable OLPC OS distro similar to what goes out to the field today. To use any other OS, a lot more work is needed before you end up something which can be used at scale. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
