[OpenIndiana-discuss] kernel panic, and how to work with kernel panic:

[Toomas Soome]

> On 1. Feb 2025, at 13:12, Toomas Soome via openindiana-discuss <openindiana-discuss at openindiana.org> wrote:
> 
> 
> 
>> On 1. Feb 2025, at 10:13, Paul Graff via openindiana-discuss <openindiana-discuss at openindiana.org> wrote:
>> 
>> Hi, openindiana running on machine here is an i5 with 8 GiB ddr3 memory
>> (recently tested with memtest). openindiana on hdd drive was initially
>> in Lenovo M90p with 4 GiB memory.
>> 
>> I had just '# pkg update -vvv', had another tab open in Mate terminal
>> and attempted to envoke TOR, in order to see errors i'm dealing with for
>> TOR setup. Decided to open Firefox to create email note and then machine
>> had kernel panic and powercycled.
>> 
>> Looking in /var/adm a line:
>> DESC: The system has rebooted after a kernel panic.  Refer to
>> http://illumos.org/msg/SUNOS-8000-KL for more information.
>> Suggested website:
>> https://illumos.org/msg/SUNOS-8000-KL
>> I ticked 'back to main page' and attempted to fill in the "Message ID"
>> again...same result.
>> -
>> /var/adm$ cat messages | grep 'savecore'
>> 
>> Feb  1 01:27:33 M90p-openindiana savecore: [ID 570001 auth.error] reboot
>> after panic: assertion failed: dmu_buf_hold_array(os, object, offset,
>> size, 0, ((char *)(uintptr_t)__func__), &numbufs, &dbp) == 0 (0x5 ==
>> 0x0), file: ../../common/fs/zfs/dmu.c, line: 1111
>> Feb  1 01:27:34 M90p-openindiana savecore: [ID 440241 auth.error] Panic
>> crashdump pending on dump device but dumpadm -n in effect; run
>> savecore(8) manually to extract. Image UUID
>> ffdd0fec-aae8-42ca-9e6b-6c6c6bc27fd3.
>> Feb  1 01:27:53 M90p-openindiana AUTO-RESPONSE: The failed system image
>> was dumped to the dump device.  If savecore is enabled (see dumpadm(8))
>> a copy of the dump will be written to the savecore directory .
>> Feb  1 01:27:53 M90p-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.
>> Feb  1 01:27:53 M90p-openindiana REC-ACTION: If savecore is not enabled
>> then please take steps to preserve the crash image.
>> -
>> /var/adm$ fmdump -Vp -u ffdd0fec-aae8-42ca-9e6b-6c6c6bc27fd3
>> TIME UUID                                 SUNW-MSG-ID
>> Feb 01 2025 01:27:53.282168000 ffdd0fec-aae8-42ca-9e6b-6c6c6bc27fd3
>> SUNOS-8000-KL
>>  TIME CLASS                                 ENA
>>  Feb 01 01:27:34.4039 ireport.os.sunos.panic.dump_pending_on_device
>> 0x0000000000000000
>> nvlist version: 0
>>        version = 0x0
>>        class = list.suspect
>>        uuid = ffdd0fec-aae8-42ca-9e6b-6c6c6bc27fd3
>>        code = SUNOS-8000-KL
>>        diag-time = 1738394872 391362
>>        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/M90p-openindiana/.ffdd0fec-aae8-42ca-9e6b-6c6c6bc27fd3
>>                resource =
>> sw:///:path=/var/crash/M90p-openindiana/.ffdd0fec-aae8-42ca-9e6b-6c6c6bc27fd3
>>                savecore-succcess = 0
>>                os-instance-uuid = ffdd0fec-aae8-42ca-9e6b-6c6c6bc27fd3
>>                panicstr = assertion failed: dmu_buf_hold_array(os,
>> object, offset, size, 0, ((char *)(uintptr_t)__func__), &numbufs, &dbp)
>> == 0 (0x5 == 0x0), file: ../../common/fs/zfs/dmu.c, line: 1111
>>                panicstack = fffffffffba53911 () | zfs:dmu_write+f2 ()
>> | zfs:zvol_strategy+32f () | genunix:bdev_strategy+5c () |
>> specfs:spec_startio+8e () | specfs:spec_pageio+20 () |
>> genunix:fop_pageio+43 () | genunix:swap_putapage+382 () |
>> genunix:swap_putpage+26d () | genunix:fop_putpage+52 () |
>> genunix:segvn_sync+24c () | genunix:as_ctl+166 () | genunix:memcntl+280
>> () | unix:brand_sys_syscall+1fe () |
>>                crashtime = 1738394693
>>                panic-time = February  1, 2025 at 01:24:53 AM CST CST
>>        (end fault-list[0])
>>        fault-status = 0x1
>>        severity = Major
>>        __ttl = 0x1
>>        __tod = 0x679dccf9 0x10d18ac0
>> -
>> Is this something that can be fixed?
>> Without creating any more confusion, what should I do to approach
>> solving this?
>> Where should I look for information (possible read more handbook)?
>> 
> 
> We have seen this panic, but we do not have yet fix for it. 
> 

if you could run this in separate terminal window:

dtrace -n 'sdt:zfs::set-error /arg0 == EIO/ {stack();}’

and try to see if you will get another panic;)

rgds,
toomas