Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Mar 2016 14:19:26 -0700
From:      Neel Natu <neelnatu@gmail.com>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org>
Subject:   Re: -current host, 10.1 client loops
Message-ID:  <CAFgRE9HQyq9tsM8PNzCAzQ2AwKenstaELcn0VsYHG4wzK4fXsA@mail.gmail.com>
In-Reply-To: <20918.1458052609@critter.freebsd.dk>
References:  <20918.1458052609@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

On Tue, Mar 15, 2016 at 7:36 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> I'm seing bhyve go into some kind of endless loop while trying to
> compile the gcc port on 10.1 as guest.
>
> In one case CTRL-T on the console kept working, but showed an rm(1)
> process raking up CPU time.
>
> Are there known bogon in current/bhyve or using 10.1-R/i386 as a guest
> I have not spotted ?
>
> How does one debug stuff like this ?
>

I usually do the following things to get a sense for what might be going on:

- "top -H" on the host to figure out if guest vcpu threads are spinning
- "top -H" inside the guest if possible
- "bhyvectl --vm vmname --cpu vcpuid --get-stats" on the host

If there is nothing obvious from the above then I will recompile the
host kernel with KTR enabled (vmm.ko has detailed tracing at KTR_GEN).
This is usually very helpful to understand what might be going on.

Also, if it is possible to reproduce with a single vcpu then it will
help when analyzing the output of ktrdump.

best
Neel

> Poul-Henning
>
> Bhyve started with:
>
>         sh /usr/share/examples/bhyve/vmrun.sh \
>                 -m 1G \
>                 -t ${VMN} \
>                 -d ${P}.root.dd \
>                 -d ${P}.swap.dd \
>                 -d ${P}.tami_install.dd \
>                 -d ${P}.tami_git.dd \
>                 vm${VMU} || true
>
> Host:
>         11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016
>
>         CPU: AMD Athlon(tm) II X3 455 Processor (3311.18-MHz K8-class CPU)
>           Origin="AuthenticAMD"  Id=0x100f53  Family=0x10  Model=0x5  Stepping=3
>           Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
>           Features2=0x802009<SSE3,MON,CX16,POPCNT>
>           AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
>           AMD Features2=0x837ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT,NodeId>
>           SVM: NP,NRIP,NAsids=64
>           TSC: P-state invariant
>         real memory  = 17179869184 (16384 MB)
>         avail memory = 16573935616 (15806 MB)
>         Event timer "LAPIC" quality 400
>         ACPI APIC Table: <090712 APIC1033>
>         FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs
>         FreeBSD/SMP: 1 package(s) x 3 core(s)
>          cpu0 (BSP): APIC ID:  0
>          cpu1 (AP): APIC ID:  1
>          cpu2 (AP): APIC ID:  2
>         ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20150818/tbfadt-649)
>
>
> Guest:
>         10.1-RELEASE i386
>
>
>
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> freebsd-virtualization@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFgRE9HQyq9tsM8PNzCAzQ2AwKenstaELcn0VsYHG4wzK4fXsA>