A hibát három különböző, AMD processzoros hardveren sikerült Dillon-nak megvizsgálnia. Ezt a hibát Intel processzoros hardveren soha nem sikerült reprodukálni. A hibát egyrészt azért volt nehéz megfogni, mert a reprodukálásához kezdetben körülbelül 2 napi folyamatos buildworld tesztre volt szükség. Dillon addig ügyeskedett, amíg sikerült egy olyan tesztkörnyezetet összeállítania, amellyel a bug 60 másodperc alatt reprodukálhatóvá vált.
A bug egyszerűen reprodukálható bugos AMD processzoron DragonFly alatt egy make -j 20 buildword-del, vagy hasonló, ciklusban futtatott buildword-del.
Dillon próbálta a problémát BIOS frissítésekkel stb. megoldani, de nem járt sikerrel. A legfrissebb BIOS-okkal is előjött a probléma.
Dillon mielőtt a hardvert nevezte volna meg a probléma okaként, próbált kernelhibát keresni, hátha az okozza a gondot. Nem talált ilyen problémát. Dillon most azt hiszi, hogy a probléma forrásának CPU bugnak kell lennie.
Az érdekes levél elolvasható itt.
- A hozzászóláshoz be kell jelentkezni
- 6886 megtekintés
Hozzászólások
Karácsonyi AMD bug! :-)
>Dillon próbálta mielőtt a hardvert nevezte volna meg a probléma okaként, próbált kernelhibát keresni
Vagy kimaradt pár szó a mondatból vagy rossz a mondatrészek sorrendje.
- A hozzászóláshoz be kell jelentkezni
Helyesen:
Dillon próbálta mielőtt a hardvert nevezte volna meg a probléma okaként, próbált kernelhibát keresni
Egy szóval több volt benne. Fekve, félig alva írtam, csoda, hogy még ilyen is lett :)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ilyenkor Karácsonykor megesik az ilyesmi. :-)
- A hozzászóláshoz be kell jelentkezni
Különösen, ha sok lazacot eszik az ember, mondjuk rozmaringos tepsis burgonyával... ;)
- A hozzászóláshoz be kell jelentkezni
nem gyenge. idejét sem tudom már, mikor volt utoljára amd/intel procibug
- A hozzászóláshoz be kell jelentkezni
Csatlakozom. Azon felül elismerésem, a mukáért.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
- A hozzászóláshoz be kell jelentkezni
heh? egy rakással van mindegyikre
- A hozzászóláshoz be kell jelentkezni
csak erről a többség nem tud, mert általában nem fújják fel úgy, mint legutóbb a phenom-os tlb bug esetében :)
- A hozzászóláshoz be kell jelentkezni
Azok csak specifikacio frissitesek :D , a procinak nincs baja :D
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
bug mindig van, legfeljebb nem derül ki, mert annyira speciális környezetre van szükség, hogy a legtöbb felhasználónak olyanja nincs.
-------------------------
Trust is a weakness...
- A hozzászóláshoz be kell jelentkezni
ah ez 1 jo reklamfogas, most a sok developer developer developer fel fogja tenni a dfbsd-t h reprodukalja es hatha megtetszik nekik a rendszer
varom hogy valaki reprodukalja mas osen
- A hozzászóláshoz be kell jelentkezni
Majd ki fog derulni hogy o benazta el ;)
--
cythoon
- A hozzászóláshoz be kell jelentkezni
enis erre tippelek ;D
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
waaa, vegre itt a karacsonyi kikapcs, es kiderithetem, mert nem megy AMD-n az a szar... hehe :)
- A hozzászóláshoz be kell jelentkezni
OS X-re gondolsz? ;)
btw lenovon a vga problema azota rendbejott?
___
info
- A hozzászóláshoz be kell jelentkezni
Ez nem olyan dolog, hogy kijön egy új microcode, s le van tudva a bug?
tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Amikor én ilyen szöveggel előállok a főnöknek, visszaküld dolgozni, hogy rendes hibaleírást akar, nem rizsát.
Melyik CPU utasítások, milyen feltételek esetén,...
Az, hogy nem melegedett túl a számítógép, meg Mancika sem klikkelt félre, akkor biztos AMD CPU hiba, nem elfogadható.
Utána kiderül, hogy az egésznek semmi köze az AMD, Intel CPU-hoz és totál beégés, meg még egy kártérítési pert is kapnak a nyakukba valótlan állításáért.
- A hozzászóláshoz be kell jelentkezni
Bocs, az eredeti riport részletesebb, csak a hup megfogalmazás volt gagyi.
- A hozzászóláshoz be kell jelentkezni
Kivancsi lennek, hogy mondjuk orajel csokentesnek van -e hatasa a reprodukalhatosagra.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Mivel Matt szerint két teljesen eltérő CPU-n egyformán reprodukálható (12 magos Opteron talán 1,9 GHz, Phenom X4 asszem 3 GHz - a pontos típusok le vannak írva az eredeti levélben) ezért nem tartom esélyesnek. Nem jelterjedési hazárdnak tűnik, inkább valami ravasz corner-case.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Hu de kar volt beleneznem az assemblybe. Mar el is felejtettem milyen tragya az x86 (es sajna meg mindig ez a legnepszerubb asztali gepen). :(
- A hozzászóláshoz be kell jelentkezni
Valoban CPU bug, az AMD megerositette:
http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/14518
--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu
- A hozzászóláshoz be kell jelentkezni
Azt lehet tudni, mely CPU-kat érinti?
tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
az iromány alapján úgy tűnik, egyelőre nem, de az AMD nyilvánosságra fogja hozni csakhamar.
- A hozzászóláshoz be kell jelentkezni
Kíváncsi vagyok, mert egy AMD Phenom II X4 955 van a gépemben. További kérdés, hogy egy microcode update orvosolja-e a hibát. Mert úgy gondolom, ez lenne a microcode lényege.
tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
current known to occur with the AMD Opteron 6168 Id = 0x100f91 Stepping = 1 -- that's the 12-core opteron by the way, and the Phenom II X4 820 (Id = 0x100f42 Stepping = 2).
ez van az eredeti írásban, a többit majd mondja az AMD
- A hozzászóláshoz be kell jelentkezni
tervezel dragonfly-t fejleszteni?
- A hozzászóláshoz be kell jelentkezni
Nem, de gondolom, néhány POP utasítást követő RET esetében semmilyen körülmények között sem egészséges, ha a stack pointer rossz helyre mutat.
tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Tudod, hogy kis 8 bites CPU-n hogyan emulálják a thread-eket?
(lefoglalnak előre X helyet a stacken, utána össze-vissza állítják előre-hátra a stack pointert)
Ez annyira természetes viselkedés, hogy még a valgrind sem jelez problémát.
#include <setjmp.h>
#include <stdio.h>
jmp_buf mainTask, childTask;
void thread1(void);
void thread2_init(void);
void thread2(void);
int main(void) {
if (!setjmp(mainTask)) {
thread2_init(); /* child never returns */ /* yield */
} /* execution resumes after this "}" after first time that child yields */
thread1();
}
void thread1(void) {
for (;;) {
printf("Parent\n");
if (!setjmp(mainTask)) {
longjmp(childTask, 1); /* yield - note that this is undefined under C99 */
}
}
}
void thread2_init (void) {
char space[1000]; /* Reserve enough space for main to run */
space[999] = 1; /* Do not optimize array out of existence */
thread2();
}
void thread2 (void) {
for (;;) {
printf("Child loop begin\n");
if (!setjmp(childTask)) longjmp(mainTask, 1); /* yield - invalidates childTask in C99 */
printf("Child loop end\n");
if (!setjmp(childTask)) longjmp(mainTask, 1); /* yield - invalidates childTask in C99 */
}
/* Don't return. Instead we should set a flag to indicate that main()
should stop yielding to us and then longjmp(mainTask, 1) */
}
- A hozzászóláshoz be kell jelentkezni