Crunchez vos adresses URL
Rejoignez notre discord
Hébergez vos photos
Affichage des résultats 1 à 2 sur 2
  1. #1

    we experienced false errors in the first MB in test #7 with SMP. There is simple way to reproduce it:

    1. Turn on SMP (F2)
    2. Select test #7 (c 1 3 7 <enter>)
    3. Limit address to 1 MB (2 2 1m <enter> 0)

    But the problem only appears on some systems. Fortunately, I was able to find a bug and fix it.

    Memtest86+ contains USB workaround (USB_WAR). This workaround should prohibit writing to the lowest 1280 Bytes of the memmory by changing the start address from 0 to 1280 (0x500). This checking is done only by one (master) core just before each test starts. This change is not fully propagated to other cores due to a race-condition.

    This can be easily fixed by adding memmory barrier just after this workaround code (patch at the end of the post).

    I am not sure, if this also fixes other (already reported) bugs with SMP and test #7. I was not able to reproduce them.

    Interresting fact: The chances of false detection are much higher with precompiled memtest86+5.01 downloaded form the official site. If I compile it with newer gcc (or use compiled version from Debian repository), the race-condition appears less often.

    --- a/main.c
    +++ b/main.c
    @@ -852,6 +852,7 @@
             cprint(LINE_RANGE, COL_MID+30, " of ");
             aprint(LINE_RANGE, COL_MID+34, v->selected_pages);
    +    s_barrier();
         switch(tseq[test].pat) {

  2. #2

    Just tried the patch, it doesn't fix the freeze symptoms for me.
    It just freezes at Test #7 (Block Move) at the 4096-6114M, as many
    people seem to report on the internet.

    Having a brand new Fujitsu U757, 32GB RAM... single-core mode found no
    errors running for more than 24 h.


Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages