VirtualBox panix on OpenSolaris 135 => Fixed in SVN

[Norm Jacobs]

The short version is that when I accidentally switched from a NATed to Bridged network interface on my OpenSolaris build 135 box, I would panic my system each time I brought up a VirtualBox instance. A little closer look and I had accidentally Bridged on my ipsec tunnel interface. I imagine that this panic would occur bridging any point-to-point link.

NOTICE: iptun1016 registered
NOTICE: iptun1016 link up
vboxflt:vboxNetFltSolarisCachePhysAddr: Invalid address size. expected=6 got=4
vboxflt:vboxNetFltSolarisAttachIp4: failed to get MuxFd from MuxId. rc=0 rc2=-2
vboxflt:vboxNetFltSolarisAttachToInterface failed. rc=-3602

panic[cpu2]/thread=ffffff0619bcfc80: 
BAD TRAP: type=d (#gp General protection) rp=ffffff0027be8760 addr=0

VirtualBox:

#gp General protection
pid=2708, pc=0xfffffffffbb3f3d5, sp=0xffffff0027be8850, eflags=0x10246
cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4: 6f8<xmme,fxsr,pge,mce,pae,pse,de>
cr2: fffffd7ffa30a000
cr3: 2b77e8000
cr8: c                                
                                      
        rdi: ffffff0604f8da88 rsi:         40000003 rdx:                1
        rcx:                0  r8: ffffff05ef349e88  r9:                0
        rax:                0 rbx:                1 rbp: ffffff0027be88c0
        r10: 736e6f63692f6572 r11: ffffff060cfd0d28 r12:                0
        r13:         40000003 r14: ffffff0604f8da88 r15:                0
        fsb: fffffd7fff112a00 gsb: ffffff05f6128540  ds:               4b
         es:               4b  fs:                0  gs:                0
        trp:                d err:                0 rip: fffffffffbb3f3d5
         cs:               30 rfl:            10246 rsp: ffffff0027be8850
         ss:               38

ffffff0027be8640 unix:die+10f ()
ffffff0027be8750 unix:trap+43e ()
ffffff0027be8760 unix:cmntrap+e6 ()
ffffff0027be88c0 genunix:fop_close+6d ()
ffffff0027be8910 genunix:ldi_close+85 ()
ffffff0027be8940 vboxflt:vboxNetFltSolarisDetachFromInterface+27 ()
ffffff0027be8970 vboxflt:vboxNetFltOsDisconnectIt+18 ()
ffffff0027be89b0 vboxflt:vboxNetFltPortDisconnectAndRelease+4f ()
ffffff0027be8a10 fffffffff8d3b10b ()
ffffff0027be8a60 vboxdrv:SUPR0ObjRelease+1b9 ()
ffffff0027be8a90 fffffffff8d3ad64 ()
ffffff0027be8ae0 vboxdrv:SUPR0ObjRelease+1b9 ()
ffffff0027be8b10 fffffffff8d0ab30 ()
ffffff0027be8b50 fffffffff8d0adab ()
ffffff0027be8c30 vboxdrv:supdrvIOCtl+d52 ()
ffffff0027be8d00 vboxdrv:VBoxDrvSolarisIOCtl+359 ()
ffffff0027be8d40 genunix:cdev_ioctl+45 ()
ffffff0027be8d80 specfs:spec_ioctl+5a ()
ffffff0027be8e00 genunix:fop_ioctl+7b ()
ffffff0027be8f00 genunix:ioctl+18e ()
ffffff0027be8f10 unix:brand_sys_syscall+1f5 ()

syncing file systems...
 done
dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel
WARNING: /pci@0,0/pci108e,6676@5/disk@0,0 (sd2):
        SYNCHRONIZE CACHE command failed (5)

[Norm Jacobs]

I accidentally opened 6413 when I found out that my attachment was too large. If you need it, I can provide the crashdump upon request.

[Ramshankar Venkataraman]

Does it panic while trying it on the normal physical NIC (not ipsec interface)?

Thanks for reporting, btw.

[Norm Jacobs]

No, it doesn't panic using the physical NIC.

[Ramshankar Venkataraman]

Thank you, I'll have a look. It looks like cleanup failure on the failure exit path.

[Ramshankar Venkataraman]

I've fixed this internally. If you're interested in trying a test driver with the fix let me know (I assume you're using VBox 3.1.4).