Re: VIMAGE + PF crash in mbuf destructor
On Monday 22 July 2013 21:01:31 Adrian Chadd wrote: > Well I'm worried about _other_ stuff causing issues here. > > So - what's the "right" behaviour? Does vnet/vimage make the > assumption that for all the mbuf processing/free operations, the vnet > tag/state is set? To the best of my knowledge, there's nothing vnet-specific in any of the mbuf-handling routines, i.e. they should all work fine on a VIMAGE kernel even if curvnet isn't set. My original motivation behind keeping separate UMA zones for each vnet was solely to capture resource leaks between vnets in the early days of VIMAGE prototyping. Nothing prevents a single UMA zone to be shared by multiple vnets, unless we want to enforce per-vnet limitations on the number of items in a zone. Marko > > -adrian > > On 22 July 2013 11:59, Craig Rodrigues wrote: > > On Mon, Jul 22, 2013 at 10:11 AM, Adrian Chadd wrote: > >> I don't think the default vnet context is the correct behaviour there. > >> We'd need to figure out what the vnet context of the mbuf is and set > >> that. > > > > What do you think about Marko's suggestion to de-virtualize > > V_pf_mtag_z? What would be the down side of that? > > > > I don't understand enough of the PF code to understand which variables > > need to > > be virtual and which don't. > > > > -- > > 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" ___ 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"
FreeBSD 9.2 ami
Is there a FreeBSD ami image for downloads on a local lab openstack test environment ?? ___ 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"
Re: VIMAGE + PF crash in mbuf destructor
On Mon, Jul 22, 2013 at 10:11 AM, Adrian Chadd wrote: > > I don't think the default vnet context is the correct behaviour there. > We'd need to figure out what the vnet context of the mbuf is and set > that. > > What do you think about Marko's suggestion to de-virtualize V_pf_mtag_z? What would be the down side of that? I don't understand enough of the PF code to understand which variables need to be virtual and which don't. -- 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"
Re: VIMAGE + PF crash in mbuf destructor
Well I'm worried about _other_ stuff causing issues here. So - what's the "right" behaviour? Does vnet/vimage make the assumption that for all the mbuf processing/free operations, the vnet tag/state is set? -adrian On 22 July 2013 11:59, Craig Rodrigues wrote: > On Mon, Jul 22, 2013 at 10:11 AM, Adrian Chadd wrote: >> >> >> I don't think the default vnet context is the correct behaviour there. >> We'd need to figure out what the vnet context of the mbuf is and set >> that. >> > > What do you think about Marko's suggestion to de-virtualize > V_pf_mtag_z? What would be the down side of that? > > I don't understand enough of the PF code to understand which variables need > to > be virtual and which don't. > > -- > 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"
Re: VIMAGE + PF crash in mbuf destructor
On 22 July 2013 08:43, Nikos Vassiliadis wrote: > Hi, > > I think this comes from the eventhandlers pf installs to handle > ifnet events. It seems like a wifi event causes this code to run > and the context is not set. Does the panic happen only when you > use vnet jails? > > Could you try putting all evenhandlers in an > 'if (IS_DEFAULT_VNET(curvnet))' block? > > It's here: > http://fxr.watson.org/fxr/source/netpfil/pf/pf_if.c#L127 > the pfi_*_cookie = ... lines. > > I am not sure if this would be enough though since it might > panic in other places. I don't think the default vnet context is the correct behaviour there. We'd need to figure out what the vnet context of the mbuf is and set that. -adrian ___ 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"
Re: VIMAGE + PF crash in mbuf destructor
On 07/22/13 09:32, Craig Rodrigues wrote:
Hi,
I used a kernel config with the following lines:
include GENERIC
options VIMAGE
and compiled a CURRENT kernel from svn://svn.freebsd.org/base/head@253346 .
I also have PF enabled on my system.
Once in a while I have been getting kernel panics like these:
(kgdb) #0 doadump (textdump=1) at pcpu.h:236
#1 0x808bc617 in kern_reboot (howto=260)
at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:447
#2 0x808bcb25 in vpanic (fmt=,
ap=)
at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:754
#3 0x808bcb73 in panic (fmt=)
at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:683
#4 0x8033dff7 in db_panic (addr=,
have_addr=, count=,
modif=)
at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:482
#5 0x8033dbcd in db_command (cmd_table=)
at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:449
#6 0x8033d944 in db_command_loop ()
at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:502
#7 0x803402f0 in db_trap (type=, code=0)
at /usr/home/rodrigc/freebsd/head/sys/ddb/db_main.c:231
#8 0x808f3623 in kdb_trap (type=12, code=0, tf=)
at /usr/home/rodrigc/freebsd/head/sys/kern/subr_kdb.c:654
#9 0x80cda43a in trap_fatal (frame=0xff811dbab6b0,
eva=)
at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:868
#10 0x80cda6f4 in trap_pfault (frame=0x0, usermode=0)
at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:699
#11 0x80cd9ef0 in trap (frame=0xff811dbab6b0)
at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:463
#12 0x80cc31a2 in calltrap ()
at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/exception.S:232
#13 0x8208f7b7 in pf_mtag_free (t=0xfe00a8797870)
at
/usr/home/rodrigc/freebsd/head/sys/modules/pf/../../netpfil/pf/pf.c:830
#14 0x808a51c9 in mb_dtor_mbuf (mem=0xfe000d0bc500, size=256,
arg=0x0) at /usr/home/rodrigc/freebsd/head/sys/kern/kern_mbuf.c:499
#15 0x80b55d4d in uma_zfree_arg (zone=0xfe000b4ab900,
item=0xfe000d0bc500, udata=0x0)
at /usr/home/rodrigc/freebsd/head/sys/vm/uma_core.c:2560
#16 0x8092d1f5 in m_freem (mb=) at uma.h:364
#17 0x8058ba72 in iwn_tx_done (sc=0xff8000974000,
desc=, ackfailcnt=16, status=131 '\203')
at /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:2817
#18 0x80583e60 in iwn_notif_intr (sc=0xff8000974000)
at /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:3015
#19 0x80583684 in iwn_intr (arg=0xff8000974000)
at /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:3306
#20 0x8088daf3 in intr_event_execute_handlers (
p=, ie=0xfe000b696600)
at /usr/home/rodrigc/freebsd/head/sys/kern/kern_intr.c:1263
#21 0x8088e4c6 in ithread_loop (arg=0xfe000b31b040)
at /usr/home/rodrigc/freebsd/head/sys/kern/kern_intr.c:1276
#22 0x8088b3f4 in fork_exit (
callout=0x8088e420 , arg=0xfe000b31b040,
frame=0xff811dbabac0)
at /usr/home/rodrigc/freebsd/head/sys/kern/kern_fork.c:991
#23 0x80cc36de in fork_trampoline ()
at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/exception.S:606
#24 0x in ?? ()
Current language: auto; currently minimal
(kgdb)
It turns out that in this file: src/sys/netpfil/pf/pf.c
826 static void
827 pf_mtag_free(struct m_tag *t)
828 {
829
830 uma_zfree(V_pf_mtag_z, t);
831 }
when line 830 is hit, it turns out that curthread->td_vnet is NULL.
Does anyone have an idea as to the best place
to put CURVNET_SET() to avoid this problem?
I am a little less famiiar with mbuf and pf.
Hi,
I think this comes from the eventhandlers pf installs to handle
ifnet events. It seems like a wifi event causes this code to run
and the context is not set. Does the panic happen only when you
use vnet jails?
Could you try putting all evenhandlers in an
'if (IS_DEFAULT_VNET(curvnet))' block?
It's here:
http://fxr.watson.org/fxr/source/netpfil/pf/pf_if.c#L127
the pfi_*_cookie = ... lines.
I am not sure if this would be enough though since it might
panic in other places.
HTH, Nikos
___
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"
Re: FreeBSD PVHVM call for testing
Hi, On 22 Jul 2013, at 10:40, Jeroen van der Ham wrote: >> Could you also try a HEAD XENHVM kernel (without my patches), to see if >> the issue is related to my changes or to some bug already present in HEAD? It seems I was worrying too soon. I have been putting the system through the wringer some more, and I now believe that it has been caused by adding a new swap file. Just before I rebooted my system I created a larger swap file to be used by /etc/rc.d/add_swap. Right after I rebooted I started compiling and doing other things. And I am getting the feeling that the system was still initialising that swap file and was unable to provide swap space at that time. I've rebooted my system again with the PVHVM system, abused it even more than I did before and I'm not seeing the same messages again, nor getting any exaggerated sluggishness. So my apologies for the false alarm. Jeroen. ___ 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"
Re: VIMAGE + PF crash in mbuf destructor
On Monday 22 July 2013 08:57:43 Craig Rodrigues wrote:
> On Sun, Jul 21, 2013 at 11:38 PM, Adrian Chadd wrote:
> > hm. There's lots of mbuf free calls in the net80211 TX and RX path; do
> > we have to have to set the vnet context during the whole tx/rx path?
>
> I'm not sure about that.
> In src/sys/netpfil/pf/pf.c, we have this in pf_initialize():
>
> 751 /* Mbuf tags */
> 752 V_pf_mtag_z = uma_zcreate("pf mtags", sizeof(struct
> m_tag) + 753 sizeof(struct pf_mtag), NULL, NULL,
> pf_mtag_init, NULL, 754 UMA_ALIGN_PTR, 0);
>
> and further down this:
>
> 812 static int
> 813 pf_mtag_init(void *mem, int size, int how)
> 814 {
> 815 struct m_tag *t;
> 816
> 817 t = (struct m_tag *)mem;
> 818 t->m_tag_cookie = MTAG_ABI_COMPAT;
> 819 t->m_tag_id = PACKET_TAG_PF;
> 820 t->m_tag_len = sizeof(struct pf_mtag);
> 821 t->m_tag_free = pf_mtag_free;
> 822
> 823 return (0);
> 824 }
> 825
> 826 static void
> 827 pf_mtag_free(struct m_tag *t)
> 828 {
> 829
> 830 uma_zfree(V_pf_mtag_z, t);
> 831 }
>
>
> Can we somehow modify pf_mtag_init() so that it passes the
> vnet into the pf_mtag?
> Then we can call CURVNET_SET/CURVNET_RESTORE in pf_mtag_free().
I'd say just de-virtualize V_pf_mtag_z, and you're done.
Marko
> --
> Craig
>
> > -adrian
> >
> > On 21 July 2013 23:32, Craig Rodrigues wrote:
> > > Hi,
> > >
> > > I used a kernel config with the following lines:
> > >
> > > include GENERIC
> > > options VIMAGE
> > >
> > > and compiled a CURRENT kernel from svn://
> >
> > svn.freebsd.org/base/head@253346 .
> >
> > > I also have PF enabled on my system.
> > >
> > > Once in a while I have been getting kernel panics like these:
> > >
> > >
> > >
> > > (kgdb) #0 doadump (textdump=1) at pcpu.h:236
> > > #1 0x808bc617 in kern_reboot (howto=260)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:447
> > > #2 0x808bcb25 in vpanic (fmt=,
> > > ap=)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:754
> > > #3 0x808bcb73 in panic (fmt=)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:683
> > > #4 0x8033dff7 in db_panic (addr=,
> > > have_addr=, count=,
> > > modif=)
> > > at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:482
> > > #5 0x8033dbcd in db_command (cmd_table= > > out>) at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:449 #6
> > > 0x8033d944 in db_command_loop ()
> > > at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:502
> > > #7 0x803402f0 in db_trap (type=,
> > > code=0) at /usr/home/rodrigc/freebsd/head/sys/ddb/db_main.c:231
> > > #8 0x808f3623 in kdb_trap (type=12, code=0, tf= > > optimized out>)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/subr_kdb.c:654
> > > #9 0x80cda43a in trap_fatal (frame=0xff811dbab6b0,
> > > eva=)
> > > at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:868
> > > #10 0x80cda6f4 in trap_pfault (frame=0x0, usermode=0)
> > > at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:699
> > > #11 0x80cd9ef0 in trap (frame=0xff811dbab6b0)
> > > at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:463
> > > #12 0x80cc31a2 in calltrap ()
> > > at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/exception.S:232
> > > #13 0x8208f7b7 in pf_mtag_free (t=0xfe00a8797870)
> > > at
> > > /usr/home/rodrigc/freebsd/head/sys/modules/pf/../../netpfil/pf/pf.c:8
> > >30 #14 0x808a51c9 in mb_dtor_mbuf (mem=0xfe000d0bc500,
> > > size=256, arg=0x0) at
> > > /usr/home/rodrigc/freebsd/head/sys/kern/kern_mbuf.c:499 #15
> > > 0x80b55d4d in uma_zfree_arg (zone=0xfe000b4ab900,
> > > item=0xfe000d0bc500, udata=0x0)
> > > at /usr/home/rodrigc/freebsd/head/sys/vm/uma_core.c:2560
> > > #16 0x8092d1f5 in m_freem (mb=) at
> > > uma.h:364 #17 0x8058ba72 in iwn_tx_done
> > > (sc=0xff8000974000, desc=, ackfailcnt=16,
> > > status=131 '\203') at
> > > /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:2817 #18
> > > 0x80583e60 in iwn_notif_intr (sc=0xff8000974000) at
> > > /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:3015 #19
> > > 0x80583684 in iwn_intr (arg=0xff8000974000)
> > > at /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:3306
> > > #20 0x8088daf3 in intr_event_execute_handlers (
> > > p=, ie=0xfe000b696600)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/kern_intr.c:1263
> > > #21 0x8088e4c6 in ithread_loop (arg=0xfe000b31b040)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/kern_intr.c:1276
> > > #22 0x8088b3f4 in fork_exit (
> > > callout=0x8088e420 ,
> > >
Current problem reports assigned to freebsd-virtualization@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/169991 virtualization[run] [vimage] panic after device plugged in o kern/165252 virtualization[vimage] [pf] [panic] kernel panics with VIMAGE and PF o kern/161094 virtualization[vimage] [pf] [panic] kernel panic with pf + VIMAGE wh o kern/160541 virtualization[vimage][pf][patch] panic: userret: Returning on td 0x o kern/160496 virtualization[vimage] [pf] [patch] kernel panic with pf + VIMAGE o kern/148155 virtualization[vimage] [pf] Kernel panic with PF + VIMAGE kernel opt a kern/147950 virtualization[vimage] [carp] VIMAGE + CARP = kernel crash s kern/143808 virtualization[pf] pf does not work inside jail 8 problems total. ___ 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"
Re: FreeBSD PVHVM call for testing
On 22/07/13 10:40, Jeroen van der Ham wrote: > Hi, > > On 22 Jul 2013, at 10:29, Roger Pau Monné wrote: >> Is your guest running a 32bit or a 64bit kernel? > > $ uname -a > FreeBSD positron.dckd.nl 10.0-CURRENT FreeBSD 10.0-CURRENT #0 > r+a09eac7-dirty: Wed Jul 17 17:51:10 CEST 2013 > root@image01:/usr/obj/usr/home/jeroen/freebsd/sys/XENHVM amd64 > >> >> Could you also provide the config file used to launch your guest and the >> Xen and Dom0 kernel versions? > > Guest config: > > kernel = '/usr/lib/xen-4.0/boot/hvmloader' > device_model = '/usr/lib/xen-4.0/bin/qemu-dm' > builder = 'hvm' > shadow_memory = 8 Are you setting the shadow memory size manually because your hardware lacks HAP support? > memory = 512 > name = "positron" > vcpus = 2 > cpus = "2-7" > maxvcpus = 4 > xen_shell = 'root, jeroen' This doesn't seem like a standard xl config option. > > vif = [ > 'type=vifname=positron.wan,bridge=br-wan,mac=00:16:3E:2F:AD:99,ip=94.142.246.99' > , > 'type=vifname=positron.lan,bridge=br-lan,mac=00:16:3E:0D:96:5C,ip=10.20.0.99' > ] > > disk = ['phy:/xen/domains/positron/positron-disk1,hda,w'] > > xen_platform_pci=1 > boot = 'c' > sdl=0 > stdvga=0 > serial='pty' > > > Xen info: > > host : soleus01.soleus.nu > release: 2.6.32-5-xen-amd64 > version: #1 SMP Mon Oct 3 07:53:54 UTC 2011 > machine: x86_64 > nr_cpus: 8 > nr_nodes : 2 > cores_per_socket : 4 > threads_per_core : 1 > cpu_mhz: 2200 > hw_caps: > 178bf3ff:efd3fbff::1310:00802001::37ff: > virt_caps : hvm > total_memory : 65534 > free_memory: 6865 > node_to_cpu: node0:0-3 > node1:4-7 > node_to_memory : node0:3128 > node1:3737 > node_to_dma32_mem : node0:3128 > node1:0 > max_node_id: 1 > xen_major : 4 > xen_minor : 0 > xen_extra : .1 > xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 > hvm-3.0-x86_32p hvm-3.0-x86_64 > xen_scheduler : credit > xen_pagesize : 4096 > platform_params: virt_start=0x8000 > xen_changeset : unavailable > xen_commandline: placeholder dom0_mem=1852M > cc_compiler: gcc version 4.4.5 (Debian 4.4.5-10) > cc_compile_by : waldi > cc_compile_domain : debian.org > cc_compile_date: Wed Jan 12 14:04:06 UTC 2011 > xend_config_format : 4 I've set up a XENHVM system with 256MB of RAM and swap and this is what I see when doing a make buildkernel: [root@ ~]# swapinfo Device 1K-blocks UsedAvail Capacity /dev/ada0p3 1048540 351116 69742433% I don't see any messages on the console or anything else, the system seems to be sluggish while doing the build, but that's quite normal when using only 256MB of RAM. This test was done using the pvhvm_20 branch, but it should not contain any significant code changes in comparison with pvhvm_v19 (it's just a rebase on top of HEAD and a reorder of patches). Could this be because you are using a 9 userland with a 10 kernel? Roger. ___ 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"
Re: FreeBSD PVHVM call for testing
Hi, On 22 Jul 2013, at 10:29, Roger Pau Monné wrote: > Is your guest running a 32bit or a 64bit kernel? $ uname -a FreeBSD positron.dckd.nl 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r+a09eac7-dirty: Wed Jul 17 17:51:10 CEST 2013 root@image01:/usr/obj/usr/home/jeroen/freebsd/sys/XENHVM amd64 > > Could you also provide the config file used to launch your guest and the > Xen and Dom0 kernel versions? Guest config: kernel = '/usr/lib/xen-4.0/boot/hvmloader' device_model = '/usr/lib/xen-4.0/bin/qemu-dm' builder = 'hvm' shadow_memory = 8 memory = 512 name = "positron" vcpus = 2 cpus = "2-7" maxvcpus = 4 xen_shell = 'root, jeroen' vif = [ 'type=vifname=positron.wan,bridge=br-wan,mac=00:16:3E:2F:AD:99,ip=94.142.246.99' , 'type=vifname=positron.lan,bridge=br-lan,mac=00:16:3E:0D:96:5C,ip=10.20.0.99' ] disk = ['phy:/xen/domains/positron/positron-disk1,hda,w'] xen_platform_pci=1 boot = 'c' sdl=0 stdvga=0 serial='pty' Xen info: host : soleus01.soleus.nu release: 2.6.32-5-xen-amd64 version: #1 SMP Mon Oct 3 07:53:54 UTC 2011 machine: x86_64 nr_cpus: 8 nr_nodes : 2 cores_per_socket : 4 threads_per_core : 1 cpu_mhz: 2200 hw_caps: 178bf3ff:efd3fbff::1310:00802001::37ff: virt_caps : hvm total_memory : 65534 free_memory: 6865 node_to_cpu: node0:0-3 node1:4-7 node_to_memory : node0:3128 node1:3737 node_to_dma32_mem : node0:3128 node1:0 max_node_id: 1 xen_major : 4 xen_minor : 0 xen_extra : .1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : unavailable xen_commandline: placeholder dom0_mem=1852M cc_compiler: gcc version 4.4.5 (Debian 4.4.5-10) cc_compile_by : waldi cc_compile_domain : debian.org cc_compile_date: Wed Jan 12 14:04:06 UTC 2011 xend_config_format : 4 > Could you also try a HEAD XENHVM kernel (without my patches), to see if > the issue is related to my changes or to some bug already present in HEAD? Will do. Jeroen. ___ 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"
Re: FreeBSD PVHVM call for testing
On 22/07/13 09:18, Jeroen van der Ham wrote: > Hi, > > After some more testing I thought it would be good to put this into > production for my personal server. I've used pvhvm_v19 and built it without > debugging options and installed it on a FreeBSD 9.1 system. > > I've run into some hiccups with 9.1 user land and a 10-CURRENT kernel, but > that's all solvable[0]. > > My VPS has some very limited memory (256M), but I've compensated with swap > space (1G) Is your guest running a 32bit or a 64bit kernel? Could you also provide the config file used to launch your guest and the Xen and Dom0 kernel versions? > > Now anytime I'm putting the system under stress, by building ports or by > running a git clone on the kernel repository here, I'm seeing a lot of > messages about swap_pager: > >> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 132545, size: 4096 > > The system also becomes very sluggish and sometimes unresponsive. > The weird thing was that one of these messages happened right after a reboot > when I rebuilt an outdated port and on the main console was checking the swap > memory: > >> jeroen:~/ $ swapinfo >> [8:13:29] >> Device 1K-blocks UsedAvail Capacity >> /dev/ada0p2524288 2484 521804 0% >> /dev/md0 1048576 2364 1046212 0% >> Total 1572864 4848 1568016 0% >> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 131424, size: 4096 > > > Is anyone else seeing something similar? Could you also try a HEAD XENHVM kernel (without my patches), to see if the issue is related to my changes or to some bug already present in HEAD? > I certainly did not experience something like this on 9.0 with a XENHVM > kernel. > > If necessary I can rebuild a kernel with debugging support and do some more > recording of what is actually going on. > > Jeroen. > > > [0]: I have edited bsd.port.mk to always apply the FBSD10_FIX, and for > version checking I am running "pkg version" with UNAME_r=9.1-RELEASE. > ___ 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"
Re: FreeBSD PVHVM call for testing
Hi, After some more testing I thought it would be good to put this into production for my personal server. I've used pvhvm_v19 and built it without debugging options and installed it on a FreeBSD 9.1 system. I've run into some hiccups with 9.1 user land and a 10-CURRENT kernel, but that's all solvable[0]. My VPS has some very limited memory (256M), but I've compensated with swap space (1G) Now anytime I'm putting the system under stress, by building ports or by running a git clone on the kernel repository here, I'm seeing a lot of messages about swap_pager: > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 132545, size: 4096 The system also becomes very sluggish and sometimes unresponsive. The weird thing was that one of these messages happened right after a reboot when I rebuilt an outdated port and on the main console was checking the swap memory: > jeroen:~/ $ swapinfo > [8:13:29] > Device 1K-blocks UsedAvail Capacity > /dev/ada0p2524288 2484 521804 0% > /dev/md0 1048576 2364 1046212 0% > Total 1572864 4848 1568016 0% > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 131424, size: 4096 Is anyone else seeing something similar? I certainly did not experience something like this on 9.0 with a XENHVM kernel. If necessary I can rebuild a kernel with debugging support and do some more recording of what is actually going on. Jeroen. [0]: I have edited bsd.port.mk to always apply the FBSD10_FIX, and for version checking I am running "pkg version" with UNAME_r=9.1-RELEASE. ___ 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"
