OpenSolaris

Printable Version Enter a New Search
Bug ID 6777756
Synopsis Panic can occur on guest domain when unplumbing 2 or more HIO enabled vnets on same vswitch
State 10-Fix Delivered (Fix available in build)
Category:Subcategory driver:nxge
Keywords Hybrid | I/O | LDOMs | ldoms-1dot1RR-notes-included | panic | unplumb | vnet
Responsible Engineer Michael Speer
Reported Against
Duplicate Of
Introduced In solaris_nevada
Commit to Fix snv_105
Fixed In snv_105
Release Fixed solaris_nevada(snv_105) , solaris_10u7(s10u7_06) (Bug ID:2170133)
Related Bugs 6405398 , 6805126
Submit Date 28-November-2008
Last Update Date 17-December-2008
Description
The unplumbing of two or more Hybrid I/O enabled vnets that are on the same vswitch in the same domain can cause a panic to occur.  This panic is reproducible.  The expected behavior is to allow the Hybrid I/O enabled vnets to be freely plumbed and unplumbed as needed.  The panic is not seen when using native/VIO-mode vnets.  

The panic message from the console is shown below.

panic[cpu0]/thread=2a10011fca0: BAD TRAP: type=31 rp=2a10011f7c0 addr=0 mmu_fsr=0 occurred in module "unix" due to a NULL pointer dereference

sched: trap type = 0x31
pid=0, pc=0x1054404, sp=0x2a10011f061, tstate=0x4400001603, context=0x0
g1-g7: 38698095f9a3, 3ffffffffffd9b28, 0, 0, 7bb03e40, 0, 2a10011fca0

000002a10011f4e0 unix:die+78 (31, 2a10011f7c0, 0, 0, 2a10011f5a0, 10af800)
  %l0-3: 00000000c0800000 0000000000000031 0000000001000000 0000000000002000
  %l4-7: 0000000001832110 0000000001832000 0000000000000000 0000000000000002
000002a10011f5c0 unix:trap+9e4 (2a10011f7c0, 0, 5, 1c00, 0, 1)
  %l0-3: 0000000000000000 000000000185b240 0000000000000031 0000000000000000
  %l4-7: ffffffffffffe000 0000000000000001 0000000000000005 0000000000000002
000002a10011f710 unix:ktl0+64 (38, 2a10011fca0, 180c000, 0, 0, 300018946c8)
  %l0-3: 000000000180c000 0000000000000000 0000004400001603 0000000001021158
  %l4-7: 0000000000000001 0000000000000023 0000000000000000 000002a10011f7c0
000002a10011f860 nxge:nxge_check_guest_state+18 (30006984278, 2a10011fca0, 0, 38, 49b0, 49b0)
  %l0-3: 0000000000000000 0000000000000000 000002a10001fca0 000002a10001fca0
  %l4-7: 0000000000000002 0000000000000000 0000000000021ebb 00000000018f2c00
000002a10011f910 genunix:callout_execute+b8 (3000184d000, 8000000000000000, 21ebb, bffffffffffd9b28, 21ebb, 3000184e610)
  %l0-3: 0000030007157f08 0000000000000000 000003000184d038 0000001c95e967cd
  %l4-7: 0000000000000000 000003000184e038 0000000000021ebb 00000000000000bb
000002a10011f9c0 genunix:taskq_thread+1a4 (300038379b0, 30003837958, 10003, 38698095f9a3, 2a10011fa8a, 2a10011fa88)
  %l0-3: 0000000000010000 0000030003837980 0000030003837988 000003000383798a
  %l4-7: 0000030003831538 0000000000000000 0000000000000000 0000030003837978

syncing file systems... done
dumping to /dev/dsk/c0d0s1, offset 214827008, content: kernel
100% done: 29486 pages dumped, compression ratio 5.70, dump succeeded
rebooting...
Resetting...
Work Around
Here's a workaround that needs to be verified:

1) Guest domains may only use a single hybrid I/O share from each
   NIU port nxge0 and nxge1.

2) /etc/path_to_inst restrictions, all entries in /etc/path_to_inst
   on the guest domain must be for functions 0 and 1.  Example below:

	"/niu@80/network@bad1" 0 "nxge"
	"/niu@80/network@bad5" 1 "nxge"

If these two conditions are met, the bug will not be encountered.
Comments
N/A