From owner-freebsd-xen@FreeBSD.ORG Tue Feb 12 21:26:35 2013 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB2144F2 for ; Tue, 12 Feb 2013 21:26:35 +0000 (UTC) (envelope-from richardt@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 63D81265 for ; Tue, 12 Feb 2013 21:26:35 +0000 (UTC) Received: from bloch.maths.tcd.ie ([134.226.81.34] helo=bloch.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 12 Feb 2013 21:26:32 +0000 (GMT) Date: Tue, 12 Feb 2013 21:26:32 +0000 From: "Richard M. Timoney" To: freebsd-xen@freebsd.org Subject: FreeBSD 9.1 and Xen 4.0? Message-ID: <20130212212632.GA9603@maths.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: richardt@maths.tcd.ie X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.14 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, 12 Feb 2013 21:26:36 -0000 Dear Jeroen, With regard to the problem of > This boots, and then goes into a loop printing "pudna: fpcurthread == > curthread xx times" when it tries to mount the filesystem. I had a similar issue with 8.3 and I found that the change that precipitated it was r241253, a change to sys/kern/sched_ule.c that really seemed to have nothing to do with the symptoms. http://svnweb.freebsd.org/base?view=revision&revision=241253 However, in my case FreeBSD 9.1 would boot (the one I tried was kernel_9.1_r244394). My Dom0 is a Dell R815 (which has AMD processors) and I don't see the issue on a Dell 2900 (which has Intel CPUs and a slightly older Xen). The newer version is using package xen-hypervisor 4.0.1-4 , while the older is 4.0.1-2. I have found a work-around (for 8.3) that involves putting code in sched_ule.c that does nothing really useful and nothing at all once the system is running for any length of time. But it seems to get the thing to boot, and then stuff seems stable after that. Here is the diff I am using now: ============================ svn diff sys/kern/sched_ule.c Index: sys/kern/sched_ule.c =================================================================== --- sys/kern/sched_ule.c (revision 246597) +++ sys/kern/sched_ule.c (working copy) @@ -1848,6 +1848,7 @@ struct td_sched *ts; struct mtx *mtx; int srqflag; + static int sched_switch_num_times=0; int cpuid, preempted; THREAD_LOCK_ASSERT(td, MA_OWNED); @@ -1949,6 +1950,10 @@ TDQ_LOCK_ASSERT(tdq, MA_OWNED|MA_NOTRECURSED); MPASS(td->td_lock == TDQ_LOCKPTR(tdq)); td->td_oncpu = cpuid; +if (sched_switch_num_times < 5000) { + ++sched_switch_num_times; + sscanf("5", "%d", &cpuid); + } } /* ============================ It would be nice to know what the actual problem is, because the fix makes no real sense to me (and seems to have nothing to do with the code where the fpudna message is generated. I could see some mention of a symptom like this some years ago, but none recently. I suppose it is somehow reassuring that more than one person has the issue. Yours, Richard -- Richard M. Timoney (richardt@maths.tcd.ie) Tel. +353-1-896 1196 School of Mathematics, Trinity College, Dublin 2, Ireland WWW http://www.maths.tcd.ie/~richardt FAX +353-1-896 2282