On Fri, Aug 16, 2013 at 11:34 PM, Kevin Oberman <rkober...@gmail.com> wrote:
> On Fri, Aug 16, 2013 at 10:44 PM, Kevin Oberman <rkober...@gmail.com>wrote: > >> On Fri, Aug 16, 2013 at 2:01 PM, Warren Block <wbl...@wonkity.com> wrote: >> >>> On Fri, 16 Aug 2013, Thomas Zenker wrote: >>> >>> On 08/16/13 15:41, Mikhail Tsatsenko wrote: >>>> >>>>> 2013/8/16 Thomas Zenker <t...@zenker.tk>: >>>>> >>>>>> Hi, >>>>>> >>>>>> after updating my freebsd amd64 box from 9.1 (r250841) to 9.2-RC >>>>>> (r254276) virtualbox crashes the machine. Seconds after starting VBOX >>>>>> >>>>> After starting VBOX gui or guest machine? If first, try to rebuild >>>>> userland portion of vbox too. >>>>> >>>> >>>> After starting a virtual guest machine in the GUI or directly >>>> from cli >>>> leads to the crash. The userland has been rebuild w/ 9.2 also. The same >>>> binaries of the userland portion built with 9.2 work w/o problems in >>>> 9.1. >>>> >>> >>> Updated to 9.2-PRERELEASE #0 r254408 amd64 today, rebuilt and reloaded >>> the VirtualBox kernel module, and just started a couple of guests from the >>> GUI with no problems. >>> >> >> Updated to r254416 today.Two crashes when I tried starting VirtualBox >> 4.16_2. I have both dumps and they ere very different. The first was a >> "spin lock held too long" and the second was a general protection fault. >> Both occurred when I attempted to start a saved Windows 7 VM. >> >> FreeBSD rogue.local 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254416M: >> Fri Aug 16 11:27:20 PDT 2013 >> root@rogue.local:/usr/obj/usr/src/sys/GENERIC >> amd64 >> >> #0 doadump (textdump=<value optimized out>) at pcpu.h:234 >> 234 pcpu.h: No such file or directory. >> in pcpu.h >> (kgdb) #0 doadump (textdump=<value optimized out>) at pcpu.h:234 >> #1 0xffffffff80915c66 in kern_reboot (howto=260) >> at /usr/src/sys/kern/kern_shutdown.c:449 >> #2 0xffffffff80916167 in panic (fmt=0x1 <Address 0x1 out of bounds>) >> at /usr/src/sys/kern/kern_shutdown.c:637 >> #3 0xffffffff80cfae80 in trap_fatal (frame=0x9, eva=<value optimized >> out>) >> at /usr/src/sys/amd64/amd64/trap.c:879 >> #4 0xffffffff80cfb691 in trap (frame=0xffffff8124900830) >> at /usr/src/sys/amd64/amd64/trap.c:605 >> #5 0xffffffff80ce4ac3 in calltrap () >> at /usr/src/sys/amd64/amd64/exception.S:232 >> #6 0xffffffff80b86015 in vm_map_entry_splay (addr=984915968, >> root=0xfffffe002c9af200) at /usr/src/sys/vm/vm_map.c:832 >> #7 0xffffffff80b870f7 in vm_map_lookup_entry (map=0xfffffe007535b640, >> address=984915968, entry=0xffffff8124900970) >> at /usr/src/sys/vm/vm_map.c:1080 >> #8 0xffffffff80b8a5cc in vm_map_madvise (map=0xfffffe007535b640, >> start=984915968, end=985440256, behav=5) at >> /usr/src/sys/vm/vm_map.c:2050 >> #9 0xffffffff80b8d9e3 in sys_madvise (td=0xfffffe000549e920, >> uap=<value optimized out>) at /usr/src/sys/vm/vm_mmap.c:760 >> #10 0xffffffff80cfa62a in amd64_syscall (td=0xfffffe000549e920, traced=0) >> at subr_syscall.c:135 >> #11 0xffffffff80ce4da7 in Xfast_syscall () >> at /usr/src/sys/amd64/amd64/exception.S:391 >> #12 0x000000002ce13dcc in ?? () >> Previous frame inner to this frame (corrupt stack?) >> >> I can make the cores and text dumps available. kmod was rebuilt after >> the upgrade. >> > > Just confirmed that 254050 works fine. Trying 354162 and will continue > binary hunt till I find it. > > I am now up to 254270, at the point of the original failure report. I now suspect I may have botched the kmod re-install on my original failure. I am calling it quits of the night now, but will finish tests tomorrow morning. The updates are pretty few and far between between 270 and the present. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"