Latest current -CURRENT (rev 255904) panics with device hyperv on XenServer 6.2

2013-10-04 Thread Sergey Nasonov 


I just tried FreeBSD 10 ALPHA4 ISO. The ISO fails to boot on
XenServer 6.2 resulting with the same HyperV panic

Regards.
@shankerbalan

Hi,
You can disable viridian support for that VM by command:
xe vm-param-set platform:viridian=false uuid=vm_uuid

after that check platform parameter for FBSD VM by command:
xe vm-param-get param-name=platform uuid=vm_uuid
viridian: false; timeoffset: 0; nx: true; acpi: 1; apic: true; pae: true

It helps me run FreeBSD 10 ALPHA 4 without problems. 

I have tested live migration with both statis and dynamic memory configuration. 
If 
I set static configuration, for example 512 MB RAM then VM migration ends fine. 
VM migration during acive dynamic memory configuration (512 MB - min 1024 MB 
- max) triggers huge amount of console messages:

KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe003d291900
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe003d2919b0
witness_warn() at witness_warn+0x4a8/frame 0xfe003d291a70
uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfe003d291ae0
malloc() at malloc+0x101/frame 0xfe003d291b30
balloon_process() at balloon_process+0x44a/frame 0xfe003d291bb0
fork_exit() at fork_exit+0x84/frame 0xfe003d291bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe003d291bf0
--- trap 0, rip = 0, rsp = 0xfe003d291cb0, rbp = 0 ---
uma_zalloc_arg: zone 16 with the following non-sleepable locks held:
exclusive sleep mutex balloon_lock (balloon_lock) r = 0 (0x816e7158) 
locked 
@ /usr/src/sys/dev/xen/balloon/balloon.c:339
exclusive sleep mutex balloon_mutex (balloon_mutex) r = 0 (0x816e7138) 
locked @ /usr/src/sys/dev/xen/balloon/balloon.c:373
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe003d291900
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe003d2919b0
witness_warn() at witness_warn+0x4a8/frame 0xfe003d291a70
uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfe003d291ae0
malloc() at malloc+0x101/frame 0xfe003d291b30
balloon_process() at balloon_process+0x44a/frame 0xfe003d291bb0
fork_exit() at fork_exit+0x84/frame 0xfe003d291bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe003d291bf0
--- trap 0, rip = 0, rsp = 0xfe003d291cb0, rbp = 0 ---
uma_zalloc_arg: zone 16 with the following non-sleepable locks held:
exclusive sleep mutex balloon_lock (balloon_lock) r = 0 (0x816e7158) 
locked 
@ /usr/src/sys/dev/xen/balloon/balloon.c:339
exclusive sleep mutex balloon_mutex (balloon_mutex) r = 0 (0x816e7138) 
locked @ /usr/src/sys/dev/xen/balloon/balloon.c:373
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe003d291900
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe003d2919b0
witness_warn() at witness_warn+0x4a8/frame 0xfe003d291a70
uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfe003d291ae0
malloc() at malloc+0x101/frame 0xfe003d291b30
balloon_process() at balloon_process+0x44a/frame 0xfe003d291bb0
fork_exit() at fork_exit+0x84/frame 0xfe003d291bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe003d291bf0
--- trap 0, rip = 0, rsp = 0xfe003d291cb0, rbp = 0 ---
uma_zalloc_arg: zone 16 with the following non-sleepable locks held:
exclusive sleep mutex balloon_lock (balloon_lock) r = 0 (0x816e7158) 
locked 
@ /usr/src/sys/dev/xen/balloon/balloon.c:339
exclusive sleep mutex balloon_mutex (balloon_mutex) r = 0 (0x816e7138) 
locked @ /usr/src/sys/dev/xen/balloon/balloon.c:373
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe003d291900
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe003d2919b0
witness_warn() at witness_warn+0x4a8/frame 0xfe003d291a70
uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfe003d291ae0
malloc() at malloc+0x101/frame 0xfe003d291b30
balloon_process() at balloon_process+0x44a/frame 0xfe003d291bb0
fork_exit() at fork_exit+0x84/frame 0xfe003d291bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe003d291bf0
--- trap 0, rip = 0, rsp = 0xfe003d291cb0, rbp = 0 ---
uma_zalloc_arg: zone 16 with the following non-sleepable locks held:
exclusive sleep mutex balloon_lock (balloon_lock) r = 0 (0x816e7158) 
locked 
@ /usr/src/sys/dev/xen/balloon/balloon.c:339
exclusive sleep mutex balloon_mutex (balloon_mutex) r = 0 (0x816e7138) 
locked @ /usr/src/sys/dev/xen/balloon/balloon.c:373
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe003d291900  

After migration VM running on another physical host and ssh session didnt 
interrupted. But I loss console access over XenCenter. 


-- 
Best Regards,
Nasonov Sergey

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Latest current -CURRENT (rev 255904) panics with device hyperv on XenServer 6.2

2013-10-04 Thread Sergey Nasonov 
Hi Sergey,

Thank you very much for suggesting the workaround.

My use case is for users uploading the ISO to CloudStack private cloud and not 
being able to
install FreeBSD 10. As an end user of cloudstack, I don't have access to the 
hypervisor (XenServer)
to make the required param changes.

End user's only have the ability to upload ISOs and create VMs and they will 
hit 
the panic.
Ок, in that case you need to change properties of template, based on which your 
users created their VMs. 

I think it is possible with CloudStack.

-- 
Best Regards,
Nasonov Sergey

___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org

Re: Latest current -CURRENT (rev 255904) panics with device hyperv on XenServer 6.2

2013-10-04 Thread Shanker Balan 
On 04-Oct-2013, at 5:35 PM, Sergey Nasonov snaso...@bcc.ru wrote:

 Hi Sergey,
 
 Thank you very much for suggesting the workaround.
 
 My use case is for users uploading the ISO to CloudStack private cloud and 
 not being able to
 install FreeBSD 10. As an end user of cloudstack, I don't have access to the 
 hypervisor (XenServer)
 to make the required param changes.
 
 End user's only have the ability to upload ISOs and create VMs and they will 
 hit the panic.
 Ок, in that case you need to change properties of template, based on which 
 your users created their VMs. 
  
 

The only user modifiable template setting is the Operating System type.

 I think it is possible with CloudStack.
  
 

As of now, its not possible to modify any param-set options via template 
settings in CloudStack.

Regards.
@shankerbalan
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org