similar to: Re: FreeBSD PVHVM call for testing

On 19/06/13 14:33, Jeroen van der Ham wrote: > > On 19 Jun 2013, at 14:20, Roger Pau Monné <roger.pau@citrix.com> wrote: >> That''s because Justin recently pushed a commit that changed the ad >> translation to ada, you should change your /etc/fstab to ada0p2. It''s >> commit 526f3ad11acb296481215d7c2915b3f30f1844f6. > > > Ah, you may want

Hi, After some more testing I thought it would be good to put this into production for my personal server. I''ve used pvhvm_v19 and built it without debugging options and installed it on a FreeBSD 9.1 system. I''ve run into some hiccups with 9.1 user land and a 10-CURRENT kernel, but that''s all solvable[0]. My VPS has some very limited memory (256M), but I''ve

On 19 Jun 2013, at 13:34, Roger Pau Monné <roger.pau@citrix.com> wrote: > > Could you provide the boot log of the DomU, backtrace, Xen version and > Dom0 kernel version? I did not have a console attached when it rebooted, so I did not have a log of the initial boot. Now that I did, I see that it fails to mount its root volume. It had been running previously on pvhvm_v10 for about

Hello, I'm having some trouble getting a good result for a smoothScatter plot. I have some data that I want to log-plot, but when I use smoothScatter the result is not correct. The problem seems to be that with the log="x" argument smoothScatter calculates the bins linearly, so the plot will be skewed towards the right. See for example:

flight 12043 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/12043/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rhel6hvm-amd 7 redhat-install fail REGR. vs. 12031 test-amd64-i386-rhel6hvm-intel 7 redhat-install fail REGR. vs. 12031 test-amd64-i386-xl-winxpsp3-vcpus1 7

Huge thanks to you (Jeroen) and R-core for doing this. I wasn't involved with this directly but I know it was a pretty seriously heavy list so well done all around! ~G On Tue, Apr 28, 2020, 11:04 AM Herv? Pag?s <hpages at fredhutch.org> wrote: > Thanks Jeroen! > > > On Tue, Apr 7, 2020 at 6:07 PM Kevin Ushey <kevinushey at gmail.com> wrote: > >> >

Boulder, CO - August 25, 2003 - The FreeBSD Foundation today announced the availability of a binary distribution of the Java JDK version 1.3.1 for the widely used FreeBSD operating system. Wes Peters of the FreeBSD Core Team commented "This announcement hallmarks a new era of Java support for FreeBSD. Having easy to install binary Java packages will ensure that all users can enjoy the

Thanks Jeroen! > On Tue, Apr 7, 2020 at 6:07 PM Kevin Ushey <kevinushey at gmail.com> wrote: >> >> Regardless, I would like to thank R core, CRAN, and Jeroen for all of >> the time that has gone into creating and validating this new >> toolchain. This is arduous work at an especially arduous time, so I'd >> like to voice my appreciation for all the time

Jeroen, Sorry, I was unclear. I'm not arguing against switching tot the new windows tool chain. Without being involved or knowing the details of any remaining difficulties, I am de facto for that. I was specifically responding to the prospect of R packages moving to directly rely on c++17 this quickly, which Kevin brought up. R itself obviously won't be relying on c++17 since there is

The FreeBSD Foundation is pleased to announce Ed Maste's new role as the Foundation's part-time Director of Project Development. Ed has served on the Foundation's board for two years, and has stepped down in order to accept this new position. In this position Ed will manage the Foundation's sponsored work, including projects funded under specific grants, operational support and

Hi Linus, These patches make it possible to inhibit the Xen emulated device unplug on the kernel command line (mostly "Just In Case") and renames xen_emul_unplug=ignore to the clearer xen_emul_unplug=unnecessary. Since it changes the name of a command line option we''d like to get it in before 2.6.36 proper. The third changeset is a pure cleanup which you could ignore for

Hello users, I have a problem when I save/restore a PVHVM guest. I installed xen-4.1.2 on my server. And I run a PVHVM guest on LVM. And my PVHVM guest is ubuntu-12.04.2-desktop. Actually when I save a machine, it acts fine. (Of course, when I saved it, There were some processes like movie player) But, When I restore it, It seems more slow. Additionally, machine finally die after a while. I

kernel use callback linked in panic_notifier_list to notice others when panic happens. NORET_TYPE void panic(const char * fmt, ...){ ... atomic_notifier_call_chain(&panic_notifier_list, 0, buf); } When xen aware this, it will call xen_reboot(SHUTDOWN_crash) to send out an event with reason code - SHUTDOWN_crash. xen_panic_handler_init() is defined to register on panic_notifier_list but

kernel use callback linked in panic_notifier_list to notice others when panic happens. NORET_TYPE void panic(const char * fmt, ...){ ... atomic_notifier_call_chain(&panic_notifier_list, 0, buf); } When xen aware this, it will call xen_reboot(SHUTDOWN_crash) to send out an event with reason code - SHUTDOWN_crash. xen_panic_handler_init() is defined to register on panic_notifier_list but

kernel use callback linked in panic_notifier_list to notice others when panic happens. NORET_TYPE void panic(const char * fmt, ...){ ... atomic_notifier_call_chain(&panic_notifier_list, 0, buf); } When xen aware this, it will call xen_reboot(SHUTDOWN_crash) to send out an event with reason code - SHUTDOWN_crash. xen_panic_handler_init() is defined to register on panic_notifier_list but

Hello, I'm looking for an example configuration for a PVHVM domU that works with 4.3.1. The one at http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers causes 3 warnings and some errors: WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override" instead if you really want a non-default firmware WARNING: ignoring device_model directive. WARNING: Use

Checked out the latest unstable version of Xen 4.4 but failed to create a PVHVM domU Configured Xen with ./configure --prefix=/usr DomU config file: name = "pvhvm" builder=''hvm'' device_model = ''qemu-xen'' memory = ''512'' vcpus = ''4'' pae=1 acpi=1 apic=1 vif = [ ''mac=00:16:3E:51:20:8C, bridge=xenbr0,

Hello, While testing Fedora 16 Xen PVHVM guests I noticed the following problem: When starting F16 PVHVM guest I can see the vifX.0 and tapX.0 interfaces appear on dom0, but after the guest kernel (Linux 3.1.0) starts and loads PVHVM drivers the vif/tap interfaces disappear from dom0.. so the bridge in dom0 doesn''t have any vifs/taps connected to it anymore. Has anyone seen that

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c index 492ade8..d99346e 100644 --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c @@ -374,7 +374,7 @@ int __init pci_xen_init(void) int __init pci_xen_hvm_init(void) { - if (!xen_feature(XENFEAT_hvm_pirqs)) + if (!xen_have_vector_callback ||

Hi List, I'm trying to work out the balloon driver on CentOS6 HVM but it seems to be not working with default 2.6.32 or newer 3.4 kernel. Does balloon driver work on HVM linux guests with Linux Kernel 3.4 from centos repo ? PV is fine and is able to balloon. My host is Xen 4.1.2 with dom0 as 3.4.46-8.el6.centos.alt.x86_64 My guest is CentOS6.4 with kernel 3.4.46-8.el6.centos.alt.x86_64