similar to: Bug#1032480: xen: Important cherry-picks for bookworm/updates

Initially out there as #965245. I strongly prefer to build ARM64 packages on non-ARM systems. Something about my main build machine having twice the cores and twice the clock speed. As such after many builds I've managed to generate a set of patches which appear to mostly function to get functioning cross-builds of Xen. These are NOT a 100% solution. Some packaging hacks were needed. In

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u3 Debian 8.2 installed on a supermicro H8SGL Board, AMD 6128 with 4x4GB ECC RAM. When booting the plain kernel (stock Jessie 3.16 or backport 4.1 or 4.3), both memory controllers (mc0 and mc1) appear under /sys/devices/system/edac/mc with two csrow* each as expected. Same happens, when booted with Xen 4.1.4-3+deb7u1. When booted with Xen

Fewer fork()s and execve()s quickly add up to significant savings. I'm concerned Debian is slowly headed towards recreating SunOS^WSolaris 5.7^W2.7^W7 and the layers and layers of scripts which killed performance. As these runtime scripts are heavily used, avoid all uses of external programs by them. Signed-off-by: Elliott Mitchell <ehem+debian at m5p.com> --- The gains from this

I haven't yet done as much experimentation as Andreas Pflug has, but I can confirm I'm also running into this bug with Xen 4.4.1. I've only tried Linux kernel 3.16.43, but as Dom0: EDAC MC: Ver: 3.0.0 AMD64 EDAC driver v3.4.0 EDAC amd64: DRAM ECC enabled. EDAC amd64: NB MCE bank disabled, set MSR 0x0000017b[4] on node 0 to enable. EDAC amd64: ECC disabled in the BIOS or no ECC

On Mon, May 15, 2017 at 02:02:53AM -0600, Jan Beulich wrote: > >>> On 14.05.17 at 00:36, <ehem+debian at m5p.com> wrote: > > I haven't yet done as much experimentation as Andreas Pflug has, but I > > can confirm I'm also running into this bug with Xen 4.4.1. > > > > I've only tried Linux kernel 3.16.43, but as Dom0: > > > > EDAC

Elliott Mitchell writes ("[PATCH 12/12] Partially revert "Cross-compilation fixes.""): > This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7. Wow, that is an upsteam commit from 2005. However, I would like some kind of explanation. Is it in fact now false that | # These don't cross-compile ? Should this patch go upstream ? Ian. -- Ian Jackson

Package: xen-utils-common Version: 3.0.3-0-2 Severity: wishlist The "xendomains" init script will start domains according to the order of config files found in /etc/xen/auto/*. I use this so that, in the event of a hard reboot, the more important domains will start first. Some of these contain essential services like DNS resolvers, slapd and so on, and since starting xen domains

Package: src:xen Version: 4.11.1-1 Currently, these are rdepends: -$ apt-cache rdepends libxenmisc4.11 libxenmisc4.11 Reverse Depends: libxen-dev xen-utils-4.11 collectd qemu-system-x86 libvirt-daemon collectd-core It's on the wishlist to start doing buster-backports for Xen. If the user has a cluster of servers and can make use of live migrate, then this allows the user to

Package: src:xen Version: 4.14.1+11-gb0b734a8b3-1 Severity: critical Justification: causes serious data loss X-Debbugs-Cc: debianbts at virtualzone.hu Dear Maintainer, after a clean install of bullseye/testing the xen dmesg shows the following message: (XEN) AMD-Vi: IO_PAGE_FAULT: 0000:01:00.1 d0 addr fffffffdf8000000 flags 0x8 I this is the sata device: 01:00.1 SATA controller: Advanced Micro

tags 988477 - moreinfo found 988477 4.17.2+76-ge1f9cb16e2-1~deb12u1 affects 988477 src:linux severity 988477 critical quit I am also observing #988477 occur. This machine has a AMD Zen 4 processor. The first observation was when motherboard/processor was swapped out, the older motherboard/processor was several generations old. The pattern which is emerging is Linux MD RAID1 plus recent AMD

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I read and find a way (well, there seems to be several equal implementations) to collect the ssh keys of machines. However they all give only the choice to choose between the key formats. But is there a way to collect both keys of a machine, the rsa _and_ the dss key (and maybe the rsa1 too)? I didn''t find a way to solve this as

I've copied vorbis@xiph on this message simply because it will be interesting there, but also to give those who haven't yet subscribed to the advocacy list a taste of the things that (should) happen there. As you know we are planning to sell vorbis shirts, both to promote the vorbis format and to raise some money for the Xiph.org Foundation. I have been talking to an online retailer

Hi Michael, Can you please cherry pick r195411 into release-3.4 to fix building on older OS X? Thanks, Jeremy commit e323506316cc3948bd801be537a723c308d8e2d4 Author: Michael Gottesman <mgottesman at apple.com> Date: Fri Nov 22 05:00:51 2013 +0000 [block-freq] Update data in test case to be unsigned long long to fix mingw build. git-svn-id:

On Tue, Jan 19, 2016 at 5:22 AM, Jiri Slaby <jslaby at suse.cz> wrote: > Hi, > > On 01/17/2016, 08:28 PM, Ilia Mirkin wrote: >> I'd like to recommend backporting this commit: >> >> commit 0a363e85cdafbceeee6a49b91c604d0d4d070dc7 >> Author: Hans de Goede <hdegoede at redhat.com> >> Date: Thu Jul 23 17:20:12 2015 +0200 >> >>

On Sun, Jan 17, 2016 at 02:28:13PM -0500, Ilia Mirkin wrote: > Hello, > > I'd like to recommend backporting this commit: > > commit 0a363e85cdafbceeee6a49b91c604d0d4d070dc7 > Author: Hans de Goede <hdegoede at redhat.com> > Date: Thu Jul 23 17:20:12 2015 +0200 > > drm/nouveau/nv46: Change mc subdev oclass from nv44 to nv4c It doesn't apply to

Hi, On 01/17/2016, 08:28 PM, Ilia Mirkin wrote: > I'd like to recommend backporting this commit: > > commit 0a363e85cdafbceeee6a49b91c604d0d4d070dc7 > Author: Hans de Goede <hdegoede at redhat.com> > Date: Thu Jul 23 17:20:12 2015 +0200 > > drm/nouveau/nv46: Change mc subdev oclass from nv44 to nv4c > > This disables MSI by default on G72 (NV46)

A colleague just came in and asked me about a problem he was having with stub_render, which reminded me of another issue he had a week or so ago, which seems related. Let me start with the earlier issue. He was trying to write specs for a method which sends the same message possibly multiple times, but with different arguments under different calling conditions. He wanted to write

Hello, I'd like to recommend backporting this commit: commit 0a363e85cdafbceeee6a49b91c604d0d4d070dc7 Author: Hans de Goede <hdegoede at redhat.com> Date: Thu Jul 23 17:20:12 2015 +0200 drm/nouveau/nv46: Change mc subdev oclass from nv44 to nv4c This disables MSI by default on G72 (NV46) devices where it's apparently a bit buggy. We have a later patch which turns MSI back

30.04.2023 11:20, Rowland Penny via samba ?????: .. > There is a big problem with this, bookworm hasn't been released yet and as far as I can see, there isn't a bookworm-backports yet. > The only mention of Samba 4.18 that I can see in Debian is in experimental, a long way from any backports. No, there's no long way to bookworm-backports. I use experimental just because debian

Hi folks, I have been spending the better part of the day, trying to get time synchronization to a Samba AD DC (Debian Bookworm 12.1) to work. Debian Bookworm has recently replaced ntp with ntpsec, and time synchronization stopped working. I have logged the behavior, and Windows 10 clients first send a Windows 2000! compatible request, and ntpsec chokes on it, and does not respond. The