Date: Sat, 19 Mar 2011 11:54:13 +0200 From: Yuriy Kohut <ykohut@onapp.com> To: Colin Percival <cperciva@freebsd.org> Cc: "freebsd-xen@freebsd.org" <freebsd-xen@freebsd.org> Subject: Re: 8.2-RELEASE (XEN config) panics on /usr/src/sys/i386/xen/pmap.c:1073 Message-ID: <1C2668D1-1E5A-40CC-8D8B-2862A8E6A6B0@onapp.com> In-Reply-To: <4D83BC8A.6030600@freebsd.org> References: <FD51089A-0B47-4854-947D-7EB6A94FE771@onapp.com> <4D83BC8A.6030600@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for making things clear. --- Yura On Mar 18, 2011, at 10:11 PM, Colin Percival wrote: > On 03/18/11 02:56, Yuriy Kohut wrote: >> I got kernel panics while was compiling GHC from ports: >>=20 >> =3D=3D=3D> Configuring for hs-ghc-paths-0.1.0.5_1 >> [1 of 1] Compiling Main ( Setup.hs, Setup.o ) >> Linking setup ... >> gcc: Internal error: Killed: 9 (program ld) >> Please submit a full bug report. >> See <URL:http://gcc.gnu.org/bugs.html>; for instructions. >> *** Error code 1 >=20 > That's not a kernel panic... >=20 >> The panic details are (from main console): >>=20 >> lock order reversal: >> 1st 0xc05b08c4 PMAP2 (PMAP2) @ /usr/src/sys/i386/xen/pmap.c:1049 >> 2nd 0xc054de04 vm page queue mutex (vm page queue mutex) @ = /usr/src/sys/i386/xen/pmap.c:1073 >> KDB: stack backtrace: >> X_db_sym_numargs(c0363f9a,c03e8cbc,282,0,a3481215,...) at = X_db_sym_numargs+0x146 >> kdb_backtrace(c010e74b,c0366eaf,c16ca5f0,c16ca178,cca6eab8,...) at = kdb_backtrace+0x2a >> = witness_display_spinlock(c0366eaf,c054de04,c03670bc,c16ca178,c038d96c,...)= at witness_display_spinlock+0x75 >> witness_checkorder(c054de04,9,c038d96c,431,0,...) at = witness_checkorder+0x839 >> _mtx_lock_flags(c054de04,0,c038d96c,431,292,...) at = _mtx_lock_flags+0xc4 >> pmap_extract(c1ae78fc,28202000,4,c035f3ba,c1ae78fc,...) at = pmap_extract+0x1c8 >> vm_fault_unwire(c1ae784c,28202000,28203000,0,0,...) at = vm_fault_unwire+0x32 >> vm_map_delete(c1ae784c,1000,bf800000,1,c1ae784c,...) at = vm_map_delete+0x17f >> vm_map_remove(c1ae784c,1000,bf800000,0,c1b2d7f8,...) at = vm_map_remove+0x51 >> vmspace_exit(c18f82d0,0,c035bd35,12d,cca6ec60,...) at = vmspace_exit+0xbf >> exit1(c18f82d0,0,cca6ec8c,c0117f86,c18f82d0,...) at exit1+0x5db >> sys_exit(c18f82d0,cca6ecfc,cca6ed38,c0365893,0,...) at sys_exit+0x1d >> syscallenter(c18f82d0,cca6ecf4,cca6ecf4,0,c03335ea,...) at = syscallenter+0x246 >> syscall(cca6ed38) at syscall+0x34 >> Xint0x80_syscall() at Xint0x80_syscall+0x22 >> --- syscall (1, FreeBSD ELF32, sys_exit), eip =3D 0x280ff32f, esp =3D = 0xbf7fe72c, ebp =3D 0xbf7fe738 --- >=20 > This is a known LOR, but shouldn't cause a kernel panic. >=20 > --=20 > Colin Percival > Security Officer, FreeBSD | freebsd.org | The power to serve > Founder / author, Tarsnap | tarsnap.com | Online backups for the truly = paranoid
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1C2668D1-1E5A-40CC-8D8B-2862A8E6A6B0>