Kedves Fórumozók!
Az alábbi témában kérném ötleteiteket/javaslataitokat. A jelenlegi helyzetet, illetve a probléma előéletét igyekszem tömören összefoglalni.
Egy N40L-es HP MicroServerből szeretnék kialakítani egy "szegény ember storage-át" Solaris 11 segítségével.
A gépre a Solaris 11.0-át telepítettem, majd azt a parancssori webes frissítési móddal frissítettem 11.1-re.
Ezután egy leírás alapján be akartam kapcsolni az FC target támogatást. Minden rendben is ment, feltelepítettem a szükséges csomagokat (ekkor automatikusan létrejött egy backup boot environment) a gépben levő QLogic FC kártyához hozzárendeltem a qlt drivert, majd újraindítottam a gépet.
A rendszer rendesen elindult, majd ezután létrehoztam egy ZFS volume-ot, ami felett létrehoztam egy LUNt, hogy később ki lehessen ajánlani.
A leírást nem követtem tovább, hanem itt abbahagytam a folyamatot. Target és host groupokat, és view-kat sem hoztam létre, mert egyelőre nem lenne mivel tesztelni még.
Ezután a következő újraindításnál, és azóta mindig elpánikol a rendszer, NULL pointer dereference jellegű hiba miatt. Már majdnem megjelenik a konzolos login felület, mikor elpánikol, és kidumpolja a memóriát.
A hibajelentés nem a qlt modult jelöli meg ludasként, hanem maga a kernel (unix) szerepel bűnösként. Mivel a probléma az FC-targetes témakör feszegetése után jelentkezett, ezért úgy gondolom, hogy közvetlenül, vagy közvetve ez okozhatja.
Korábban Solaris 11.0 alatt is próbáltam ezt a tutorialt követve FC target módot beállítani, és akkor nem jött elő ilyen hiba. (Talán a 11.1-es upgrade-nek is lehet köze hozzá.)
Most pillanatnyilag úgy tudok egy működő környezetbe eljutni, hogy a GRUB menüjéből az FC targetes csomagok telepítésekor automatikusan létrejött backup BE-t bootolom meg.
(Külön érdekes, hogy ha a backup BE-ből init 6-tal újraindítom a gépet (tehát nem BIOS reset), akkor valamiért elindul az FC targetes BE, és látható néhány warning, amiben arra panaszkodik a qlt driver, hogy a kártya firmware inicializációja nem sikerült (qlt(0): init fw failed...), ellenben hidegen indítva (vagy legalább BIOS resettel), az FC targetes BE mindig elhasal.)
Van valamelyikőtöknek valamilyen ötlete/tapasztalata, hogy hogyan oldjam meg ezt a problémát, vagy hogy legalább a probléma pontos okát meghatározhassam?
Ha esetleg valakit érdekel, be tudom bemásolni pár diagnosztikai tool (fmadm, fmdump, miegymás) kiemenetét.
Update: Egyértelműen a qlt driverre terelődött a gyanú. Lásd ezt a hozzászólást.
Update 2:: Lassan megint előjön az a problémám, hogy a Google kereséseknél a saját HUP-os témám jön elő első helyen. :)
- 9076 megtekintés
Hozzászólások
A panic üzenet kéne (a bennelevő stack dumppal együtt).
Ha soros konzolt használsz, akkor triviális a lementése a konzolról, egyébként jobb esetben a következő sikeres bootnál belerakja a messages fájlba, rosszabb esetben a /var/crash alatt készült core dumpból kinyerhető. Legrosszabb esetben egyik sem... Anno egyszer találkoztam olyan felhasználóval, aki digitális fényképezőgéppel lefotózta a grafikus konzollal felszerelt munkaállomás képernyőjéről a panic üzenetet, mert más módon nem tudta azt onnan lementeni :)
A stack dumpból elég jó közelítéssel lehet tippelni arra, hogy melyik kernel modul környékén érdemes nézelődni, bár a leírás alapján mondjuk igen valószínű, hogy a qlt driver és/vagy az arra épülő többi cucc valamelyike lesz a hunyó.
- A hozzászóláshoz be kell jelentkezni
Sajnos nekem is grafikus konzolom van (soros port egyátalán nincs a gépen), de a dumpból ki tudtam szedni talán pár hasznos infót:
root@space:~# fmadm faulty
--------------- ------------------------------------ -------------- ---------
TIME EVENT-ID MSG-ID SEVERITY
--------------- ------------------------------------ -------------- ---------
Dec 27 09:35:49 f70c1f43-2d0f-69d2-c49d-896d95e37cd2 SUNOS-8000-KL Major
Problem Status : solved
Diag Engine : software-diagnosis / 0.1
System
Manufacturer : unknown
Name : unknown
Part_Number : unknown
Serial_Number : unknown
System Component
Manufacturer : HP
Name : ProLiant-MicroServer
Part_Number : 658553-421
Serial_Number :
Host_ID : 0047e99f
----------------------------------------
Suspect 1 of 1 :
Fault class : defect.sunos.kernel.panic
Certainty : 100%
Affects : sw:///:path=/var/crash/.f70c1f43-2d0f-69d2-c49d-896d95e37cd2
Status : faulted but still in service
Description : The system has rebooted after a kernel panic.
Response : The failed system image was dumped to the dump device. If
savecore is enabled (see dumpadm(1M)) a copy of the dump will be
written to the savecore directory /var/crash.
Impact : There may be some performance impact while the panic is copied to
the savecore directory. Disk space usage by panics can be
substantial.
Action : Use 'fmadm faulty' to provide a more detailed view of this event.
If savecore is not enabled then please take steps to preserve the
crash image. Use 'fmdump -Vp -u
f70c1f43-2d0f-69d2-c49d-896d95e37cd2' to view more panic detail.
Please refer to the associated reference document at
http://support.oracle.com/msg/SUNOS-8000-KL for the latest
service procedures and policies regarding this diagnosis.
root@space:~# fmdump -Vp -u f70c1f43-2d0f-69d2-c49d-896d95e37cd2
TIME UUID SUNW-MSG-ID
Dec 27 2012 09:35:49.243395000 f70c1f43-2d0f-69d2-c49d-896d95e37cd2 SUNOS-8000-KL
TIME CLASS ENA
Dec 27 09:35:39.4171 ireport.os.sunos.panic.dump_available 0x0000000000000000
Dec 27 09:35:36.4681 ireport.os.sunos.panic.dump_pending_on_device 0x0000000000000000
nvlist version: 0
version = 0x0
class = list.suspect
uuid = f70c1f43-2d0f-69d2-c49d-896d95e37cd2
code = SUNOS-8000-KL
diag-time = 1356597349 223078
de = fmd:///module/software-diagnosis
fault-list-sz = 0x1
__case_state = 0x1
topo-uuid = d6b41fa7-6518-c459-f61f-e4f946400c61
fault-list = (array of embedded nvlists)
(start fault-list[0])
nvlist version: 0
version = 0x0
class = defect.sunos.kernel.panic
certainty = 0x64
asru = sw:///:path=/var/crash/.f70c1f43-2d0f-69d2-c49d-896d95e37cd2
resource = sw:///:path=/var/crash/.f70c1f43-2d0f-69d2-c49d-896d95e37cd2
savecore-succcess = 1
dump-dir = /var/crash
dump-files = vmdump.0
os-instance-uuid = f70c1f43-2d0f-69d2-c49d-896d95e37cd2
panicstr = BAD TRAP: type=e (#pf Page fault) rp=fffffffc800a7940 addr=69 occurred in module "unix" due to a NULL pointer dereference
panicstack = unix:die+105 () | unix:trap+153e () | unix:cmntrap+e6 () | unix:ddi_mem_get32+0 () | unix:av_dispatch_autovect+74 () | \
unix:dispatch_hardint+33 () | unix:switch_sp_and_call+13 () | unix:do_interrupt+b6 () | unix:cmnint+ba () | unix:randtick+2 () | \
genunix:mnode_choose+62 () | genunix:flr_choose_one+e8 () | unix:page_create_va_common+15e () | unix:page_create_va+85 () | \
genunix:swap_getapage+10a () | genunix:swap_getpage+90 () | genunix:fop_getpage+c8 () | genunix:anon_private+10f () | \
genunix:segvn_faultpage+71d () | genunix:segvn_fault+b78 () | genunix:as_fault+3e7 () | unix:pagefault+99 () | unix:trap+cd9 () | \
unix:cmntrap+e6 () |
crashtime = 1356597220
panic-time = December 27, 2012 09:33:40 AM CET CET
(end fault-list[0])
fault-status = 0x1
severity = Majorinit
__ttl = 0x1
__tod = 0x50dc0865 0xe81e9b8
Ha esetleg még tudsz mondani pár parancsot, akkor azokkal is meg tudom nézni a dumpokat.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
- A hozzászóláshoz be kell jelentkezni
Nem derül ki belőle egyértelműen, hogy melyik komponens a hunyó.
A support - ha akarná - valószínűleg ki tudná nyomozni, más kérdés, hogy ahhoz (nagyon) fizető vendégnek kéne lenni, és még akkor is kérdéses, hogy akarnák-e igazán.
Én visszamennék a korábbi verzióra, ami nem produkálta a problémát, aztán "majd egyszer" hátha megtalálják és megjavítják.
- A hozzászóláshoz be kell jelentkezni
Időközben landolt nálam egy friss hivatalos patch bundle a 11.1-hez, de annak telepítése után is ugyanúgy összeomlik a rendszer.
Csináltam pár fényképet, a rendszer haláláról, de sajnos a stack trace mindig mintha más lenne, de a hiba (NULL pointer dereference) ugyanaz.
Sajnos nem mindegyik kép lett épp a legmegfelelőbb minőségű. :(
https://docs.google.com/open?id=0B-5ERau05QaZM05yMFllTHJ2dm8
https://docs.google.com/open?id=0B-5ERau05QaZSXFqYlEtOEZ0OVk
https://docs.google.com/open?id=0B-5ERau05QaZVWtXeGFRanhBeGM
https://docs.google.com/open?id=0B-5ERau05QaZb0ROd04zcVFzdU0
https://docs.google.com/open?id=0B-5ERau05QaZcXZZa0FaVVE0Nnc
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
- A hozzászóláshoz be kell jelentkezni
Pedig mind ugyanaz: cmnint/do_interrupt-tól felfele ugyanazt látod.
Jön egy hw interrupt, az av_dispatch_autovect feladata lenne az interrupt handler(ek) meghívása. Hogy a ddi_mem_get32 hogy jön ide, az jó kérdés.
- A hozzászóláshoz be kell jelentkezni
Nekem az a tapasztalatom, hogy a Solaris 11 nem igazan kedveli az AMD processorokat.
Probald meg a kerdeses BE-ben a /lib/libc.so.1-et a /usr/lib/libc/libc_hwcap2.so.1-el fixen helyettesiteni. A /lib/svc/method/fs-root mountolja a libc-t lofi device-al. Ideiglenesen kikommentelheted benne a libc_mount fuggveny hivakozasait.
Remelem erthetoen irtam le, es segit megoldani a gondodat.
Mas:
Keletkezett a panicolos BE-ben crash file? Ha igen, akkor nezd meg a /var/adm/messages-ben a "panic string"-et. Ha jartasabb vagy a Solarisban, akkor megnezheted mdb-vel a crash file-ban is.
Toni
- A hozzászóláshoz be kell jelentkezni
panicstr = BAD TRAP: type=e (#pf Page fault) rp=fffffffc800a7940 addr=69 occurred in module "unix" due to a NULL pointer dereference
Mivel a probléma korábban nem jött elő, ezért nem vagyok benne biztos, hogy neki kellene állnom a különböző .so fájlok cserélgetésének. Később lehet, hogy megpróbálom, ha már végképp nem lesz más ötletem.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
- A hozzászóláshoz be kell jelentkezni
Udv Uram,
en nem ertek mar annyira ezekhez az uj dolgokhoz, de Solarisban mindig csak egy package, egy driver lehetett fenn mert a pkgadd mindig panaszkodott pl. hogy ha ujat akarsz felrakni szedd le a regit. Ez csak ilyen driver hozzarendelgetes modszerrel megy amit akarsz?nem lehet hogy a 11.1ben by default hozna fel a orakulum sajat driveret de te meg megadod neki hogy na megsem azt kene es erre gajdul meg?
Ha jol tudom a boot is smfben van, lehet ott kellene meg turkalni egy kicsit de ez csak egy tipp.
- A hozzászóláshoz be kell jelentkezni
A látszat alapján ez is hivatalos, supportált driver. Az Oracle hivatalos repójában van fent, és onnan szedtem le a leírás alapján.
A hozzárendelés így történt:
# update_drv -d -i 'pciex1077,2432' qlc
# update_drv -a -i 'pciex1077,2432' qlt
11.0-ban így kellett csinálni, és akkor valamiért ment is, most meg 11.1-gyel valamiért nem...
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
- A hozzászóláshoz be kell jelentkezni
"A rendszer rendesen elindult, majd ezután létrehoztam egy ZFS volume-ot, ami felett létrehoztam egy LUNt, hogy később ki lehessen ajánlani."
Szerintem itt van a kutya elásva.
Esetleg ha végig csinálod a leírást akkor is csinálja é illetve ezek szerint míg nem hoztad létre zfs volumot/lunt addig nem volt baja.
- A hozzászóláshoz be kell jelentkezni
Ennek a doksinak a 248. oldal aljatol probalkozz. Ez magyarazatot ad a qlt driver warningjara is.
http://www.google.com/url?sa=t&rct=j&q=qlt%20firmware%20driver%20initia…
- A hozzászóláshoz be kell jelentkezni
Köszi a linket. Hasznos kis pdf.
Azt a warningot, amivel én találkoztam, sajnos nem említi, de a józan paraszti eszem azt súgja, hogy mivel csak init 6-os újraindítás volt, ezért a kártya nem lett resetelve rendesen, és a qlc driver firmware-e maradt betöltve, ezért nem lehet betölteni a (qlt-féle, esetlegesen módosított) firmware-t a reboot után.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
- A hozzászóláshoz be kell jelentkezni
X86-os architektúránál default a fast reboot. Egy 'reboot' vagy 'init 6' ezt fogja eredményezni. SVC-ben kikapcsolható a boot-config service config/fastreboot opciójának false-ra állításával. Ha csak ideiglenesen kell akkor 'reboot -p'.
Szerk: Ha jól tudom akkor panic után is fast rebootot csinál.
- A hozzászóláshoz be kell jelentkezni
Hát, látni láttam, hogy csinált rendes resetet néha pánikkor (olyankor nem dumpolt), meg olyan is volt, hogy a dumpolás után úgy maradt, annak ellenére, hogy kiírta, hogy "Rebooting..."
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
- A hozzászóláshoz be kell jelentkezni
Szerk.: nem ide
- A hozzászóláshoz be kell jelentkezni
Engem az "EHCI hand-off" BIOS-opció szívatott két hónapon át az N36L-emen Solaris 11 alatt: teljesen instabillá tette, és képtelen voltam visszavezetni a hibát bármire is, mert bár nem tudott nem megdögleni, kétszer ugyanúgy megdögleni sem tudott. Amint eljutottam a szisztematikus teszt során ehhez és átbillentettem, azonnal megszűnt minden problémám. Megérhet egy pillantást, nekem két marék hajamba került.
/etc/lib/lu/plugins/lupi_bebasic
- A hozzászóláshoz be kell jelentkezni
Köszönöm a hintet. Az ötletedet követve kikapcsoltam a BIOS-ban, de sajnos ugyanúgy elcrashsel.
Viszont azt megfigyeltem, hogy a stack trace mintha mindig más lenne. :-\
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
- A hozzászóláshoz be kell jelentkezni
Ez már az Oracle-takeover eredménye, a hibaüzeneteket Solaris 10 óta Java-programozókkal íratják és azok a megszokott exception-jeikhez alakították ezeket. ;)
--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”
- A hozzászóláshoz be kell jelentkezni
90%-ra teszem, hogy a qlt driver a ludas.
Nyakatekert módon* be sikerült bootolni a legfrissebb BE-t, amire a friss patch bundle-t is feltettem.
Az
update_drv -d -i 'pciex1077,2432' qltparanccsal töröltem az eszköz társítását a qlt driverrel, és azóta (hideg) újraindítás után sem omlott össze az OS.
*nyakatekert mód: Bebootoltam a még működő BE-t, amiben még a qlc volt társítva a kártyához, és ilyenkor egy quick reboot után hajlandó elindulni az OS (olyankor nem tud betöltődni a kártya firmware-e, és a qlt emiatt nem működik, és nem omlik össze a rendszer).
Update: Közben visszatértem az eredeti frissen telepített 11.0-ás BE-hez is pár pillantás erejéig. Feltettem oda is az FC target modehoz szükséges csomagokat, társítottam a kártyához a qlt drivert végrehajtottam a leírás ugyanazon lépéseit, de valamiért nem romlott el. A biztonság kedvéért meg is frissítettem (nem 11.1-re, csak a 11.0-hoz elérhető frissítéseket tettem fel), de ugyanúgy jó maradt, és nem crashsel el. Érdekes...
Update 2: A fentebb felfrissített 11.0-át (ami teljesen rendben működött qlt-vel, miegymással) frissítettem 11.1-re. A következő (rendes) reboot után elfeküdt ismét. Most már tehát biztos, hogy a qlt driverrel van gond, és a 11.1-től kezdve jön elő. A jelek szerint még nincs javítva ez a bug.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
- A hozzászóláshoz be kell jelentkezni
https://sort.symantec.com/public/documents/sfha/6.0/solaris/productguid…
Workaround: Disable Solaris I/O multipathing on the server to avoid the system panic.
To disable Solaris I/O multipathing on the server
Disable Solaris I/O multipathing:
# stmsboot -d
Reboot the server:
# reboot
Ez egy probat meger, hatha alapon, vagy mar probaltad(?), jo masfajta storage-al kapcsolatban jott ez elo, meg My Oracle szerint Solution offered de lehet csak Hitachi storage fele.
- A hozzászóláshoz be kell jelentkezni
Sajna itt nem az adott gép használ storage-ot, ahol a multipathing gondot okozhatna (tudtommal sehol sem használok multipathingot), hanem a gépből szeretnék majd "storageot" faragni.
A doksiban levő stack trace is más jellegű, mint amivel én találkoztam. Vl szerint valami egy bizonyos hardver interrupt (gondolom a kártya és a qlt driver produkálhatja) kezelése környékén romolhatott el.
Azért köszi, hogy próbálsz segíteni onnan messziről. (Bár most gondolom még itthon vagy.)
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
- A hozzászóláshoz be kell jelentkezni