ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző Linux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
AMD CPU hibába botlott Matthew Dillon?Matthew Dillon, a Dragonfly BSD projekt alapítója és vezetője egy érdekes probléma leírását és lehetséges megkerülését tette közzé karácsony első napján. Mint azt levelében írja, jóval több mint egy éve küzd ezzel a problémával és az elmúlt két hónapban keményen dolgozott azon, hogy a végére járjon. A probléma kizárólag a gcc 4.4.7-ben található cc1-gyel jött elő és kizárólag AMD processzoron. Ugyanaz a kód ugyanazon az operációs rendszer környezetben Intel hardveren nem okoz hibát. Mivel a kód ugyanazon paraméterekkel történő ismételt futtatásával nem sikerült a hibát reprodukálni konzisztensen, Dillon azt feltételezte, hogy a hiba nem magában a cc1-ben van. 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.
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 10% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 18% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 27% Egyáltalán nem ismerem. 34% Csak az eredmény érdekel. 7% Összes szavazat: 562
Új felhasználók
InformációKövess minket!Partnerünk |
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.
Helyesen:
Egy szóval több volt benne. Fekve, félig alva írtam, csoda, hogy még ilyen is lett :)
--
trey @ gépház
Ilyenkor Karácsonykor megesik az ilyesmi. :-)
Különösen, ha sok lazacot eszik az ember, mondjuk rozmaringos tepsis burgonyával... ;)
nem gyenge. idejét sem tudom már, mikor volt utoljára amd/intel procibug
Csatlakozom. Azon felül elismerésem, a mukáért.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.
heh? egy rakással van mindegyikre
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 :)
[ NeoCalc - Earnings Calculator for NeoBux ]Azok csak specifikacio frissitesek :D , a procinak nincs baja :D
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
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...
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
--
http://blog.sartek.net | https://twitter.com/sartek
Majd ki fog derulni hogy o benazta el ;)
--
cythoon
enis erre tippelek ;D
--
NetBSD - Simplicity is prerequisite for reliability
waaa, vegre itt a karacsonyi kikapcs, es kiderithetem, mert nem megy AMD-n az a szar... hehe :)
OS X-re gondolsz? ;)
btw lenovon a vga problema azota rendbejott?
___
info
Ez nem olyan dolog, hogy kijön egy új microcode, s le van tudva a bug?
tr [:lower:] [:upper:] <<<locsemegeLOCSEMEGE
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.
Bocs, az eredeti riport részletesebb, csak a hup megfogalmazás volt gagyi.
Kivancsi lennek, hogy mondjuk orajel csokentesnek van -e hatasa a reprodukalhatosagra.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
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
Hu de kar volt beleneznem az assemblybe. Mar el is felejtettem milyen tragya az x86 (es sajna meg mindig ez a legnepszerubb asztali gepen). :(
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
Azt lehet tudni, mely CPU-kat érinti?
tr [:lower:] [:upper:] <<<locsemegeLOCSEMEGE
az iromány alapján úgy tűnik, egyelőre nem, de az AMD nyilvánosságra fogja hozni csakhamar.
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:] <<<locsemegeLOCSEMEGE
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
tervezel dragonfly-t fejleszteni?
--
http://blog.sartek.net | https://twitter.com/sartek
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:] <<<locsemegeLOCSEMEGE
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) */
}