Solaris 11.1 kernel pánik

 ( wowbagger | 2012. december 28., péntek - 1:50 )

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. :)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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ó.

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

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.

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

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.

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

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

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 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 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.

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

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.

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

Szerk.: nem ide

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

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

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!”

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' qlt paranccsal 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

https://sort.symantec.com/public/documents/sfha/6.0/solaris/productguides/html/sf_notes/ch01s09s02s03.htm

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.

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