Re: Xen PV drivers for FreeBSD
On Wed, 2010-11-24 at 09:03 -0800, Yuriy Kohut wrote: > Hi, > > It is for amd64 only, correct ? > > Do you know is it stable enough ? > --- > Yura > The version in -CURRENT and FreeBSD 8 that Justin is talking about is very stable. I will be updating FreeBSD 7 and 6 today. You will need to update from source to get this version as it is not on the release ISOs We are using it a lot at Yahoo. It is very stable. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen PV drivers for FreeBSD
Yeah, I'm not seeing this patch in -stable 8 yet. sean On Tue, 2010-11-30 at 07:35 -0800, Yuriy Kohut wrote: > switching to todays updates on RELENG_8 the following is got: > - > xctrl: xctrl0 already exists; skipping it > xctrl0: on xenstore0 > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > xen_usb_nop_confighook_cb xenbusb_nop_confighook_cb > t_delta ... to long > - > > And message repeats every 60 sec. > --- > Yura > > On Nov 30, 2010, at 5:07 PM, Yuriy Kohut wrote: > > > Hi, ones more > > > > Here is some results of my investigation running FreeBSD amd64 HVM Xen DomU > > with PV drivers installed (XENHVM config is used). > > . > > FreeBSD was booted on "Boot FreeBSD with verbose logging" mode. > > > > Custom kernel was built using > > - 8.1-RELEASE sources from src/sys installed with sysinstall > > - RELENG_8_1 get with csup/cvsup > > - RELENG_8 get with csup/cvsup > > > > Every time the same error got, and boot stops: > > > > ata1: New device: 00020001 > > ata1-slave: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire > > ... > > ata1: reinit done .. > > unknown: FAILURE - ATA_IDENTIFY timed aut LBA=0 > > > > The next messages are CDROM detection. And after that boot stops. > > > > > > > > Here is config I'm using for DomU: > > > > kernel = "/usr/lib/xen/boot/hvmloader" > > builder='hvm' > > memory = 1024 > > #shadow_memory = 8 > > name = "freebsd-8.1" > > vif = [ 'bridge=eth0', ] > > disk = [ > > 'tap:aio:/opt/images/freebsd-8.1-test.img,hda,w', > > "tap:aio:/opt/images/freebsd-8.1-swap.img,hdb,w", > > #"phy:/dev/vg0/lvol18,ioemu:hdb,w", > > 'file:/opt/iso/boot-freebsd.iso,hdd:cdrom,r' ] > > device_model = "/usr/lib64/xen/bin/qemu-dm" > > boot="cd" > > sdl=0 > > vnc=1 > > vncpasswd='' > > stdvga=0 > > serial='pty' > > acpi=1 > > apic=1 > > stdvga=0 > > > > > > > > Justin, I'm still not seing your update with csup for > > sys/kern/subr_autoconf.c in RELENG_8 > > --- > > Yura > > > > On Nov 30, 2010, at 1:26 PM, Yuriy Kohut wrote: > > > >> Just built XENHVM based on RELENG_8 and got kernel panic. > >> > >> Please find VNC console snapshot attached. > >> > >> > >> > >> Unfortunately I have no way to copy/paste from VNC. > >> --- > >> Yura > >> > >> On Nov 30, 2010, at 11:36 AM, Yuriy Kohut wrote: > >> > >>> Hi, Justin, > >>> > >>> I'm using cvsup (csup) and still didn't see the merge on the RELENG_8... > >>> > >>> --- > >>> Yura > >>> > >>> On Nov 29, 2010, at 5:29 PM, Yuriy Kohut wrote: > >>> > Ok, I'll check and let you know results > > Thank you > --- > Yura > > On Nov 29, 2010, at 5:06 PM, Justin T. Gibbs wrote: > > > On 11/29/2010 6:50 AM, Yuriy Kohut wrote: > >> Hi, > >> > >> I have just build XENHVM from RELANG_8 cvs tag. > >> > >> VM stuck on booting too. The last message in VNC console was: > >> - > >> xctrl0: on xenstore0 > >> - > >> > >> Could somebody please suggest ? > > > > I neglected to merge SVN revision 211236 into -stable, and this > > should be the cause of your hang. I just submitted the merge, > > but it will take a little while for it to be replicated into > > CVS. Once you've pulled down this revision (it updates > > sys/kern/subr_autoconf.c), can you rebuild, test, and report > > your results? > > > > Thanks, > > Justin > > ___ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" > >>> > >>> ___ > >>> freebsd-xen@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-xen > >>> To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" > >> > >> ___ > >> freebsd-xen@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-xen > >> To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" > > > > ___ > > freebsd-xen@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > > To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" > > ___ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
domU config for NetBSD Dom0
Does anyone have a working HVM config for a FreeBSD DomU under the NetBSD Dom0? Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen Dom0 support in Free BSD
On Tue, 2011-03-15 at 05:48 -0700, Lars Kurth wrote: > Hi, > > I was wondering what the status of FreeBSD support for Xen as Dom0 is. I > couldn't find any mention on http://wiki.freebsd.org/FreeBSD/Xen > > We are currently updating > - http://wiki.xensource.com/xenwiki/XenDomUSupport > - http://wiki.xensource.com/xenwiki/XenDom0Kernels > > Thank you for helping out > Lars > ___ AFAIK, there is no Dom0 support in FreeBSD at this time. I'm not sure if anyone has spent any significant time looking at the NetBSD Dom0 as a base to port over to FreeBSD. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Panic XENHVM
Installed a freebsd-current non-xen kernel from a few months ago and used it to compile and installworld/kern from the largeSMP branch. In addition, the Dom0 is NetBSD and the Hypervisor is xen 4.1 There is a significant possibility that I don't know what I'm doing and was looking for your thoughts here. Timecounters tick every 10.000 msec usbus0: 12Mbps Full Speed USB v1.0 xenbusb_front0: on xenstore0 ugen0.1: at usbus0 uhub0: on usbus0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [211588 x 2048 byte records] xn0: at device/vif/0 on xenbusb_front0 xn0: Error 2 parsing device/vif/0/mac xn0: Fatal error. Transitioning to Closing State panic: do something smart cpuid = 0 KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x3b: movq$0,0x90f4d2(%rip) db> trace Tracing pid 0 tid 10 td 0x810b9c80 kdb_enter() at kdb_enter+0x3b panic() at panic+0x180 netfront_attach() at netfront_attach+0x19a device_attach() at device_attach+0x69 xenbusb_probe_children() at xenbusb_probe_children+0xdf xenbusb_attach() at xenbusb_attach+0x11c device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a xs_attach_deferred() at xs_attach_deferred+0x21 run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks +0x73 boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x2c mi_startup() at mi_startup+0x77 btext() at btext+0x2c xen config for this DomU # # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. kernel = "/usr/pkg/lib/xen/boot/hvmloader" device_model = '/usr/lib/xen/bin/qemu-dm' builder='hvm' # Initial memory allocation (in megabytes) for the new domain. memory = 4098 # number of CPUS vcpus = 4 # A name for your domain. All domains must have different names. name = "fbsd9" #Network interface. By default emules a realtek 8139. For a NetBSD guest you # have to disable re(4) and let rtk attach to use it. # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0 # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets with # pcn(4) under NetBSD. vif = [ 'mac=00:16:3e:00:00:14, bridge=bridge0, type=ioemu' ] # # device model to use: only qemu-dm available for now device_model = '/usr/pkg/libexec/qemu-dm' # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. # For hvm domains you can only use hda to hdd. You can set extra types # (e.g. cdrom) disk = [ 'file:/var/virt/FreeBSD-9.0-CURRENT-201101-amd64-disc1.iso,hdc:cdrom,r', 'file:/var/virt/vmtest9_amd64.bin,hda,w' ] # floppy images; this doesn't seem to work currently. Use a iso image instead. #fda = '/home/domains/boot1.fs' # boot device: a = floppy, c= hard drive, d= cdrom (with the disk entry # before) boot='c' # By default, 'xm create' will try to open an X window on the current display # for the virtal framebuffer. You can have the virtal framebuffer in vnc # instead, and connect using a vnc client (using localhost:$vncdisplay) # If vncunused is set to 1 (this is the default value), vncdisplay # will be set to the first unused port; so it's recommended to vnc = 1 vncdisplay = 1 vncunused = 1 vncpasswd='' #Xen emulates a PS/2 mouse, but the pointer in the guest has difficulties # tracking the absolute position. Xen can emulate a USB tablet in addition # to the mouse which will report the absolute position of the pointer, # and make the mouse much easier to use. # usb=1 usbdevice='tablet' #usbdevice='mouse' serial='pty' on_reboot='restart' ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Some success, some questions
I've made some significant progress on the freebsd.org xen hosting machines (no dom0 support yet, but I'm working on it). I've installed a netbsd-current dom0 and the 3.3.2 xen hypervisor on xen1.freebsd.org and started up a freebsd-current DomU with the XENHVM kernel installed. I've attached the dmesg and the xen config for "xen2.freebsd.org" to this message. I've been crashing the hypervisor pretty reliably by setting the DomU to use multiple CPUs. Not sure if this is a Xen or NetBSD thing, but for now i'm leaving vcpus set to 1. 1. How do I switch the networking vif entry to use the netfront xn0 driver instead of emulating a e1000? 2. What tests would people like to see on this? 3. Is anyone working on OpenStack or Ganetti for Free/NetBSD? Sean # # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. kernel = "/usr/pkg/lib/xen/boot/hvmloader" device_model = '/usr/lib/xen/bin/qemu-dm' builder='hvm' # Initial memory allocation (in megabytes) for the new domain. memory = 4098 # number of CPUS vcpus = 1 # A name for your domain. All domains must have different names. name = "fbsd9" #Network interface. By default emules a realtek 8139. For a NetBSD guest you # have to disable re(4) and let rtk attach to use it. # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0 # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets with # pcn(4) under NetBSD. #vif = [ 'mac=00:16:3e:00:00:14, bridge=bridge0, type=ioemu' ] vif = [ 'mac=00:16:3e:00:00:14, bridge=bridge0, model=e1000' ] # # device model to use: only qemu-dm available for now device_model = '/usr/pkg/libexec/qemu-dm' # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. # For hvm domains you can only use hda to hdd. You can set extra types # (e.g. cdrom) disk = [ 'file:/var/virt/FreeBSD-9.0-CURRENT-201105-amd64-dvd1.iso,hdc:cdrom,r', #'file:/var/virt/FreeBSD-9.0-CURRENT-201101-amd64-disc1.iso,hdc:cdrom,r', 'file:/var/virt/vmtest9_amd64.bin,hda,w' ] # floppy images; this doesn't seem to work currently. Use a iso image instead. #fda = '/home/domains/boot1.fs' # boot device: a = floppy, c= hard drive, d= cdrom (with the disk entry # before) boot='c' # By default, 'xm create' will try to open an X window on the current display # for the virtal framebuffer. You can have the virtal framebuffer in vnc # instead, and connect using a vnc client (using localhost:$vncdisplay) # If vncunused is set to 1 (this is the default value), vncdisplay # will be set to the first unused port; so it's recommended to vnc = 1 vncdisplay = 1 vncunused = 1 vncpasswd='' #Xen emulates a PS/2 mouse, but the pointer in the guest has difficulties # tracking the absolute position. Xen can emulate a USB tablet in addition # to the mouse which will report the absolute position of the pointer, # and make the mouse much easier to use. # usb=1 usbdevice='tablet' #usbdevice='mouse' serial='pty' on_reboot='restart' # From: Sean Bruno To: sbr...@freebsd.org Subject:dmesg from xenhvm on netbsd dom0 Date: Tue, 24 May 2011 15:10:29 -0700 Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0 r39: Tue May 24 12:06:26 PDT 2011 root@xen2:/usr/obj/usr/home/sbruno/head/sys/XENHVM amd64 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2493.82-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0x781fbff Features2=0x80082201 AMD Features=0x20100800 AMD Features2=0x1 real memory = 4297064448 (4098 MB) avail memory = 4113154048 (3922 MB) Event timer "LAPIC" q
FreeBSD 8, PV, i386 panic with vcpus > 1
I assume then, that the i386 PV instance cannot do more than 1 CPU at this time? sean Started domain ref8-xen32 (id=120) WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #1 r224449: Tue Jul 26 09:53:36 PDT 2011 sbr...@ref8-xen32.freebsd.org:/usr/obj/dumpster/scratch/sbruno-scratch/8/sys/XEN i386 WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 2493.746 MHz processor. Timecounter "ixen" frequency 1953125 Hz quality 0 CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2493.75-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfe3fbff Features2=0xce3bd AMD Features=0x2010 AMD Features2=0x1 TSC: P-state invariant real memory = 805306368 (768 MB) avail memory = 777650176 (741 MB) gdtpfn=20103f pdptpfn=3d0be panic: HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, &ctxt): /dumpster/scratch/sbruno-scratch/8/sys/i386/xen/mp_machdep.c:930 cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db> db> db> db> bt Tracing pid 0 tid 0 td 0xc03dec90 kdb_enter(c0369837,c0369837,c03915fd,c06b4ca8,0,...) at kdb_enter+0x3a panic(c03915fd,c03983a2,c0398124,3a2,c0398124,...) at panic+0x134 start_all_aps(c0396bf2,1,c03b2890,c036e574,0,...) at start_all_aps+0x7d4 cpu_mp_start(c03f3234,c036e574,0,1,fff,...) at cpu_mp_start+0x155 smp_topo_find(0,6040800,6040800,6b9000,0,...) at smp_topo_find+0xbf mi_startup(6b9000,0,0,0,0,...) at mi_startup+0xac btext() at btext+0x95 ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
FreeBSD Xen PV i386 --> 855MB Max?
I note that if I scale the i386 PV Xen kernel past 855MB, I get an insta panic at boot. I assume that there's a hard limit on the amount of RAMS we can use here? Using config file "./ref8-xen32". Started domain ref8-xen32 (id=133) WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #1 r224449: Tue Jul 26 09:53:36 PDT 2011 sbr...@ref8-xen32.freebsd.org:/usr/obj/dumpster/scratch/sbruno-scratch/8/sys/XEN i386 WARNING: WITNESS option enabled, expect reduced performance. panic: pmap_init: page table page is out of range cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at 0xc010e68a: movl$0,0xc03f20b4 ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD Xen PV i386 --> 855MB Max?
On Tue, 2011-07-26 at 12:01 -0700, K. Macy wrote: > It's an artifact of the initialization code and how the xen domain > builder configures the initial mapped memory. I've come against this > and fixed this issue in the past but I guess either the domain builder > has changed or the initial code has bit rotted. I can't commit so ask > Colin if he can fix. > > Cheers I have one of those "commit bits" if you have something in mind. sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD PV i386 panics
On Tue, 2011-07-26 at 11:58 -0700, Colin Percival wrote: > On 07/26/11 11:35, Sean Bruno wrote: > > I assume then, that the i386 PV instance cannot do more than 1 CPU at > > this time? > > Correct. SMP support was clearly started but never completed. > > > I note that if I scale the i386 PV Xen kernel past 855MB, I get an insta > > panic at boot. I assume that there's a hard limit on the amount of RAMS > > we can use here? > > There's a problem somewhere in FreeBSD's PV machine init code, but I haven't > had > an opportunity to track it down yet. I hope to look at this some time soon > (if > I can access the xen box in the cluster?) but I've been swamped lately. > Yup, you're on my list to get access today. I'll get kerberos up and running on the hypervisor so you can screw around in a bit. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
FreeBSD 8, PV i386 VNC fails?
Probably not doing it right. When I switched from pure HVM to PV on the i386 VMs in the cluster, VNC stopped working all together. Did I do it wrong? I've tried the following: vnc = 1 vncdisplay = 1 vncunused = 1 vncpasswd='' and vfb = [ "type = vnc, vncdisplay = 1, vncunused = 1, vncpasswd=''" ] The vfb = [] syntax seems to hang the VM on frame buffer initialization and it will not post. The old style syntax seems to allow the host to boot, but there is no VNC listening on the host. Understand that the old style syntax works just fine in HVM mode. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD 8, PV i386 VNC fails?
On Tue, 2011-07-26 at 15:18 -0700, Luke S. Crawford wrote: > On Tue, Jul 26, 2011 at 03:04:48PM -0700, Colin Percival wrote: > > On 07/26/11 14:48, Sean Bruno wrote: > > > Probably not doing it right. When I switched from pure HVM to PV on the > > > i386 VMs in the cluster, VNC stopped working all together. Did I do it > > > wrong? > > > > Is it possible to use PV with VNC? I thought under PV there wasn't any > > emulated console, just the Xen paravirtual console which lets you read > > and write characters as on a serial console. > > It's possible, redhat built a paravirtualized framebuffer to give > pv guests a framebuffer > > http://www.xen.org/files/xensummit_4/Xenpvfb07_Armbruster.pdf > > I imagine the problem is probably hypervisor dependent; I mean, > I don't know anyone who actually used the paravirtualized framebuffer, > so it's probably not well tested, and may suffer from bit rot as other > features are added to xen. I tested it, /I believe/ on rhel/centos 5.3. > ___ I think that sort of makes sense to me. That is, there would need to be a PV framebuffer driver for PV mode to use it. I guess. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
FreeBSD 8, PV i386 Console
I can't quite tell what's happening (perhaps its ntpd and Xen something here), but this appears on the VM console about every 10 seconds. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. if the system is completely idle, I see: 26 Jul 15:56:02 ntpdate[543]: poll(): nfound = 0, error: Interrupted system call [XEN] hypervisor wallclock nudged; nudging TOD. thoughts? Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Ok, so why is Sean whining so much today
I'm almost done building a test reference system in the Yahoo portion of the FreeBSD cluster. Nothing special, but I'm trying to get you folks some testing resources that are capable of being used for testing and development of Xen. The emails I'm sending are just the bits of things that I'm seeing fall out of a basic installation of 4 VMs (32/64bit version of 8/HEAD). Over the next few days I'll be "releasing" them for your general consumption and taking suggestions on what we should be doing with them. I'm hopeful that we can come up with some ideas to make the DomU code more accessible to end users. So, if you see things you'd like tested, or somewhere to run an idea, let use know on the clusteradm@ mail list and we'll take care of you. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
FreeBSD 8, i386 PV panic at idle
Simple left my xen domu running over night. The console looks like this: rtc0: [XEN] xen_rtc_settime [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. panic: HYPERVISOR_update_va_mapping(((unsigned long)(sysmaps->CADDR2)), (0x001 | 0x002 | xpmap_ptom(((m)->phys_addr)) | 0x020 | 0x040), UVMF_INVLPG| UVMF_ALL) < 0: /dumpster/scratch/sbruno-scratch/8/sys/i386/xen/pmap.c:3400 cpuid = 0 KDB: enter: panic [thread pid 61868 tid 100085 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db> bt Tracing pid 61868 tid 100085 td 0xc3e0d2e0 kdb_enter(c0369837,c0369837,c03915fd,e1ae0acc,0,...) at kdb_enter+0x3a panic(c03915fd,c0398e3e,c039848a,d48,c05bc140,...) at panic+0x134 pmap_zero_page(c15d9038,e,0,40,e1ae0c14,...) at pmap_zero_page+0x112 vm_fault(c350e0ec,bf7ee000,2,8,bf7eed78,...) at vm_fault+0x1201 dblfault_handler() at dblfault_handler+0x4d7 --- trap 0x17, eip = 0, esp = 0, ebp = 0 --- The Dom0 has the following on its console: entOS release 5.6 (Final) Kernel 2.6.18-238.12.1.el5xen on an x86_64 xen1.freebsd.org login: (XEN) mm.c:2315:d146 Bad type (saw 4802 != exp e000) for mfn 1269f1 (pfn 25d7a) (XEN) mm.c:807:d146 Error getting mfn 1269f1 (pfn 25d7a) from L1 entry 0001269f1063 for l1e_owner=146, pg_owner=146 DomU config: # # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. #kernel = "/usr/lib/xen/boot/hvmloader" kernel = "/var/virt/freebsd-8-stable-i386-domu-kernel" # # device model to use: only qemu-dm available for now #device_model = '/usr/lib64/xen/bin/qemu-dm' #builder='hvm' # Initial memory allocation (in megabytes) for the new domain. memory = 855 # number of CPUS vcpus = 1 # A name for your domain. All domains must have different names. name = "ref8-xen32" arch = "i386" #Network interface. By default emules a realtek 8139. For a NetBSD guest you # have to disable re(4) and let rtk attach to use it. # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0 # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets with # pcn(4) under NetBSD. #vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0, type=ioemu' ] vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0, type=vbd' ] # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. # For hvm domains you can only use hda to hdd. You can set extra types # (e.g. cdrom) disk = [ 'file:/var/virt/FreeBSD-8.2-RELEASE-i386-disc1.iso,hdc:cdrom,r', 'file:/var/virt/ref8-xen32.bin,hda,w' ] extra = "vfs.root.mountfrom=ufs:/dev/ad0s1a" # floppy images; this doesn't seem to work currently. Use a iso image instead. #fda = '/home/domains/boot1.fs' # boot device: a = floppy, c= hard drive, d= cdrom (with the disk entry # before) # # boot CDROM image #boot='d' # boot from DISK file boot='c' # By default, 'xm create' will try to open an X window on the current display # for the virtal framebuffer. You can have the virtal framebuffer in vnc # instead, and connect using a vnc client (using localhost:$vncdisplay) # If vncunused is set to 1 (this is the default value), vncdisplay # will be set to the first unused port; so it's recommended to #vfb = [ "type = vnc, vncdisplay = 1, vncunused = 0, display = TEST" ] #Xen emulates a PS/2 mouse, but the pointer in the guest has difficulties # tracking the absolute position. Xen can emulate a USB tablet in addition # to the mouse which will report the absolute position of the pointer, # and make the mouse much easier to use. # usb=1 usbdevice='tablet' #usbdevice='mouse' serial='pty' on_reboot='restart' # ___ freebsd-xe
Re: I am trying to install freebsd on Centos 5.6
On Thu, 2011-07-28 at 08:49 -0700, Rafael Mas wrote: > Dear Reader, > > > > I am new to this list, and also to the installation of Freebsd on a > Virtualez Xen box running on Centos 5.6. I am trying to find the proper > documentation or tutorial to get this done, and I would like you to guide me > with some good tutorials that I can read to get this project accomplish for > my current company. I will appreciate all your help on this important > matter. > Good question. How far did you get and what problems are you experiencing? Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
RE: I am trying to install freebsd on Centos 5.6
Can you post the following? domU xen config for your VM the output of "ifconfig -a" on the domU the output of "uname -a" on the domU Sean On Thu, 2011-07-28 at 11:38 -0700, Rafael Mas wrote: > Dear Sean, Readers > > I am having problems right now... :( > > I was using the Kernel-Xen ver (3.1.2-238-9.1.el5) that is updated from the > Centos-Base repo automatically. Reading some forum post on Xen, I decided to > update the Xen to its latest Xen version 4.1.1 using a repo > http://www.gitco.de/repo/GITCO-XEN4.1.1_x86_64.repo now, the machine starts > but without starting any network interface it complains that IRQ Type > mismatch when I try to ifup eth1 or 0. I am not sure if this is because > changes on the Xen itself or ? . The sad part of this , is that this is one > of my production servers. Have anyone have this kind of issue before with > this repo ?, can it be solved without reinstalling/repairing the Linux Kernel > ? > > I've attached a picture on this email with the specs of the error, any input > will be super appreciated. > > Best Regards, > > > -Original Message- > From: Sean Bruno [mailto:sean...@yahoo-inc.com] > Sent: Thursday, July 28, 2011 2:07 PM > To: Rafael Mas > Cc: freebsd-xen@freebsd.org > Subject: Re: I am trying to install freebsd on Centos 5.6 > > On Thu, 2011-07-28 at 08:49 -0700, Rafael Mas wrote: > > Dear Reader, > > > > > > > > I am new to this list, and also to the installation of Freebsd on a > > Virtualez Xen box running on Centos 5.6. I am trying to find the proper > > documentation or tutorial to get this done, and I would like you to guide me > > with some good tutorials that I can read to get this project accomplish for > > my current company. I will appreciate all your help on this important > > matter. > > > > > Good question. How far did you get and what problems are you > experiencing? > > Sean > ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
HVM boot fail, BETA-1 and current
Tried to boot up an BETA-1 XENHVM kernel today, apparently CAMATA doesn't work in this environment. Let me know if you want access to this VM as its in the cluster and I can trivially get you on the machine. /boot.config: -Dh Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS 639kB/2096128kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (r...@farrell.cse.buffalo.edu, Thu Jul 28 16:09:55 UTC 2011) Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0xbb97c0 data=0x1431d0+0x2bc450 syms=[0x8 +0x110da8+0x8+0xf8650] - __ _ _ | | | _ \ / | __ \ | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_) |) | |__| | | | | | |||| | | | |_| |_| \___|\___||/|_/|_/``` ` s` `.---...--.``` -/ �Welcome to FreeBSD�� � +o .--` /y:` +. � � yo`:.:o ` +- � 1. Boot [ENTER]� y/ -/` -o/ � 2. [Esc]ape to loader prompt � .- ::/sy +:. � 3. Reboot � / `-- / � � `: :` � Options: � `: :` � 4. [A]CPI Support: Enabled � / / � 5. Boot Safe [M]ode: NO� .- -. � 6. Boot [S]ingle User: NO � -- -. � 7. Boot [V]erbose: NO �`:` `:` � � .-- `--. � � .---.. � GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=0009fc00 SMAP type=02 base=0009fc00 len=0400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=7ff0 SMAP type=02 base=fc00 len=0400 Table 'FACP' at 0xfc005ee0 Table 'APIC' at 0xfc005fe0 APIC: Found table at 0xfc005fe0 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 1: enabled SMP: Added CPU 2 (AP) Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-BETA1 #0 r224482M: Fri Jul 29 16:42:18 PDT 2011 r...@ref9-xen64.freebsd.org:/usr/obj/dumpster/scratch/sbruno-scratch/head/sys/XENHVM amd64 WARNING: WITNESS option enabled, expect reduced performance. Table 'FACP' at 0xfc005ee0 Table 'APIC' at 0xfc005fe0 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0x815c4000. Hypervisor: Origin = "XenVMMXenVMM" Calibrating TSC clock ... TSC clock: 2493823785 Hz CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2493.82-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0x1781fbff Features2=0x80082201 AMD Features=0x20100800 AMD Features2=0x1 real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x015f3000 - 0x7c38, 2061094912 bytes (503197 pages) avail memory = 2045038592 (1950 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 2 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 x86bios: IVT 0x00-0x0004ff at 0xfe00 x86bios: SSEG 0x001000-0x001fff at 0xff800020d000 x86bios: EBDA 0x09f000-0x09 at 0xfe09f000 x86bios: ROM 0x0a-0x0fefff at 0xfe0a APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xea020 00024 (v02Xen) ACPI: XSDT 0xfc006050 00034 (v01Xen HVM HVML ) ACPI: FACP 0xfc005ee0 000F4 (v04Xen HVM HVML ) ACPI: DSDT 0xfc002c40 0321F (v02Xen HVM INTL 20090220) ACPI: FACS 0xfc002c00 00040 ACPI: APIC 0xfc005fe0 00070 (v02Xen HVM HVML ) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 5, irq 5 ioapic0: intpin 5 trigger: level ioapic0: intpin 5 polarity: low M
BETA-1 NFS not working, Xen PV i386
Doesn't make a lot of sense here, but building with the i386 XEN kernel config yields the following boot up in PV mode. Odd ... it looks like i386/XEN needs: options NFSCL # New Network Filesystem Client Sean Using config file "./ref9-xen32". Started domain ref9-xen32 (id=38) WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-BETA1 #0 r224482M: Fri Jul 29 13:34:25 PDT 2011 r...@ref9-xen32.freebsd.org:/usr/obj/dumpster/scratch/sbruno-scratch/head/sys/XEN i386 WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 2493.756 MHz processor. Timecounter "ixen" frequency 1953125 Hz quality 0 CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2493.76-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfe3fbff Features2=0xce3bd AMD Features=0x2010 AMD Features2=0x1 real memory = 805306368 (768 MB) avail memory = 777121792 (741 MB) [XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0) [XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1) [XEN] xen_rtc_probe: probing Hypervisor RTC clock rtc0: on motherboard [XEN] xen_rtc_attach: attaching Hypervisor RTC clock xenstore0: on motherboard xc0: on motherboard Event timer "ixen" quality 600 Timecounters tick every 10.000 msec xenbusb_front0: on xenstore0 [XEN] hypervisor wallclock nudged; nudging TOD. xn0: at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 00:16:3e:00:00:03 xenbusb_back0: on xenstore0 xctrl0: on xenstore0 xbd0: 497MB at device/vbd/5632 on xenbusb_front0 xbd0: attaching as ad2 xbd1: 10240MB at device/vbd/768 on xenbusb_front0 xbd1: attaching as ad0 Timecounter "TSC" frequency 2493756000 Hz quality 800 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0p2 []... WARNING: / was not properly dismounted rtc0: [XEN] xen_rtc_gettime rtc0: [XEN] xen_rtc_gettime: wallclock 1311892419 sec; 132269700 nsec rtc0: [XEN] xen_rtc_gettime: uptime 94008 sec; 379306109 nsec rtc0: [XEN] xen_rtc_gettime: TOD 1311986427 sec; 511575809 nsec Setting hostuuid: 1c127834-ab5a-c2e4-7b24-5ea29d364d9d. Setting hostid: 0xdea9fbfd. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: ** SU+J Recovering /dev/ad0p2 ** Reading 33554432 byte journal from inode 4. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. * FILE SYSTEM MARKED CLEAN * Mounting local file systems:. Setting hostname: ref9-xen32.freebsd.org. xn0: link state changed to DOWN xn0: link state changed to UP Starting Network: lo0 xn0. lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff00 nd6 options=21 xn0: flags=8843 metric 0 mtu 1500 options=503 ether 00:16:3e:00:00:03 nd6 options=29 media: Ethernet manual status: active Starting devd. DHCPREQUEST on xn0 to 255.255.255.255 port 67 DHCPACK from 69.147.83.62 bound to 69.147.83.99 -- renewal in 900 seconds. add net :::0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 kldload: can't load nfscl: File exists /etc/rc: WARNING: Unable to load kernel module nfscl ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files. Starting syslogd. No core dumps found. Setting date via ntp. rtc0: [XEN] xen_rtc_settime 29 Jul 17:40:33 ntpdate[585]: step time server 69.147.83.54 offset -25202.462526 sec kldload: can't load nfscl: File exists /etc/rc: WARNING: Unable to load kernel module nfscl Setting NIS domain: freebsd. Starting rpcbind. Starting ypbind. Clearing /tmp (X related). Updating motd:. Mounting late file systems:mount_nfs: nfscl is not available mount_nfs: nfscl is not available mount_nfs: nfscl is not available . Mounting /etc/fstab filesystems failed, startup aborted ERROR: ABORTING BOOT (sending SIGTERM to parent)! Jul 29 17:40:34 ref9-xen32 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Networking issues with FreeBSD HVM + SMP
On Sun, 2011-07-31 at 20:22 -0700, Ben C. wrote: > Hello all, > > Thanks for taking time to read this post. It's a fairly long winded > tale of confusion, but here goes: > > * I originally installed FreeBSD 8.2-RELEASE fine working under 100% > HVM. Using the GENERIC kernel with xen's qemu > * I trashed the box (kind of willingly, it's been a while since I've > had the pleasure of FreeBSD and think of it as my first pancake) > * Reinstalled. Networking failed. I had no idea why. Several weeks > past, I finally got networking back working after about 20-30 install > attempts. > * Setup the box properly. > * Did some changes throughout the dom0/domu's - I had originally had > the vcpu's pinned to physical cpu's and all this mojo. I found that > my load averages on the dom0 were significantly lower when the vcpu's > were bound to 'any physical' -- but that's beside the point. The > point is, FreeBSD changed vcpu's from 1 to 2 - and networking stopped. > * I honestly thought it surely was something else. I triple-checked > and confirmed, when vcpu=1, networking worked as expected. When vcpu > was >1, networking failed with a vauge .. em0 (or re0, see below) .. > watchdog timeout spewing all over. > > If you take a look at my configuration below, I originally had > model=e1000 in the vif, which I *thought* was what made it work > originally. I was apprently wrong. vcpu pinning doesn't matter. > Essentially, if it has more than 1 (v)cpu's, networking fails. > > The dom0 is running NetBSD -CURRENT [current there is just like > current here], on an Intel i7. I could try the -current branch or > using the xenhvm kernel/drivers. I'm fairly sure the latter may help > the situation, but honestly I'm just a bit bothered by the strangeness > of this "bug". Does anyone else have any suggestions on what I > should try next? > > Thanks for your time, Ben > > > name ="a5freebsd" > memory = 2048 > > kernel = "/usr/pkg/lib/xen/boot/hvmloader" > builder='hvm' > device_model = '/usr/pkg/libexec/qemu-dm' > > disk = [ > 'phy:/dev/mapper/rxenpool-a5freebsd_root,ioemu:hda,w', > > 'file:/home/xen/iso/FreeBSD-8.2-RELEASE-amd64-disc1.iso,ioemu:hdc:cdrom,r' > ] > boot = 'cd' > > vcpus=2 > #cpus=['2'] > > > #vif=[ 'type=ioemu,bridge=bridge0,model=e1000,mac=00:16:3e:4f:bb:78' ] > vif=[ 'type=ioemu,bridge=bridge0,mac=00:16:3e:4f:bb:78' ] > > vnc = 1 > vncdisplay = 2 > vnclisten = "1.2.3.4" > vncpasswd = "removed" > > on_reboot = 'restart' > on_crash= 'restart' > > usbdevice = 'tablet' I haven't tried the e1000 emulation on the refernce build Xen images in the cluster yet, but when I use the stock Generic kernel I seem to be using re(4). Not that this really matters, but its a reference point. Also, I kind of gave up on the NetBSD dom0 a while ago so I could get stuff working in the cluster. Currently I'm utilizing a CentOS 5.6 Dom0 with Xen 3.4.3 from http://www.gitco.de/repo/ Here's the config I'm using for ref8-xen64.freebsd.org that seems to be the most likely thing to work: # # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. kernel = "/usr/lib/xen/boot/hvmloader" # # device model to use: only qemu-dm available for now device_model = '/usr/lib64/xen/bin/qemu-dm' builder='hvm' # Initial memory allocation (in megabytes) for the new domain. memory = 1024 # number of CPUS vcpus = 2 # A name for your domain. All domains must have different names. name = "ref8-xen64" arch = "x86_64" #Network interface. By default emules a realtek 8139. For a NetBSD guest you # have to disable re(4) and let rtk attach to use it. # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0 # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets with # pcn(4) under NetBSD. vif = [ 'mac=00:16:3e:00:00:02, bridge=xenbr0, type=ioemu' ] #vif = [ 'mac=00:16:3e:00:00:02, bridge=xenbr0, type=vbd' ] # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. # For hvm domains you can only use hda to hdd. You can set extra types # (e.g. cdrom) disk = [ 'file:/var/virt/FreeBSD-8.2-RELEASE-amd64-disc1.iso,hdc:cdrom,r', 'file:/var/virt/ref8-xen64.bin,hda,w' ] # floppy images; this doesn't seem to work currently. Us
Re: amd64 HVM(+PV) domUs: losing 10+ minutes a day
On Mon, 2011-08-22 at 10:37 -0700, Hugo Silva wrote: > On 08/22/11 16:43, DeuZa wrote: > > 2011/8/22 Hugo Silva > > > >> Hello, > >> > > > > Hello Hugo, I was in the same cas (I think) > > I use a workaround on my VPS : > > > > machdep.independent_wallclock: 1 > > > > And the ntpd is fine now, I know it's just a workaround, but practice for > > running ntpd on Xen instances > > > > Regards, > > Hi, > > This oid does not appear to exist in the domU. Found some references in > google, but not much. May it be that it is only present on the i386 PV port? > > Regards, > > Hugo Huh, this used to exist. But anyway, try this: http://forums.freebsd.org/showpost.php?p=105415&postcount=15 Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: amd64 HVM(+PV) domUs: losing 10+ minutes a day
On Wed, 2011-08-24 at 02:24 -0700, DeuZa wrote: > > I tried setting machdep_disable_rtc_set to 1, but it made no difference. > > > > Hello, > > Same thing here wth machdep_disable_rtc_set 1, always : > > Aug 24 10:00:06 mouette kernel: rtc0: [XEN] xen_rtc_settime > > > > DeuZa: Are you running i386 PV or amd64/HVM+PV ? > > > > I just check on this VPS it's i386 > > It's your ntpd is up and running with "machdep.independent_wallclock=1" ?? > > Regards, > Just to be clear, did you set the /proc/sys/xen/independent_wallclock to 1 on the dom0 ? sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [CFT/CFR] Improved Xen Suspend/Resume Support
On Thu, 2011-09-01 at 09:55 -0700, Justin T. Gibbs wrote: > This work was sponsored by BQ Internet Corporation and they have > successfully migrated 100+ FreeBSD VMs with these changes (slightly > modified for use in 8.x). I'd like to have feedback from other > developers and FreeBSD Xen users before submitting this and/or > asking for approval to push them into 9.0. > > Thanks, > Justin > Firing these up on ref9-xen64/32 momentarily. What's the magic foo to get patch to understand p4 stuffs? Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [CFT/CFR] Improved Xen Suspend/Resume Support
On Thu, 2011-09-01 at 10:55 -0700, Justin T. Gibbs wrote: > On Sep 1, 2011, at 11:40 AM, Sean Bruno wrote: > > > On Thu, 2011-09-01 at 09:55 -0700, Justin T. Gibbs wrote: > >> This work was sponsored by BQ Internet Corporation and they have > >> successfully migrated 100+ FreeBSD VMs with these changes (slightly > >> modified for use in 8.x). I'd like to have feedback from other > >> developers and FreeBSD Xen users before submitting this and/or > >> asking for approval to push them into 9.0. > >> > >> Thanks, > >> Justin > >> > > > > Firing these up on ref9-xen64/32 momentarily. What's the magic foo to > > get patch to understand p4 stuffs? > > > > Sean > > Only some p4 commands generate 100% patch friendly output and I neglected to > use those here. You can either just feed the file name into path when it asks > or I can regenerate the doffs when I get back to my desk. > > Sorry about that. :-( > > -- > Justin Aye, I did the latter to move along. No worries. looks like ref9-xen64 is up on this patch set. I shall try some suspend resume things with the xen 3.4 tools I have on xen1.f.o Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [CFT/CFR] Improved Xen Suspend/Resume Support
On Thu, 2011-09-01 at 09:55 -0700, Justin T. Gibbs wrote: > This work was sponsored by BQ Internet Corporation and they have > successfully migrated 100+ FreeBSD VMs with these changes (slightly > modified for use in 8.x). I'd like to have feedback from other > developers and FreeBSD Xen users before submitting this and/or > asking for approval to push them into 9.0. > > Thanks, > Justin > hrm ... am I doing it right? [root@xen1 xen]# xm suspend ref9-xen64 Error: Domain is not managed by Xend lifecycle support. Usage: xm suspend Suspend a Xend managed domain [root@xen1 xen]# rpm -q -a|grep xen xen-libs-3.0.3-120.el5_6.2 xen-3.4.3-5.el5 xen-libs-3.4.3-5.el5 kernel-xen-2.6.18-238.12.1.el5 [root@xen1 xen]# Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [CFT/CFR] Improved Xen Suspend/Resume Support
On Thu, 2011-09-01 at 11:32 -0700, Justin T. Gibbs wrote: > On Sep 1, 2011, at 12:05 PM, Sean Bruno wrote: > > > On Thu, 2011-09-01 at 09:55 -0700, Justin T. Gibbs wrote: > >> This work was sponsored by BQ Internet Corporation and they have > >> successfully migrated 100+ FreeBSD VMs with these changes (slightly > >> modified for use in 8.x). I'd like to have feedback from other > >> developers and FreeBSD Xen users before submitting this and/or > >> asking for approval to push them into 9.0. > >> > >> Thanks, > >> Justin > >> > > > > hrm ... am I doing it right? > > > > [root@xen1 xen]# xm suspend ref9-xen64 > > Error: Domain is not managed by Xend lifecycle support. > > Usage: xm suspend > > > > Suspend a Xend managed domain > > [root@xen1 xen]# rpm -q -a|grep xen > > xen-libs-3.0.3-120.el5_6.2 > > xen-3.4.3-5.el5 > > xen-libs-3.4.3-5.el5 > > kernel-xen-2.6.18-238.12.1.el5 > > [root@xen1 xen]# > > > > > > > > Sean > > The domain must be "managed". You can use "xm new " to create a > managed domain. > > -- > Justin HVM enabled 9 test looks good I think. I suspended a VM, and resumed it. I assume that this is what we wanted to excercise. What other things can I do to test this code? Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [CFT][PATCH] Netfront fixes for FreeBSD-head
On Mon, 2011-09-12 at 16:36 -0700, Justin T. Gibbs wrote: > Folks, > > I'm planning to ask RE for permission to merge the following netfront > fixes (listed below) into 9.0/head. Before I do so, I'd appreciate some > community testing on the proposed patch set (attached). The main areas > of concern are: > > o TSO/LRO and performance > o Compatibility with NetBSD and other Dom0s that lack sg or TSO/LRO >support. > o Compatibility with configurations enabling ioemu on an interface. > > Thanks, > Justin Should these be applied with the suspend/resume enhancements? Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [CFT][PATCH] Netfront fixes for FreeBSD-head
On Mon, 2011-09-12 at 16:36 -0700, Justin T. Gibbs wrote: > Folks, > > I'm planning to ask RE for permission to merge the following netfront > fixes (listed below) into 9.0/head. Before I do so, I'd appreciate some > community testing on the proposed patch set (attached). The main areas > of concern are: > > o TSO/LRO and performance > o Compatibility with NetBSD and other Dom0s that lack sg or TSO/LRO >support. > o Compatibility with configurations enabling ioemu on an interface. > > Thanks, > Justin Ok, I've got ref9-xen64 and ref9-xen32 up and running and it looks good for a smoke test. I need to come up with a regression suite that will update these images and boot up to do "stuff and things" at some point. If project committer's want access here, you should be able to log in and poke around. "root" access via kerberos is totally available, but has to be cleared by clusteradm@ first. FreeBSD ref9-xen64.freebsd.org 9.0-BETA2 FreeBSD 9.0-BETA2 #2 r225561M: Wed Sep 14 14:37:48 PDT 2011 sbr...@ref9-xen64.freebsd.org:/dumpster/scratch/sbruno-scratch/test/sys/amd64/compile/XENHVM amd64 FreeBSD ref9-xen32.freebsd.org 9.0-BETA2 FreeBSD 9.0-BETA2 #0 r225561M: Wed Sep 14 15:41:40 PDT 2011 sbr...@ref9-xen32.freebsd.org:/dumpster/scratch/sbruno-scratch/test/sys/i386/compile/XEN i386 ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
I'll test this out on the VMs in the fbsd cluster later.
Sean
On Fri, 2011-12-16 at 11:32 -0800, Alan Cox wrote:
> Is anyone here actively working on fixing problems with SMP support
> under PV i386? While doing some other maintenance on the
> vm_page_alloc() callers in the source tree, I happened to take a look at
> cpu_initialize_context() in mp_machdep.c. This function is involved in
> bringing up the 2nd, 3rd, etc. CPUs on an SMP system. I spotted a
> couple obvious errors. First, the size parameter given to kmem_*()
> functions is expected to be in terms of bytes and not pages. Second, I
> believe that PV i386 requires PAE to be used. If so, there are out of
> range accesses to the array m[].
>
> Index: i386/xen/mp_machdep.c
> ===
> --- i386/xen/mp_machdep.c (revision 228561)
> +++ i386/xen/mp_machdep.c (working copy)
> @@ -810,7 +810,7 @@ cpu_initialize_context(unsigned int cpu)
> {
> /* vcpu_guest_context_t is too large to allocate on the stack.
> * Hence we allocate statically and protect it with a lock */
> - vm_page_t m[4];
> + vm_page_t m[NPGPTD + 2];
> static vcpu_guest_context_t ctxt;
> vm_offset_t boot_stack;
> vm_offset_t newPTD;
> @@ -831,8 +831,8 @@ cpu_initialize_context(unsigned int cpu)
> pmap_zero_page(m[i]);
>
> }
> - boot_stack = kmem_alloc_nofault(kernel_map, 1);
> - newPTD = kmem_alloc_nofault(kernel_map, NPGPTD);
> + boot_stack = kmem_alloc_nofault(kernel_map, PAGE_SIZE);
> + newPTD = kmem_alloc_nofault(kernel_map, NPGPTD * PAGE_SIZE);
> ma[0] = VM_PAGE_TO_MACH(m[0])|PG_V;
>
> #ifdef PAE
> @@ -854,7 +854,7 @@ cpu_initialize_context(unsigned int cpu)
> nkpt*sizeof(vm_paddr_t));
>
> pmap_qremove(newPTD, 4);
> - kmem_free(kernel_map, newPTD, 4);
> + kmem_free(kernel_map, newPTD, 4 * PAGE_SIZE);
> /*
> * map actual idle stack to boot_stack
> */
>
> ___
> freebsd-xen@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-xen
> To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
On Fri, 2011-12-16 at 11:32 -0800, Alan Cox wrote:
> Is anyone here actively working on fixing problems with SMP support
> under PV i386? While doing some other maintenance on the
> vm_page_alloc() callers in the source tree, I happened to take a look at
> cpu_initialize_context() in mp_machdep.c. This function is involved in
> bringing up the 2nd, 3rd, etc. CPUs on an SMP system. I spotted a
> couple obvious errors. First, the size parameter given to kmem_*()
> functions is expected to be in terms of bytes and not pages. Second, I
> believe that PV i386 requires PAE to be used. If so, there are out of
> range accesses to the array m[].
>
> Index: i386/xen/mp_machdep.c
> ===
> --- i386/xen/mp_machdep.c (revision 228561)
> +++ i386/xen/mp_machdep.c (working copy)
> @@ -810,7 +810,7 @@ cpu_initialize_context(unsigned int cpu)
> {
> /* vcpu_guest_context_t is too large to allocate on the stack.
> * Hence we allocate statically and protect it with a lock */
> - vm_page_t m[4];
> + vm_page_t m[NPGPTD + 2];
> static vcpu_guest_context_t ctxt;
> vm_offset_t boot_stack;
> vm_offset_t newPTD;
> @@ -831,8 +831,8 @@ cpu_initialize_context(unsigned int cpu)
> pmap_zero_page(m[i]);
>
> }
> - boot_stack = kmem_alloc_nofault(kernel_map, 1);
> - newPTD = kmem_alloc_nofault(kernel_map, NPGPTD);
> + boot_stack = kmem_alloc_nofault(kernel_map, PAGE_SIZE);
> + newPTD = kmem_alloc_nofault(kernel_map, NPGPTD * PAGE_SIZE);
> ma[0] = VM_PAGE_TO_MACH(m[0])|PG_V;
>
> #ifdef PAE
> @@ -854,7 +854,7 @@ cpu_initialize_context(unsigned int cpu)
> nkpt*sizeof(vm_paddr_t));
>
> pmap_qremove(newPTD, 4);
> - kmem_free(kernel_map, newPTD, 4);
> + kmem_free(kernel_map, newPTD, 4 * PAGE_SIZE);
> /*
> * map actual idle stack to boot_stack
> */
This seems happy on our ref9 VMs. I don't suppose this means I can go
above 768M of Ram now?
[root@xen1 sbruno]# /usr/sbin/xm create -c ref9-xen32
Using config file "/etc/xen/ref9-xen32".
Started domain ref9-xen32 (id=106)
WARNING: loader(8) metadata is missing!
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights
reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-PRERELEASE #0: Sat Dec 17 16:13:02 PST 2011
sbr...@ref9-xen32.freebsd.org:/dumpster/scratch/sbruno-scratch/9/sys/i386/compile/XEN
i386
WARNING: WITNESS option enabled, expect reduced performance.
Xen reported: 2493.756 MHz processor.
Timecounter "ixen" frequency 1953125 Hz quality 0
CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2493.76-MHz
686-class CPU)
Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17
Stepping = 6
Features=0xbfe3fbff
Features2=0xce3bd
AMD Features=0x2010
AMD Features2=0x1
real memory = 805306368 (768 MB)
avail memory = 776830976 (740 MB)
[XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0)
[XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1)
[XEN] xen_rtc_probe: probing Hypervisor RTC clock
rtc0: on motherboard
[XEN] xen_rtc_attach: attaching Hypervisor RTC clock
xenstore0: on motherboard
xc0: on motherboard
Event timer "ixen" quality 600
Timecounters tick every 10.000 msec
xenbusb_front0: on xenstore0
[XEN] hypervisor wallclock nudged; nudging TOD.
xn0: at device/vif/0 on xenbusb_front0
xn0: Ethernet address: 00:16:3e:00:00:03
xenbusb_back0: on xenstore0
xctrl0: on xenstore0
xn0: backend features: feature-sg feature-gso-tcp4
xbd0: 10240MB at device/vbd/768 on xenbusb_front0
xbd0: attaching as ad0
Timecounter "TSC" frequency 2493756000 Hz quality 800
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from ufs:/dev/ad0p2 []...
rtc0: [XEN] xen_rtc_gettime
rtc0: [XEN] xen_rtc_gettime: wallclock 1313550543 sec; 871707442 nsec
rtc0: [XEN] xen_rtc_gettime: uptime 10619933 sec; 620343100 nsec
rtc0: [XEN] xen_rtc_gettime: TOD 1324170477 sec; 492050542 nsec
Setting hostuuid: 1c127834-ab5a-c2e4-7b24-5ea29d364d9d.
Setting hostid: 0xdea9fbfd.
Entropy harvesting: interrupts ethernet point_to_point kickstart.
Starting file system checks:
/dev/ad0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ad0p2: clean, 1874771 free (883 frags, 234236 blocks, 0.0%
fragmentation)
Mounting local file systems:.
Setting hostname: ref9-xen32.freebsd.org.
xn0: link state changed to DOWN
xn0: link state changed to UP
Starting Network: lo0 xn0.
lo0: flags=8049 metric 0 mtu 16384
options=3
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff00
nd6 options=21
xn0: flags=8843 metric 0 mtu
1
Re: PV i386 patch
On Sat, 2011-12-17 at 18:01 -0800, Colin Percival wrote: > On 12/17/11 16:56, Sean Bruno wrote: > > This seems happy on our ref9 VMs. I don't suppose this means I can go > > above 768M of Ram now? > > Can't hurt to try... whatever the problem is with our code and large > amounts of RAM, the fact that it's an insta-panic during paging setup > suggests that it's something at a similar level of fail. > Nope, insta panic ... early though. 768M works, 1024M panics. [root@xen1 sbruno]# /usr/sbin/xm create -c ref9-xen32 Using config file "/etc/xen/ref9-xen32". Started domain ref9-xen32 (id=109) WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-PRERELEASE #0: Sat Dec 17 16:13:02 PST 2011 sbr...@ref9-xen32.freebsd.org:/dumpster/scratch/sbruno-scratch/9/sys/i386/compile/XEN i386 WARNING: WITNESS option enabled, expect reduced performance. panic: pmap_init: page table page is out of range cpuid = 0 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at 0xc0181d7a: movl$0,0xc0478174 ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
> > > > The code that panics shouldn't even exist in the Xen pmap. Try the > attached patch. > > Alan > Indeed how on earth did we ever use this stuff? :-) Tested to 2G on ref9-xen32.f.o should I go any higher? Sean [root@xen1 sbruno]# xm create -c ref9-xen32 Using config file "/etc/xen/ref9-xen32". Started domain ref9-xen32 (id=113) WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-PRERELEASE #1: Tue Dec 20 04:59:58 PST 2011 sbr...@ref9-xen32.freebsd.org:/dumpster/scratch/sbruno-scratch/9/sys/i386/compile/XEN i386 WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 2493.750 MHz processor. Timecounter "ixen" frequency 1953125 Hz quality 0 CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2493.75-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfe3fbff Features2=0xce3bd AMD Features=0x2010 AMD Features2=0x1 real memory = 2147483648 (2048 MB) avail memory = 2092331008 (1995 MB) [XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0) [XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1) [XEN] xen_rtc_probe: probing Hypervisor RTC clock rtc0: on motherboard [XEN] xen_rtc_attach: attaching Hypervisor RTC clock xenstore0: on motherboard xc0: on motherboard Event timer "ixen" quality 600 Timecounters tick every 10.000 msec xenbusb_front0: on xenstore0 [XEN] hypervisor wallclock nudged; nudging TOD. xn0: at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 00:16:3e:00:00:03 xenbusb_back0: on xenstore0 xctrl0: on xenstore0 xn0: backend features: feature-sg feature-gso-tcp4 xbd0: 10240MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 Timecounter "TSC" frequency 249375 Hz quality 800 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0p2 []... rtc0: [XEN] xen_rtc_gettime rtc0: [XEN] xen_rtc_gettime: wallclock 1313550543 sec; 871707442 nsec rtc0: [XEN] xen_rtc_gettime: uptime 10837322 sec; 93904105 nsec rtc0: [XEN] xen_rtc_gettime: TOD 1324387865 sec; 965611547 nsec Setting hostuuid: 1c127834-ab5a-c2e4-7b24-5ea29d364d9d. Setting hostid: 0xdea9fbfd. Entropy harvesting: interrupts ethernet point_to_point kickstart. Starting file system checks: /dev/ad0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0p2: clean, 1874750 free (878 frags, 234234 blocks, 0.0% fragmentation) Mounting local file systems:. Setting hostname: ref9-xen32.freebsd.org. xn0: link state changed to DOWN xn0: link state changed to UP Starting Network: lo0 xn0. lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff00 nd6 options=21 xn0: flags=8843 metric 0 mtu 1500 options=503 ether 00:16:3e:00:00:03 nd6 options=29 media: Ethernet manual status: active Starting devd. DHCPREQUEST on xn0 to 255.255.255.255 port 67 DHCPACK from 69.147.83.62 bound to 69.147.83.99 -- renewal in 900 seconds. add net :::0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 Waiting 30s for the default route interface: . Mounting NFS file systems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Creating and/or trimming log files. Starting syslogd. No core dumps found. Setting date via ntp. rtc0: [XEN] xen_rtc_settime 20 Dec 05:18:03 ntpdate[689]: step time server 69.147.83.54 offset -29618.895999 sec NFS access cache time=60 Setting NIS domain: freebsd. Starting rpcbind. Starting ypbind. Clearing /tmp (X related). Updating motd:. Starting ntpd. Starting sshd. Starting cron. Starting background file system checks in 60 seconds. Tue Dec 20 05:18:04 PST 2011 FreeBSD/i386 (ref9-xen32.freebsd.org) (xc0) login: ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
On Tue, 2011-12-20 at 10:49 -0800, Alan Cox wrote: > On 12/20/2011 07:28, Sean Bruno wrote: > >> The code that panics shouldn't even exist in the Xen pmap. Try the > >> attached patch. > >> > >> Alan > >> > > Indeed how on earth did we ever use this stuff? :-) > > > > Tested to 2G on ref9-xen32.f.o should I go any higher? > > Sure. Right now, I don't know of any reason that it should crash with > more memory. :-) > > Do either of you know if there is a PR in gnats for this 768 MB > limitation bug that I should mention in the commit log? > > Alan > No, I just checked and I didn't put a PR in ... lame. I think I discussed it with colin or kip, but I don't remember if we ever figured out anything else. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
On Tue, 2011-12-20 at 12:09 -0800, Alan Cox wrote: > On 12/20/2011 13:57, Sean Bruno wrote: > > On Tue, 2011-12-20 at 10:49 -0800, Alan Cox wrote: > >> On 12/20/2011 07:28, Sean Bruno wrote: > >>>> The code that panics shouldn't even exist in the Xen pmap. Try the > >>>> attached patch. > >>>> > >>>> Alan > >>>> > >>> Indeed how on earth did we ever use this stuff? :-) > >>> > >>> Tested to 2G on ref9-xen32.f.o should I go any higher? > >> Sure. Right now, I don't know of any reason that it should crash with > >> more memory. :-) > >> > >> Do either of you know if there is a PR in gnats for this 768 MB > >> limitation bug that I should mention in the commit log? > >> > >> Alan > >> > > > > No, I just checked and I didn't put a PR in ... lame. > > > > I think I discussed it with colin or kip, but I don't remember if we > > ever figured out anything else. > > > > Ok. I'll commit the patch shortly. (Note that what I'll commit will > remove another bit of unnecessary code.) > > Alan > I suspect that this earns you +1 beer at bsdcan this year. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
On Tue, 2011-12-20 at 12:12 -0800, Colin Percival wrote: > kern/153789. Yeah, that's definitely this issue. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
On Wed, 2011-12-21 at 12:47 -0800, Alan Cox wrote: > Can you please try the attached patch? I'm trying to reduce the number > of differences between the native and Xen pmap implementations. > > Alan > I will test this today, this should apply against 9 and -current ? Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
On Wed, 2011-12-21 at 12:47 -0800, Alan Cox wrote: > Can you please try the attached patch? I'm trying to reduce the number > of differences between the native and Xen pmap implementations. > > Alan > Without really looking at the output, I note that this didn't apply cleanly against -head ... can you regenerate it? Sean Patching file i386/xen/pmap.c using Plan A... Reversed (or previously applied) patch detected! Assume -R? [y] Hunk #1 succeeded at 5. Hunk #2 succeeded at 75. Hunk #3 succeeded at 136 (offset -2 lines). Hunk #4 succeeded at 152 (offset -2 lines). Hunk #5 succeeded at 160 (offset -2 lines). Hunk #6 succeeded at 177 (offset -2 lines). Hunk #7 succeeded at 192 (offset -2 lines). Hunk #8 failed at 206. Hunk #9 succeeded at 251 (offset -2 lines). Hunk #10 failed at 284. Hunk #11 failed at 333. Hunk #12 succeeded at 365 with fuzz 2 (offset 13 lines). Hunk #13 succeeded at 407 (offset 18 lines). Hunk #14 succeeded at 437 (offset 13 lines). Hunk #15 succeeded at 462 with fuzz 1 (offset 18 lines). Hunk #16 succeeded at 490 (offset 13 lines). Hunk #17 succeeded at 509 (offset 18 lines). Hunk #18 succeeded at 512 (offset 13 lines). Hunk #19 succeeded at 656 (offset 18 lines). Hunk #20 succeeded at 675 (offset 13 lines). Hunk #21 succeeded at 731 (offset 18 lines). Hunk #22 succeeded at 754 (offset 13 lines). Hunk #23 failed at 813. Hunk #24 succeeded at 833 (offset 6 lines). Hunk #25 succeeded at 950 (offset 13 lines). Hunk #26 succeeded at 958 (offset 6 lines). Hunk #27 succeeded at 974 (offset 13 lines). Hunk #28 succeeded at 984 (offset 6 lines). Hunk #29 succeeded at 999 (offset 13 lines). Hunk #30 succeeded at 1018 (offset 6 lines). Hunk #31 succeeded at 1125 (offset 13 lines). Hunk #32 succeeded at 1128 (offset 6 lines). Hunk #33 succeeded at 1154 with fuzz 1 (offset 13 lines). Hunk #34 succeeded at 1230 with fuzz 2 (offset -12 lines). Hunk #35 succeeded at 1272 (offset 14 lines). Hunk #36 succeeded at 1255 (offset -12 lines). Hunk #37 succeeded at 1310 (offset 14 lines). Hunk #38 failed at 1342. Hunk #39 succeeded at 1344 (offset -12 lines). Hunk #40 succeeded at 1378 (offset 14 lines). Hunk #41 succeeded at 1364 (offset -12 lines). Hunk #42 failed at 1391. Hunk #43 succeeded at 1442 (offset 9 lines). Hunk #44 succeeded at 1440 (offset -12 lines). Hunk #45 succeeded at 1514 with fuzz 1 (offset 9 lines). Hunk #46 succeeded at 1524 (offset -11 lines). Hunk #47 succeeded at 1563 (offset 9 lines). Hunk #48 succeeded at 1660 (offset -11 lines). Hunk #49 succeeded at 1704 with fuzz 2 (offset 9 lines). Hunk #50 failed at 1721. Hunk #51 succeeded at 1715 (offset -19 lines). Hunk #52 succeeded at 1760 (offset 12 lines). Hunk #53 succeeded at 1744 (offset -19 lines). Hunk #54 failed at 1784. Hunk #55 succeeded at 1837 with fuzz 2 (offset 11 lines). Hunk #56 succeeded at 1842 with fuzz 1 (offset -20 lines). Hunk #57 failed at 1853. Hunk #58 succeeded at 1899 (offset 11 lines). Hunk #59 failed at 2044. Hunk #60 succeeded at 2027 (offset -21 lines). Hunk #61 failed at 2074. Hunk #62 failed at 2104. Hunk #63 succeeded at 2217 (offset 12 lines). Hunk #64 succeeded at 2204 (offset -21 lines). Hunk #65 succeeded at 2257 (offset 12 lines). Hunk #66 succeeded at 2352 (offset -21 lines). Hunk #67 succeeded at 2411 (offset 12 lines). Hunk #68 succeeded at 2457 (offset -21 lines). Hunk #69 succeeded at 2537 (offset 12 lines). Hunk #70 succeeded at 2749 (offset -21 lines). Hunk #71 succeeded at 2795 (offset 12 lines). Hunk #72 succeeded at 2780 (offset -21 lines). Hunk #73 failed at 2804. Hunk #74 succeeded at 2867 (offset 12 lines). Hunk #75 succeeded at 2853 (offset -21 lines). Hunk #76 succeeded at 2917 (offset 12 lines). Hunk #77 succeeded at 2897 (offset -21 lines). Hunk #78 succeeded at 2955 (offset 12 lines). Hunk #79 failed at 2968. Hunk #80 succeeded at 2971 (offset -20 lines). Hunk #81 succeeded at 3061 (offset 12 lines). Hunk #82 succeeded at 3053 with fuzz 1 (offset -20 lines). Hunk #83 succeeded at 3102 (offset 12 lines). Hunk #84 succeeded at 3110 (offset -20 lines). Hunk #85 succeeded at 3153 (offset 12 lines). Hunk #86 succeeded at 3136 (offset -20 lines). Hunk #87 succeeded at 3330 (offset 12 lines). Hunk #88 succeeded at 3330 (offset -21 lines). Hunk #89 succeeded at 3411 (offset 12 lines). Hunk #90 succeeded at 3412 (offset -21 lines). Hunk #91 succeeded at 3462 (offset 12 lines). Hunk #92 succeeded at 3458 (offset -21 lines). Hunk #93 failed at 3552. Hunk #94 succeeded at 3597 (offset 13 lines). Hunk #95 failed at 3624. Hunk #96 failed at 3652. Hunk #97 succeeded at 3630 (offset -21 lines). Hunk #98 succeeded at 3692 (offset 13 lines). Hunk #99 succeeded at 3689 (offset -21 lines). Hunk #100 failed at 3702. Hunk #101 succeeded at 3747 (offset 13 lines). Hunk #102 succeeded at 3797 (offset -27 lines). Hunk #103 succeeded at 3901 (offset 13 lines). Hunk #104 succeeded at 3883 (offset -27 lines). Hunk #105 succeeded at 3966 (offset 13 lines). Hunk #106 failed at 3993. Hunk #107 succeeded a
Re: PV i386 patch
On Tue, 2011-12-27 at 09:40 -0800, Alan Cox wrote: > On 12/23/2011 16:25, Sean Bruno wrote: > > On Wed, 2011-12-21 at 12:47 -0800, Alan Cox wrote: > >> Can you please try the attached patch? I'm trying to reduce the number > >> of differences between the native and Xen pmap implementations. > >> > >> Alan > >> > > > > Without really looking at the output, I note that this didn't apply > > cleanly against -head ... can you regenerate it? > > > > My bad. I gave you the wrong patch. Try this instead. > > Alan > Initial testing looks ok from here. Single CPU PV DomU is up and running as ref10-xen32.f.o if you want to poke around at all. I'm updating the HVM enabled ref10-xen64.f.o as well to check it out. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
On Tue, 2011-12-27 at 22:14 -0800, Adrian Chadd wrote: > On 27 December 2011 15:24, Sean Bruno wrote: > > > Initial testing looks ok from here. Single CPU PV DomU is up and > > running as ref10-xen32.f.o if you want to poke around at all. > > > > I'm updating the HVM enabled ref10-xen64.f.o as well to check it out. > > Since I don't yet have my test environment going here, is anyone here > running (developer) accessible PVM hosts (32 bit) that I can get > access to? > I can run a whole sleuth of thrashing tests on it to see if it breaks. > > Thanks, > > > > Adrian Yes. I've been keeping a linux dom0 running in the fbsd cluster. Go ahead and poke at ref10-xen32.f.o ... that's what its there for. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
On Thu, 2011-12-29 at 12:22 -0800, Alan Cox wrote: > Please try this patch. It eliminates a race condition that might > actually account for some of the crashes in FreeBSD >= 9 on Xen. > > Alan > ref10-xen32.freebsd.org has this applied now. Looks ok to me? Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV i386 patch
On Thu, 2011-12-29 at 14:52 -0800, Alan Cox wrote: > On 12/29/2011 16:28, Sean Bruno wrote: > > On Thu, 2011-12-29 at 12:22 -0800, Alan Cox wrote: > >> Please try this patch. It eliminates a race condition that might > >> actually account for some of the crashes in FreeBSD>= 9 on Xen. > >> > >> Alan > >> > > ref10-xen32.freebsd.org has this applied now. Looks ok to me? > > > > > I know that lmbench's bw_pipe program exercises the code path that I > changed if you want to give it a bit more testing. > > Alan > Ok, I ran "a thing" ... I have a lot of poking around to do in lmbench now. Thanks for pointing me at this. Cursory run with patch "xen-pmap.c" [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe Pipe bandwidth: 892.52 MB/sec [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe -N 5 Pipe bandwidth: 982.46 MB/sec [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe -N 5 -P 2 Pipe bandwidth: 899.34 MB/sec Cursory run of vanilla-current: [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe Pipe bandwidth: 984.37 MB/sec [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe -N 5 Pipe bandwidth: 977.54 MB/sec [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe -N 5 -P 2 Pipe bandwidth: 887.26 MB/sec [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ uname -a FreeBSD ref10-xen32.freebsd.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r228971: Fri Dec 30 18:27:01 UTC 2011 sbr...@ref10-xen32.freebsd.org:/var/tmp/dumpster/scratch/sbruno-scratch/head/sys/XEN i386 ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: 8.2 releng
Can you send in your xen domu config? Sean On Tue, 2012-01-03 at 01:56 -0800, Richard Kojedzinszky wrote: > Dear users, > > I forget to mention, If i remove pf and pflog from the config, then the > built kernel boots well under xen. > > Regards, > > > Kojedzinszky Richard > Euronet Magyarorszag Informatikai Zrt. > > On Tue, 3 Jan 2012, Richard Kojedzinszky wrote: > > > Date: Tue, 3 Jan 2012 10:40:13 +0100 (CET) > > From: Richard Kojedzinszky > > To: freebsd-xen@FreeBSD.org > > Subject: 8.2 releng > > > > Dear xen developers, > > > > I have a xen domU with the attached config, and unfortunately it does not > > boot. I am compiling it with: > > $ make kernel KERNCONF=DB WERROR= > > > > And it only makes a crash dump in the hosts xm dmesg. > > > > It is a recent 8.2 releng src tree. > > > > What should I change to make this work? > > > > Regards, > > > > Kojedzinszky Richard > > Euronet Magyarorszag Informatikai Zrt. > ___ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: 8.2 releng
No, not the kernel config. See attached example. Sean On Tue, 2012-01-03 at 08:16 -0800, Richard Kojedzinszky wrote: > Dear Sean, > > Attached. > > Thanks in advance, > > > Kojedzinszky Richard > Euronet Magyarorszag Informatikai Zrt. > > On Tue, 3 Jan 2012, Sean Bruno wrote: > > > Date: Tue, 03 Jan 2012 08:00:28 -0800 > > From: Sean Bruno > > To: Richard Kojedzinszky > > Cc: "freebsd-xen@freebsd.org" > > Subject: Re: 8.2 releng > > > > Can you send in your xen domu config? > > > > Sean > > > > On Tue, 2012-01-03 at 01:56 -0800, Richard Kojedzinszky wrote: > >> Dear users, > >> > >> I forget to mention, If i remove pf and pflog from the config, then the > >> built kernel boots well under xen. > >> > >> Regards, > >> > >> > >> Kojedzinszky Richard > >> Euronet Magyarorszag Informatikai Zrt. > >> > >> On Tue, 3 Jan 2012, Richard Kojedzinszky wrote: > >> > >>> Date: Tue, 3 Jan 2012 10:40:13 +0100 (CET) > >>> From: Richard Kojedzinszky > >>> To: freebsd-xen@FreeBSD.org > >>> Subject: 8.2 releng > >>> > >>> Dear xen developers, > >>> > >>> I have a xen domU with the attached config, and unfortunately it does not > >>> boot. I am compiling it with: > >>> $ make kernel KERNCONF=DB WERROR= > >>> > >>> And it only makes a crash dump in the hosts xm dmesg. > >>> > >>> It is a recent 8.2 releng src tree. > >>> > >>> What should I change to make this work? > >>> > >>> Regards, > >>> > >>> Kojedzinszky Richard > >>> Euronet Magyarorszag Informatikai Zrt. > >> ___ > >> freebsd-xen@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-xen > >> To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" > > > > # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. #kernel = "/usr/lib/xen/boot/hvmloader" kernel = "/var/virt/freebsd-8-stable-i386-domu-kernel" # # device model to use: only qemu-dm available for now #device_model = '/usr/lib64/xen/bin/qemu-dm' #builder='hvm' # Initial memory allocation (in megabytes) for the new domain. memory = 855 # number of CPUS vcpus = 1 # A name for your domain. All domains must have different names. name = "ref8-xen32" arch = "i386" #Network interface. By default emules a realtek 8139. For a NetBSD guest you # have to disable re(4) and let rtk attach to use it. # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0 # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets with # pcn(4) under NetBSD. #vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0, type=ioemu' ] vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0, type=vbd' ] # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. # For hvm domains you can only use hda to hdd. You can set extra types # (e.g. cdrom) disk = [ 'file:/var/virt/ref8-xen32.bin,hda,w' ] extra = "vfs.root.mountfrom=ufs:/dev/ad0s1a" # floppy images; this doesn't seem to work currently. Use a iso image instead. #fda = '/home/domains/boot1.fs' # boot device: a = floppy, c= hard drive, d= cdrom (with the disk entry # before) # # boot CDROM image #boot='d' # boot from DISK file #boot='c' # boot from DHCP/PXE then DISK file boot='nc' # By default, 'xm create' will try to open an X window on the current display # for the virtal framebuffer. You can have the virtal framebuffer in vnc # instead, and connect using a vnc client (using localhost:$vncdisplay) # If vncunused is set to 1 (this is the default value), vncdisplay # will be set to the first unused port; so it&
Re: FreeBSD at Amazon EC2 status
On Tue, 2012-01-03 at 09:07 -0800, Alexandre Biancalana wrote: > Hi lists, > > What´s is the current state of FreeBSD running on Amazon EC2 ? Is > this stable ? Looking at Colin's status page > (http://www.daemonology.net/freebsd-on-ec2/) looks like there´s no > active development on that. > > Does someone running production workload with FreeBSD on EC2 ? > > I'm interested in running network (dns and http with accept filter) > and memory/buffer cache intensive applications on m1.small, m1.large > and m2.xlarge instances. > > Any thoughts ? > > (I had posted this message to -question list, sorry for whom already > received this) > > Best Regards and Happy New Year ! > Alexandre I suspect that the folks on x...@freebsd.org could comment on this. FreeBSD on EC2 is working fine as far as I know, however I don't personally use it at this time. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: 8.2 releng
On Tue, 2012-01-03 at 11:55 -0800, Richard Kojedzinszky wrote: > bootloader = "/usr/lib/xen-4.0/bin/pygrub" Ok, let me see if I can get a Xen 4 Dom0 working in the cluster today. I don't think that I've seen any issues with a Xen 3.4.3 Dom0. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: i386/XENHVM now works
On Sun, 2012-01-15 at 18:42 -0800, Colin Percival wrote: > Hi all, > > i386/XENHVM now works on HEAD. I'll MFC to stable/9 in a week or two. > +1 beer Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: 8.2 releng
On Mon, 2012-01-16 at 02:58 -0800, Richard Kojedzinszky wrote: > Dear Sean, > > I've investigated the problem, and found the following: > > When starting with > # xm create -c /dev/null kernel=/home/krichy/kernel extra="kern.hz=100" > memory=464 > > The kernel boots up, but when adding only one more MB to it, as: > # xm create -c /dev/null kernel=/home/krichy/kernel extra="kern.hz=100" > memory=465 > > it does crash. > > The config is the simple one I've attached previously, with pf and pflog > disabled. But again, if I enable pf and pflog, the domain starts with > 512MB ram well. > > Regards, Ah, this one! Alan has resolved these issues in xen on -current at the moment. I suspect an MFC is coming soon: http://svnweb.freebsd.org/base/head/sys/i386/xen/?view=log If you want to try r229007, r228935, r228923, r228747, r228746 and r228522 on stable/8 we'd appreciate the testing. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: XENHVM on 9-stable
On Mon, 2012-05-07 at 03:50 -0700, Ivan Voras wrote: > Hi, > > Is XENHVM usable on 9-STABLE amd64? I seem to recall some problems > early in 9-current. > ___ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" Btw, I do have vm's in the cluster running for this purpose. ref[8,9,10]-xen64 Sean p.s pv 32bit ref[8,9,10]-xen32 ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD Xen Dom0 Support
On Wed, 2012-05-30 at 07:56 -0700, Carsten Heesch wrote: > However, if you intend to run 64bit, you are restricted to HVM (use > the XENHVM kernel to get better performance from the optimised device > drivers for HVM). > If you are planning on running 32bit, you can use PV. > I think that is still valid for 9.0. And mind you, PV is (or was?) > also limited to about 850M memory in the DomU. > > A couple of nits here, alc@ fixed the PV memory restrictions so the 850M limit isn't a thing anymore: FreeBSD ref9-xen32.freebsd.org 9.0-STABLE FreeBSD 9.0-STABLE #2 r231914: Mon Feb 20 05:30:49 PST 2012 sbr...@ref9-xen32.freebsd.org:/var/tmp/dumpster/scratch/sbruno-scratch/9/sys/XEN i386 [sbruno@ref9-xen32 ~]$ sysctl hw.physmem hw.physmem: 2136674304 And, I think, there is a 64bit PV config now in development at: http://svnweb.freebsd.org/base/projects/amd64_xen_pv/ This is prerequisite work for a dom0 on freebsd which is under development. Stay tuned, things are happening! Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: building kernel modules with XENHVM kernel
On Sun, 2012-06-03 at 10:17 -0700, Colin Percival wrote: > Hi all, > > Ever since the XENHVM kernel config file was added, it has included > > makeoptionsMODULES_OVERRIDE="" > > I don't see any reason for doing this, and I'd like to remove it; I took > it out of the config file I use for EC2 instances a long time ago, and > there are people using e.g., zfs.ko without problems. > > Any objections? > Nope, we're not using it over here at Yahoo either. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: kern/166174: [xen] Problems ROOT MOUNT ERROR <freebsd 8.3>
The following reply was made to PR kern/166174; it has been noted by GNATS. From: Sean Bruno To: bug-follo...@freebsd.org, ilsuj...@gmail.com Cc: Subject: Re: kern/166174: [xen] Problems ROOT MOUNT ERROR <freebsd 8.3> Date: Mon, 04 Jun 2012 15:14:51 -0700 I've got stable/8, stable/9 and -current XEN PV and XENHVM instances running in the freebsd cluster and have done so for quite some time. http://people.freebsd.org/~sbruno/ref8-xen32.txt http://people.freebsd.org/~sbruno/ref8-xen64.txt Does this help at all? Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Compiling error for amd64 on FreeBSD9.0 with XENHVM when include xen console driver.
On Tue, 2012-07-31 at 22:32 -0700, Wei Xu wrote: > Hi All, > I'm trying to compile new kernel with Xen Console driver on AMD 64 > platform, it's not included by default, > I got compile error like this , I checked the code and i386 has the > pc_ipi_to_irq but amd64 doesn't, > look like it hasn't been experience with amd64, is there anyone know > whether it can work? thanks. > Since there's no PV support for amd64 yet. I don't think you need the console driver. QEMU will emulate the uart(4) device for you and freebsd will use the device as its serial console. >From the dom0, you would run "xm console ". Is this what you mean to do? Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Compiling error for amd64 on FreeBSD9.0 with XENHVM when include xen console driver.
I run a linux Dom0 (64bit RHEL 5) currently for testing purposes in the freebsd cluster. We have 32bit (PV) and 64bit (HVM) instances running there. How are you installing FreeBSD on your Dom0? Are you starting with HVM support and the ISO image and then converting to PV support? Sean On Thu, 2012-08-02 at 02:36 -0700, Wei Xu wrote: > Sean, > Thanks for your comments. > > Current I'm trying to investigate if I can porting the Console Driver > to Solaris. > > I know the uart emulated by QEMU, but it's not my purpose to use it, I > just want to try the console driver with Hypervisor itself, Must it > bundle with PV? Does XENHVM make sense too? > > I am not familiar with how the console driver works by comparing to > Qemu serial, so I'll be really appreciated if you can give some words > about that, thanks. > > To verify it, I installed a new 32 bit i386 FreeBSD guest domain and > compiled the kernel with XEN support, that means already included the > console driver, but after I installed the new kernel, system can't > boot up after loaded the kernel, both the Xen and the Dom0 are 64 bit, > so i guess maybe it can't work for 64bit Hypervisor and Dom0, I wonder > how can I verify the console driver? > > Regards, > Wei > > > On Thu, Aug 2, 2012 at 2:02 AM, Sean Bruno > wrote: > On Tue, 2012-07-31 at 22:32 -0700, Wei Xu wrote: > > Hi All, > > I'm trying to compile new kernel with Xen Console driver on > AMD 64 > > platform, it's not included by default, > > I got compile error like this , I checked the code and i386 > has the > > pc_ipi_to_irq but amd64 doesn't, > > look like it hasn't been experience with amd64, is there > anyone know > > whether it can work? thanks. > > > > > Since there's no PV support for amd64 yet. I don't think you > need the > console driver. QEMU will emulate the uart(4) device for you > and > freebsd will use the device as its serial console. > > >From the dom0, you would run "xm console ". Is this > what you > mean to do? > > Sean > > ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Compiling error for amd64 on FreeBSD9.0 with XENHVM when include xen console driver.
On Thu, 2012-08-02 at 19:21 -0700, Wei Xu wrote: > My Dom0 is Oracle Linux(64bit too), Xen version is 4.0.2, I installed > FreeBSD with the official iso image, that's > "FreeBSD-9.0-RELEASE-i386-dvd1.iso", I'm not sure if it was started as > HVM by default, how can i check it? > If the VM started up at all, it had to be running via full hardware virtualization. :-) > How to convert it to PV support, i just compiled and installed the src > with the "XEN" config in the source tree, I think that will include PV > support, since "XEN" is defined in the options, right? > Correct. You compile your i386 kernel with the XEN kernel config, then you need to copy that kernel into your Dom0 and reconfigure the VM to be PV and boot with no HVM options. I'm not sure how to do that with the tools that you have access to, but I did this by editing the xen domU config file for the virtual machine. Here's an example of my DomU config for your reference. Of course, this is a Xen 3 hypervisor, so your changes might have to be different( xl create vs xm create). # # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. #kernel = "/usr/lib/xen/boot/hvmloader" kernel = "/var/virt/freebsd-9.current-i386-domu-kernel" # # device model to use: only qemu-dm available for now #device_model = '/usr/lib64/xen/bin/qemu-dm' #builder='hvm' # Initial memory allocation (in megabytes) for the new domain. memory = 2048 # number of CPUS vcpus = 1 # A name for your domain. All domains must have different names. name = "ref9-xen32" arch = "i386" #Network interface. By default emules a realtek 8139. For a NetBSD guest you # have to disable re(4) and let rtk attach to use it. # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0 # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets with # pcn(4) under NetBSD. #vif = [ 'mac=00:16:3e:00:00:03, bridge=xenbr0, type=ioemu' ] vif = [ 'mac=00:16:3e:00:00:03, bridge=xenbr0, type=vbd' ] # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. # For hvm domains you can only use hda to hdd. You can set extra types # (e.g. cdrom) disk = [ 'file:/var/virt/ref9-xen32.bin,hda,w', 'file:/var/virt/ref9-xen32_scratch.bin,hdb,w' ] # floppy images; this doesn't seem to work currently. Use a iso image instead. #fda = '/home/domains/boot1.fs' extra = "vfs.root.mountfrom=ufs:/dev/ad0p2,kern.hz=100" # boot device: a = floppy, c= hard drive, d= cdrom (with the disk entry # before) # # boot CDROM image #boot='d' # boot from DISK file #boot='c' # boot from DHCP/PXE then DISK file boot='nc' # By default, 'xm create' will try to open an X window on the current display # for the virtal framebuffer. You can have the virtal framebuffer in vnc # instead, and connect using a vnc client (using localhost:$vncdisplay) # If vncunused is set to 1 (this is the default value), vncdisplay # will be set to the first unused port; so it's recommended to #vnc = 1 #vncdisplay = 3 #vncunused = 1 #vncpasswd='' #Xen emulates a PS/2 mouse, but the pointer in the guest has difficulties # tracking the absolute position. Xen can emulate a USB tablet in addition # to the mouse which will report the absolute position of the pointer, # and make the mouse much easier to use. # usb=1 usbdevice='tablet' #usbdevice='mouse' acpi = 1 serial='pty' on_reboot='restart' # ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
RE: stock Xen kernels on 9.0 release
On Sat, 2012-08-04 at 20:22 -0700, Jay West wrote: > The stock XEN kernel (x86) was broken on 9.0 release, and appears to still > be broken on 9.1 Beta. Is there some way that you can post screen shots of this "brokeness" for us? Either the console output into a pastebin or screen shots of the boot up? sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: On porting xen to Freebsd7
On Wed, 2012-08-08 at 13:53 -0700, arvind viswanathan wrote: > Hi, > > The OS that I work on is a flavor of FreeBSD7 and I am working on making it > work as a paravirtualized dom U. I was under the impression that I may have > to port a network driver and scsi driver to my current FreeBSD version and > I should be good to go. But that does not seem to be the case. I could not > find any PV drivers that have to ported to FreeBSD 7.0 Most of the related > threads started with FreeBSD8.0 or 9.0 and asked me to compile the kernel > with special flags. I am not in a position where I can simply upgrade to > the next FreeBSD version and evaluate xen, but I have to port the xen > subsystem into FreeBSD 7.0 Does any one know the modules that have to be > installed in FreeBSD7.0 to make it a PV domU. If this post does not have > enough info I can provide more information. > PS: would be really useful if a high level comment can also be provided. > > Thanks > Arvind > ___ I'd probably start with http://svnweb.freebsd.org/base/projects/stable_7_xen/ If its too far out of date, let me know and I'll update the bits that don't work. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Q on types of xen virtualization
On Thu, 2012-08-09 at 16:30 -0700, arvind viswanathan wrote: > Hi, > > I use a version of Freebsd 7 for my work and I was able to brint it up in > Open xen 4.2 However the, OS version I use does not have any xen related > files in it (no xen device folder, no xen folder in sys.., no change to the > kernel config either) But the server we use supports virtualization. So is > the mode that we are currently working in referred to as pure HVM ? I also > hear about PV HVM and purely PV. I guess in PV HVM, we use a XEN > configuration file and run on a machine supporting virtualization and > currently 64 bit machines can only be run this way ? Can some one confirm > if my understanding is right. > Thanks > arvind > ___ For full PV support, you can only use a 32bit version of FreeBSD 8 and higher via the XEN kernel config. For HVM mode you can use 64bit FreeBSD 8 and higher with the XENHVM kernel config. There is no PV support in 64bit mode at this time. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Q on types of xen virtualization
On Thu, 2012-08-09 at 17:28 -0700, arvind viswanathan wrote: > Thanks Sean. the freebsd that I use does not have xen related change set. > So is it a Xen HVM or is it simply HVM. Also in case of 64 bit, its > mentioned that if xen drivers are supported performance improves ? Any > numbers on the improvement on that was achieved with and without the xen > drivers ? > Thanks > Arvind *IF* you are booting a 64bit FreeBSD vm, it will be HVM until you recompiled using the XENHVM kernel config to build and install a new kernel. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Q regarding XENHVM kernel
On Fri, 2012-08-10 at 12:36 -0700, arvind viswanathan wrote: > Hi, > > > > In full PV kernel, procedure insists that domU kernel be copied to dom0. > For XENHVM kernel, do we still have to copy the domU kernel to dom0 ? > > > > Thanks > > arvind > ___ No, we still boot via QEMU in this case, you just get some drivers paravirtualized. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: xen development in Freebsd 7
On Tue, 2012-08-21 at 11:06 -0700, arvind viswanathan wrote: > Hi, > > Is the xen addition to FreeBSD 7, > http://svnweb.freebsd.org/base/projects/stable_7_xen/?view=log a backport > of xen relateed changes from 8_2 ? > > Thanks > Arvind I tried to mirror -head on these changes. They are the same changes I made at work. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: xenbusb_nop_confighook_cb timeout and cd issue
On Mon, 2012-12-03 at 19:04 +0100, Egoitz Aurrekoetxea Aurre wrote:
> Good morning,
>
> After doing some checks and debugs about this problem, I can conclude that :
> under Xen 4.1.3 on Debian Wheezy it works properly although in XCP1.6 if you
> remove the cd drive from the vm works too. I'm going to describe the two test
> environments have used for debugging this :
>
> ENV 1.- XCP 1.6 XEN 4.1.3 + FREEBSD 9.1-RC3 :
>
> As you can see with an iso image mounted and without it, the boot process
> gets stuck there….. (I paste here both screenshot location).
>
> http://postfixquotareject.ramattack.net/PastedGraphic-8.tiff
> http://postfixquotareject.ramattack.net/PastedGraphic-11.tiff
>
>
> I have placed here two examples, with an empty (but existing) cd drive and
> with a iso mounted in the drive.
>
> BUT If I do a in the XCP shell :
>
> xe vm-cd-remove uuid=08aec342-9572-8690-5e58-91d1b1f0aab2 cd-name=xs-tools.iso
>
> The drive is being removed from the vm and it boots normally. This is the
> workaround I'm using for the moment.
>
> Another debugging check I have done too is to apply this patch (although it's
> just for testing purposes and for checking if cd drive works) to see how the
> drive behaves after booting but without stopping in that loop of the FreeBSD
> kernel source code.
>
> --- /usr/src/sys/kern/subr_autoconf.c-defecto 2012-10-10 13:51:27.0
> +0200
> +++ /usr/src/sys/kern/subr_autoconf.c 2012-10-10 18:21:51.0 +0200
> @@ -133,16 +133,17 @@
> /* Block boot processing until all hooks are disestablished. */
> mtx_lock(&intr_config_hook_lock);
> warned = 0;
> - while (!TAILQ_EMPTY(&intr_config_hook_list)) {
> + /* while (!TAILQ_EMPTY(&intr_config_hook_list)) { */
> if (msleep(&intr_config_hook_list, &intr_config_hook_lock,
> 0, "conifhk", WARNING_INTERVAL_SECS * hz) ==
> EWOULDBLOCK) {
> mtx_unlock(&intr_config_hook_lock);
> warned++;
> run_interrupt_driven_config_hooks_warning(warned);
> mtx_lock(&intr_config_hook_lock);
> }
> - }
> + /* } */
> mtx_unlock(&intr_config_hook_lock);
> }
>
> After applying this patch, kernel boots under XCP 1.6Beta and cd can be
> mounted in the shell (should say I have not noticed about IRQ problems after
> this). It seems like FreeBSD domU is not able to continue the boot process
> because it's not able to finish up some test related to THIS (the cd drive)
> device setup (IRQ assigning tests I assume concretely) that should succeed
> before being able to continue the boot process.
>
> ENV 2.- Debian Wheezy (testing) XEN 4.1.3 + FreeBSD 9.1-RC3 :
>
> Here is the concrete environment and config :
>
> root@pruebas-xen-egoitz:~# uname -ar
> Linux pruebas-xen-egoitz 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux
>
> root@pruebas-xen-egoitz:~# cat /etc/issue
> Debian GNU/Linux wheezy/sid \n \l
>
> root@pruebas-xen-egoitz:~# dpkg -l | grep -i xen
> ii libxen-4.1 4.1.3-4 amd64
> Public libs for Xen
> ii libxenstore3.0 4.1.3-4 amd64
> Xenstore communications library for Xen
> ri linux-image-2.6.32-5-xen-amd64 2.6.32-46 amd64
> Linux 2.6.32 for 64-bit PCs, Xen dom0 support
> rc xen-hypervisor-4.0-amd64 4.0.1-5.4 amd64
> The Xen Hypervisor on AMD64
> ii xen-hypervisor-4.1-amd64 4.1.3-4 amd64
> Xen Hypervisor on AMD64
> ii xen-linux-system-3.2.0-4-amd64 3.2.32-1 amd64
> Xen system with Linux 3.2 on 64-bit PCs (meta-package)
> ii xen-linux-system-amd64 3.2+46amd64
> Xen system with Linux for 64-bit PCs (meta-package)
> ii xen-system-amd64 4.1.3-4 amd64
> Xen System on AMD64 (meta-package)
> ii xen-tools 4.3.1-1 all
> Tools to manage Xen virtual servers
> ii xen-utils-4.1 4.1.3-4 amd64
> XEN administrative tools
> ii xen-utils-common 4.1.3-4 all
> Xen administrative tools - common files
> ii xenstore-utils 4.1.3-4 amd64
> Xenstore utilities for Xen
>
> root@pruebas-xen-egoitz:~# xm list
> NameID Mem VCPUs State
> Time(s)
> Domain-0 0 6908 8 r- 1526.2
> freebsd90js.ramattack.net 24 512 2 -b 59.9
>
> I normally create the life cycle with a xm new, later xm start……. the config
> file is :
>
> root@pruebas-xen-egoitz:~# cat /etc
Re: Call for testers: vfork(2) repair for Xen
On Tue, 2012-12-04 at 23:02 +0200, Konstantin Belousov wrote:
> Hi,
> there is plain erronous special case for Xen in the handling of vfork(2)
> syscall, which converts it into the fork(2), but only on Xen. I think this
> was a bug to commit the change in the course of importing Xen support at all.
>
> Could somebody of you, who use paravirtualized kernels, test the patch
> below. After the patched kernel is booted, just running csh(1) and
> calling any external command from it, e.g. ls(1), is enough.
>
> I already tried to solicit the testing of the fix in private, but nobody
> responded. I am going to commit the change in a week, unless somebody
> report a real issue with Xen pmap, uncovered by it.
>
> diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
> index b8a4825..0d2709f 100644
> --- a/sys/kern/kern_fork.c
> +++ b/sys/kern/kern_fork.c
> @@ -150,11 +150,7 @@ sys_vfork(struct thread *td, struct vfork_args *uap)
> int error, flags;
> struct proc *p2;
>
> -#ifdef XEN
> - flags = RFFDG | RFPROC; /* validate that this is still an issue */
> -#else
> flags = RFFDG | RFPROC | RFPPWAIT | RFMEM;
> -#endif
> error = fork1(td, flags, 0, &p2, NULL, 0);
> if (error == 0) {
> td->td_retval[0] = p2->p_pid;
Ack. Will test tonight after dom0.freebsd.org is restored.
Sean
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: XENHVM ada -> ad ?
On Fri, 2012-12-21 at 01:31 +0200, Ion-Mihai Tetcu wrote: > Hi, > > > I have the feeling I'm missing something very basic here: > > I have a 9-STABLE-amd64 (as of a few minutes ago, but I see the same > thing with older versions) running as guest on Xen HVM (APIC, ACPI on). > > I can boot the GENERIC kernel, but trying to boot the XENHVM kernel > results in > trying to mount root from ufs: /dev/ada0p2 [rw] ... > mountroot: waiting for device /dev/ada0p2 ... > Mounting from ufs:/dev/ada0p2 failed with error 19. > > I can: > mountroot> ufs:ad0p2 > and it breaks there, of course. > > Do I need to translate from 'ada' back to 'ad' if I use XENHVM? Why? > > > Thanks, > Yes. adaX-->adX. Look at the dmesg on bootup. Sean ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: SR-IOV drivers for FreeBSD VM
On Fri, 2013-02-15 at 13:57 -0800, arvind viswanathan wrote: > Hi, > > I have a FB7 instance running as a guest. I would like to add SR-IOV > capability to my VM and I was searching for the VF drivers. I hit this link > http://www.intel.com/support/network/adapter/pro100/sb/CS-031492.htm#4 > where they discuss where to find drivers. > For freebsd I only see a e1000 driver. Is intel yet to come up with 10G > driver for FreeBSD. 10G driver support seems to be there for linux. > > Thanks > Arvind I think you are looking for the ixgbe(4) driver. Sean http://svnweb.freebsd.org/base/head/sys/dev/ixgbe/ http://svnweb.freebsd.org/base/head/sys/dev/ixgb/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: PV crash
On Wed, 2013-06-26 at 13:40 +, Eggert, Lars wrote: > real memory = 67108864 (64 MB) > avail memory = 58556416 (55 MB) That looks a bit small for a x86 instance of FreeBSD 10 IMO. Try bumping that to >512MB just to be sure. Sean signature.asc Description: This is a digitally signed message part
XENHVM on -curent useless
Just got a rootbsd.net instance and the 9.1r XENHVM that they provided me works great. Attempted to boot -current on their systems and the XENHVM kernel panic'd when it could find any hardware timers. This is a pretty serious regression that I'll bisect this weekend if nobody is looking at it. For the record I did *try* to compile the PVHVM tree in git, and it did not build for me on 9.x because of some stupid unlreated yyparse error that made me table flip and go back to 9.1r Sean signature.asc Description: This is a digitally signed message part
Re: KERNCONF=XENHVM FAILED to build
On Sat, 2013-06-15 at 11:45 +0800, J wrote: > I can't get the errors now as I can't build world now. > I have built the world without gcc before the xen build, does it matter? > > > On Thu, Jun 13, 2013 at 12:28 AM, J wrote: > > > > > > > Yeah. It does matter. The "error" you posted is the result of the build failing, but it doesn't actually show the build failure. :-( Sean signature.asc Description: This is a digitally signed message part
Re: XENHVM on -curent useless
On Wed, 2013-07-10 at 18:15 +0200, Roger Pau Monné wrote: > On 10/07/13 17:54, Sean Bruno wrote: > > Just got a rootbsd.net instance and the 9.1r XENHVM that they provided > > me works great. > > > > Attempted to boot -current on their systems and the XENHVM kernel > > panic'd when it could find any hardware timers. This is a pretty > > serious regression that I'll bisect this weekend if nobody is looking at > > it. > > Could you post the boot log and the panic with a backtrace? > Yeah, I'll do that in a bit. I'm doing a testcompile on my instance at the moment, but the panic string was: panic: No usable event timer found I'm rebuilding world/kernel at the moment, so it'll be a couple of hours before I can fire it up. Sean p.s. thanks for your work on PVHVM. I look forward to testing it soon. signature.asc Description: This is a digitally signed message part
Re: XENHVM on -curent useless [VERY USEFUL TODAY]
On Wed, 2013-07-10 at 18:15 +0200, Roger Pau Monné wrote: > On 10/07/13 17:54, Sean Bruno wrote: > > Just got a rootbsd.net instance and the 9.1r XENHVM that they provided > > me works great. > > > > Attempted to boot -current on their systems and the XENHVM kernel > > panic'd when it could find any hardware timers. This is a pretty > > serious regression that I'll bisect this weekend if nobody is looking at > > it. > > Could you post the boot log and the panic with a backtrace? > Today, sync'd to head at svn r253159, head works *just fine* and is fantastic. :-) sean signature.asc Description: This is a digitally signed message part
Re: CFT: replacing XENHVM kernel config with GENERIC + xenhvm.ko
On Mon, 2013-08-26 at 22:08 -0700, Colin Percival wrote: > Hi all, > > I've attached a patch which eliminates the XENHVM kernel configuration and > instead allows FreeBSD to run under Xen/HVM with PV drivers by loading a > new xenhvm.ko module from the boot loader. This will mean that FreeBSD > virtual machines running under Xen/HVM will be able to run "straight off > the ISO" binaries; this will also mean they will be able to use FreeBSD > Update to update the kernel. > > I have spent about 10 minutes testing this in Amazon EC2. Please help me > out by doing some more testing. ;-) > > The fine details: > 1. I've created a new kernel module for i386 and amd64, "xenhvm", with all > of the source files which were added via "options XENHVM" and "device xenpci". > 2. I have removed those from sys/conf/files and sys/conf/options.*; those > options are now meaningless. > 3. I moved the "detect Xen and disable QEMU emulated devices" code from > sys/amd64/amd64/machdep.c to the kernel module MOD_LOAD event handler. > 4. I have made the PCPU values required by Xen/HVM support -- two unsigned > ints -- unconditionally compiled in. This is the only change to the GENERIC > kernel. > 5. I have removed the XENHVM kernel configuration files. > > Depending on feedback from freebsd-xen@ I hope to send this to freebsd-current > for wider review later this week and then commit it before the FreeBSD 10.0 > code freeze starts on September 7th. Seems like you've got a winner there. $ uname -a FreeBSD ujvl 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254959M: Tue Aug 27 18:29:11 EDT 2013 sbruno@ujvl:/usr/obj/usr/src/sys/GENERIC amd64 $ kldstat Id Refs AddressSize Name 1 21 0x8020 168eaa0 kernel 21 0x8188f000 76ef8xenhvm.ko 31 0x81a12000 34e0 ums.ko 41 0x81a16000 312c5pf.ko 51 0x81a48000 643d nullfs.ko 61 0x81a4f000 52c1 fdescfs.ko Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r254959M: Tue Aug 27 18:29:11 EDT 2013 sbruno@ujvl:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206c2 Family = 0x6 Model = 0x2c Stepping = 2 Features=0x1781fbff Features2=0x81b82201 AMD Features=0x28100800 AMD Features2=0x1 real memory = 536870912 (512 MB) avail memory = 490692608 (467 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-47 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a (3) failed cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc1a0-0xc1af at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 uhci0: port 0xc180-0xc19f irq 23 at device 1.2 on pci0 usbus0: controller did not stop usbus0 on uhci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xf000-0xf1ff,0xf304-0xf3040fff at device 2.0 on pci0 xenpci0: port 0xc000-0xc0ff mem 0xf200-0xf2ff irq 28 at device 3.0 on pci0 xenstore0: on xenpci0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 qpi0: on motherboard orm0: at iomem 0xc9000-0xc97ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3
Re: [CFR] Event channel Interrupts and unified Xen interrupt infrastructure.
On Thu, 2013-08-29 at 10:32 -0600, Justin T. Gibbs wrote: > I've been working to get the next chunk of Spectra/Roger Pau Monné Xen work > into head. The latest version of the patch I'm working on can be found here: > > http://people.freebsd.org/~gibbs/xen_intr.diff > > I will continue my testing today and commit it tonight unless I hear > complaints. Comments, corrections, improvements, and bug reports welcome. > > -- > Justin > ___ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" so far, so good here in RootBSD.net land. FreeBSD ujvl 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r255040: Thu Aug 29 16:33:24 EDT 2013 sbruno@ujvl:/usr/obj/usr/src/sys/XENHVM amd64 FreeBSD ujvl 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r255040: Thu Aug 29 16:33:24 EDT 2013 sbruno@ujvl:/usr/obj/usr/src/sys/XENHVM amd64 root@ujvl:/usr/home/sbruno # dmesg Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1 r255040: Thu Aug 29 16:33:24 EDT 2013 sbruno@ujvl:/usr/obj/usr/src/sys/XENHVM amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. XEN: Hypervisor version 4.1 detected. CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206c2 Family = 0x6 Model = 0x2c Stepping = 2 Features=0x1781fbff Features2=0x81b82201 AMD Features=0x28100800 AMD Features2=0x1 real memory = 536870912 (512 MB) avail memory = 490733568 (468 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-47 on motherboard random: initialized kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a (3) failed cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc1a0-0xc1af at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 uhci0: port 0xc180-0xc19f irq 23 at device 1.2 on pci0 usbus0: controller did not stop usbus0 on uhci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xf000-0xf1ff,0xf304-0xf3040fff at device 2.0 on pci0 xenpci0: port 0xc000-0xc0ff mem 0xf200-0xf2ff irq 28 at device 3.0 on pci0 xenstore0: on xenpci0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 qpi0: on motherboard orm0: at iomem 0xc9000-0xc97ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 fdc0: No FDOUT register! Timecounters tick every 10.000 msec usbus0: 12Mbps Full Speed USB v1.0 xenbusb_front0: on xenstore0 ugen0.1: at usbus0 uhub0: on usbus0 xn0: at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 00:16:3e:0b:9b:56 xn1: at device/vif/1 on xenbusb_front0 xn1: Ethernet address: 00:16:3e:50:c5:a7 xenbusb_back0: on xenstore0 xctrl0: on xenstore0 xn0: backend features: feature-sg feature-gso-tcp4 xn1: backend features: feature-sg feature-gso-tcp4 xbd0: 20480MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ada0 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.2: at usbus0 Trying to mount root from ufs:/dev/ada0p2 [rw]... xn0: 2 link states coalesced ums0: on usbus0 ums0: 3 buttons and [Z] coordinates ID=0 signature.asc Description: This is
Re: Kernel Panic on Xen HVM Guest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/21/15 17:08, Shawn Webb wrote: > Hey All, > > I'm experiencing a kernel panic at boot time on my RootBSD VPS on > FreeBSD- CURRENT. > > Since I'm limited to VNC, I've uploaded a screenshot of the crash > here: http://imgur.com/yWtvJDc > > Thanks, > I haven't seen that one yet. I'm at FreeBSD 11.0-CURRENT #23 r278970 However, I did have to disable x2apic in my loader.conf as I was getting an insta panic on CPU enumeration. https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054576.html sean -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJU6h3gXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kcUMIAM1BURE9dpsK3MHyvsXuygTK di6OAWGt02xKofCTPU6Eceu2dIU6b8oTN77FQJ+TaFNPRh/oz5obPDjRvqxCGeWx MnyZ3vBalfZpDU7x1YwWTJZQ6oDF8/8RFqKvPLZp+R2BxsZgaYouGf32+Rd2Yedz Ho+ps2Vy3hWzhhtIoKONoTNycZbuVzphhWViLJJkmf36E+xBSOI9LxJJyK1+Kx2p COT0ir/LuvPjsx+2GWm0zYASsun+E4eo3cGnpOLt0YBF1f94Kmx1q3jy1Tn79X3p SvX6Pip4GPIuOGZw1cGkwbopxt6TPIRQfG0fYnAXPQ4KN4kYoxaMI8f3K7bJG9s= =9TTB -END PGP SIGNATURE- ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
