From bugmaster at FreeBSD.org Mon Oct 5 11:07:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 5 11:10:07 2009 Subject: Current problem reports assigned to freebsd-xen@FreeBSD.org Message-ID: <200910051107.n95B74ZD088855@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/136251 xen [xen] [patch] xn0 doesn't DHCP o kern/135421 xen [xen] FreeBSD Xen PVM DomU network failure - netfronc. o kern/135179 xen [xen] Xen domU does not properly reboot o kern/135178 xen [xen] Xen domU outgoing data transfer stall when TSO i o kern/135069 xen [xen] FreeBSD-current/Xen SMP doesn't function at all o kern/135008 xen [xen] FreeBSD-current/Xen timecounter jumps o kern/134926 xen [xen] [panic] FreeBSD-current Xen DomU networking pani 7 problems total. From yury.buldakov at gmail.com Tue Oct 6 07:31:40 2009 From: yury.buldakov at gmail.com (Yury A. Buldakov) Date: Tue Oct 6 07:31:46 2009 Subject: [xen] FreeBSD Xen PVM DomU crashes Message-ID: <4ACAF24D.3010607@gmail.com> FreeBSD environment: uname -a FreeBSD pbox-xen-freebsd.silentnoise.intra 8.0-RC1 FreeBSD 8.0-RC1 #0 r: Mon Oct 5 12:58:34 EEST 2009 root@freebsd-8-buildbox.silentnoise.intra:/usr/obj/usr/src/sys/XEN i386 I have nfs-shared /usr/ports. While making pkgdb -aF my freebsd domU crashes: panic: HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF) < 0: /usr/src/sys/i386/xen/xen_machdep.c:465 cpuid = 0 KDB: enter: panic [thread pid 4695 tid 100078 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> But in most cases it crashes with the following: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x107 fault code = supervisor read, page not present instruction pointer = 0x21:0xc01764e8 stack pointer = 0x29:0xd59f883c frame pointer = 0x29:0xd59f883c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 1, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 18518 (sendmail) [thread pid 18518 tid 100089 ] Stopped at strlen+0x8: cmpb $0,0(%edx) db> Tracing pid 18518 tid 100089 td 0xc2d876c0 strlen(107,d59f898c,0,d59f888c,c011a32b,...) at strlen+0x8 kvprintf(c035c5ae,c0108b80,d59f898c,a,d59f89cc,...) at kvprintf+0x8fe vsnprintf(c03d3460,100,c035c5ae,d59f89cc,0,...) at vsnprintf+0x3b panic(c035c5ae,107,c036d649,33e,16d,...) at panic+0x8d _mtx_lock_flags(c076d808,0,c036d649,33e,c30dfc00,...) at _mtx_lock_flags+0x9a netisr_clearqdrops(d59f8a28,c2d87764,c0512828,0) at netisr_clearqdrops+0x66e netisr_queue_src(1,0,c30dfc00,d59f8a6c,c01861ee,...) at netisr_queue_src+0xa7 netisr_queue(1,c30dfc00,c30dfc48,d59f8af8,d59f8a80,...) at netisr_queue+0x20 if_simloop(c237b000,c30dfc00,2,0,c01a299f,...) at if_simloop+0xfe looutput(c237b000,c30dfc00,d59f8b00,d59f8af8,c031fee4,...) at looutput+0x141 ip_output(c30dfc00,0,0,0,0,...) at ip_output+0x9cc tcp_output(c273d768,c246b840,1b9,c26501a4,c2d8c19c,...) at tcp_output+0x1540 tcp_ctloutput(c2d8c19c,c246b840,c2d876c0,25,d59f8c70,...) at tcp_ctloutput+0x933 soconnect(c2d8c19c,c246b840,c2d876c0,bf7fadc0,c246b840,...) at soconnect+0x52 kern_connect(c2d876c0,6,c246b840,c246b840,ffffffff,...) at kern_connect+0xa6 connect(c2d876c0,d59f8d08,c,c0364398,c039d138,...) at connect+0x46 syscall(d59f8d48) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x22 --- syscall (98, FreeBSD ELF32, connect), eip = 0x283b9e5b, esp = 0xbf7fac5c, ebp = 0xbf7fae88 --- From freebsd-xen at winnipeg.nl Tue Oct 6 10:00:43 2009 From: freebsd-xen at winnipeg.nl (Lotte-Sara Laan) Date: Tue Oct 6 10:00:50 2009 Subject: FreeBSD 8.0RC1 and CURRENT panics when trying to boot as xenU Message-ID: <4ACB0F08.9080603@winnipeg.nl> I've send this email to the freebsd-current mailinglist, but I think this is a better place for it (-; --------------------- I'm trying to get FreeBSD working under Xen 3.4.1 using the Gentoo dom0 kernel 2.6.29.6 I downloaded and compiled the 8.0RC1 and the CURRENT svn version revision 197720 from http://svn.freebsd.org/base/head with the KERNCONF=XEN option but when I'm starting my domU I'm getting the following panic: WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 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 #1 r197720: Sat Oct 3 14:09:31 CEST 2009 root@freebsd.winnipeg.nl:/usr/local/xen/current-obj/usr/src/sys/XEN-LOTJUH i386 WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 2611.800 MHz processor. Timecounter "ixen" frequency 1000000000 Hz quality 0 CPU: AMD Phenom(tm) II X4 810 Processor (2611.80-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant Data TLB: 48 entries, fully associative Instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 1073741824 (1024 MB) Physical memory chunk(s): 0x00000000008ab000 - 0x000000003ecb2fff, 1044414464 bytes (254984 pages) avail memory = 1040429056 (992 MB) APIC: Using the MPTable enumerator. SMP: Added CPU 0 (BSP) SMP: Added CPU 1 (AP) SMP: Added CPU 2 (AP) SMP: Added CPU 3 (AP) panic: HYPERVISOR_update_va_mapping(((unsigned long)(va)), (pa | 0x002 | 0x001 | pgeflag | pmap_cache_bits(mode, 0)), UVMF_INVLPG| UVMF_ALL) < 0: /usr/src/sys/i386/xen/pmap.c:1269 cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 0 tid 0 td 0xc03e10f0 kdb_enter(c03698a8,c03698a8,c038e3f1,c06f9cd4,0,...) at kdb_enter+0x3a panic(c038e3f1,c0396429,c0396207,4f5,0,...) at panic+0x136 pmap_mapdev_attr(0,0,100000,6,c06f9d44,...) at pmap_mapdev_attr+0x13d pmap_mapbios(0,0,100000,1,c03c946c,...) at pmap_mapbios+0x27 x86bios_intr(c36e4840,0,0,76,c0395e2b,...) at x86bios_intr+0x1b0 module_register_init(c03dbe88,3040800,3040800,6fe000,0,...) at module_register_init+0xa7 mi_startup(6fe000,0,0,0,0,...) at mi_startup+0x96 btext() at btext+0x95 db> I'm getting the same panic when I add only 1 cpu. And I've tried revision 197775 now as well which gives me exactly the same panic. I'm using the following boot line for pygrub: kernel /boot/kernel/kernel vfs.root.mountfrom=ufs:xbd0,kern.hz=100,kern.smp.disabled=1,boot_verbose=1,boot_single=1 I've tried it with and without the kern.smp.disabled option And for 8.0RC1 I get: WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 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.0-RC1 #0: Fri Oct 2 22:05:22 CEST 2009 root@freebsd.winnipeg.nl:/usr/local/xen/obj-xenbro2/usr/src/sys/XEN-LOTJUH WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 2611.800 MHz processor. Timecounter "ixen" frequency 1000000000 Hz quality 0 CPU: AMD Phenom(tm) II X4 810 Processor (2611.80-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant Data TLB: 48 entries, fully associative Instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 1073741824 (1024 MB) Physical memory chunk(s): 0x0000000000899000 - 0x000000003ecb2fff, 1044488192 bytes (255002 pages) avail memory = 1040502784 (992 MB) APIC: Using the MPTable enumerator. SMP: Added CPU 0 (BSP) ULE: setup cpu 0 [XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0) [XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1) Event-channel device installed. mem: Pentium Pro MTRR support enabled null: nfslock: pseudo-device random: kbd0 at kbdmux0 io: Grant table initialized xenbus0: on motherboard xc0: on motherboard [XEN] xen_rtc_probe: probing Hypervisor RTC clock rtc0: on motherboard [XEN] xen_rtc_attach: attaching Hypervisor RTC clock rtc0: registered as a time-of-day clock (resolution 1000000us) npx0: INT 16 interface Device configuration finished. procfs registered Timecounters tick every 10.000 msec kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault whilelo0: bpf attached in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x21:0xc0320011 stack pointer = 0x29:0xc35c6ca0 frame pointer = 0x29:0xc35c6ca8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 1, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 [XEN] hypervisor wallclock nudged; nudging TOD. [thread pid 11 tid 100003 ] Stopped at spinlock_enter+0x91: hlt db> bt Tracing pid 11 tid 100003 td 0xc3708b40 spinlock_enter(1,c35c6cf8,c00fb6fe,1,0,...) at spinlock_enter+0x91 cpu_idle(1,0,c035f75b,9e9,c3708b40,...) at cpu_idle+0x12 sched_idletd(0,c35c6d38,c035909c,343,c3706aa0,...) at sched_idletd+0x23e fork_exit(c00fb4c0,0,c35c6d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc35c6d70, ebp = 0 --- db> Does anyone have any ideas about what's going wrong? Lotte-Sara Laan From glarkin at FreeBSD.org Sat Oct 10 02:43:51 2009 From: glarkin at FreeBSD.org (Greg Larkin) Date: Sat Oct 10 02:43:58 2009 Subject: finishing up the xen port - would funding help? In-Reply-To: References: <77abe410908211256g44dd20d8o9b50c20357e63a6b@mail.gmail.com> <4A94CD0D.8070902@prgmr.com> Message-ID: <4ACFEC6E.2030109@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Chadd wrote: > Give me a few days to get stuff together here and I'll see what I can > do in -head. > > Thanks for all your offers of support. > > adrian > [...] Hi everyone, I received an email from a contact @ Amazon AWS yesterday asking about the status of the FreeBSD Xen project. He and I connected earlier this year after a short exchange on Twitter and some emails about getting FreeBSD AMIs running on Amazon EC2. I told him that there was a thread on the freebsd-xen mailing list in August. My understanding is that the primary blocker is funding for the developers who have the skills required to bring the Xen support up to production quality. I also figured that it might take even more time to then port to the version of Xen used by Amazon. I hope to hear back from him soon with his thoughts. Obviously, it would be extremely helpful if Amazon funded the development, presuming there would be a long-term financial gain for them. If anyone has any feedback that I should relay to him, let me know. I also asked him if he wanted contact information for the FreeBSD/Xen developers and other folks who are involved in the project at a high level. I'll post back here if he does. Best regards, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKz+xu0sRouByUApARArKYAKCVziRDp71w977HHy2XpKxQsHgUXgCaA2fT RFxGu9dVA1s39MKn0+o6520= =Zg60 -----END PGP SIGNATURE----- From cracauer at cons.org Sat Oct 10 15:36:59 2009 From: cracauer at cons.org (Martin Cracauer) Date: Sat Oct 10 15:37:06 2009 Subject: finishing up the xen port - would funding help? In-Reply-To: <4ACFEC6E.2030109@FreeBSD.org> References: <77abe410908211256g44dd20d8o9b50c20357e63a6b@mail.gmail.com> <4A94CD0D.8070902@prgmr.com> <4ACFEC6E.2030109@FreeBSD.org> Message-ID: <20091010150224.GA71643@cons.org> Greg Larkin wrote on Fri, Oct 09, 2009 at 10:07:42PM -0400: > I also figured that it might take even more time to > then port to the version of Xen used by Amazon. What version is that and why do they assume they are still using it when the port is finished? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From bugmaster at FreeBSD.org Mon Oct 12 11:07:06 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 12 11:10:17 2009 Subject: Current problem reports assigned to freebsd-xen@FreeBSD.org Message-ID: <200910121107.n9CB759I036616@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/136251 xen [xen] [patch] xn0 doesn't DHCP o kern/135421 xen [xen] FreeBSD Xen PVM DomU network failure - netfronc. o kern/135179 xen [xen] Xen domU does not properly reboot o kern/135178 xen [xen] Xen domU outgoing data transfer stall when TSO i o kern/135069 xen [xen] FreeBSD-current/Xen SMP doesn't function at all o kern/135008 xen [xen] FreeBSD-current/Xen timecounter jumps o kern/134926 xen [xen] [panic] FreeBSD-current Xen DomU networking pani 7 problems total. From adrian at freebsd.org Wed Oct 14 10:11:16 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Wed Oct 14 10:11:24 2009 Subject: finishing up the xen port - would funding help? In-Reply-To: <4ACFEC6E.2030109@FreeBSD.org> References: <77abe410908211256g44dd20d8o9b50c20357e63a6b@mail.gmail.com> <4A94CD0D.8070902@prgmr.com> <4ACFEC6E.2030109@FreeBSD.org> Message-ID: Please contact the FreeBSD foundation and let them know that Amazon contacted you. The best thing to do IMHO is get Amazon and the Foundation discussing Xen related things before involving developers. Thanks, Adrian 2009/10/10 Greg Larkin : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Adrian Chadd wrote: >> Give me a few days to get stuff together here and I'll see what I can >> do in -head. >> >> Thanks for all your offers of support. >> >> adrian >> > [...] > > Hi everyone, > > I received an email from a contact @ Amazon AWS yesterday asking about > the status of the FreeBSD Xen project. ?He and I connected earlier this > year after a short exchange on Twitter and some emails about getting > FreeBSD AMIs running on Amazon EC2. > > I told him that there was a thread on the freebsd-xen mailing list in > August. ?My understanding is that the primary blocker is funding for the > developers who have the skills required to bring the Xen support up to > production quality. ?I also figured that it might take even more time to > then port to the version of Xen used by Amazon. > > I hope to hear back from him soon with his thoughts. ?Obviously, it > would be extremely helpful if Amazon funded the development, presuming > there would be a long-term financial gain for them. ?If anyone has any > feedback that I should relay to him, let me know. > > I also asked him if he wanted contact information for the FreeBSD/Xen > developers and other folks who are involved in the project at a high > level. ?I'll post back here if he does. > > Best regards, > Greg > - -- > Greg Larkin > > http://www.FreeBSD.org/ ? ? ? ? ? - The Power To Serve > http://www.sourcehosting.net/ ? ? - Ready. Set. Code. > http://twitter.com/sourcehosting/ - Follow me, follow you > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFKz+xu0sRouByUApARArKYAKCVziRDp71w977HHy2XpKxQsHgUXgCaA2fT > RFxGu9dVA1s39MKn0+o6520= > =Zg60 > -----END PGP SIGNATURE----- > > From bugmaster at FreeBSD.org Mon Oct 19 11:07:06 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 19 11:10:09 2009 Subject: Current problem reports assigned to freebsd-xen@FreeBSD.org Message-ID: <200910191107.n9JB75qc063624@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/136251 xen [xen] [patch] xn0 doesn't DHCP o kern/135421 xen [xen] FreeBSD Xen PVM DomU network failure - netfronc. o kern/135179 xen [xen] Xen domU does not properly reboot o kern/135178 xen [xen] Xen domU outgoing data transfer stall when TSO i o kern/135069 xen [xen] FreeBSD-current/Xen SMP doesn't function at all o kern/135008 xen [xen] FreeBSD-current/Xen timecounter jumps o kern/134926 xen [xen] [panic] FreeBSD-current Xen DomU networking pani 7 problems total. From glarkin at FreeBSD.org Tue Oct 20 22:12:35 2009 From: glarkin at FreeBSD.org (Greg Larkin) Date: Tue Oct 20 22:12:43 2009 Subject: finishing up the xen port - would funding help? In-Reply-To: <20091010150224.GA71643@cons.org> References: <77abe410908211256g44dd20d8o9b50c20357e63a6b@mail.gmail.com> <4A94CD0D.8070902@prgmr.com> <4ACFEC6E.2030109@FreeBSD.org> <20091010150224.GA71643@cons.org> Message-ID: <4ADE35CC.3070108@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Cracauer wrote: > Greg Larkin wrote on Fri, Oct 09, 2009 at 10:07:42PM -0400: >> I also figured that it might take even more time to >> then port to the version of Xen used by Amazon. > > What version is that and why do they assume they are still using it > when the port is finished? > > Martin Hi Martin, As far as I know, Amazon is using Xen 3.0.3 (according to http://wiki.freebsd.org/FreeBSD/Xen), but it's possible that it has been upgraded. I'll see if I can get an update from my contact at Amazon. Thank you, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK3jXM0sRouByUApARAuNCAJ9zgYdU5E1mqaDLOQnli7hdcqpbmQCfdw3v QpmtaNK4nHjLWK/D1VzuAC8= =hNyI -----END PGP SIGNATURE----- From glarkin at FreeBSD.org Tue Oct 20 22:13:19 2009 From: glarkin at FreeBSD.org (Greg Larkin) Date: Tue Oct 20 22:13:25 2009 Subject: finishing up the xen port - would funding help? In-Reply-To: References: <77abe410908211256g44dd20d8o9b50c20357e63a6b@mail.gmail.com> <4A94CD0D.8070902@prgmr.com> <4ACFEC6E.2030109@FreeBSD.org> Message-ID: <4ADE35F8.5070901@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Chadd wrote: > Please contact the FreeBSD foundation and let them know that Amazon > contacted you. The best thing to do IMHO is get Amazon and the > Foundation discussing Xen related things before involving developers. > > Thanks, > > > > Adrian > Hi Adrian, Ok, that sounds like a great idea - will do. Cheers, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK3jX40sRouByUApARAk83AJ4xjMBN/Z6MMQ34RPBzR4Rb/4PNIQCgv9y4 W7M8aLAPibjgtW4giZJ3kyk= =I2mi -----END PGP SIGNATURE----- From sysconfig at ossafe.org Sat Oct 24 21:03:23 2009 From: sysconfig at ossafe.org (Carsten Heesch) Date: Sat Oct 24 21:03:30 2009 Subject: Problem: Xen 3.3.1 with FreeBSD 8.0 RC1 Message-ID: <850CF1B7-499E-4468-9045-19A2803E6D05@ossafe.org> Hi guys, I don't know really when the bug was introduced, but maybe I can help narrowing it down. I have similar problems as others reported: Running FreeBSD 8.0-RC1 as a guest in a Xen 3.3.1 environment fails with either "kernel trap 12" in an endless loop (using amd64) or "kernel trap 9" (using i386). For 8.0-RC1 it doesn't make a difference if it's a clean install, in which case I wouldn't even be able to start the installer, or a "freebsd-update upgrade -r 8.0-RC1" from 7.2-RELEASE, in which case it wouldn't reboot with the newly compiled kernel. Funnily one of the earlier betas (not sure which one it exactly was, and can't reproduce any more, as they are not available on any mirrors), and 8.0-SNAPSHOT-200906 (tested today) both work without any problems. With the snapshot, I was also able to build a XENHVM kernel, which boots fine, and offers the XENHVM network and block devices. The environment I'm testing on is: - Intel i7 920, 12 GB RAM - Dom0 is running on CentOS 5.2 and Xen 3.3.1 (Citrix XenServer 5.5) Is there any way to extract relevant information, which would help you to fix it? I'd really like to see FreeBSD 8.0-RELEASE working on Xen! So if there is anything you need to know, please tell me what it is, and how I can gather it. Cheers Carsten From carsten at heesch.me.uk Sat Oct 24 23:50:03 2009 From: carsten at heesch.me.uk (Carsten Heesch) Date: Sat Oct 24 23:50:10 2009 Subject: Problem: Xen 3.3.1 with FreeBSD 8.0 RC1 In-Reply-To: <850CF1B7-499E-4468-9045-19A2803E6D05@ossafe.org> References: <850CF1B7-499E-4468-9045-19A2803E6D05@ossafe.org> Message-ID: <3941E1B9-6CD6-4D9A-AF1C-93401F571FCE@heesch.me.uk> I realised that it's still possible to use 8.0-BETA* as a target for freebsd-update. So I investigated a bit further. For whatever it's worth: The problems described earlier started with BETA-4. BETA-3 is fine with both GENERIC and XENHVM kernel, except that I see this on the console and in dmesg every now and then (with both kernels): lock order reversal: 1st 0xffffff8014810620 bufwait (bufwait) @ /usr/src/sys/kern/ vfs_bio.c:2559 2nd 0xffffff00015a7c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x88b ufs_makeinode() at ufs_makeinode+0x31c VOP_CREATE_APV() at VOP_CREATE_APV+0x8d vn_open_cred() at vn_open_cred+0x423 kern_openat() at kern_openat+0x179 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (5, FreeBSD ELF64, open), rip = 0x800e32dfc, rsp = 0x7fffffffe608, rbp = 0x1a4 --- I though this might be XENHVM kernel related, but it happens with GENERIC kernel as well. Not sure if this is related to XEN at all. Cheers Carsten From bugmaster at FreeBSD.org Mon Oct 26 11:07:11 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 26 11:10:48 2009 Subject: Current problem reports assigned to freebsd-xen@FreeBSD.org Message-ID: <200910261107.n9QB7BYe043941@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/136251 xen [xen] [patch] xn0 doesn't DHCP o kern/135421 xen [xen] FreeBSD Xen PVM DomU network failure - netfronc. o kern/135179 xen [xen] Xen domU does not properly reboot o kern/135178 xen [xen] Xen domU outgoing data transfer stall when TSO i o kern/135069 xen [xen] FreeBSD-current/Xen SMP doesn't function at all o kern/135008 xen [xen] FreeBSD-current/Xen timecounter jumps o kern/134926 xen [xen] [panic] FreeBSD-current Xen DomU networking pani 7 problems total. From sysconfig at ossafe.org Tue Oct 27 13:18:46 2009 From: sysconfig at ossafe.org (Carsten Heesch) Date: Tue Oct 27 13:18:52 2009 Subject: Problem: Xen 3.3.1 with FreeBSD 8.0 RC1 In-Reply-To: <3941E1B9-6CD6-4D9A-AF1C-93401F571FCE@heesch.me.uk> References: <850CF1B7-499E-4468-9045-19A2803E6D05@ossafe.org> <3941E1B9-6CD6-4D9A-AF1C-93401F571FCE@heesch.me.uk> Message-ID: <8C3C0877-F36E-45D1-BDEE-4EE22BD45205@ossafe.org> Athough I seem to be talking to myself here, I have good news for RC2! It works! Just did an "freebsd-update -R 8.0-RC2 upgrade". Both GENERIC and XENHVM kernels work without any problems. Maybe somebody else can chime in an confirm that, too? Probably good for the developers to see positive feedback, while 8.0-RELEASE is coming closer :-) Cheers Carsten On 25 Oct 2009, at 00:31, Carsten Heesch wrote: > > I realised that it's still possible to use 8.0-BETA* as a target for > freebsd-update. So I investigated a bit further. For whatever it's > worth: > > The problems described earlier started with BETA-4. > > BETA-3 is fine with both GENERIC and XENHVM kernel, except that I > see this on the console and in dmesg every now and then (with both > kernels): > > > lock order reversal: > 1st 0xffffff8014810620 bufwait (bufwait) @ /usr/src/sys/kern/ > vfs_bio.c:2559 > 2nd 0xffffff00015a7c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ > ufs_dirhash.c:285 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > _sx_xlock() at _sx_xlock+0x55 > ufsdirhash_acquire() at ufsdirhash_acquire+0x33 > ufsdirhash_add() at ufsdirhash_add+0x19 > ufs_direnter() at ufs_direnter+0x88b > ufs_makeinode() at ufs_makeinode+0x31c > VOP_CREATE_APV() at VOP_CREATE_APV+0x8d > vn_open_cred() at vn_open_cred+0x423 > kern_openat() at kern_openat+0x179 > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (5, FreeBSD ELF64, open), rip = 0x800e32dfc, rsp = > 0x7fffffffe608, rbp = 0x1a4 --- > > > I though this might be XENHVM kernel related, but it happens with > GENERIC kernel as well. Not sure if this is related to XEN at all. > > > > Cheers > Carsten > > > From hugo at barafranca.com Tue Oct 27 17:07:47 2009 From: hugo at barafranca.com (Hugo Silva) Date: Tue Oct 27 17:08:23 2009 Subject: Problem: Xen 3.3.1 with FreeBSD 8.0 RC1 In-Reply-To: <8C3C0877-F36E-45D1-BDEE-4EE22BD45205@ossafe.org> References: <850CF1B7-499E-4468-9045-19A2803E6D05@ossafe.org> <3941E1B9-6CD6-4D9A-AF1C-93401F571FCE@heesch.me.uk> <8C3C0877-F36E-45D1-BDEE-4EE22BD45205@ossafe.org> Message-ID: <4AE723F4.10606@barafranca.com> Carsten Heesch wrote: > Athough I seem to be talking to myself here, I have good news for RC2! > It works! > Just did an "freebsd-update -R 8.0-RC2 upgrade". Both GENERIC and > XENHVM kernels work without any problems. > > Maybe somebody else can chime in an confirm that, too? Probably good > for the developers to see positive feedback, while 8.0-RELEASE is > coming closer :-) > > > Cheers > Carsten > > > On 25 Oct 2009, at 00:31, Carsten Heesch wrote: > >> >> I realised that it's still possible to use 8.0-BETA* as a target for >> freebsd-update. So I investigated a bit further. For whatever it's >> worth: >> >> The problems described earlier started with BETA-4. >> >> BETA-3 is fine with both GENERIC and XENHVM kernel, except that I see >> this on the console and in dmesg every now and then (with both kernels): >> >> >> lock order reversal: >> 1st 0xffffff8014810620 bufwait (bufwait) @ >> /usr/src/sys/kern/vfs_bio.c:2559 >> 2nd 0xffffff00015a7c00 dirhash (dirhash) @ >> /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> _witness_debugger() at _witness_debugger+0x2e >> witness_checkorder() at witness_checkorder+0x81e >> _sx_xlock() at _sx_xlock+0x55 >> ufsdirhash_acquire() at ufsdirhash_acquire+0x33 >> ufsdirhash_add() at ufsdirhash_add+0x19 >> ufs_direnter() at ufs_direnter+0x88b >> ufs_makeinode() at ufs_makeinode+0x31c >> VOP_CREATE_APV() at VOP_CREATE_APV+0x8d >> vn_open_cred() at vn_open_cred+0x423 >> kern_openat() at kern_openat+0x179 >> syscall() at syscall+0x1af >> Xfast_syscall() at Xfast_syscall+0xe1 >> --- syscall (5, FreeBSD ELF64, open), rip = 0x800e32dfc, rsp = >> 0x7fffffffe608, rbp = 0x1a4 --- >> >> >> I though this might be XENHVM kernel related, but it happens with >> GENERIC kernel as well. Not sure if this is related to XEN at all. >> >> >> >> Cheers >> Carsten >> >> >> > > _______________________________________________ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" I grabbed the 8.0-RC2/amd64iso to give this a spin; no luck here, it hangs after "Trying to mount root from ufs:/dev/md0". Also, I confirm the panics on boot with RC1. It's gone with RC2, but as I said, it gets stuck (for me, at least). My dom0 is NetBSD 5 / amd64. From adrian at freebsd.org Tue Oct 27 17:57:41 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Tue Oct 27 17:57:48 2009 Subject: Problem: Xen 3.3.1 with FreeBSD 8.0 RC1 In-Reply-To: <4AE723F4.10606@barafranca.com> References: <850CF1B7-499E-4468-9045-19A2803E6D05@ossafe.org> <3941E1B9-6CD6-4D9A-AF1C-93401F571FCE@heesch.me.uk> <8C3C0877-F36E-45D1-BDEE-4EE22BD45205@ossafe.org> <4AE723F4.10606@barafranca.com> Message-ID: This sounds like you're running the domU with >1 CPU.. ? Adrian 2009/10/28 Hugo Silva : > Carsten Heesch wrote: >> >> Athough I seem to be talking to myself here, I have good news for RC2! It >> works! >> Just did an "freebsd-update -R 8.0-RC2 upgrade". Both GENERIC and XENHVM >> kernels work without any problems. >> >> Maybe somebody else can chime in an confirm that, too? Probably good for >> the developers to see positive feedback, while 8.0-RELEASE is coming closer >> :-) >> >> >> Cheers >> Carsten >> >> >> On 25 Oct 2009, at 00:31, Carsten Heesch wrote: >> >>> >>> I realised that it's still possible to use 8.0-BETA* as a target for >>> freebsd-update. So I investigated a bit further. For whatever it's worth: >>> >>> The problems described earlier started with BETA-4. >>> >>> BETA-3 is fine with both GENERIC and XENHVM kernel, except that I see >>> this on the console and in dmesg every now and then (with both kernels): >>> >>> >>> lock order reversal: >>> 1st 0xffffff8014810620 bufwait (bufwait) @ >>> /usr/src/sys/kern/vfs_bio.c:2559 >>> 2nd 0xffffff00015a7c00 dirhash (dirhash) @ >>> /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >>> _witness_debugger() at _witness_debugger+0x2e >>> witness_checkorder() at witness_checkorder+0x81e >>> _sx_xlock() at _sx_xlock+0x55 >>> ufsdirhash_acquire() at ufsdirhash_acquire+0x33 >>> ufsdirhash_add() at ufsdirhash_add+0x19 >>> ufs_direnter() at ufs_direnter+0x88b >>> ufs_makeinode() at ufs_makeinode+0x31c >>> VOP_CREATE_APV() at VOP_CREATE_APV+0x8d >>> vn_open_cred() at vn_open_cred+0x423 >>> kern_openat() at kern_openat+0x179 >>> syscall() at syscall+0x1af >>> Xfast_syscall() at Xfast_syscall+0xe1 >>> --- syscall (5, FreeBSD ELF64, open), rip = 0x800e32dfc, rsp = >>> 0x7fffffffe608, rbp = 0x1a4 --- >>> >>> >>> I though this might be XENHVM kernel related, but it happens with GENERIC >>> kernel as well. Not sure if this is related to XEN at all. >>> >>> >>> >>> Cheers >>> Carsten >>> >>> >>> >> >> _______________________________________________ >> freebsd-xen@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-xen >> To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" > > > I grabbed the 8.0-RC2/amd64iso to give this a spin; no luck here, it hangs > after "Trying to mount root from ufs:/dev/md0". Also, I confirm the panics > on boot with RC1. It's gone with RC2, but as I said, it gets stuck (for me, > at least). > > My dom0 is NetBSD 5 / amd64. > _______________________________________________ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" > From lab at gta.com Tue Oct 27 18:23:36 2009 From: lab at gta.com (Larry Baird) Date: Tue Oct 27 18:23:42 2009 Subject: Problem: Xen 3.3.1 with FreeBSD 8.0 RC1 In-Reply-To: <109927.135756.6915@localhost> Message-ID: <20091027182331.12291.qmail@mailgate.gta.com> I have two Citrix XenServer 5.5.0 servers. One with an Intel processor and one with an AMD processor. Current versions of FreebSD 8 and 9 run on the Intel processor. Both panic after displaying available memory on the AMD processor. Panic message is: panic: vm_fault: fault on nofault entry, addr: c428200 I guess I'll need to install FreeBSD 7 and then cvsup to FreeBSD 9 to really get any useful debug information. Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From paulw at macrolan.com Thu Oct 29 10:48:10 2009 From: paulw at macrolan.com (Paul Wollner) Date: Thu Oct 29 10:48:20 2009 Subject: Problem: Xen 3.3.1 with FreeBSD 8.0 RC1 In-Reply-To: <4AE723F4.10606@barafranca.com> References: <850CF1B7-499E-4468-9045-19A2803E6D05@ossafe.org> <3941E1B9-6CD6-4D9A-AF1C-93401F571FCE@heesch.me.uk> <8C3C0877-F36E-45D1-BDEE-4EE22BD45205@ossafe.org> <4AE723F4.10606@barafranca.com> Message-ID: <1C91F622D1DF2347AF9354BEC77D76EAB2B7645150@server.macrolan.com> I have installed amd64 8.0 RC2 on Citrix Xenserver. GENREIC and XENHVM both booted without problems. I just checked the output of dmesg and I see the following error: lock order reversal: 1st 0xffffff80000b0618 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 2nd 0xffffff00017a6000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x88b ufs_makeinode() at ufs_makeinode+0x31c VOP_CREATE_APV() at VOP_CREATE_APV+0x8d vn_open_cred() at vn_open_cred+0x423 kern_openat() at kern_openat+0x179 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (5, FreeBSD ELF64, open), rip = 0x80083757c, rsp = 0x7fffffffdb78, rbp = 0x8 --- -----Original Message----- From: owner-freebsd-xen@freebsd.org [mailto:owner-freebsd-xen@freebsd.org] On Behalf Of Hugo Silva Sent: 27 October 2009 06:47 PM To: freebsd-xen@freebsd.org Subject: Re: Problem: Xen 3.3.1 with FreeBSD 8.0 RC1 Carsten Heesch wrote: > Athough I seem to be talking to myself here, I have good news for RC2! > It works! > Just did an "freebsd-update -R 8.0-RC2 upgrade". Both GENERIC and > XENHVM kernels work without any problems. > > Maybe somebody else can chime in an confirm that, too? Probably good > for the developers to see positive feedback, while 8.0-RELEASE is > coming closer :-) > > > Cheers > Carsten > > > On 25 Oct 2009, at 00:31, Carsten Heesch wrote: > >> >> I realised that it's still possible to use 8.0-BETA* as a target for >> freebsd-update. So I investigated a bit further. For whatever it's >> worth: >> >> The problems described earlier started with BETA-4. >> >> BETA-3 is fine with both GENERIC and XENHVM kernel, except that I see >> this on the console and in dmesg every now and then (with both kernels): >> >> >> lock order reversal: >> 1st 0xffffff8014810620 bufwait (bufwait) @ >> /usr/src/sys/kern/vfs_bio.c:2559 >> 2nd 0xffffff00015a7c00 dirhash (dirhash) @ >> /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> _witness_debugger() at _witness_debugger+0x2e >> witness_checkorder() at witness_checkorder+0x81e >> _sx_xlock() at _sx_xlock+0x55 >> ufsdirhash_acquire() at ufsdirhash_acquire+0x33 >> ufsdirhash_add() at ufsdirhash_add+0x19 >> ufs_direnter() at ufs_direnter+0x88b >> ufs_makeinode() at ufs_makeinode+0x31c >> VOP_CREATE_APV() at VOP_CREATE_APV+0x8d >> vn_open_cred() at vn_open_cred+0x423 >> kern_openat() at kern_openat+0x179 >> syscall() at syscall+0x1af >> Xfast_syscall() at Xfast_syscall+0xe1 >> --- syscall (5, FreeBSD ELF64, open), rip = 0x800e32dfc, rsp = >> 0x7fffffffe608, rbp = 0x1a4 --- >> >> >> I though this might be XENHVM kernel related, but it happens with >> GENERIC kernel as well. Not sure if this is related to XEN at all. >> >> >> >> Cheers >> Carsten >> >> >> > > _______________________________________________ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" I grabbed the 8.0-RC2/amd64iso to give this a spin; no luck here, it hangs after "Trying to mount root from ufs:/dev/md0". Also, I confirm the panics on boot with RC1. It's gone with RC2, but as I said, it gets stuck (for me, at least). My dom0 is NetBSD 5 / amd64. _______________________________________________ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" From sysconfig at ossafe.org Thu Oct 29 23:27:13 2009 From: sysconfig at ossafe.org (Carsten Heesch) Date: Thu Oct 29 23:27:32 2009 Subject: SCHED_ULE vs SCHED_4BSD for XENHVM domU Message-ID: <869459F8-7490-4270-84D0-A1168002E509@ossafe.org> Hi guys, After FreeBSD 8.0-RC2 is working well (for me) on Xen 3.3.1, I somehow made an interesting observation: Even if the FreeBSD domU does absolutely nothing, each of the assigned vCPUs will be reported by xentop as using 15%-25% CPU time. It doesn't matter, if domU is running with 1 or 4 vCPUs. All of them float at the same level. On the same Xen box five other domU's (CentOS 5.2-5.4) have an idle CPU percentage of 0 to 0.5%. So I played a bit and figured out that changing the scheduler in the XENHVM kernel configuration from "option SCHED_ULE" to "option SCHED_4BSD" resolves this problem. The idle state of the FreeBSD domU is now identical to the CentOS domU's. However, this of course means using an old (maybe even deprecated?) scheduler, which moreover isn't the best choice for multiple (virtual) CPUs. The configuration I tested on is: Intel i7 920 Quad-Core with Hyperthreading (8 logical CPUs) Citrix XenServer 5.5 (based on CentOS 5.2, Xen 3.3.1) Any thoughts, ideas, solutions? Thanks! Carsten From carsten at ossafe.org Thu Oct 29 23:31:15 2009 From: carsten at ossafe.org (Carsten Heesch) Date: Thu Oct 29 23:31:21 2009 Subject: SCHED_ULE vs SCHED_4BSD for XENHVM domU Message-ID: Hi guys, After FreeBSD 8.0-RC2 is working well (for me) on Xen 3.3.1, I somehow made an interesting observation: Even if the FreeBSD domU does absolutely nothing, each of the assigned vCPUs will be reported by xentop as using 15%-25% CPU time. It doesn't matter, if domU is running with 1 or 4 vCPUs. All of them float at the same level. On the same Xen box five other domU's (CentOS 5.2-5.4) have an idle CPU percentage of 0 to 0.5%. So I played a bit and figured out that changing the scheduler in the XENHVM kernel configuration from "option SCHED_ULE" to "option SCHED_4BSD" resolves this problem. The idle state of the FreeBSD domU is now identical to the CentOS domU's. However, this of course means using an old (maybe even deprecated?) scheduler, which moreover isn't the best choice for multiple (virtual) CPUs. The configuration I tested on is: Intel i7 920 Quad-Core with Hyperthreading (8 logical CPUs) Citrix XenServer 5.5 (based on CentOS 5.2, Xen 3.3.1) Any thoughts, ideas, solutions? Thanks! Carsten From sysconfig at ossafe.org Thu Oct 29 23:33:25 2009 From: sysconfig at ossafe.org (Carsten Heesch) Date: Thu Oct 29 23:33:31 2009 Subject: SCHED_ULE vs SCHED_4BSD for XENHVM domU In-Reply-To: <869459F8-7490-4270-84D0-A1168002E509@ossafe.org> References: <869459F8-7490-4270-84D0-A1168002E509@ossafe.org> Message-ID: Oops, sorry for posting this twice. I thought it didn't go through with the first attempt. On 29 Oct 2009, at 23:27, Carsten Heesch wrote: > Hi guys, > > After FreeBSD 8.0-RC2 is working well (for me) on Xen 3.3.1, I > somehow made an interesting observation: > > Even if the FreeBSD domU does absolutely nothing, each of the > assigned vCPUs will be reported by xentop as using 15%-25% CPU time. > It doesn't matter, if domU is running with 1 or 4 vCPUs. All of them > float at the same level. > > On the same Xen box five other domU's (CentOS 5.2-5.4) have an idle > CPU percentage of 0 to 0.5%. > > So I played a bit and figured out that changing the scheduler in the > XENHVM kernel configuration from "option SCHED_ULE" to "option > SCHED_4BSD" resolves this problem. The idle state of the FreeBSD > domU is now identical to the CentOS domU's. > > However, this of course means using an old (maybe even deprecated?) > scheduler, which moreover isn't the best choice for multiple > (virtual) CPUs. > > The configuration I tested on is: > Intel i7 920 Quad-Core with Hyperthreading (8 logical CPUs) > Citrix XenServer 5.5 (based on CentOS 5.2, Xen 3.3.1) > > > Any thoughts, ideas, solutions? > > > Thanks! > > Carsten > > > _______________________________________________ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" Best regards, Carsten Heesch Mobile: +44 (0)7889-129998 Mail: carsten@heesch.me.uk Skype: carstenh74 From mister.olli at googlemail.com Fri Oct 30 09:30:47 2009 From: mister.olli at googlemail.com (Mr. Olli) Date: Fri Oct 30 09:30:53 2009 Subject: SCHED_ULE vs SCHED_4BSD for XENHVM domU In-Reply-To: References: Message-ID: <1256895023.6479.42.camel@phoenix.blechhirn.net> Hi, I compiled FreeBSD8-RC2 from SVN revision 198456 with the XEN config file left unchanged. the domU is 32bit. I'm running on SCHED_ULE and the system consumes <1% vCPU (according to xentop) in idle status. My dom0 is a gentoo linux 32-bit with 2x athlonMP 1900+ and 4GB ram. greetz, ---- Mr. Olli On Thu, 2009-10-29 at 23:12 +0000, Carsten Heesch wrote: > Hi guys, > > After FreeBSD 8.0-RC2 is working well (for me) on Xen 3.3.1, I somehow > made an interesting observation: > > Even if the FreeBSD domU does absolutely nothing, each of the assigned > vCPUs will be reported by xentop as using 15%-25% CPU time. It doesn't > matter, if domU is running with 1 or 4 vCPUs. All of them float at the > same level. > > On the same Xen box five other domU's (CentOS 5.2-5.4) have an idle > CPU percentage of 0 to 0.5%. > > So I played a bit and figured out that changing the scheduler in the > XENHVM kernel configuration from "option SCHED_ULE" to "option > SCHED_4BSD" resolves this problem. The idle state of the FreeBSD domU > is now identical to the CentOS domU's. > > However, this of course means using an old (maybe even deprecated?) > scheduler, which moreover isn't the best choice for multiple > (virtual) CPUs. > > The configuration I tested on is: > Intel i7 920 Quad-Core with Hyperthreading (8 logical CPUs) > Citrix XenServer 5.5 (based on CentOS 5.2, Xen 3.3.1) > > > Any thoughts, ideas, solutions? > > > Thanks! > > Carsten > > > > _______________________________________________ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" From danilobaio at gmail.com Fri Oct 30 18:17:25 2009 From: danilobaio at gmail.com (Danilo Baio) Date: Fri Oct 30 18:17:32 2009 Subject: SCHED_ULE vs SCHED_4BSD for XENHVM domU In-Reply-To: References: Message-ID: <5b9854910910301050j3d6d3ab8h5e9b35227b58304@mail.gmail.com> On Thu, Oct 29, 2009 at 9:12 PM, Carsten Heesch wrote: > Hi guys, > > After FreeBSD 8.0-RC2 is working well (for me) on Xen 3.3.1, I somehow made > an interesting observation: > > Even if the FreeBSD domU does absolutely nothing, each of the assigned > vCPUs will be reported by xentop as using 15%-25% CPU time. It doesn't > matter, if domU is running with 1 or 4 vCPUs. All of them float at the same > level. > > On the same Xen box five other domU's (CentOS 5.2-5.4) have an idle CPU > percentage of 0 to 0.5%. > > So I played a bit and figured out that changing the scheduler in the XENHVM > kernel configuration from "option SCHED_ULE" to "option SCHED_4BSD" resolves > this problem. The idle state of the FreeBSD domU is now identical to the > CentOS domU's. > > However, this of course means using an old (maybe even deprecated?) > scheduler, which moreover isn't the best choice for multiple (virtual) > CPUs. > > The configuration I tested on is: > Intel i7 920 Quad-Core with Hyperthreading (8 logical CPUs) > Citrix XenServer 5.5 (based on CentOS 5.2, Xen 3.3.1) > > > Any thoughts, ideas, solutions? > > > Thanks! > > Carsten > > Hi, Same thing here. I've build 8.0-RC2 amd64 with kernel XENHVM for testing with a XenServer 5.0.0 that i have here. Only the memory information don't appear on the console of xencenter. And the processor 14% of use all the time. After build with SCHED_4BSD, 3% usage CPU. AMD64 - XENHVM freeba8# uname -a FreeBSD freeba8.localdomain 8.0-RC2 FreeBSD 8.0-RC2 #0: Fri Oct 30 15:18:43 BRST 2009 root@freeba8.localdomain:/usr/obj/usr/src/sys/XENHVM amd64 XenServer 5.0.0 (CentOS) Xen 3.2 Regards. -- Danilo Gon?alves Baio (dbaio) danilobaio (*) gmail . com +55 (44) 8801 1257