[OmniOS-discuss] kernel panic "kernel heap corruption detected" when creating zero eager disks

[Richard Elling]

On Mar 26, 2015, at 11:24 PM, wuffers <moo at wuffers.net> wrote:

>> 
>> So here's what I will attempt to test:
>> - Create thin vmdk @ 10TB with vSphere fat client: PASS 
>> - Create lazy zeroed vmdk @ 10 TB with vSphere fat client: PASS
>> - Create eager zeroed vmdk @ 10 TB with vSphere web client: PASS! (took 1 hour)
>> - Create thin vmdk @ 10TB with vSphere web client: PASS
>> - Create lazy zeroed vmdk @ 10 TB with vSphere web client: PASS
> 
> Additionally, I tried:
> - Create fixed vhdx @ 10TB with SCVMM (Hyper-V): PASS (most likely no primitives in use here - this took slightly over 3 hours)

is compression enabled?


  -- richard

>  
> Everything passed (which I didn't expect, especially the 10TB eager zero).. then I tried again on the vSphere web client for a 20TB eager zero disk, and I got another kernel panic altogether (no kmem_flags 0xf set, unfortunately).
> 
> Mar 27 2015 01:09:33.664060000 2e2305c2-54b5-c1f4-aafd-fb1eccc982dd SUNOS-8000-KL
> 
>   TIME                 CLASS                                 ENA
>   Mar 27 01:09:33.6307 ireport.os.sunos.panic.dump_available 0x0000000000000000
>   Mar 27 01:08:30.6688 ireport.os.sunos.panic.dump_pending_on_device 0x0000000000000000
> 
> nvlist version: 0
>         version = 0x0
>         class = list.suspect
>         uuid = 2e2305c2-54b5-c1f4-aafd-fb1eccc982dd
>         code = SUNOS-8000-KL
>         diag-time = 1427432973 633746
>         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/unknown/.2e2305c2-54b5-c1f4-aafd-fb1eccc982dd
>                 resource = sw:///:path=/var/crash/unknown/.2e2305c2-54b5-c1f4-aafd-fb1eccc982dd
>                 savecore-succcess = 1
>                 dump-dir = /var/crash/unknown
>                 dump-files = vmdump.2
>                 os-instance-uuid = 2e2305c2-54b5-c1f4-aafd-fb1eccc982dd
>                 panicstr = BAD TRAP: type=d (#gp General protection) rp=ffffff01eb72ea70 addr=0
>                 panicstack = unix:real_mode_stop_cpu_stage2_end+9e23 () | unix:trap+a30 () | unix:cmntrap+e6 () | genunix:anon_decref+35 () | genunix:anon_free+74 () | genunix:segvn_free+242 () | genunix:seg_free+30 () | genunix:segvn_unmap+cde () | genunix:as_free+e7 () | genunix:relvm+220 () | genunix:proc_exit+454 () | genunix:exit+15 () | genunix:rexit+18 () | unix:brand_sys_sysenter+1c9 () |
>                 crashtime = 1427431421
>                 panic-time = Fri Mar 27 00:43:41 2015 EDT
>         (end fault-list[0])
> 
>         fault-status = 0x1
>         severity = Major
>         __ttl = 0x1
>         __tod = 0x5514e60d 0x2794c060
> 
> Crash file:
> https://drive.google.com/file/d/0B7mCJnZUzJPKT0lpTW9GZFJCLTg/view?usp=sharing
> 
> It appears I can do thin and lazy zero disks of those sizes, so I will have to be satisfied to use those options as a workaround (plus disabling WRITE_SAME from the hosts if I really wanted the eager zeroed disk) until some of that Nexenta COMSTAR love is upstreamed. For comparison sake, provisioning a 10TB fixed vhdx took approximately 3 hours in Hyper-V, while the same provisioning in VMware took about 1 hour. So we can say that WRITE_SAME accelerated the same job by 3x.
> 
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20150330/a22ae797/attachment-0001.html>