Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Jun 2011 11:36:32 +0200
From:      Sergi <sergi@estrafolari.com>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-xen@freebsd.org
Subject:   Re: fpudna: fpcurthread == curthread XXXX times
Message-ID:  <4DE60820.1080409@estrafolari.com>
In-Reply-To: <20110601082156.GB48734@deviant.kiev.zoral.com.ua>
References:  <4DE5EDD7.20105@estrafolari.com> <20110601082156.GB48734@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On 01/06/11 10:21, Kostik Belousov wrote:
> On Wed, Jun 01, 2011 at 09:44:23AM +0200, Sergi wrote:
>    
>> Hello,
>>
>> I'm working with full virtual FreeBSD 8.2-RELEASE-p1 domU under debian
>> squeeze and xen-hypervisor-4.0-amd64.
>>
>> If I cfg this hvm with cpu>  4 :
>>
>>   vcpus    = 5
>>
>> these messages block the server :
>>
>>   fpudna: fpcurthread == curthread XXXX times
>>
>> The machine is pingable but I'm unable to ssh to it.
>>
>> On single user it works fine, fsck an so on ok, but when switching to
>> multiuser these fpudna messages start flooding.
>>
>> I've googled but haven't found anything; something from 2005 about fpudna :
>>
>>   http://lists.freebsd.org/pipermail/freebsd-amd64/2005-April/004413.html
>>
>> and this link, but I don't have the options he mentions enabled on the
>> kernel :
>>
>>   http://forums.freebsd.org/showthread.php?t=17979
>>
>> Has anyone stepped on this behaviour before?, is there any workaround?
>> The machine really seems to detect cpu's available and responds to keyboard
>> on VNC, but it's impossible to see whats written down because of the
>> messages flooding the screen.
>>      
> You did not specified the architecture of the domu. From the message, I can
> guess that your guest is running amd64 kernel. There are slight differences
> in the handling of the FPU in i386 and amd64 that may matter there.
>
> The message you reported means that the FreeBSD kernel assumes that FPU
> is currently loaded with the context of the current thread, but the
> CR0.TS bit is set, meaning that FPU context is set for switch.
>
> AFAIR, HVM means that you run bare-metal kernel, right ? Most likely,
> it is some issue with Xen itself. I am curious whether the following
> will cause any usermode-visible regression for you:
>
> diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c
> index 08e5e57..a5ee853 100644
> --- a/sys/amd64/amd64/fpu.c
> +++ b/sys/amd64/amd64/fpu.c
> @@ -394,14 +394,8 @@ fpudna(void)
>   	struct pcb *pcb;
>
>   	critical_enter();
> -	if (PCPU_GET(fpcurthread) == curthread) {
> -		printf("fpudna: fpcurthread == curthread %d times\n",
> -		    ++err_count);
> -		stop_emulating();
> -		critical_exit();
> -		return;
> -	}
> -	if (PCPU_GET(fpcurthread) != NULL) {
> +	if (PCPU_GET(fpcurthread) != NULL&&
> +	    PCPU_GET(fpcurthread) != curthread) {
>   		printf("fpudna: fpcurthread = %p (%d), curthread = %p (%d)\n",
>   		       PCPU_GET(fpcurthread),
>   		       PCPU_GET(fpcurthread)->td_proc->p_pid,
>    
Hello,

yes, sorry, amd64, and yes, hvm hardware virtual machine, not paravirtual.

So, you mean patching fpu.c and recompiling the kernel, right?, I'm new 
to modifiying src files.

Thanks for your help,
Sergi





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DE60820.1080409>