English is good. $ fmdump -m SUNW-MSG-ID: SUNOS-8000-KL, TYPE: Defect, VER: 1, SEVERITY: Major EVENT-TIME: Thu Jan 17 20:08:28 CST 2013 PLATFORM: System-Product-Name, CSN: System-Serial-Number, HOSTNAME: openindiana SOURCE: software-diagnosis, REV: 0.1 EVENT-ID: 809adc23-290c-c3bb-bcde-c3d4c5c1ebe6 DESC: The system has rebooted after a kernel panic. Refer to http://illumos.org/msg/SUNOS-8000-KL for more information. AUTO-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/openindiana. IMPACT: There may be some performance impact while the panic is copied to the savecore directory. Disk space usage by panics can be substantial. REC-ACTION: If savecore is not enabled then please take steps to preserve the crash image. Use 'fmdump -Vp -u 809adc23-290c-c3bb-bcde-c3d4c5c1ebe6' to view more panic detail. Please refer to the knowledge article for additional information.
With the extended info: $ fmdump -Vp -u 809adc23-290c-c3bb-bcde-c3d4c5c1ebe6 TIME UUID SUNW-MSG-ID Jan 17 2013 20:08:28.919350000 809adc23-290c-c3bb-bcde-c3d4c5c1ebe6 SUNOS-8000-KL TIME CLASS ENA Jan 17 20:08:28.9139 ireport.os.sunos.panic.dump_available 0x0000000000000000 Jan 17 20:08:07.5900 ireport.os.sunos.panic.dump_pending_on_device 0x0000000000000000 nvlist version: 0 version = 0x0 class = list.suspect uuid = 809adc23-290c-c3bb-bcde-c3d4c5c1ebe6 code = SUNOS-8000-KL diag-time = 1358474908 917149 de = fmd:///module/software-diagnosis fault-list-sz = 0x1 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/openindiana/.809adc23-290c-c3bb-bcde-c3d4c5c1ebe6 resource = sw:///:path=/var/crash/openindiana/.809adc23-290c-c3bb-bcde-c3d4c5c1ebe6 savecore-succcess = 1 dump-dir = /var/crash/openindiana dump-files = vmdump.0 os-instance-uuid = 809adc23-290c-c3bb-bcde-c3d4c5c1ebe6 panicstr = BAD TRAP: type=e (#pf Page fault) rp=ffffff003c913840 addr=77 occurred in module "smbsrv" due to a NULL pointer dereference panicstack = unix:die+dd () | unix:trap+17db () | unix:cmntrap+e6 () | smbsrv:smb_mbc_vdecodef+b3 () | smbsrv:smb_mbc_decodef+98 () | smbsrv:smb_dispatch_request+ca () | smbsrv:smb_session_worker+6c () | genunix:taskq_d_thread+b1 () | unix:thread_start+8 () | crashtime = 1358409705 panic-time = January 17, 2013 02:01:45 AM CST CST (end fault-list[0]) fault-status = 0x1 severity = Major __ttl = 0x1 __tod = 0x50f8ae9c 0x36cc2af0 And as I am a n00b to OI, I still don't really know what is going on… Thanks you again, Dave On 2013-01-19, at 4:15 PM, David Scharbach <david.scharb...@mac.com> wrote: > $ fmdump > TIME UUID SUNW-MSG-ID EVENT > Jan 17 20:08:28.9193 809adc23-290c-c3bb-bcde-c3d4c5c1ebe6 SUNOS-8000-KL > Diagnosed > $ uptime > 16:12pm up 1 day 20:04, 2 users, load average: 0.08, 0.14, 0.21 > > Given today is the 19th and such, I think that timestamp on the fmdump is > near when the OI server last crashed. I don't know what the event means. > Can you let me know? > > Cheers, > > Dave > > > On 2013-01-19, at 12:30 PM, Aurélien Larcher <aurelien.larc...@gmail.com> > wrote: > >> Hi, >> Has someone mentioned using 'fmdump' ? >> >> With this tool I discovered that I had issues with an unreliable disk >> controller on my workstation with the consequence of OI freezing approx. >> every 2months. >> In my case ZFS is getting the fault and standby until resolution of the >> issue, thus yielding an indefinite wait for disk I/O to resume. >> Best >> >> Aurelien >> >> >> On Sat, Jan 19, 2013 at 3:19 PM, Reginald Beardsley >> <pulask...@yahoo.com>wrote: >> >>> One time when I happened to look, I saw that the Ultra 60 I used at work >>> had been up for over 18 months. >>> >>> If a sys admin told me he wanted to reboot a system once a week, "just in >>> case" he'd be looking for a new job very soon or else sent back to the PC >>> support pool. >>> >>> BTW The reason that 11/780 era admins did not want to shut machines down >>> was primarily the problems posed by hundreds, if not thousands of >>> mechanical connectors some of which if allowed to cool would lose contact. >>> The cure was simple, but tedious, you went around reseating circuit boards >>> and cabling and powered up again. There are a lot of boards and cables in a >>> well populated 11/780 especially if its got an FPS-120B, Gould-DeAnza >>> graphics processor and a Versatec plotter attached along w/ the usual disk >>> and tape drives. >>> >>> One summer weekend in Dallas, my group moved across town. So our >>> workstations spent the day in a moving van probably at 130+ F. Monday >>> morning several would not boot until I went around and reseated the disk >>> drive cables. >>> >>> Voodoo has no place in computing. >>> >>> Have Fun! >>> Reg >>> >>> _______________________________________________ >>> OpenIndiana-discuss mailing list >>> OpenIndiana-discuss@openindiana.org >>> http://openindiana.org/mailman/listinfo/openindiana-discuss >>> >> >> >> >> -- >> ------------------------------------------------------------------------------- >> LARCHER Aurélien | KTH, School of Computer Science and >> Communication >> Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 5 >> Mob.: +46 (0) 7 09 46 40 17 | 100 44 Stockholm, SWEDEN >> ------------------------------------------------------------------------------- >> Praise the Caffeine embeddings ... >> _______________________________________________ >> OpenIndiana-discuss mailing list >> OpenIndiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss > > > _______________________________________________ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss