similar to: Problem about RLock when starting VMs in parallel

Hi all I get problem here when I try resume a vm. I do this: xm new VM xm start VM xm suspend VM Everything normal. No errors. But when I try resume the VM: xm resume VM I get this error: [2010-05-06 12:29:59 2040] ERROR (XendCheckpoint:357) /usr/lib/xen/bin/xc_restore 28 2 3 4 1 1 1 0 failed Traceback (most recent call last): File

Hi all I get problem here when I try resume a vm. I do this: xm new VM xm start VM xm suspend VM Everything normal. No errors. But when I try resume the VM: xm resume VM I get this error: [2010-05-06 12:29:59 2040] ERROR (XendCheckpoint:357) /usr/lib/xen/bin/xc_restore 28 2 3 4 1 1 1 0 failed Traceback (most recent call last): File

I am seeing a strange issue while running Mini-OS on the changeset 9906:a95e677073c1. This is on both i386 and x86_64. The only difference being on i386 if I stop printing to the console, this issue is not manifested. But with x86_64 it happens all the time. Bringing up Mini-OS for the first time causes xm to hang on certain commands like "list, destroy". Other commands like

Hi, I cannot boot Windows XP domU on SXCE104 dom0. It was running for weeks.. Is it a known bug? # virsh start wxpp01 & # virsh dumpxml wxpp01 <domain type=''xen'' id=''-1''> <name>wxpp01</name> <uuid>fb96e8c9-940d-7e0a-12ef-f167a7f1102c</uuid> <os> <type>hvm</type>

Hi all, I installed 2009.06, xVM and happily installed a domU with no issues. I just did this through the virt-manager GUI, and kept it as simple as possible. Later I installed and booted a zone with very simple and standard configuration. My existing xVM virtual machine did not immediately stop working, or have any interruption at all. But, I can no longer create new virtual machines, or even

I was trying to install a guest OS with the following command. $ virt-install -r 1024 --accelerate -n ubuntu-first-test -f /var/lib/libvirt/images/guest.img --cdrom /root/ubuntu-12.04-desktop-i386.iso --hvm and it says the following. Starting install... ERROR POST operation failed: xend_post: error from xen daemon: <Fault 3: ''ubuntu-first-test''> Domain installation

Lockdep report [1] correctly identifies a potential deadlock between nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due to inverted lock order of event->lock with drm core's dev->vblank_time_lock. Fix vblank event deadlock by converting event handler list to RCU. List updates remain serialized by event->lock. List traversal & handler execution is lockless which

On Wed, Jul 28, 2010 at 01:42:03AM -0400, Valdis.Kletnieks at vt.edu wrote: > On Tue, 27 Jul 2010 14:56:50 PDT, akpm at linux-foundation.org said: > > The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to > > > > http://userweb.kernel.org/~akpm/mmotm/ > > Hit this while the X server was on its way down during a 'shutdown -r now'. Worked fine

hi guys My OS is centos 5.4 uname -a : Linux localhost.localdomain 2.6.18-prep #1 SMP Mon Jul 12 20:03:46 CST 2010 x86_64 x86_64 x86_64 GNU/Linux and my xen version is 3.3.1, I install xen from souce code. The xen dom0 and xend is ok but I can''t use virt-install to install a domU. The error is below:

When I try to use stubdom-dm in lieu of qemu-dm, the guest domain crashes almost immediately if I specify an emulated NIC (''vif='') in the guest configuration file. If I don''t specify a vif, it works fine. If I use the same configuration with qemu-dm instead of sutbdom-dm, it works fine. Is there some reason QEMU emulated networking doesn''t work with stub domains

Hi, Virt-install is not working when I try to provision a vm today. Err is: -- Starting install... Retrieving file vmlinuz... | 1.9 MB 00:00 Retrieving file initrd.img... | 7.1 MB 00:00 Creating storage file... | 110 GB 00:00 ERROR POST operation failed:

Hi Patch "drm/nouveau: use drm_mm in preference to custom code doing the same thing" in nouveau tree introduced new deadlock possibility, for which lockdep complains loudly: [ 1541.070202] [drm] nouveau 0000:02:00.0: Allocating FIFO number 3 [ 1541.084772] [drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised FIFO 3 [ 2417.733440] [drm] nouveau 0000:02:00.0:

When xfstests 224 was running, the box was panic, and i got this message: [ 1998.327235] ============================================= [ 1998.329940] [ INFO: possible recursive locking detected ] [ 1998.329940] 2.6.39+ #3 [ 1998.329940] --------------------------------------------- [ 1998.329940] dd/25718 is trying to acquire lock: [ 1998.329940] (&(&eb->lock)->rlock){+.+...}, at:

On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote: > Hi All, > > We've had a report[1] of the virt_blk driver causing a lot of spew > because it's calling a sleeping function from an invalid context. The > backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. Hi Jens, pls see below - it looks like the call to blk_mq_end_io from IRQ context is

Hi All I have xen 4.0 in centos dom0 the machine was working fine for months and yesterday out of sudden I can no longer provision new vms and to make things worst If any vm shutdown I cannot re run it again . the vm stop at the process of detecting the (ubuntu and debian all versions) [!] Detect Disks "No disk drive was detected. If you know the name of the driver needed by your disk

Hi All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. The reporter is on CC and can give you relevant details. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1113805 [drm] Initialized bochs-drm 1.0.0 20130925 for

Hi All, We've had a report[1] of the virt_blk driver causing a lot of spew because it's calling a sleeping function from an invalid context. The backtrace is below. This is with kernel v3.16-rc2-69-gd91d66e88ea9. The reporter is on CC and can give you relevant details. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1113805 [drm] Initialized bochs-drm 1.0.0 20130925 for

Hi Keir, Attached patch gets rid of the global attr variable and adds support for NetBSD. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht

Pardon me for a long detailed post but this looks pretty serious. The bottom line is that, when I attempt to shut down or reboot my simple xen-2.0.7 server running FC3 with two domUs, shutting down xendomains appears to send python into an infinite loop. This may be due to a serious misconfiguration on my part but it is certainly a big problem. If we shutdown the domUs manually first, the