Launchpad has imported 36 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=442285.
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 2008-04-13T21:41:11+00:00 Robert wrote: Description of problem: Please solve real cause of bug #437701 and rebuild memtest86+ with GCC 4.3, shipping and or requiring legacy components is a worse thing. Version-Release number of selected component (if applicable): memtest86+-2.01-3 Actual results: GCC 3.4 is used to build memtest86+ because of a GCC or memtest86+ bug. Expected results: Solve real cause of #437701 and rebuild memtest86+ with GCC 4.3 Additional info: This is likely to be a post F9 thing. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/0 ------------------------------------------------------------------------ On 2008-05-14T09:23:18+00:00 Bug wrote: Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/1 ------------------------------------------------------------------------ On 2008-07-27T14:34:59+00:00 Robert wrote: Ping? Maybe Jakub is able to provide some help here? Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/4 ------------------------------------------------------------------------ On 2008-11-01T18:55:40+00:00 Robert wrote: Ping? Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/21 ------------------------------------------------------------------------ On 2008-11-26T02:12:34+00:00 Bug wrote: This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/22 ------------------------------------------------------------------------ On 2008-12-28T20:58:45+00:00 Robert wrote: Warren - any news here? Jakub, can you please help investigating here to solve the issue...I think, you're a good C guy? Adding Jesse that we maybe can get rid of that before Fedora 11? Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/23 ------------------------------------------------------------------------ On 2008-12-29T09:13:49+00:00 Warren wrote: memtest86+ version 2.10 announcement mentioned: Warning : GCC 4.2+ is not yet supported. Thanks to the new pointers over/underflows limitations introduced with that version ! Memtest86+ compiled with GCC 4.2+ will result in a non-working binary (hangs in the first seconds). We're working on a fix but there is really many parts of the code to check & change everywhere. So, please use GCC 4.1 instead. So this isn't our fault. This is heavy lifting that must happen upstream. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/24 ------------------------------------------------------------------------ On 2009-03-11T01:17:36+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/25 ------------------------------------------------------------------------ On 2009-04-14T00:31:36+00:00 Jesse wrote: ... and it looks like it isn't happening for F11. I don't think we'd delay the release for this, moving over to target. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/26 ------------------------------------------------------------------------ On 2009-06-09T09:32:49+00:00 Bug wrote: This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/27 ------------------------------------------------------------------------ On 2009-07-24T21:04:25+00:00 Jarod wrote: I've been asked to look into this, and have been getting up to speed on things intertwined with other tasks, and just started in on some bisection of .o files. I've got a build with all gcc 4.4 build .o files, except for test.o and patn.o, and its already most of the way through a test run (already way further than a pure gcc 4.4 build got). Assuming this pass completes, I'll check if its only one or both of these causing failure, then start looking at the respective source files themselves. Its looking like fixing this won't actually be all that bad. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/28 ------------------------------------------------------------------------ On 2009-07-24T21:22:07+00:00 Jarod wrote: Narrowed the failure down to test.o, looking over its source now... Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/29 ------------------------------------------------------------------------ On 2009-07-24T21:28:56+00:00 Jakub wrote: Does it fail even with -O0 when built with gcc 4.4? Or when built with -O2 -fno-inline -fno-inline-small-functions? If inlining isn't necessary to reproduce the failure, you can as well continue doing the binary search among functions within that file (put half of functions into one file, half in another, remove static and/or add prototypes where needed). Or, if it doesn't fail at -O0, you can use __attribute__((__optimize__(0))) on various functions to compile them non-optimized, while keeping the rest optimized. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/30 ------------------------------------------------------------------------ On 2009-07-24T22:50:13+00:00 Jarod wrote: (In reply to comment #12) > Does it fail even with -O0 when built with gcc 4.4? It works just fine built with -O0 > Or when built with -O2 > -fno-inline -fno-inline-small-functions? Fails the same as before with these options. (stock is -Os, fwiw) > If inlining isn't necessary to > reproduce the failure, you can as well continue doing the binary search among > functions within that file (put half of functions into one file, half in > another, remove static and/or add prototypes where needed). > Or, if it doesn't fail at -O0, you can use __attribute__((__optimize__(0))) on > various functions to compile them non-optimized, while keeping the rest > optimized. I'll give the latter a shot next. Thanks much! Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/31 ------------------------------------------------------------------------ On 2009-07-24T22:59:29+00:00 Jarod wrote: So given that it was failing on test #2, I'd been figuring it was most likely the function addr_tst2() in test.c at fault, so I threw __attribute__((__optimize(0))) on that first, and that indeed the resulting binary does work, so it confirms my suspicion about the guilty function. Still looking over the code, but after a few reads through, I'm not sure what it could be. I'm assuming probably something in the /* Check for overflow */ area is getting optimized out, and that's probably where I'll tinker next, but its now 7pm on Friday night, and the kids are wanting some attention. ;) Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/32 ------------------------------------------------------------------------ On 2009-07-24T23:01:16+00:00 Jarod wrote: Oh, wait... I think I might see it now... But yeah, kid time first... Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/33 ------------------------------------------------------------------------ On 2009-07-24T23:08:47+00:00 Jakub wrote: Relying on undefined signed overflow or something similar? Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/34 ------------------------------------------------------------------------ On 2009-07-24T23:25:12+00:00 Jakub wrote: if (pe + SPINSZ > pe) or if (pe - SPINSZ < pe) or if (pe + SPINSZ*4 > pe) for pe being pointer is obviously all optimized away, pointers in C never wrap around and so for positive SPINSZ all these can be assumed always true. Just use if ((((uintptr_t)pe) + SPINSZ * sizeof (ulong)) > (uintptr_t)pe) and similar. Alternatively you could use -fno-strict-overflow, but it is better to just fix the buggy code. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/35 ------------------------------------------------------------------------ On 2009-07-25T02:47:18+00:00 Jarod wrote: > Just use > if ((((uintptr_t)pe) + SPINSZ * sizeof (ulong)) > (uintptr_t)pe) > and similar. So I tried this (actually, a number of different variations of it too), but its still blowing up the same as before. Must be doing something wrong, or missing something else... Going to table it 'til Monday, but we're close... Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/36 ------------------------------------------------------------------------ On 2009-07-27T20:28:07+00:00 Jarod wrote: In a hurry to try to get this figured out last week, I think I may have stumbled on one of the last few steps... After back-tracking, building with -O0 works, but the attribute addition to addr_tst2() only route is failing, same as before. Going to retrace my steps from there forward now... Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/37 ------------------------------------------------------------------------ On 2009-07-27T21:26:43+00:00 Jarod wrote: Okay... So I was right the first time, adding the attribute to addr_tst2() does work. However, its definitely not the pe comparison that is tripping things up (not to say that it doesn't also need to be fixed). Looking like somehow the BAILR bit is getting optimized out. Here's the minimal working diff: --- rpmbuild/BUILD/memtest86+-2.11/test.c 2008-11-15 19:18:14.000000000 -0500 +++ memtest86+-2.11/test.c 2009-07-27 13:20:34.885941221 -0400 @@ -130,6 +130,15 @@ void addr_tst1() } } +static int bail_check() +{ + if (bail) + return 1; + else + return 0; + +} __attribute__((__optimize__(0))) + /* * Memory address test, own address */ @@ -181,7 +190,9 @@ void addr_tst2() : "D" (p), "d" (pe) ); do_tick(); - BAILR + //BAILR + if (bail_check()) + return; } while (!done); } @@ -243,7 +254,9 @@ void addr_tst2() : "ecx" ); do_tick(); - BAILR + //BAILR + if (bail_check()) + return; } while (!done); } } BAILR is simply: #define BAILR if (bail) return; Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/38 ------------------------------------------------------------------------ On 2009-07-27T21:49:34+00:00 Jarod wrote: Oh fun. The plot thickens. Its not actually addr_tst2() where we're running into trouble. That correlates to Test #1, not #2. I'd assumed it started at Test #1, because Test #0 happens so fast, you never see it on-screen. Test #2, where we're dying, is actually "Moving inversions, ones & zeros", which corresponds to movinvr(). So why the above helps, I dunno... Digging some more... Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/39 ------------------------------------------------------------------------ On 2009-07-27T21:54:37+00:00 Jarod wrote: Oh crap. I think I'm dumb, and don't know what I'm doing with where I'm putting the attribute... Just looked at the docs, yep, I'm Doing It Wrong. Ugh. Ignore the last several comments, lemme redo this the right way. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/40 ------------------------------------------------------------------------ On 2009-07-27T22:20:47+00:00 Jarod wrote: Alright, I'm back on track now... And I have a theory as to what is going on. It seems that gcc thinks 'bail' is always zero, and so the BAILR lines are always optimized out. bail is defined in main.c, then referenced as an extern int in both test.c and config.c. It can be set to non-zero by config.c, but is never touched by test.c. Pretty much any effort I take to NOT optimize something that touches bail within test.c results in a working Test #2, which would explain why my earlier misguided attempts worked, even though I was prodding the wrong function... I don't know if this is a gcc buglet, or if the code is just doing something it really shouldn't... Or if I'm way off and don't know what I'm talking about. ;) Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/41 ------------------------------------------------------------------------ On 2009-07-27T22:37:11+00:00 Jakub wrote: gcc -S -fverbose-asm -Wall -march=i486 -m32 -Os -fomit-frame-pointer -fno-builtin -ffreestanding test.c grep bail test.s | sort | uniq -c 21 cmpl $0, bail #, bail grep BAILR test.c | wc -l 21 So, at least in test.c that doesn't seem to be the case. Have you tried compiling test.c with -march=i486 -Os -fomit-frame-pointer -fno-builtin -fftreestanding -fno-strict-overflow (or s/-fno-strict-overflow/-fwrapv)? Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/42 ------------------------------------------------------------------------ On 2009-07-28T13:45:23+00:00 Jarod wrote: > So, at least in test.c that doesn't seem to be the case. Huh, so it isn't. I'm rather confused why simply un-optimizing the parts that touch bail seems to make a difference then... > Have you tried compiling test.c with -march=i486 -Os -fomit-frame-pointer > -fno-builtin -fftreestanding -fno-strict-overflow I thought I had, but apparently not. Just tried that, and the resulting binary does work as expected. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/43 ------------------------------------------------------------------------ On 2009-07-31T01:16:03+00:00 Jarod wrote: (In reply to comment #18) > > Just use > > if ((((uintptr_t)pe) + SPINSZ * sizeof (ulong)) > (uintptr_t)pe) > > and similar. > > So I tried this (actually, a number of different variations of it too), but > its > still blowing up the same as before. Must be doing something wrong, or missing > something else... Going to table it 'til Monday, but we're close... Finally figured it out... This doesn't work: if ((((uintptr_t)pe) + SPINSZ) > (uintptr_t)pe) But this does: if ((uintptr_t)(pe + SPINSZ) > (uintptr_t)pe) Is that expected? Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/44 ------------------------------------------------------------------------ On 2009-07-31T01:16:54+00:00 Jarod wrote: Moving to rawhide and reassigning. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/45 ------------------------------------------------------------------------ On 2009-08-05T18:45:54+00:00 Jarod wrote: So while casting the result of the addition gets us through test #2 (and 3-6), test #7 still fails spectacularly, for different reasons. Marking the movinvr() function as -O0 gets it working, so I started refactoring the code to try to narrow down where it was going wrong. If I simply move this block (the first do while loop) out of movinvr() and into its own function, called by movinvr(), then a full -Os compiled build works. Without moving the code, it results in test #7 failing. ----8<---- do { /* Check for overflow */ if ((uintptr_t)(pe + SPINSZ) > (uintptr_t)pe) { pe += SPINSZ; } else { pe = end; } if (pe >= end) { pe = end; done++; } if (p == pe ) { break; } /* Original C code replaced with hand tuned assembly code */ /* for (; p < pe; p++) { *p = rand(); } */ asm __volatile__ ( "jmp L200\n\t" ".p2align 4,,7\n\t" "L200:\n\t" "call rand\n\t" "movl %%eax,(%%edi)\n\t" "addl $4,%%edi\n\t" "cmpl %%ebx,%%edi\n\t" "jb L200\n\t" : "=D" (p) : "D" (p), "b" (pe) : "eax" ); do_tick(); BAILR } while (!done); ----8<---- I'm pretty much at a loss why moving that code *unaltered* beyond putting it in a separate function works... Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/46 ------------------------------------------------------------------------ On 2009-08-17T21:01:44+00:00 Jarod wrote: Also works within the loop if movinvr() is tagged with __attribute__((__optimize__(2))). About the only thing left that I can think of is perhaps a register in addition to eax is getting clobbered at some point. Will do a bit of poking in this direction... Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/47 ------------------------------------------------------------------------ On 2009-08-17T21:22:14+00:00 Jarod wrote: Indeed, simply adding edx to the clobber list makes things fully functional without the loop moved external to movinvr(). I'm guessing perhaps the call to rand() somehow stomps on it, since the rest of the asm doesn't use it at all... Going to call it good with this change, flip the switch, and rebuild memtest86+ w/o resorting to gcc34 now. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/48 ------------------------------------------------------------------------ On 2009-09-17T13:44:25+00:00 Jarod wrote: We've been including gcc 4.4-built memtest86+ packages in rawhide for about a month now, haven't seen any new bug reports come in, so I'll go ahead and close this as fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/49 ------------------------------------------------------------------------ On 2009-10-20T16:41:19+00:00 Fedora wrote: memtest86+-4.00-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/memtest86+-4.00-2.fc11 Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/50 ------------------------------------------------------------------------ On 2009-12-25T17:25:52+00:00 Robert wrote: Reopening, because of "BuildRequires: compat-gcc-34" - why do we need this? Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/52 ------------------------------------------------------------------------ On 2009-12-25T17:42:02+00:00 Robert wrote: We don't need this, fixed with memtest86+-4.00-3.fc13. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/53 ------------------------------------------------------------------------ On 2010-01-19T00:57:26+00:00 Fedora wrote: memtest86+-4.00-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. Reply at: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/comments/54 ** Changed in: memtest86+ (Fedora) Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/246412 Title: [intrepid] memtest86+ broken on various hardware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/246412/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
