JAVA program Ryzen 2500U fagyás MEGOLDVA

Java

Üdv! A Jogkódex nevű program Ryzen 2500U procival kifagy. Ugyanez a program Athlon 200GE alatt vígan dolgozik. Próbált JAVA verziók: Oracle 1.8 OpenJDK 11 Kernelek: 5.4 ; 5.8 Disztrók: Linux Mint 19.3; LMDE A logokban nincs nyoma a fagyásnak. Terminálból indítva hibaüzenet nincs. Kérdés, hogyan tudom kideríteni a fagyás okát?

 

Megoldás: BIOS update megoldotta. Kellett hozzá azbest és Polesz segítsége. Hirensbootcd-vel, amit a Rufus-szal írtam ki, frissíteni tudtam a BIOS-t, és lám elindult a csoda..

  • 688 megtekintés

( hory v | 2020. 10. 15., cs – 12:54 )

esetleg megbizhatatlan hardver nyug? java elegge ki tudja porgetni a procit indulaskor.

memtest, cputest, ilyesmi volt mar?

( Ebcsont | 2020. 10. 15., cs – 13:04 )

Memtest, cputest még nem volt, már csak amiatt se mert az ABEVjava és még egy javás progi nem produkál ilyet.

( uid_4263 v | 2020. 10. 15., cs – 13:08 )

Messziről megmondom hogy nincs az az isten 2020-ban, hogy pont ezen a procin egy adott Java app ne futna, egy másikon meg igen. Minden ugyanaz, csak a procit cseréled ki a gépben, vagy mi az összehasonlítás alapja?

Az egyik egy laptop, a másik egy asztali gép. Ugyanazt a progit próbálom beizzítani egy elvileg erősebb vason. A baj az, hogy nincs log amin el tudnék indulni. Elvileg ez az indítószkript:

#!/bin/sh
cd $( dirname $0 )/packages
LIBPATH=.
JAVA_HOME=../jre
PATH=$JAVA_HOME/bin:$PATH
CLASSPATH=$JAVA_HOME/lib/rt.jar
CLASSPATH=$CLASSPATH:$LIBPATH/iText-5.0.5.jar
CLASSPATH=$CLASSPATH:$LIBPATH/jaxmexs-0.5.2.jar
CLASSPATH=$CLASSPATH:$LIBPATH/jcifs-1.3.15.jar
CLASSPATH=$CLASSPATH:$LIBPATH/jdom.jar
CLASSPATH=$CLASSPATH:$LIBPATH/lucene.jar
CLASSPATH=$CLASSPATH:$LIBPATH/sqlitejdbc-v056.jar
CLASSPATH=$CLASSPATH:$LIBPATH/PDFRenderer.jar
CLASSPATH=$CLASSPATH:$LIBPATH/hvggui2z.jar
$JAVA_HOME/bin/java -Xmx512M -XX:MaxPermSize=300m -cp $CLASSPATH enter.AppStart /ini=../args.ini /i >/dev/null &

( KGer | 2020. 10. 15., cs – 13:50 )

1. ha az egyik proci sokkal gyorsabb akkor szoktak olyan hibák előjönni hogy rossz thread kezelés miatt összeakad és deadlock-ba kerül

fagyás alatt mit értesz? a process fut vagy meghal? stacktrace?

ha nyomsz rá egy strace-t mit ír ki hol akad el? ez időben változik vagy tényleg deadlock?

2. illetve simán lehet hogy vhogy mégis más a classpath, más verziójú jar-t tölt be vmelyik lib-ből és összeakad

 

ezek a legszebb hibák :)

+1

kill -3 PID hatására a Java az stdout-ra (ami akárhová is lehet irányítva, meg kell keresni) csinál egy thread dumpot. Ha klasszik fagyás, azaz deadlock van, az ebben látszani fog. Lehetséges, hogy időzítések miatt a másik procin nem jött elő egy ilyen potenciális hiba.

 

Próbálkozásképpen a processzt érdemes lehet egy magra korlátozni, hátha bejön.

Az nem Java thread deadlock lesz... Esetleg a guit tudhatja valahogy lockolni? Ssh szervert ha inditasz, az is lehal? Nekem akkor tudta a guit befagyasztani, ha popup context menu felugrasara tettem breakpointot. Ez valahogy teljes osszeakadast csinalt az X szintjen. Sshrol kellett kiloni a processzt.

Ssh nincs a gépen még.

"Nekem akkor tudta a guit befagyasztani, ha popup context menu felugrasara tettem breakpointot. Ez valahogy teljes osszeakadast csinalt az X szintjen."

Valami hasonló történhet, mert ahol működik ott felugrik a bejelentkezési ablak az indítás után, ezen meg nem.

Ez is simán lehet, de én mégis inkább arra gondolok, hogy a kompozitorok néha nem kezelik jól a Java-s alkalmazásokat, és mivel a két kérdéses gépen eltér a driver, ezért az egyiken fagy, a másikon nem. Én kikapcsolt kompozitálással is megnézném.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Igen, nem jól fejeztem ki magam. Az amdgpu driverben viszont eltérő kódbázist használhatnak, mivel eltérő GPU család, generációról van szó, ami x verziós mesa-val vagy valami kompozitoros megoldással simán összeakadhat egyik esetben, míg a másikban nem. Azért mondom, a kérdező kapcsolja ki a kompozitort, csak egy tipp, ingyen van megpróbálni. Nem is olyan régen pl. a KDE-ben volt egy bug, hogy a Java-s alkalmazások nem jelenítettek meg semmit kompozitálással, pl. AbevJava helyén egy fekete ablak volt, kikapcsolt kompozitorral megjavult. Egy próbát megér, legfeljebb a kollégánál nem ez lesz a helyzet.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( uid_21239 | 2020. 10. 15., cs – 19:12 )

Ha fizettek erte, akkor reklamaljatok.

Letoltottem a cuccot, java 6 van mellecsomagolva. Kicsit se regi.... 

Esetleg megprobalhatnad futtatni java 8-cal.

( azbest | 2020. 10. 16., p – 21:08 )

Rákeresve, hogy "java freeze ryzen", azért a google dob pár találatot.

https://bugs.dragonflybsd.org/issues/3131
kommentekből az látszik, hogy csak az első generációsoknál fordul elő. Igen a 2500u még első generációs zen-re épül. És hogy tán microcode update kellhet hozzá (két éve volt).

https://www.digitaltrends.com/computing/ryzen-amd-bios-fix-fma3-crash/
máshol is szóba került hasonló

-> bios frissítéssel hogy állsz?

-> amd64-microcode csomag van fenn? Friss?

( KGer | 2020. 10. 17., szo – 22:49 )

ez egy jó kis hiba volt, minden developer álma