search for: num_devs

This deadlock comes from xfstests 251. We''ll hold the chunk_mutex throughout the whole of a chunk allocation. But if we find that we''ve used up system chunk space, we need to allocate a new system chunk, but this will lead to a recursion of chunk allocation and end up with a deadlock on chunk_mutex. So instead we need to allocate the system chunk first if we find we''re

....c Tue Jan 25 15:14:52 2011 +0000 +++ b/tools/libxl/libxl_pci.c Tue Jan 25 15:34:43 2011 +0000 @@ -268,7 +268,7 @@ static int libxl_create_pci_backend(libx for (i = 0; i < num; i++, pcidev++) libxl_create_pci_backend_device(gc, back, i, pcidev); - flexarray_vappend(back, "num_devs", libxl__sprintf(gc, "%d", num)); + flexarray_vappend(back, "num_devs", libxl__sprintf(gc, "%d", num), NULL); flexarray_vappend(front, "backend-id", libxl__sprintf(gc, "%d", 0), ________________________________...

...xampleDomain" frontend = "/local/domain/8/device/pci/0" uuid = "7f2dc1a1-d0de-ebf0-37fd-67ff0103c3c9" dev-1 = "0000:03:00.00" dev-0 = "0000:02:00.00" state = "4" online = "1" frontend-id = "8" num_devs = "2" root-0 = "0000:00" root_num = "1" -- best rgds, edwin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...msitranslate=%d,power_mgmt=%d", pcidev->msitranslate, pcidev->power_mgmt)); + flexarray_set(back, boffset++, libxl_sprintf(gc, "state-%d", i)); + flexarray_set(back, boffset++, libxl_sprintf(gc, "%d", 1)); } flexarray_set(back, boffset++, "num_devs"); - flexarray_set(back, boffset++, libxl_sprintf(ctx, "%d", num)); + flexarray_set(back, boffset++, libxl_sprintf(gc, "%d", num)); flexarray_set(front, foffset++, "backend-id"); - flexarray_set(front, foffset++, libxl_sprintf(ctx, "%d",...

Hi, compilation of xen-unstable with a fresh Ubuntu 11.10 x86_64 fails with following error: cc1: warnings being treated as errors libxl_create.c: In function ‘store_libxl_entry’: libxl_create.c:465: error: format not a string literal and no format arguments Steps to reproduce: - Install Ubuntu 11.10 ( http://www.ubuntu.com/start-download?distro=desktop&bits=64&release=latest) - sudo

..., r_log=...) > at llvm/invocation.cpp:710 > #23 0x00007ffff6b0a371 in clover::program::build (this=this at entry=0x23a0530, devs=..., opts=opts at entry=0x7ffff793dc0d "", headers=...) > at core/program.cpp:63 > #24 0x00007ffff6af31c4 in clBuildProgram (d_prog=0x23a0538, num_devs=0, d_devs=0x0, p_opts=<optimized out>, pfn_notify=0x0, user_data=0x0) > at api/program.cpp:182 > > Does this look related? If so, let me know what other information you need to > try to debug this issue. This could be related; I'm not sure. It looks like a leak detectio...

The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the C++ side of it. This was a rocky day, but I suppose that's what I get for failing to stage the change in smaller pieces. As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, so if I've missed some problem in the sea of buildbot errors, please flag me down. I'll follow up soon with

...llvm/invocation.cpp:710 >>> #23 0x00007ffff6b0a371 in clover::program::build (this=this at entry=0x23a0530, devs=..., opts=opts at entry=0x7ffff793dc0d "", headers=...) >>> at core/program.cpp:63 >>> #24 0x00007ffff6af31c4 in clBuildProgram (d_prog=0x23a0538, num_devs=0, d_devs=0x0, p_opts=<optimized out>, pfn_notify=0x0, user_data=0x0) >>> at api/program.cpp:182 >>> >>> Does this look related? If so, let me know what other information you need to >>> try to debug this issue. >> >> This could be related;...

Hi, I tried to attach passrough io device to domU, the command (ended successfully in dom0), but when I entered the domU and typed the "lspci" command I didn''t see the new device, although the dom0 removed it from the "pci-list-assignable-devices". When I tried to detach it from the domU, the detach command returned with timeout error. What did I miss? perhaps I

...gt; >>>> #23 0x00007ffff6b0a371 in clover::program::build (this=this at entry=0x23a0530, devs=..., opts=opts at entry=0x7ffff793dc0d "", headers=...) > >>>> at core/program.cpp:63 > >>>> #24 0x00007ffff6af31c4 in clBuildProgram (d_prog=0x23a0538, num_devs=0, d_devs=0x0, p_opts=<optimized out>, pfn_notify=0x0, user_data=0x0) > >>>> at api/program.cpp:182 > >>>> > >>>> Does this look related? If so, let me know what other information you need to > >>>> try to debug this issue. > &...

...gt;> #23 0x00007ffff6b0a371 in clover::program::build (this=this at entry=0x23a0530, devs=..., opts=opts at entry=0x7ffff793dc0d "", headers=...) >>>>>>> at core/program.cpp:63 >>>>>>> #24 0x00007ffff6af31c4 in clBuildProgram (d_prog=0x23a0538, num_devs=0, d_devs=0x0, p_opts=<optimized out>, pfn_notify=0x0, user_data=0x0) >>>>>>> at api/program.cpp:182 >>>>>>> >>>>>>> Does this look related? If so, let me know what other information you need to >>>>>>> try...

Hello all Xen devels, I''m writing howto''s in brazilian portuguese language about Xen-3.3.0 stubdom, pv-grub and others configurations. Following what is written in xen-3.3.0/stubdom/README, I tried start a HVM but without success. When I start the virtual machine calling ''xm create hvmtest'' command, in a few seconds the virtual machine is dead (see

...d'': ''e4b1c87e-663e-658c-b352-83fecb702ab9'', ''dev-0'': ''0000:11:0a.00'', ''state'': ''1'', ''online'': ''1'', ''frontend-id'': ''2'', ''num_devs'': ''1''} to /local/domain/0/backend/pci/2/0. [2009-05-04 09:46:50 2332] INFO (image:289) spawning device models: /usr/lib/xen-3.2-1/bin/qemu-dm [''/usr/lib/xen-3.2-1/bin/qemu-dm'', ''-d'', ''2'', ''-domain-name'...

An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs. Current updating device tree requires space from METADATA chunk, so we -may- need to do a recursive chunk allocation when adding/updating dev extent, that is where the deadlock comes from. If we use SYSTEM metadata to update device tree, we can avoid the recursive stuff. Reported-by: Jim Schutt

On Wed, 2024-10-02 at 14:54 +0200, Thomas Hellstr?m wrote: > On Wed, 2024-10-02 at 14:45 +0200, Christian K?nig wrote: > > Am 02.10.24 um 14:24 schrieb Thomas Hellstr?m: > > > The ttm_device_init funcition uses multiple bool arguments. That > > > means > > > readability in the caller becomes poor, and all callers need to > > > change if > > >

On Fri, Oct 04, 2024 at 04:28:29PM +0200, Thomas Hellstr?m wrote: > On Wed, 2024-10-02 at 14:54 +0200, Thomas Hellstr?m wrote: > > On Wed, 2024-10-02 at 14:45 +0200, Christian K?nig wrote: > > > Am 02.10.24 um 14:24 schrieb Thomas Hellstr?m: > > > > The ttm_device_init funcition uses multiple bool arguments. That > > > > means > > > >

Hi, The following patches add support for ext4 and btrfs to PV-GRUB. These patches are taken nearly verbatim from those provided by Fedora and Gentoo. We''ve been using these patches for the PV-GRUB images available in EC2 for some time now with no problems. Changes from v1: - Makefile has been changed to check the exit code from patch - The btrfs patch has been rebased to apply

Hello, I have been working on VGA-passthrough in the last month. When Xen was at his version 3.5 there was a few patches to make this work for some graphic cards using the patches developed by Han Weidong and posted here (http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01176.html) and the same patches posted file by file are here

Hello, I have been working on VGA-passthrough in the last month. When Xen was at his version 3.5 there was a few patches to make this work for some graphic cards using the patches developed by Han Weidong and posted here (http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01176.html) and the same patches posted file by file are here

...#39;40'', ''vdevfn-0'': ''10'', ''vdevfn-1'': ''28'', ''vdevfn-2'': ''30'', ''vdevfn-3'': ''38'', ''frontend-id'': ''3'', ''num_devs'': ''5''} to /local/domain/0/backend/pci/3/0. [2011-05-24 16:02:05 2335] DEBUG (pciif:169) Reconfiguring PCI device 0000:00:02.0. [2011-05-24 16:02:05 2335] DEBUG (pciif:320) pci: enabling ioport 0xf160/0x8 [2011-05-24 16:02:05 2335] DEBUG (pciif:334) pci: enabling iomem 0xf...