Launchpad has imported 48 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=579838.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2010-04-06T17:28:18+00:00 Dan wrote: F-13 userspace can't be booted in system with AMD Geode LX CPU. Per http://fedoraproject.org/wiki/Features/F12X86Support it is a supported CPU for the x86 Fedora. Because the panic or "Illegal instruction" exception appears so early when userspace binaries should be run leads me to think that something is wrong in libc. The symptoms are - when booted F-13 kernel + F-13 initramfs => kernel panic when code from initramfs should be executed - when booted F-12 kernel + F-12 initramfs => unable to chroot to the F-13 userspace, see the attachments for boot logs in 2 situations - first is with init=/bin/bash on the kernel command line, second is with rdbreak=pre-pivot and manual chroot Version-Release number of selected component (if applicable): glibc-2.11.90-16 Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/0 ------------------------------------------------------------------------ On 2010-04-06T17:28:57+00:00 Dan wrote: Created attachment 404757 f12kernel-f13userspace-1 Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/1 ------------------------------------------------------------------------ On 2010-04-06T17:29:25+00:00 Dan wrote: Created attachment 404758 f12kernel-f13userspace-2 Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/2 ------------------------------------------------------------------------ On 2010-04-06T17:29:51+00:00 Dan wrote: Created attachment 404759 f13kernel-f13userspace Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/3 ------------------------------------------------------------------------ On 2010-04-07T07:43:40+00:00 Dan wrote: Created attachment 404857 disassembly I have installed gdb into the initramfs and now I can see the exact place of the crash. The NOPL instruction throws the exception and it's really unknown on the Geode LX per http://support.amd.com/us/Embedded_TechDocs/33234H_LX_databook.pdf. Buildroot used to build this glibc is http://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=742936 and gcc is gcc-4.4.3-8.fc13.i686.rpm Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/4 ------------------------------------------------------------------------ On 2010-04-07T07:48:56+00:00 Jakub wrote: So the CPU isn't i686 compatible and thus isn't supported. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/5 ------------------------------------------------------------------------ On 2010-04-07T08:41:38+00:00 Dan wrote: Ok, then we should write a new release note for F-13 about the changed CPU support. Just for curiosity, where can I get the definition of i686 architecture? I have "Intel® 64 and IA-32 Architectures Software Developer’s Manual", but how can one find there what's i686 and what was added in later CPUs? Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/6 ------------------------------------------------------------------------ On 2010-04-07T11:15:39+00:00 Andreas wrote: That should eventually be fixed in the kernel, see <http://marc.info/?l =linux-kernel&m=126748102722641&w=2>. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/7 ------------------------------------------------------------------------ On 2010-06-02T09:50:28+00:00 Till wrote: (In reply to comment #5) > So the CPU isn't i686 compatible and thus isn't supported. I opened a Fesco ticket to clarify which CPUs are supported by Fedora: https://fedorahosted.org/fesco/ticket/387 Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/22 ------------------------------------------------------------------------ On 2010-06-08T04:26:30+00:00 Dont wrote: There is no clarification needed by FESCo. The release was intended to support the Geode LX -- whether or not it is an "i686" (it isn't). Nothing in the F13 release specifications says anything about changing the set of supported CPUs from F12, which clearly supported the Geode LX (see Comment 1). Further investigation in the released Fedora 13 i686 LiveCD reveals that NOPL instructions only occur in binaries produced from glibc, and in a couple of statically linked binaries (/sbin/sln and /sbin/mdadm.static) linked with glibc. NOPL instructions can be generated by the GNU Assembler for .align commands that occur in executable sections. GCC can generate .align when optimizing, to align loop starts on cache line boundaries. Gas only generates NOPL when instructed that the machine architecture supports it. Apparently, sometime between F12 and F13, either gas's .align support was improved or enbugged, or the arguments to gas when compiling glibc were changed to an inappropriate value that excluded the Geode LX. This is not a generic problem with every package in the release -- it's a bug in the build configuration or Makefiles of glibc. This should be fixable by rebuilding the binary packages derived from glibc. This won't fix the release CDs and DVDs, but will fix the repos, which is key for the largest affected Fedora customer, OLPC. However, this problem HAS been reported by other users on other Geode LX hardware; see: http://sharkcz.livejournal.com/5708.html This bug was timely reported, but the report was ignored while there was plenty of time to fix the release. This bug should be reopened -- but bugzilla.redhat.com does not seem to offer me a user interface with which to do that. The priority of this bug should be increased, because it causes the release media to fail to boot and fail to install on supported hardware. For the same reason, it should also be documented in the release notes here: http://fedoraproject.org/wiki/Common_F13_bugs#Hardware-related_issues Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/33 ------------------------------------------------------------------------ On 2010-06-08T21:28:40+00:00 Daniel wrote: It's true that Geode LX is not-quite i686 and we seem to be aware of some other places in which it is lacking (in addition to nopl). This time around it does appear that the only problematic package we know about is glibc, so I'll focus on that case. The reason that glibc is the only affected package is because glibc's build system checks if the assembler supports the "-mtune" option, and if so, when building for i686 it passes -mtune=i686. Normally gcc does not pass -mtune or -march to the assembler (surprised me, too). But glibc explicitly checks if the assembler accepts it, and if so, it passes -Wa,-mtune=i686 to gcc, causing gcc to pass -mtune=i686 to the assembler. (the assembler's -march option remains unused) Passing -mtune=i686 to the assembler causes nopl to be used. This indicates an assembler bug, because mtune should produce enhanced code for a certain arch without breaking compat, but in this case using nopl instructions *will* break compat. This is http://sourceware.org/bugzilla/show_bug.cgi?id=6957 (looks like the developer wants a test case before continuing, I'll try and come up with one now) Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/34 ------------------------------------------------------------------------ On 2010-06-08T22:26:45+00:00 Daniel wrote: Alright. Posted some test cases on the upstream bug and already got a response. Invoking "as -mtune=i686" is effectively equivalent to invoking "as -march=i686 -mtune=i686" (a small behavioural difference when compared to gcc). So it will look to produce optimized code for i686, with the whole of the i686 instruction set at its disposition. So there is no glibc or assembler bug here. We're asking glibc to build for i686, and glibc is doing a better job than most packages of communicating the target architecture through the whole build chain. (by default the optimization flags do not reach the assembler, but glibc makes this happen) If we want to fix F13, we have a number of options available: - build glibc for target arch i586 - hack glibc build system to use -Wa,-mtune=i586 (i.e. we ask all parts of the build chain to optimize for i686, except for the assembler which we ask to optimize for i586) - hack glibc build system to use -Wa,-mtune=i686 -Wa,-march=i586 (i.e. ask the assembler to optimize for i686, but never going outside of the instruction set supported by i586 processes) - hack glibc build system so that we don't ask assembler to do any optimizations (like the rest of the world) In the FESCO meeting, we decided that we should gain a full understanding of this issue before coming up with a decision (do we hack glibc in F13 to fix this? Do we change target arch for F14? or both? or...?). I think with my analysis we have now gained an understanding. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/35 ------------------------------------------------------------------------ On 2010-06-09T06:32:49+00:00 Dan wrote: And there is also the NOPL emulator for kernel, that seems to be simple enough. I would use this (the Geode LX is very close to i686) and do iX86 < i686 as secondary arch where other people would profit too. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/36 ------------------------------------------------------------------------ On 2010-06-09T07:02:29+00:00 Jakub wrote: The NOPL emulator or letting Geode LX use a secondary i586 (or i486) arch is the only reasonable way to resolve this. All packages are built with -march=i686, so even if as -mtune=i686 perhaps shouldn't use automatically i686 insns, -march=i686 certainly should. gcc should switch to telling as to use i686 optimized code for -march=i686, so all packages will eventually have i686 nops. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/37 ------------------------------------------------------------------------ On 2010-06-09T07:54:23+00:00 Andreas wrote: (In reply to comment #11) > If we want to fix F13, we have a number of options available: > - hack glibc build system to use -Wa,-mtune=i686 -Wa,-march=i586 (i.e. ask > the > assembler to optimize for i686, but never going outside of the instruction set > supported by i586 processes) $ echo 'cmove %eax,%edx' | as -32 -march=i586 -mtune=i686 {standard input}: Assembler messages: {standard input}:1: Error: `cmove' is not supported on `i586' Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/38 ------------------------------------------------------------------------ On 2010-06-09T17:29:00+00:00 Dont wrote: Having somebody else fix the bug in some other software component always "seems to be simple enough". In this case, it isn't; there is serious dissent in the kernel team about whether, and how, to make this "simple" instruction emulation work. Independent of the kernel-architecture disagreement, nobody has yet posted a correct patch for "simply" emulating it in the kernel (the best patch opens security holes by peeking at userspace without appropriate permission checks). And if NOPL is going to become common in every program, as Jakub suggested, the last thing we want is for it to take thousands of cycles because it has to trap into the kernel every time it wants to do a no-op! Perhaps another way to look at the problem is that gcc and gas do not provide a way to target the instruction set of the Geode LX processor. Fedora definitely wants to target these processors, because they are a significant part of the installed base of Fedora - 1.5 million machines to date. (Here's the Fedora Feature notice for the change in F11 that made i586 support the base: http://fedoraproject.org/wiki/Features/ArchitectureSupport . And here's the F12 change that was supposed to support both the i686 AND the Geode LX while desupporting the i586: http://fedoraproject.org/wiki/Features/F12X86Support ) Yet there are no compiler/gas switches that let the full instruction set of the Geode LX processor be used without also including instructions that the processor doesn't implement. This may be a result of the unfortunate Intel-Corporation orientation of the instruction set (in general they like to ignore their competition). Intel did not document the NOPL instruction for the i686, yet all their 686 processors happened to implement it, so it crept into the tools even though it was not part of the documented spec. But other vendors who merely implemented the spec did not implement it. Here is the 1997 "Intel Architecture Software Developer's Manual: Volume 2: Instruction Set Reference" from the Pentium Pro era, as retrieved by the Internet Archive: http://web.archive.org/web/20070221130324/http://developer.intel.com/design/pentium/manuals/24319101.pdf . It does not document NOPL, only the 1-byte NOP instruction. Contrast this with the current "Intel 64 and IA-32 Architectures Software Developers Manual, Volume 2", which does document long NOP instructions: http://www.intel.com/Assets/PDF/manual/253667.pdf . So one possible resolution is to keep the "i686" designation for this instruction set, but to remove NOPL from the "i686" instruction set, making the GNU tools match the i686 (Pentium Pro and successors) documentation. What is the actual performance impact of altering GAS to avoid the use of NOPL on the i686 while aligning in executable sections? Since GAS already knows how to align on every kind of processor (it picks from among four or five different alternative NOP selections already), patching gas's NOP selection on i686 seems to be the least intrusive change that would result in long-term support for both the i686 and the Geode LX. A more intrusive change would be to define an instruction set "geodelx" and for Fedora to supply -march=geodelx -mtune=atom (rather than -march=i686 -mtune=atom). This would allow the use of long NOPs on -march=i686 (real Intel i686s) while avoiding them in the Fedora distribution. We (the community) may want to do one thing to patch F13, and another thing in the long term (for F14 and other distros). This is because the F13 issue is confined to a small number of packages and yet kills 1.5M customers. We can afford to recompile the world for F14, but if we decide that that's the only fix possible, F13 is dead on Geodes. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/39 ------------------------------------------------------------------------ On 2010-06-09T18:50:37+00:00 Richard wrote: Comment 15: Well argued. Another way to look at this is that 32 bit x86 is already a legacy architecture. No one who cares about performance should be using it -- all those power users long switched to x86-64. If you accept this argument then what we in Fedora should be doing is not making much effort to optimize 32 bit legacy systems at all. Rather, we should work on broadening support to as many old systems as possible by compiling for the lowest common denominator (i486 or i586 systems were probably the oldest ones that would have had enough memory to run mini Fedora spins). Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/40 ------------------------------------------------------------------------ On 2010-06-10T00:52:27+00:00 Dont wrote: I don't think the 36.3 million people who bought Atom netbooks in 2009 think their system is "legacy" -- nor the 58 million expected to buy in 2010 (estimated May 2010: http://www.abiresearch.com/press/1656-2009+Netbook+Shipments+Pass+Expectations%2C+58+Million+Forecast+for+2010). All CPU vendors are still selling high and growing volumes of 32-bit- only x86 chips. Their users do care about performance, though the issue is much more about performance-per-watt than about raw performance. X86 chips without amd64 support are mostly used either in mobile applications where battery life matters, or in embedded boards with limited heat budgets (or fanless operation). Given the higher penetration of Linux in netbooks (and OLPCs) than on desktops, there may well be more people running Fedora on x86 than on amd64. Indeed that's exactly what smolt shows: http://smolt.fedoraproject.org/static/stats/stats.html, with 69% on x86 and 30% on 64-bit, out of about 203,000 reporting hosts. (Smolt never runs on 1.5 million Fedora OLPCs that are Geode LX's. XO-1.5's will replace XO-1 sales this year; they use the Via C7-M ULV processor which is also only 32-bit x86 compatible, and all of them will run Fedora.) Unfortunately the web and repo stats aren't broken out by architecture: http://fedoraproject.org/wiki/Statistics . Perhaps this page can be improved to tell us how many accesses are happening to x86 versus x64 repos? The overall picture is clear: 32-bit x86 is still the dominant architecture in use in Fedora. We shouldn't break high volume 32-bit chips in Fedora, nor should we stop optimizing for 32-bit systems. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/41 ------------------------------------------------------------------------ On 2010-06-10T09:01:05+00:00 Andreas wrote: *** Bug 594660 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/42 ------------------------------------------------------------------------ On 2010-06-21T03:58:47+00:00 Daniel wrote: Created attachment 425520 Disable assembler optimizations in the FESCO meeting it was decided to patch glibc for F13. Here is an appropriate patch. The response for F14+ is not yet clear, but will be continue to be discussed in tuesdays meeting. https://fedorahosted.org/fesco/ticket/387 Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/51 ------------------------------------------------------------------------ On 2010-06-23T21:50:23+00:00 Chuck wrote: *** Bug 607186 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/53 ------------------------------------------------------------------------ On 2010-06-30T19:56:06+00:00 John wrote: Not to be impatient, but is there an estimate of when we might see a patched glibc for F13 hitting the testing repo? Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/59 ------------------------------------------------------------------------ On 2010-07-06T14:14:26+00:00 Fedora wrote: glibc-2.12-3 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/glibc-2.12-3 Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/60 ------------------------------------------------------------------------ On 2010-07-07T17:51:20+00:00 Fedora wrote: glibc-2.12-3 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update glibc'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/glibc-2.12-3 Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/61 ------------------------------------------------------------------------ On 2010-07-08T21:50:34+00:00 Dennis wrote: (In reply to comment #16) > Comment 15: Well argued. > > Another way to look at this is that 32 bit x86 is already a legacy > architecture. No one who cares about performance should be using > it -- all those power users long switched to x86-64. If you accept > this argument then what we in Fedora should be doing is not making > much effort to optimize 32 bit legacy systems at all. Rather, we should > work on broadening support to as many old systems as possible by > compiling for the lowest common denominator (i486 or i586 systems > were probably the oldest ones that would have had enough memory to > run mini Fedora spins). hear, hear. I was proud of Linux in the "old days" when it truely supported old hardware. With my Via C3 and C3-2, I have to look at other solutions, perhaps even NetBSD. I mean this will still support the Atom netbooks. I really dont think "the up to one percentage" gained by going from i586 to i686 was a good choice. I also have a Atom netbook. Doesn't most newer Intel Atoms have the 64 bit extension? Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/62 ------------------------------------------------------------------------ On 2010-07-10T00:11:26+00:00 Fran wrote: Soekris 5501 with Geode LX processor boots and runs OK after installing this test build. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/63 ------------------------------------------------------------------------ On 2010-07-13T07:33:42+00:00 Fedora wrote: glibc-2.12-3 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/64 ------------------------------------------------------------------------ On 2010-07-27T14:50:37+00:00 Chuck wrote: *** Bug 618592 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/65 ------------------------------------------------------------------------ On 2010-07-27T14:59:49+00:00 Peter wrote: I've just started testing this on my Fit-PC1 which has a geode (I would have tested it sooner but its been packed in boxes moving since March and i've only just recovered it. The initial upgrade of "yum upgrade yum rpm glibc" from F-12 has worked and its currently around 50% of the way through the rest of the yum upgrade for the rest of the distro. I'll be doing further testing over the coming days. Looks good so far. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/66 ------------------------------------------------------------------------ On 2010-07-27T15:02:29+00:00 Glen wrote: I can verify that doing a rebuild of the Fedora13 livecd with the livecd-creator results in an image that's bootable on my Via C3-2 hardware. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/67 ------------------------------------------------------------------------ On 2010-09-03T04:38:02+00:00 Quentin wrote: FYI the Linux binutils 2.20.51.0.11 release contains a fix that no longer generates the offending NOPs for i686. 2010/08/06 patch http://sourceware.org/ml/binutils-cvs/2010-08/msg00057.html 2010/08/11 release http://gcc.gnu.org/ml/gcc/2010-08/msg00194.html Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/69 ------------------------------------------------------------------------ On 2010-09-06T01:08:36+00:00 frank wrote: Is there any formal FC13 CD/DVD I can download to install on geode? I need a full installtion that is likely Fedora-13-i386-DVD.iso? Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/72 ------------------------------------------------------------------------ On 2010-09-07T18:41:20+00:00 Nick wrote: This should really be revisited. The basic semantics for choosing the NOP sequence were completely wrong. This has been fixed now. The NOPL instruction is not supported by all i686 processors, the coded assumption was that they all did. This has been changed by the recent AMD patches linked to by Quentin Neill so that it is not assumed and it's specified as an extension where it is supported. (NOPL is not standard i686, it was undocumented and has just been de facto supported since the Pentium Pro.) The benefit of full i686 optimisation, which do have real performance implications, are things like bswap (useful in networking), cmpxchg/xadd (used in atomics) and cmov (useful in compiler generated code). The correct solution is surely to ensure that when something is compiled for generic i686, NOPL is nowhere to be seen... Once the AMD patches that fix the bad semantics for NOPL and i686 in binutils (GAS) have been applied, the build of eglibc should be changed to restore i686 optimisation. The frustrating thing is that broken semantics for i686 have led to absurd patches such as the following being proposed as a workaround: http://groups.google.com/group/linux.kernel/browse_thread/thread/c1ec68f5498236dc/617726bec31595ed?show_docid=617726bec31595ed The point that gets missed there is that, abstractly, a NOP is meant to be exactly as it says on the tin, a No Operation. It's meant to do nothing at all - for a predefined number of clock cycles. A NOP is commonly used for timing purposes, that completely breaks that contract. Again, NOPL is not standard i686 - it's an extension supported by the vast, vast majority of i686 class processors. If you're compiling generically for i686, you cannot assume that it is present. Bad patches like the above to work around broken compilation cause more harm than good, plastering over the real problem. I've also had a brief look at the kernel. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/x86/Makefile_32.cpu;hb=HEAD … special cases the GX1 to -march=pentium-mmx and the LX to -march=geode,-march=pentium-mmx. There is also a special case for the bug in binutils for !CONFIG_X86_P6_NOP where -mtune=generic32 is set. And what about [x86: do not promote TM3x00/TM5x00 to i686-class] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7ef94e6889186848573a10c5bdb8271405f44de - that patch is based on the bad assumption that i686 includes NOPL when it does not. I haven't looked thoroughly, there might be more places! Cheers, Nick Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/87 ------------------------------------------------------------------------ On 2011-02-04T07:31:39+00:00 Andre wrote: The most recent glibc.i686 build for Rawhide ( http://koji.fedoraproject.org/koji/buildinfo?buildID=215507 ) appears to have reintroduced the NOPL instruction. See http://lists.fedoraproject.org/pipermail/test/2011-February/096805.html . Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/111 ------------------------------------------------------------------------ On 2011-02-04T08:06:02+00:00 Peter wrote: Re-opening and adding as a F15 Alpha blocker Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/112 ------------------------------------------------------------------------ On 2011-02-07T14:40:19+00:00 Daniel wrote: Is there a risk that this new binutils version will spit NOPLs into a whole range of packages, not just glibc? If so this should ideally be given attention this week, as the F15 rebuild is due. I had a quick look at the changelog and NEWS files of the newest releases and nothing stood out. I took a look at the patches that fixed this originally against the current code, but I don't have the background knowledge to make any meaningful observations. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/113 ------------------------------------------------------------------------ On 2011-02-07T19:10:54+00:00 Jan wrote: There is now: * Mon Feb 7 2011 Jan Kratochvil <jan.kratoch...@redhat.com> - 2.13.90-2 - Put back the assembler "workaround" - to disable the nopl instruction. which just reverts: * Tue Jan 25 2011 Andreas Schwab <sch...@redhat.com> - 2.13.90-1 [...] - Remove no longer needed assembler workaround so that nopl/nopw are no longer generated on i686. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/114 ------------------------------------------------------------------------ On 2011-02-07T21:27:21+00:00 Daniel wrote: Great. Thanks so much for addressing this at short notice :) Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/115 ------------------------------------------------------------------------ On 2011-02-08T19:03:11+00:00 Jan wrote: http://sourceware.org/ml/binutils/2011-02/msg00071.html -> I believe glibc should therefore use -march=something, probably -march=i686. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/116 ------------------------------------------------------------------------ On 2011-02-11T08:34:00+00:00 Adam wrote: Leaving notes on proposed blockers as I won't be at the meeting tomorrow most likely: This hits "The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media", IMO, so is an Alpha blocker. +1 Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/117 ------------------------------------------------------------------------ On 2011-02-11T17:41:38+00:00 Dennis wrote: fixed is in glibc-2.13.90-2 Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/118 ------------------------------------------------------------------------ On 2011-02-11T19:19:39+00:00 Robyn wrote: AGREED: 579838 - accepted as Alpha blocker as this impacts all XO's and is already fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/119 ------------------------------------------------------------------------ On 2011-02-14T08:06:48+00:00 Andreas wrote: This is *not* a glibc bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/120 ------------------------------------------------------------------------ On 2011-02-14T13:48:21+00:00 Jared wrote: (In reply to comment #42) > This is *not* a glibc bug. Andreas, can you be more specific? I'd like to get as many details as possible on this, so we can get it assigned to the proper component. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/121 ------------------------------------------------------------------------ On 2011-02-14T14:28:45+00:00 Nick wrote: (In reply to comment #43) > (In reply to comment #42) > > This is *not* a glibc bug. > > Andreas, can you be more specific? I'd like to get as many details as > possible > on this, so we can get it assigned to the proper component. glibc should not contain NOPL instructions when compiled with -march=i686 against a recent binutils (GAS) version. A workaround in glibc should not be needed. Refer to my previous comment. Cheers, Nick Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/122 ------------------------------------------------------------------------ On 2011-02-16T15:25:47+00:00 James wrote: @nickc - Any thoughts on how to proceed. This is currently listed as a F15Alpha release blocker. THe Alpha release candidate compose is scheduled for this friday (02-18). For this bug, we'll need either a workaround, a fix, or proof it does not qualify as an F15Alpha release blocker. Thanks! Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/123 ------------------------------------------------------------------------ On 2011-02-16T16:12:35+00:00 Nick wrote: With the workaround reapplied, it is clearly not a blocker. The fix is merely applied in the wrong place. It is just bandaid, if you like. The longer term view should be to correct things so that the optimal compilation options are used. Now that binutils has been fixed, i686 is a sane baseline for a 32-bit build. In my view, the entire 32-bit build of FC15 should be targeted for i686 with -march=i686 with a fixed version of binutils (GAS) that does not make bad assumption over the presence of NOPL. As far as compatibility impact of compiling for i686, which need to be understood and digested: VIA Edens based on the 'Samuel 2' design do not support CMOV or NOPL. (These would break.) All VIA Edens based on the 'Nehemiah' design support CMOV but not NOPL. (Introduced in 2003. These would not break.) Via C3s based on the 'Samuel 2'or 'Ezra'/'Ezra-T' design do not support CMOV or NOPL. (These would break.) All C3s based on the 'Nehemiah' design support CMOV but not NOPL. (Introduced in 2003. These would not break.) National Semi's GXm, GXLV and GX1 do not support CMOV or NOPL. (These would break.) All Geodes since and including National Semi's GX2 support CMOV but not NOPL. (Introduced in 2002. These would not break.) The AMD branded Geodes (GX and LX) support CMOV but not NOPL. (These would not break.) The Cyrix 6x86 processors do not support CMOV or NOPL. (These would break.) The Cyrix 8x86MX / Cyrix MII do support CMOV but not NOPL. (These would not break.) The AMD K6 and K6-2 do not support CMOV or NOPL. (These would break.) Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/124 ------------------------------------------------------------------------ On 2011-02-16T16:30:33+00:00 Adam wrote: This bug is for NOPL instructions existing in glibc. That bug is clearly now fixed, hence this should be closed. Nick, if you think that working around the issue in glibc is the wrong fix, can you please file a new bug against whichever component should be fixed so that glibc does not need to include a workaround (I'm guessing binutils)? It would be easier to track the correct issues that way; we should close this one so it's no longer blocking the Alpha release. Thanks. Reply at: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/587186/comments/125 ** Changed in: binutils (Fedora) Status: Unknown => Fix Released ** Changed in: binutils (Fedora) Importance: Unknown => Medium ** Bug watch added: fedorahosted.org/fesco/ #387 https://fedorahosted.org/fesco/ticket/387 ** Bug watch added: Sourceware.org Bugzilla #6957 https://sourceware.org/bugzilla/show_bug.cgi?id=6957 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/587186 Title: libc6 upgrade fails: illegal instruction To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/587186/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
