similar to: [systemd-devel] udev virtio by-path naming

On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote: > On 01.03.2017 04:30, Zbigniew J?drzejewski-Szmek wrote: > > On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: > >>>>>> One could argue about back-level compatibility, but virtio by-path > >>>>>> naming has changed multiple times. We have seen

On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote: > On 01.03.2017 04:30, Zbigniew J?drzejewski-Szmek wrote: > > On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: > >>>>>> One could argue about back-level compatibility, but virtio by-path > >>>>>> naming has changed multiple times. We have seen

On 01.03.2017 16:58, Daniel P. Berrange wrote: > On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote: >> On 01.03.2017 04:30, Zbigniew J?drzejewski-Szmek wrote: >>> On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: >>>>>>>> One could argue about back-level compatibility, but virtio by-path >>>>>>>>

On Tue, Feb 28, 2017 at 08:39:07PM +0100, Lennart Poettering wrote: > On Tue, 28.02.17 19:28, Daniel P. Berrange (berrange at redhat.com) wrote: > > The problem with splitting these rules out into a separate project > > is that there's no other existing place that they would live. The > > "virtio people" as a group merely write specifications. The actual >

On Tue, Feb 28, 2017 at 08:39:07PM +0100, Lennart Poettering wrote: > On Tue, 28.02.17 19:28, Daniel P. Berrange (berrange at redhat.com) wrote: > > The problem with splitting these rules out into a separate project > > is that there's no other existing place that they would live. The > > "virtio people" as a group merely write specifications. The actual >

On Wed, Mar 01, 2017 at 07:28:46PM +0100, Viktor Mihajlovski wrote: > On 01.03.2017 16:58, Daniel P. Berrange wrote: > > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the > > guide above... > > > > looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': > > KERNEL=="vda" > >

On Wed, Mar 01, 2017 at 07:28:46PM +0100, Viktor Mihajlovski wrote: > On 01.03.2017 16:58, Daniel P. Berrange wrote: > > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the > > guide above... > > > > looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': > > KERNEL=="vda" > >

On 01.03.2017 04:30, Zbigniew J?drzejewski-Szmek wrote: > On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: >>>>>> One could argue about back-level compatibility, but virtio by-path >>>>>> naming has changed multiple times. We have seen virtio-pci-virtio<n> >>>>>> (not predictable), pci-<busid> and

Hi, I have a box with / and /home being subvolumes from the same btrfs filesystem. /etc/fstab: UUID=c0686... / btrfs subvol=root,x-systemd.device-timeout=0 1 1 UUID=c0686... /home btrfs subvol=home,x-systemd.device-timeout=0 1 1 ... / is initially mounted readonly by the initramfs, and then after switching to the real system, /home is attempted to be mounted in parallel with /

On 01.03.2017 19:44, Daniel P. Berrange wrote: [...] replying on the list, a bit lengthy > > Ok, my guest has 4 disks > > - sda - virtio-scsi, over virtio-pci transport > - sdb - virtio-scsi, over virtio-mmio transport > - vda - virtio-scsi, over virtio-pci transport > - vdb - virtio-scsi, over virtio-mmio transport > > with systemd 231 I get these links >

01.03.2017 06:43, Zbigniew J?drzejewski-Szmek ?????: > > We could keep an informal list of people who care about specific areas. MAINTAINERS file as part of systemd sources?

Hello, I'm using Fedora 7 and I thought I should try nouveau. I couldn't get direct rendering to work. I found out that the Mesa package that ships with Fedora 7 doesn't include a DRI interface for the nouveau module. So I fetched the latest Mesa source from git, compiled with 'mke DRI_DIRS=nouveau linux-dri-x86' and copied the produced ./lib/nouveau_dri.so in the

On Sat, Oct 14, 2017 at 01:41:14AM +0900, Tetsuo Handa wrote: > Michael S. Tsirkin wrote: > > On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote: > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > serialize against fill_balloon(). But in fill_balloon(), > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC |

On Sat, Oct 14, 2017 at 01:41:14AM +0900, Tetsuo Handa wrote: > Michael S. Tsirkin wrote: > > On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote: > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > serialize against fill_balloon(). But in fill_balloon(), > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC |

Tetsuo Handa wrote: > Michael S. Tsirkin wrote: > > > > > > > > The proper fix isn't that hard - just avoid allocations under lock. > > > > > > > > Patch posted, pls take a look. > > > > > > Your patch allocates pages in order to inflate the balloon, but > > > your patch will allow leak_balloon() to deflate the

Tetsuo Handa wrote: > Michael S. Tsirkin wrote: > > > > > > > > The proper fix isn't that hard - just avoid allocations under lock. > > > > > > > > Patch posted, pls take a look. > > > > > > Your patch allocates pages in order to inflate the balloon, but > > > your patch will allow leak_balloon() to deflate the

Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers at canonical.com> --- This is mostly just for testing, although it should be safe to apply to nouveau trunk. src/nouveau_dri2.c | 34 +++++++++++ src/nv_driver.c | 163 +++++++++++++++++++++++++++++++++++++++++++++++----- src/nv_type.h | 7 +++ 3 files changed, 191 insertions(+), 13 deletions(-) diff

https://bugs.freedesktop.org/show_bug.cgi?id=51798 Bug #: 51798 Summary: Cannot enable second video card on nvidia quadro NVS420 Classification: Unclassified Product: xorg Version: 7.7 (2011) Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority:

I need to start running a dual head on one of my machines. Eventual target is CentOS 5.x. Decided to test first on my 4.6 setup (eventually it will achieve 5.x). Both machines are fully up to date. The test machine is 4.6, 2 radeon video cards. Searched the web, CentOS site, even bugzilla. This bugzilla entry from a 4.2 system), http://bugs.centos.org/view.php?id=1875 had only a WFM response.

Hi! I just setup my ati radeon 9500 with fglrxconfig from the ati 3.7 drivers on a 2.6 kernel. I use primary a monitor and configured the x config file to use the tv as a second monitor which uses a different driver (graphic device section) due to different resolutions. All works pretty perfect, except for wine. No matter what i start in wine, my primary monitor blanks out while the tv keeps on