Hi! It looks fine to me.
Thanks, -adrian On 7 July 2013 02:30, Craig Rodrigues <rodr...@crodrigues.org> wrote: > Hi, > > I tried running PC-BSD 9.1 on an HP Elitebook 8460p laptop ( > http://h10010.www1.hp.com/wwpc/pscmi...oks/8460p.html ). > See the screenshot I posted here: > > http://forums.pcbsd.org/showthread.php?t=20001 > > In PC-BSD, the default kernel comes with VIMAGE enabled in the kernel > config. > > The problem I encountered seems to be caused by problems > with the FreeBSD kernel with VIMAGE + bluetooth. > > I've seen similar threads being posted here: > > "VIMAGE crashes on 9.x with hotplug net80211 devices" > http://lists.freebsd.org/pipermail/freebsd-hackers/2012-October/040784.html > > "Panic in netgraph with VIMAGE" > http://lists.freebsd.org/pipermail/freebsd-virtualization/2009-May/000325.html > > > > Doing some kernel debugging, I got this stack trace: > > #0 doadump (textdump=<value optimized out>) at pcpu.h:234 > #1 0xffffffff80923e86 in kern_reboot (howto=260) at > /usr/home/rodrigc/freebsd/9/sys/kern/kern_shutdown.c:449 > #2 0xffffffff80924387 in panic (fmt=0x1 <Address 0x1 out of bounds>) at > /usr/home/rodrigc/freebsd/9/sys/kern/kern_shutdown.c:637 > #3 0xffffffff80ce97f0 in trap_fatal (frame=0xc, eva=<value optimized out>) > at /usr/home/rodrigc/freebsd/9/sys/amd64/amd64/trap.c:879 > #4 0xffffffff80ce9b51 in trap_pfault (frame=0xffffff811e2b7700, usermode=0) > at /usr/home/rodrigc/freebsd/9/sys/amd64/amd64/trap.c:795 > #5 0xffffffff80cea104 in trap (frame=0xffffff811e2b7700) at > /usr/home/rodrigc/freebsd/9/sys/amd64/amd64/trap.c:463 > #6 0xffffffff80cd3433 in calltrap () at > /usr/home/rodrigc/freebsd/9/sys/amd64/amd64/exception.S:228 > #7 0xffffffff81cc0bbd in ng_make_node_common (type=0xffffffff81cb6000, > nodepp=0xfffffe0124d9c310) > at > /usr/home/rodrigc/freebsd/9/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:669 > #8 0xffffffff81cb320e in ubt_attach (dev=0xfffffe01041f1d00) > at > /usr/home/rodrigc/freebsd/9/sys/modules/netgraph/bluetooth/ubt/../../../../netgraph/bluetooth/drivers/ubt/ng_ubt.c:461 > #9 0xffffffff80956c9c in device_attach (dev=0xfffffe01041f1d00) at > device_if.h:180 > #10 0xffffffff8078a61e in usb_probe_and_attach (udev=0xfffffe0124580000, > iface_index=<value optimized out>) > at /usr/home/rodrigc/freebsd/9/sys/dev/usb/usb_device.c:1183 > #11 0xffffffff80792c4e in uhub_explore (udev=0xfffffe000900c000) at > /usr/home/rodrigc/freebsd/9/sys/dev/usb/usb_hub.c:272 > #12 0xffffffff80792c74 in uhub_explore (udev=0xfffffe0007ee2000) at > /usr/home/rodrigc/freebsd/9/sys/dev/usb/usb_hub.c:286 > #13 0xffffffff8077ce46 in usb_bus_explore (pm=<value optimized out>) at > /usr/home/rodrigc/freebsd/9/sys/dev/usb/controller/usb_controller.c:359 > #14 0xffffffff80796da3 in usb_process (arg=<value optimized out>) at > /usr/home/rodrigc/freebsd/9/sys/dev/usb/usb_process.c:169 > #15 0xffffffff808f1cef in fork_exit (callout=0xffffffff80796cd0 > <usb_process>, arg=0xffffff8001c3cdb0, frame=0xffffff811e2b7b00) > at /usr/home/rodrigc/freebsd/9/sys/kern/kern_fork.c:988 > #16 0xffffffff80cd395e in fork_trampoline () at > /usr/home/rodrigc/freebsd/9/sys/amd64/amd64/exception.S:602 > #17 0x0000000000000000 in ?? () > > > and the error occurred on line 669 in ng_base.c: > > #7 0xffffffff81cc0bbd in ng_make_node_common (type=0xffffffff81cb6000, > nodepp=0xfffffe0124d9c310) > at > /usr/home/rodrigc/freebsd/9/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:669 > 669 node->nd_ID = V_nextID++; /* 137/sec for 1 year before wrap */ > (kgdb) l > 664 > 665 /* Get an ID and put us in the hash chain. */ > 666 IDHASH_WLOCK(); > 667 for (; { /* wrap protection, even if silly */ > 668 node_p node2 = NULL; > 669 node->nd_ID = V_nextID++; /* 137/sec for 1 year before wrap */ > 670 > 671 /* Is there a problem with the new number? */ > 672 NG_IDHASH_FIND(node->nd_ID, node2); /* already taken? */ > 673 if ((node->nd_ID != 0) && (node2 == NULL)) { > > > It turns out that when VIMAGE is defined in the kernel, V_nextID is not an > int any more, > it is a macro. line 669 expands to something that looks like: > > node->nd_ID = (*(__typeof(vnet_entry_nextID)*) > (((((__curthread())->td_vnet))->vnet_data_base) + > (uintptr_t)&vnet_entry_nextID))++; > > On my system, td_vnet was not initialized, so that was causing the kernel > panic. > > Is the attached patch OK to commit to -CURRENT, and then after some time MFC > to stable/9? > > With this patch, my system can boot with VIMAGE enabled in the kernel and it > does not crash. > > -- > Craig _______________________________________________ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
