From owner-freebsd-xen@FreeBSD.ORG Mon Sep 21 11:07:11 2009 Return-Path: Delivered-To: freebsd-xen@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FE6910656AB for ; Mon, 21 Sep 2009 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F265B8FC28 for ; Mon, 21 Sep 2009 11:07:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8LB7Afw030494 for ; Mon, 21 Sep 2009 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8LB7AOR030490 for freebsd-xen@FreeBSD.org; Mon, 21 Sep 2009 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Sep 2009 11:07:10 GMT Message-Id: <200909211107.n8LB7AOR030490@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-xen@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-xen@FreeBSD.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 11:07:11 -0000 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 owner-freebsd-xen@FreeBSD.ORG Tue Sep 22 13:00:43 2009 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4478C1065676 for ; Tue, 22 Sep 2009 13:00:43 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id D3B968FC19 for ; Tue, 22 Sep 2009 13:00:42 +0000 (UTC) Received: (qmail 30233 invoked by uid 1000); 22 Sep 2009 12:34:01 -0000 Date: Tue, 22 Sep 2009 08:34:01 -0400 From: Larry Baird To: freebsd-xen@freebsd.org Message-ID: <20090922123401.GB29391@gta.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="aVD9QWMuhilNxW9f" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: XEN 5.5.0 and clflush X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 13:00:43 -0000 --aVD9QWMuhilNxW9f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I originally sent this message to freebsd-current. Got no response, perhaps freebsd-xen is a better mailing list. (-: Since the end of August I have been unable to boot a generic kernel from FreeBSD current or 8 under XEN 5.5.0. Finally had a chance to briefly look at the problem. If I apply attached patch to remove calls to clflush() I am able to boot current. Hopefully somebody can shed some light. Is XEN incorrecty reporting CPUID_CLFSH or is XEN not correctly virtualizing this option. Or is the issue someplace else? I have also attached the dmesg from a successful boot. This issue seems to be same as http://www.freebsd.org/cgi/query-pr.cgi?pr=138863 Here is an attempt to type backtrace from non-booting kernel: pmap_invalidate_cache_range(c3252000,c3253000,c3253000,0,fee00000,...) at +pamp_invalidate_cache_range+0x60 pmap_mapdev_attr(fee00000,400,0,c1420d34,c0ba7a72,...) at pmap_mapdev_attr+0xec pmap_mapdev() at pmap_mapdev+0x20 lapic_init() at lapic_init+0x32 madt_setup_local() at madt_setup_local+0x2c apic_init() at apic_init+0x11a mistartup() at mi_startup+0x96 begin() at begin+0x2c 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 --aVD9QWMuhilNxW9f Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="pmap.patch" --- pmap.c.orig 2009-09-21 11:14:53.000000000 -0400 +++ pmap.c 2009-09-21 11:15:01.000000000 -0400 @@ -992,9 +992,10 @@ KASSERT((eva & PAGE_MASK) == 0, ("pmap_invalidate_cache_range: eva not page-aligned")); - if (cpu_feature & CPUID_SS) + if (cpu_feature & CPUID_SS) { ; /* If "Self Snoop" is supported, do nothing. */ - else if (cpu_feature & CPUID_CLFSH) { +#ifdef MAYBE_09_21_2009 + } else if (cpu_feature & CPUID_CLFSH) { /* * Otherwise, do per-cache line flush. Use the mfence @@ -1007,6 +1008,7 @@ for (; sva < eva; sva += cpu_clflush_line_size) clflush(sva); mfence(); +#endif // MAYBE_09_21_2009 } else { /* --aVD9QWMuhilNxW9f Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" 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 #2: Mon Sep 21 11:00:46 EDT 2009 lab@sw-xenoss.gta.com:/usr/src/sys/i386/compile/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (1691.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0x789fbff Features2=0x80002201> AMD Features=0x20000000 AMD Features2=0x1 TSC: P-state invariant real memory = 536870912 (512 MB) avail memory = 493977600 (471 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1f48-0x1f4b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 62500000 Hz quality 900 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,0xc220-0xc22f at device 1.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xc200-0xc21f irq 23 at device 1.2 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0000 usbus0: controller did not stop usbus0: on uhci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xf0000000-0xf1ffffff,0xf3000000-0xf3000fff at device 2.0 on pci0 pci0: at device 3.0 (no driver attached) re0: port 0xc100-0xc1ff mem 0xf3001000-0xf30010ff irq 32 at device 4.0 on pci0 re0: Chip rev. 0x74800000 re0: MAC rev. 0x00000000 miibus0: on re0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: Ethernet address: 4e:c4:60:ce:d0:72 re0: [FILTER] atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] 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: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 cpu0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd7fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1691834274 Hz quality 800 Timecounters tick every 10.000 msec usbus0: 12Mbps Full Speed USB v1.0 ad0: 20480MB at ata0-master WDMA2 ugen0.1: at usbus0 uhub0: on usbus0 GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s). uhub0: 2 ports with 2 removable, self powered ugen0.2: at usbus0 ums0: on usbus0 ums0: 3 buttons and [Z] coordinates ID=0 acd0: CDROM at ata1-slave WDMA2 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s1a lock order reversal: (sleepable after non-sleepable) 1st 0xc390a058 rtentry (rtentry) @ net/route.c:1409 2nd 0xc0f433b8 ifnet_sx (ifnet_sx) @ netinet/sctp_bsd_addr.c:211 KDB: stack backtrace: db_trace_self_wrapper(c0c828bc,d6957788,c08c2725,c08b354b,c0c85715,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08b354b,c0c85715,c35286e8,c352c8b8,d69577e4,...) at kdb_backtrace+0x29 _witness_debugger(c0c85715,c0f433b8,c0c8e50e,c352c8b8,c0c9865e,...) at _witness_debugger+0x25 witness_checkorder(c0f433b8,1,c0c98655,d3,0,...) at witness_checkorder+0x839 _sx_slock(c0f433b8,0,c0c98655,d3,d6957878,...) at _sx_slock+0x85 sctp_init_ifns_for_vrf(3,c39018c0,d69578c0,c08c3178,c3901964,...) at sctp_init_ifns_for_vrf+0x30 sctp_addr_change(c38ffa00,1,d69578c0,c08c256c,d695791c,...) at sctp_addr_change+0x2c rt_newaddrmsg(1,c38ffa00,0,c390a000,c38ffa00,...) at rt_newaddrmsg+0x3f rtinit(c38ffa00,1,5,c0de9cfc,51573592,...) at rtinit+0x381 in_ifinit(0,c0c96ee7,1aa,1a6,c3814800,...) at in_ifinit+0x8f6 in_control(c38f7000,8040691a,c3907dc0,c3814800,c39018c0,...) at in_control+0xccb ifioctl(c38f7000,8040691a,c3907dc0,c39018c0,c38ff200,...) at ifioctl+0x14f0 soo_ioctl(c385f540,8040691a,c3907dc0,c356e100,c39018c0,...) at soo_ioctl+0x415 kern_ioctl(c39018c0,3,8040691a,c3907dc0,8bc060,...) at kern_ioctl+0x1fd ioctl(c39018c0,d6957cf8,c,c0c96f81,c0d665c8,...) at ioctl+0x134 syscall(d6957d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281bf513, esp = 0xbfbfe61c, ebp = 0xbfbfe658 --- --aVD9QWMuhilNxW9f-- From owner-freebsd-xen@FreeBSD.ORG Tue Sep 22 13:31:14 2009 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E7A01065676 for ; Tue, 22 Sep 2009 13:31:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id ABFD08FC08 for ; Tue, 22 Sep 2009 13:31:13 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n8MDAYKC057026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2009 16:10:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n8MDAYH7016244; Tue, 22 Sep 2009 16:10:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n8MDAYXw016243; Tue, 22 Sep 2009 16:10:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Sep 2009 16:10:34 +0300 From: Kostik Belousov To: Larry Baird Message-ID: <20090922131034.GV47688@deviant.kiev.zoral.com.ua> References: <20090922123401.GB29391@gta.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+dV+xilh7QQozWTa" Content-Disposition: inline In-Reply-To: <20090922123401.GB29391@gta.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: freebsd-xen@freebsd.org Subject: Re: XEN 5.5.0 and clflush X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 13:31:14 -0000 --+dV+xilh7QQozWTa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2009 at 08:34:01AM -0400, Larry Baird wrote: > I originally sent this message to freebsd-current. Got no response, perh= aps > freebsd-xen is a better mailing list. (-: >=20 > Since the end of August I have been unable to boot a generic kernel from > FreeBSD current or 8 under XEN 5.5.0. Finally had a chance to briefly lo= ok > at the problem. If I apply attached patch to remove calls to clflush() I > am able to boot current. Hopefully somebody can shed some light. Is > XEN incorrecty reporting CPUID_CLFSH or is XEN not correctly virtualizing > this option. Or is the issue someplace else? I have also attached the > dmesg from a successful boot. This issue seems to be same as > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138863 >=20 >=20 > Here is an attempt to type backtrace from non-booting kernel: >=20 > pmap_invalidate_cache_range(c3252000,c3253000,c3253000,0,fee00000,...) at > +pamp_invalidate_cache_range+0x60 > pmap_mapdev_attr(fee00000,400,0,c1420d34,c0ba7a72,...) at pmap_mapdev_att= r+0xec > pmap_mapdev() at pmap_mapdev+0x20 > lapic_init() at lapic_init+0x32 > madt_setup_local() at madt_setup_local+0x2c > apic_init() at apic_init+0x11a > mistartup() at mi_startup+0x96 > begin() at begin+0x2c I am sorry for delay in answering, you may use this temporal patch until the issue is resolved somehow. I think I will have to disable CLFLUSH support for intel CPUs when self-sno= op is not reported. diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 1f37765..7de1ca5 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -997,7 +997,7 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_= t eva) =20 if (cpu_feature & CPUID_SS) ; /* If "Self Snoop" is supported, do nothing. */ - else if (cpu_feature & CPUID_CLFSH) { + else if (0 && cpu_feature & CPUID_CLFSH) { =20 /* * Otherwise, do per-cache line flush. Use the mfence diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c index 7e3bc37..56c6776 100644 --- a/sys/i386/i386/pmap.c +++ b/sys/i386/i386/pmap.c @@ -994,7 +994,7 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_= t eva) =20 if (cpu_feature & CPUID_SS) ; /* If "Self Snoop" is supported, do nothing. */ - else if (cpu_feature & CPUID_CLFSH) { + else if (0 && cpu_feature & CPUID_CLFSH) { =20 /* * Otherwise, do per-cache line flush. Use the mfence diff --git a/sys/i386/xen/pmap.c b/sys/i386/xen/pmap.c index 1d9c9c1..7dc8029 100644 --- a/sys/i386/xen/pmap.c +++ b/sys/i386/xen/pmap.c @@ -994,7 +994,7 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_= t eva) =20 if (cpu_feature & CPUID_SS) ; /* If "Self Snoop" is supported, do nothing. */ - else if (cpu_feature & CPUID_CLFSH) { + else if (0 && cpu_feature & CPUID_CLFSH) { =20 /* * Otherwise, do per-cache line flush. Use the mfence --+dV+xilh7QQozWTa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkq4zMoACgkQC3+MBN1Mb4hwwwCgxWtzvWy3WKfT8xMYYjSsSI20 HtEAn14LQfIjMDqlDKpBQaHwwImBj306 =rcIu -----END PGP SIGNATURE----- --+dV+xilh7QQozWTa-- From owner-freebsd-xen@FreeBSD.ORG Tue Sep 22 13:59:15 2009 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D783A106566C for ; Tue, 22 Sep 2009 13:59:15 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 2070D8FC0C for ; Tue, 22 Sep 2009 13:59:14 +0000 (UTC) Received: (qmail 47497 invoked by uid 1000); 22 Sep 2009 13:59:14 -0000 Date: Tue, 22 Sep 2009 09:59:14 -0400 From: Larry Baird To: Kostik Belousov Message-ID: <20090922135914.GA44294@gta.com> References: <20090922123401.GB29391@gta.com> <20090922131034.GV47688@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090922131034.GV47688@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-xen@freebsd.org Subject: Re: XEN 5.5.0 and clflush X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 13:59:15 -0000 Kostik, > I am sorry for delay in answering, you may use this temporal patch until > the issue is resolved somehow. > > I think I will have to disable CLFLUSH support for intel CPUs when self-snoop > is not reported. Thanks for the feedback? Have you heard about this being a problem on platforms other than XEN? I am not sure how many FreeBSD users are using XEN. If this is a large base, getting a fix in before FreeBSD 8 is released would be nice. (-: 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 owner-freebsd-xen@FreeBSD.ORG Tue Sep 22 14:14:43 2009 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18748106568F for ; Tue, 22 Sep 2009 14:14:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 65D9B8FC1E for ; Tue, 22 Sep 2009 14:14:42 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n8MEEe0g062484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2009 17:14:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n8MEEetD020182; Tue, 22 Sep 2009 17:14:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n8MEEel3020181; Tue, 22 Sep 2009 17:14:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Sep 2009 17:14:40 +0300 From: Kostik Belousov To: Larry Baird Message-ID: <20090922141440.GX47688@deviant.kiev.zoral.com.ua> References: <20090922123401.GB29391@gta.com> <20090922131034.GV47688@deviant.kiev.zoral.com.ua> <20090922135914.GA44294@gta.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BgdT6MQD5banEouU" Content-Disposition: inline In-Reply-To: <20090922135914.GA44294@gta.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: freebsd-xen@freebsd.org Subject: Re: XEN 5.5.0 and clflush X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 14:14:43 -0000 --BgdT6MQD5banEouU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2009 at 09:59:14AM -0400, Larry Baird wrote: > Kostik, >=20 > > I am sorry for delay in answering, you may use this temporal patch until > > the issue is resolved somehow. > >=20 > > I think I will have to disable CLFLUSH support for intel CPUs when self= -snoop > > is not reported. > Thanks for the feedback? Have you heard about this being a problem on > platforms other than XEN? No, and AMD should have CPUs without self-snoop, but supporting CLFLUSH. This is the main reason for this optimization came in, and no single compla= in from this problem on AMD (i.e. on native CPU, not under the hypervisor). > I am not sure how many FreeBSD users are using > XEN. If this is a large base, getting a fix in before FreeBSD 8 is > released would be nice. (-: >=20 > Larry >=20 >=20 > --=20 > ------------------------------------------------------------------------ > Larry Baird | http://www.gta.com > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 --BgdT6MQD5banEouU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkq4288ACgkQC3+MBN1Mb4hQAACg22/9H738kk/FzKkYNkLH6fFC kesAnjFvg2Ks+aS4IDp+XPNXI9DkXHkj =Jl5X -----END PGP SIGNATURE----- --BgdT6MQD5banEouU-- From owner-freebsd-xen@FreeBSD.ORG Tue Sep 22 17:19:20 2009 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D23C1065670 for ; Tue, 22 Sep 2009 17:19:20 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 7A2568FC0A for ; Tue, 22 Sep 2009 17:19:19 +0000 (UTC) Received: (qmail 87337 invoked by uid 1000); 22 Sep 2009 17:19:18 -0000 Date: Tue, 22 Sep 2009 13:19:18 -0400 From: Larry Baird To: Kevin Day Message-ID: <20090922171918.GA86010@gta.com> References: <20090922123401.GB29391@gta.com> <20090922131034.GV47688@deviant.kiev.zoral.com.ua> <5078471e0909221003g43a125f4s99a1f841616bb184@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5078471e0909221003g43a125f4s99a1f841616bb184@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-xen@freebsd.org Subject: Re: XEN 5.5.0 and clflush X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 17:19:20 -0000 > > I think I will have to disable CLFLUSH support for intel CPUs when > > self-snoop > > is not reported. > > > > > That's the kinda weird part about this though... It's not triggering an > Invalid Instruction, but a GPF. Looking at AMD's description of how CLFLUSH > is supposed to work, I don't see why it's faulting with what looks like a > valid address. > > While this is probably far outside the scope of what their entry-level > support techs will understand, I can try raising this as a bug with Citrix > under our support contract if you're confident that this is broken on Xen's > end. I keep wondering about comments having to do with AMD processor. The native processor is an an Intel Xeon. Is this piece of the puzzle important? 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 owner-freebsd-xen@FreeBSD.ORG Tue Sep 22 17:28:10 2009 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C632106566C for ; Tue, 22 Sep 2009 17:28:10 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-iw0-f196.google.com (mail-iw0-f196.google.com [209.85.223.196]) by mx1.freebsd.org (Postfix) with ESMTP id 50FC08FC16 for ; Tue, 22 Sep 2009 17:28:10 +0000 (UTC) Received: by iwn34 with SMTP id 34so574686iwn.12 for ; Tue, 22 Sep 2009 10:28:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.83.75 with SMTP id e11mr2422853ibl.11.1253638985611; Tue, 22 Sep 2009 10:03:05 -0700 (PDT) X-Originating-IP: [67.186.84.206] In-Reply-To: <20090922131034.GV47688@deviant.kiev.zoral.com.ua> References: <20090922123401.GB29391@gta.com> <20090922131034.GV47688@deviant.kiev.zoral.com.ua> Date: Tue, 22 Sep 2009 12:03:05 -0500 Message-ID: <5078471e0909221003g43a125f4s99a1f841616bb184@mail.gmail.com> From: Kevin Day To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-xen@freebsd.org, Larry Baird Subject: Re: XEN 5.5.0 and clflush X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 17:28:10 -0000 On Tue, Sep 22, 2009 at 8:10 AM, Kostik Belousov wrote: > > I think I will have to disable CLFLUSH support for intel CPUs when > self-snoop > is not reported. > > That's the kinda weird part about this though... It's not triggering an Invalid Instruction, but a GPF. Looking at AMD's description of how CLFLUSH is supposed to work, I don't see why it's faulting with what looks like a valid address. While this is probably far outside the scope of what their entry-level support techs will understand, I can try raising this as a bug with Citrix under our support contract if you're confident that this is broken on Xen's end. From owner-freebsd-xen@FreeBSD.ORG Wed Sep 23 11:06:00 2009 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE511106566B for ; Wed, 23 Sep 2009 11:05:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 61EFD8FC0A for ; Wed, 23 Sep 2009 11:05:59 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n8NB5iKd053659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Sep 2009 14:05:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n8NB5i1J014590; Wed, 23 Sep 2009 14:05:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n8NB5htq014589; Wed, 23 Sep 2009 14:05:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Sep 2009 14:05:43 +0300 From: Kostik Belousov To: Larry Baird Message-ID: <20090923110543.GC47688@deviant.kiev.zoral.com.ua> References: <20090922123401.GB29391@gta.com> <20090922131034.GV47688@deviant.kiev.zoral.com.ua> <5078471e0909221003g43a125f4s99a1f841616bb184@mail.gmail.com> <20090922171918.GA86010@gta.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vHRy1SDQH4LgMqtx" Content-Disposition: inline In-Reply-To: <20090922171918.GA86010@gta.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-xen@freebsd.org Subject: Re: XEN 5.5.0 and clflush X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 11:06:00 -0000 --vHRy1SDQH4LgMqtx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2009 at 01:19:18PM -0400, Larry Baird wrote: > > > I think I will have to disable CLFLUSH support for intel CPUs when > > > self-snoop > > > is not reported. > > > > > > > > That's the kinda weird part about this though... It's not triggering an > > Invalid Instruction, but a GPF. Looking at AMD's description of how CLF= LUSH > > is supposed to work, I don't see why it's faulting with what looks like= a > > valid address. > >=20 > > While this is probably far outside the scope of what their entry-level > > support techs will understand, I can try raising this as a bug with Cit= rix > > under our support contract if you're confident that this is broken on X= en's > > end. > I keep wondering about comments having to do with AMD processor. The > native processor is an an Intel Xeon. Is this piece of the puzzle > important? Ok, the whole story (mostly to be able to point out an URL with description until the issue is sorted out). FreeBSD got ability to specify page caching attributes in the page table entries, so called Page Attribute Table (PAT). The physical to linear page mapping may specify the caching attribute, like WB (write-back), UC (uncacheable), WT (write-through) and so on. The procedure to set the caching attribute for the page involves removing old mapping, flushing TLB, creating new mapping, and then flushing the cache line that could be allocated for the remmapped physical memory. Flushing the cache may be performed by one of the three mechanisms: - do nothing; this is acceptable if CPU has so called Self-Snoop feature. For future discussion it is important to note that the feature is declared in the feature bitmap returned by CPUID instruction. - do the series of CLFLUSH instructions over the linear region. This method should be used if CPU has CLFLUSH support, again reported by CPUID. - do the WBINVD instruction that flushes the whole CPU cache. The methods above are ordered from most efficient (do nothing) to very time-consuming, and FreeBSD falls to the next method if previous is not supported. Real Intel CPUs (almost) all have all three methods implemented, and we do nothing to flush cache since self snoop is there. AMD CPUs, at least older models, do not have self-snoop, I believe, but do support CLFLUSH. I got no reports of problems caused by CLFLUSH on the AMD. If I manually disable self-snoop on Intel CPU, I get a reversed trap when doing CLFLUSH over the mapping for APIC registers page. I do not know the cause for this, my unfounded speculation is that there is some cache line allocated for it, and it is written out on CLFLUSH. Speculation is flimsy since BIOS should have programmed MTRR so that APIC is UC mode. Now, add the XEN to the picture. When whole machine virtualization (how it is called by XEN ?) runs GENERIC/i386 kernel, it uses so called VT feature of recent Intel CPUs, that, among other, gives the hypervisor the ability to intercept CPUID instruction. XEN seems to modify reported CPU features, removing self-snoop. As result. we fall back to CLFLUSH method. XEN seems to translate a fault caused by cache write-back to the APIC registrers, into #gpf. This is the issue that you get on XEN. So, I do not know why Intels cause trap on CLFLUSH, this may be either some stupidness in my clflush code, or an additional factor that I did not taken care of yet. Patch I sent disables CLFLUSH unconditionally, that is bad for performance on AMD. --vHRy1SDQH4LgMqtx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkq6AQYACgkQC3+MBN1Mb4igqQCfYQpu1Hx5xiVCpxMR6s1Uyips +RYAoIbkJzO8Kf8XIIzftK4HKwBC05MT =bCkf -----END PGP SIGNATURE----- --vHRy1SDQH4LgMqtx-- From owner-freebsd-xen@FreeBSD.ORG Sat Sep 26 13:01:39 2009 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95BB4106566C for ; Sat, 26 Sep 2009 13:01:39 +0000 (UTC) (envelope-from o.roeschke@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 011A08FC0C for ; Sat, 26 Sep 2009 13:01:38 +0000 (UTC) Received: (qmail invoked by alias); 26 Sep 2009 12:34:57 -0000 Received: from p5B3154FB.dip.t-dialin.net (EHLO [10.10.1.210]) [91.49.84.251] by mail.gmx.net (mp061) with SMTP; 26 Sep 2009 14:34:57 +0200 X-Authenticated: #26761920 X-Provags-ID: V01U2FsdGVkX185YP5nxIU5qL8E0MTSqnvZQcXFFvir1aBDMiJW8b N4J69nY8xlOBAr From: Oliver Roeschke To: freebsd-current@freebsd.org Content-Type: text/plain Organization: o.roeschke@gmx.net Date: Sat, 26 Sep 2009 14:34:28 +0200 Message-Id: <1253968468.2211.103.camel@phoenix.blechhirn.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: freebsd-xen@freebsd.org Subject: FreeBSD8-RC1 crashed X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: o.roeschke@gmx.net List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 13:01:39 -0000 Hi all, I just noticed that my XEN pv-domU based on FreeBSD8-RC1 (based on SVN r197306) crashed with the following message: [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. panic: mtx_lock() of spin mutex (null) @ /test/usr-src/sys/net/netisr.c:830 cpuid = 0 KDB: enter: panic [thread pid 21716 tid 100098 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 21716 tid 100098 td 0xc423c900 kdb_enter(c035ddd5,c035ddd5,c035c7cd,e422d9cc,0,...) at kdb_enter+0x3a panic(c035c7cd,0,c036da84,33e,16d,...) at panic+0x136 _mtx_lock_flags(c082d808,0,c036da84,33e,c3441d00,...) at _mtx_lock_flags+0x9a netisr_clearqdrops(e422da28,c423c9a4,c05129d0,0) at netisr_clearqdrops+0x66e netisr_queue_src(1,0,c3441d00,e422da6c,c01862de,...) at netisr_queue_src+0xa7 netisr_queue(1,c3441d00,c3441d48,e422daf8,e422da80,...) at netisr_queue+0x20 if_simloop(c32e9400,c3441d00,2,0,c01a2a8f,...) at if_simloop+0xfe looutput(c32e9400,c3441d00,e422db00,e422daf8,c031ff74,...) at looutput+0x141 ip_output(c3441d00,0,0,0,0,...) at ip_output+0x9cc tcp_output(c40c09e0,ca870340,1b9,c40be7a8,c40dc338,...) at tcp_output+0x1540 tcp_ctloutput(c40dc338,ca870340,c423c900,25,e422dc70,...) at tcp_ctloutput+0x933 soconnect(c40dc338,ca870340,c423c900,bf7fae20,ca870340,...) at soconnect+0x52 kern_connect(c423c900,6,ca870340,ca870340,ffffffff,...) at kern_connect+0xa6 connect(c423c900,e422dd08,c,c03646ed,c039d8b8,...) at connect+0x46 syscall(e422dd48) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x22 --- syscall (98, FreeBSD ELF32, connect), eip = 0x283b9e5b, esp = 0xbf7facbc, ebp = 0xbf7faee8 --- Is this issue already known? I have reserved the domU state, so further troubleshooting is not a problem. If anyone wonders, '/test/usr-src' is '/usr/src' within a ZFS volume ;-)) Regards, --- Mr. Olli From owner-freebsd-xen@FreeBSD.ORG Sat Sep 26 21:08:06 2009 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39C2F106566B for ; Sat, 26 Sep 2009 21:08:06 +0000 (UTC) (envelope-from edwin.shao@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id EBBAD8FC1A for ; Sat, 26 Sep 2009 21:08:05 +0000 (UTC) Received: by an-out-0708.google.com with SMTP id d14so1262792and.13 for ; Sat, 26 Sep 2009 14:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=E6ajQOTQArDe5XwYJugLfcCnZ5tsMOFCPIAOYMPygXM=; b=aanuNqe3jmENS/s5LcwhBdA8S9H1+XG7I3ujDJXgcbyRZloOtl3Yjz6A8102l1EYYN S4EG0GRiCW4OElG615+WSut9D6KLEkDqgVfIWuQz/R7TIezBj8gsJDoJGjn/o+XPBATo AC/B5dwDDYuCb8fP2v2JOhk/pWw57vqhUyQEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=LnqdV8uhtQ3ktihXDC8V21BJ4rc6BZ9x4BAzraFfAS2ayuztLN/9WjjxPsEQsC+olO 6oFl0BhBg0hVfvaYi2wtNyWq6P3znS1dcBpBFqJrHSsRAfFh8iaEkwVBE72tFrtpmAfl 7TuQaSUdavmTJ+FNKSqlMB/KLhIIo7//LjkzE= MIME-Version: 1.0 Received: by 10.100.27.12 with SMTP id a12mr1707776ana.110.1253997614776; Sat, 26 Sep 2009 13:40:14 -0700 (PDT) From: Edwin Shao Date: Sat, 26 Sep 2009 23:32:48 +0300 Message-ID: To: freebsd-xen@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Kernel trap 9 using 8.0-RC1 compiled with "XEN" configuration X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 21:08:06 -0000 As stated in subject, newly compiled 8.0-RC1 source using standard "XEN" configuration fails with the below message. 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: Sat Sep 26 20:23:41 UTC 2009 root@hyper.nekogiri.com:/usr/obj/usr/src/sys/XEN WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 2311.848 MHz processor. Timecounter "ixen" frequency 1000000000 Hz quality 0 CPU: Quad-Core AMD Opteron(tm) Processor 2376 (2311.85-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 671088640 (640 MB) avail memory = 646967296 (616 MB) [XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0) [XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1) kbd0 at kbdmux0 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 Timecounters tick every 10.000 msec kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x21:0xc0309169 stack pointer = 0x29:0xc2861cb8 frame pointer = 0x29:0xc2861cc8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 1, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 11 (idle: cpu0) [thread pid 11 tid 100003 ] Stopped at spinlock_enter+0x99: hlt db> bt Tracing pid 11 tid 100003 td 0xc2b08b40 spinlock_enter(1,c2b08b40,c03c8d40,c2861ce8,c0309c63,...) at spinlock_enter+0x99 sched_idletd(0,c2861d38,c2b06aa0,0,0,...) at sched_idletd+0x205 fork_exit(c00f5048,0,c2861d38) at fork_exit+0x76 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc2861d70, ebp = 0 ---