bhyve in -current 4/14/13 can no longer support FreeBSD stable install

[Peter Grehan]

Hi Alfred,

> What will happen is during the extract process the install will hang. No
> network IO happens and on the host I see bhyve's CPU hit 100% for each
> core assigned.
>
> For reference this is the bhyve command invoked via Neel's "vmrun.sh".
>
> 0 3915 3908 0 103 0 2122208 103428 - R+ 2 1048:45.75 /usr/sbin/bhyve -c
> 2 -m 2048 -M 0 -AI -H -P -g 0 -s 0:0,hostbridge -s 1:0,virtio-net,tap0
> -s 2:0,virtio-blk,../freebsd-stable.img -s
> 3:0,virtio-blk,../FreeBSD-9.1-STABLE-amd64-20130216-r246877-bootonly.iso
> -S 31,uart,stdio freebsd-stable
>
> I tried to gdb the bhyve process but that was bad news. Is there a set
> of steps usually taken to help pinpoint what is going on when we this
> state?

  Does the previous snapshot (r247640) work better ? The relevant change 
there was the recent virtio guest MFC.

  Some things to try:
   - boot bhyve uniprocessor
   - is the bhyve process performing any disk i/o, or is it just spinning ?
   the bhyvectl program can dump a lot of vm state - you can try 
something like

      sudo bhyvectl --get-all --cpu=0 --vm=<your vm name>
      sudo bhyvectl --get-all --cpu=1 --vm=<your vm name>

  If you do this repeatedly, it may be possible to see some patterns 
e.g. counters incrementing, %RIP values being the same etc.

  Regarding gdb and bhyve, for debugging I usually start bhyve under gdb 
in the foreground and send output to another pty with the gdb "set tty" 
command (note the other pty should have a 'sleep 100000' command run to 
avoid input being captured) - this way, a ctl-C in the gdb session will 
drop into gdb and allow breakpoints to be set etc.

later,

Peter.