On 2/1/11 8:40 AM, Monthadar Al Jaberi wrote:

I hope I am on the write place, second try...

I have written a module that loads fake wifi devices (wtap?) and
distributes packets between them. For now I use route command to route
packets between them from upper layers (TCP,...).
I want to take it to next step and create jails with VNET. I started
reading Julian Elischer's "Vimage: what is it?" and he says that if I
am writing hardware drivers I dont need to make any changes when I
enable VIMAGE option on the kernel, because each one will have their
own stack.

I can give a more detailed explanation on how my module works. But for
now I get a panic when calling if_alloc() when using option VIMAGE.

Thank you,

while this  was true to some extent it i snot 100% true now.
during allocation we now try to have separate interface indexes per vimage
which means that the setup routines do need to know the current vnet.

it looks like wtap_ioctl or wtap_attach should have the following:
(copied from the tun driver)

this should not be needed from real hardware based drivers as far as I can tell.

        /* find any existing device, or allocate new unit number */
        i = clone_create(&tunclones, &tun_cdevsw, &u, dev, 0);
        if_clone_create(name, namelen, NULL);

My setup:
FreeBSD Current 201010 guest on VirtualBox on Ubuntu 10.04.

Kernel page fault with the following non-sleepable locks held:
exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0fc8284) locked @
KDB: stack backtrace:
db_trace_self_wrapper(c0cf3cdb,1,0,0,0,...) at db_trace_self_wrapper+0x26
kdb_backtrace(19e,1,ffffffff,c0f9b194,c2fc9a1c,...) at kdb_backtrace+0x2a
_witness_debugger(c0cf6408,c2fc9a30,4,1,0,...) at _witness_debugger+0x25
witness_warn(5,0,c0d2c479,3,c4070d48,...) at witness_warn+0x1fe
trap(c2fc9abc) at trap+0x195
calltrap() at calltrap+0x6
--- trap 0xc, eip = 0xc0970999, esp = 0xc2fc9afc, ebp = 0xc2fc9b1c ---
ifindex_alloc_locked(c0d003cf,c2fc9b36,19e,19e,c15ab714,...) at
if_alloc(47,c4085a16,3,c0de9614,c32aa780,...) at if_alloc+0x85
wtap_attach(c31a7800,c40857c0,0,4,0,...) at wtap_attach+0x29
new_wtap(c32aa780,0,c2fc9bf0,c083ac9b,c3cbb200,...) at new_wtap+0x9b
wtap_ioctl(c3cbb200,80045701,c31edaa0,1,c3f90b40,...) at wtap_ioctl+0x36
devfs_ioctl_f(c3cfe3b8,80045701,c31edaa0,c3185d00,c3f90b40,...) at
kern_ioctl(c3f90b40,3,80045701,c31edaa0,fc9cec,...) at kern_ioctl+0x20d
ioctl(c3f90b40,c2fc9cec,c2fc9d28,c0cf5783,0,...) at ioctl+0x134
syscallenter(c3f90b40,c2fc9ce4,c2fc9ce4,0,0,...) at syscallenter+0x263
syscall(c2fc9d28) at syscall+0x34
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28181203, esp =
0xbfbfec3c, ebp = 0xbfbfec58 ---

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x18
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc0970999
stack pointer           = 0x28:0xc2fc9afc
frame pointer           = 0x28:0xc2fc9b1c
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1203 (ioctl)
panic: from debugger
cpuid = 0
Uptime: 21s
Physical memory: 495 MB
Dumping 55 MB: 40 24 8

freebsd-virtualization@freebsd.org mailing list
To unsubscribe, send any mail to 

Reply via email to