similar to: Stability issues since moving to 4.6 - Kernel paging request bug + VM left in null state

On 11/07/2017 03:12 PM, Nathan March wrote: > Since moving from 4.4 to 4.6, I've been seeing an increasing number of > stability issues on our hypervisors. I'm not clear if there's a singular > root cause here, or if I'm dealing with multiple bugs. > > > > One of the more common ones I've seen, is a VM on shutdown will remain in > the null state and

I just tried to setup another domain on a server running 1 domain. When i try to start the domain it gives me an error Error: Device 0 (vif) could not be connected. Backend device not found. The entry in my xen config file for the disks is disk = [''phy:/dev/xen001/xen2-fun,sda1,w'',''phy:/dev/xen001/xen2-fun-swap,sda2,w''] Looking at /var/log/xend.log, i found

Hello from a neophyte! Is there a diagnostic programme which can be run to determine if there are any faults in Samba 2.2.3a? I cannot connect from Win XP to my rev/b iMac (suddenly, maybe 'upgrade' to 10.3.4 had some effect) and the smb crashlog (shown below) has a pile of stuff which is incomprehensible to me. Secondly, how does one upgrade to another version of Samba and is this

I really need to share a filesystem and I''d rather not have to export it from one domU to another so I tried mounting it with GFS2 and then OCFS2. Both caused the xenU kernel to oops just as the mount was attempted. I assumed that a FUSE-based solution would be a little less problematic (if only because it doesn''t require kernel patches) but it also caused an oops right when

From: Robin Murphy <robin.murphy at arm.com> This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50. There is apparently something amiss with the way the TTM code handles DMA buffers, which the above commit was attempting to work around for arm64 systems with non-coherent PCI. Unfortunately, this completely breaks systems *with* coherent PCI (which appear to be the majority).

This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50. There is apparently something amiss with the way the TTM code handles DMA buffers, which the above commit was attempting to work around for arm64 systems with non-coherent PCI. Unfortunately, this completely breaks systems *with* coherent PCI (which appear to be the majority). Booting a plain arm64 defconfig + CONFIG_DRM +

Hi, While trying out v4.8-rc2 on Juno r2 (arm64), I ran into the following crash when probing the nvidia graphics card attached to the PCIe slot. So I tried rc1 and got the same crash. The card probes without any errors on v4.7. Anybody familiear with the recent changes knows what might have led to the below crashlog? Thanks, Punit ------------->8------------- [ 2.996678] [drm]

On 06/06/16 08:11, Alexandre Courbot wrote: > From: Robin Murphy <robin.murphy at arm.com> > > This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50. > > There is apparently something amiss with the way the TTM code handles > DMA buffers, which the above commit was attempting to work around for > arm64 systems with non-coherent PCI. Unfortunately, this completely

Dear R users, I am running R 2.10.0 on OS X 10.5.8. I had been running 2.10 successfully for about a week (and have used previous R versions for 2+ years on the same computer) until 2 days ago it failed to start up for me. Now when I try to start R, the application tries to initiate for several minutes then crashes. Looking at the activity monitor, my memory usage goes from having about 1.6Gb

Dear R users, I am running R 2.10.0 on OS X 10.5.8. I had been running 2.10 successfully for about a week (and have used previous R versions for 2+ years on the same computer) until 2 days ago it failed to start up for me. Now when I try to start R, the application tries to initiate for several minutes then crashes. Looking at the activity monitor, my memory usage goes from having about 1.6Gb

The ALTERNATIVE() and ALTERNATIVE_2() macros are GNU assembler macros, which makes them quite inflexible for future changes. Convert them to preprocessor macros. Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> --- arch/x86/entry/entry_32.S | 12 +++--- arch/x86/entry/entry_64.S | 10 ++--- arch/x86/entry/entry_64_compat.S | 8 ++--

hi folks, after long trying i need some help from the big world :-) question ******** when I boot a guest system, tried debian 6.0.2 amd64 firmware, I get errors like: 1) after click install on debian 6.0.2 installer [0.642450] vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632 [0.642911] vbd vbd-5632: failed to write error node for device/vbd/5632 (19 xenbus_dev_probe on device/vbd/5632) 2)

hi folks, after long trying i need some help from the big world :-) question ******** when I boot a guest system, tried debian 6.0.2 amd64 firmware, I get errors like: 1) after click install on debian 6.0.2 installer [0.642450] vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632 [0.642911] vbd vbd-5632: failed to write error node for device/vbd/5632 (19 xenbus_dev_probe on device/vbd/5632) 2)

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

Hey folks, Here's a new spin of the pvops64 patch series. We didn't get that many comments from the last time, so it should be probably almost ready to get in. Heya! >From the last version, the most notable changes are: * consolidation of system.h, merging jeremy's comments about ordering concerns * consolidation of smp functions that goes through smp_ops. They're sharing

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c