similar to: Bug#810964: only partial EDAC information with Xen

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

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: 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

Package: src:xen Version: 4.17.0+46-gaaf74a532c-1 Severity: important Two major bugs have shown with the release of new hardware from AMD. Since the new hardware is likely to become common during the life of Debian/bookworm, you may wish to grab them early: ad15a0a8ca2515d8ac58edfc0bc1d3719219cb77 x86/time: prevent overflow with high frequency TSCs Turns out the latest generation is fast enough

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

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

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

found 988477 4.17.3+10-g091466ba55-1~deb12u1 severity 988477 critical quit Justification is same as original, data loss. I'm unsure about of the border between "data loss" and "serious data loss" is, but the original reportter declared it so and I don't disagree. On Sun, Aug 25, 2024 at 11:41:44PM +0200, Maximilian Engelhardt wrote: > I am changing the severity

Initially reported to debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810964), redirected here: With AMD Opteron 6xxx processors, half of the memory controllers are missing from /sys/devices/system/edac/mc Checked with single 6120 (dual memory controller) and twin 6344 (2x dual MC), other dual-module CPUs might be affected too. Booting plain Linux (3.2, 3.16, 4.1, 4.3), all memory

Am 21.01.16 um 17:41 schrieb Jan Beulich: >>>> On 20.01.16 at 16:01, <andreas.pflug at web.de> wrote: >> Initially reported to debian >> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810964), redirected here: >> >> With AMD Opteron 6xxx processors, half of the memory controllers are >> missing from /sys/devices/system/edac/mc >> Checked

>>> On 20.01.16 at 16:01, <andreas.pflug at web.de> wrote: > Initially reported to debian > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810964), redirected here: > > With AMD Opteron 6xxx processors, half of the memory controllers are > missing from /sys/devices/system/edac/mc > Checked with single 6120 (dual memory controller) and twin 6344 (2x dual >

>>> On 22.01.16 at 10:09, <pgadmin at pse-consulting.de> wrote: > When booting with Xen 4.4.1: > > 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. I wonder how valid his message is. We actually write this MSR with all ones during boot. However, considering involved functions

Hello, I upgraded to CentOS 5.1 and everything went smoothly (Thanks for the awesome work!). But after rebooting, I get the following error: EDAC MC: Ver: 2.0.1 Nov 30 2007 EDAC e7xxx: error reporting device not found:vendor 8086 device 0x2541 (broken BIOS?) I found http://edacbugs.buttersideup.com/show_bug.cgi?id=21 with google but no solution. Is it safe to ignore the error or remove

In order to support ZFS, we upgraded a backups server with a new, ECC motherboard. We're running CentOS 6 with ZFS on Linux, recently patched. Now, I want to enable EDAC so we can check for memory errors (and maybe PCI errors as well) but so far, repeatedly pounding on the Google hasn't yielded exactly what I need to do to enable EDAC. One howto was covering PCI and edac, but

Hi List, We had the following error thrown on console on a PowerEdge server running CentOS 5 (64 bit). Googling around didn't yield any particular insights. The server crashed a few minutes after this message. Running memtester, just to check, didn't find anything; and the box has been running for months before this without issue. I'm wondering if anyone has run across this

I've got a production system running CentOS 4 that was rock solid until I upgraded from 2.6.9-55 to 2.6.9-78.0.13 (now running 2.6.9-89.0.11). The system now crashes intermittently after a few weeks. I finally caught the panic message : EDAC MC0: INTERNAL ERROR: channel-b out of range (4 >= 4) Kernel panic - not syncing: MC0: Uncorrected Error Looking at the kernel changelog, I see that

After update from centos 6.6 to centos 6.7 and reboot it, I have get a lot of this error into /var/log/messages: > May??3 11:27:20 s-virt kernel: EDAC MC0: CE row 2, channel 1, label > "": (Branch=0 DRAM-Bank=2 RDWR=Read RAS=6093 CAS=896, CE Err=0x10000 > (Correctable Patrol Data ECC)) > May??3 11:27:21 s-virt kernel: EDAC MC0: CE row 2, channel 1, label > "":