similar to: Bug#810964: [Xen-devel] [BUG] EDAC infomation partially missing

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

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

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

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

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

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

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

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

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

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

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

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

Hi All, We have installed CentOS 5.3 x86_64 in an HP DL585 server with AMD Opteron 64 bit processor and 16 GB RAM. The kernel version is 2.6.18-128.el5 . Now this has thrown an error message in /var/log/message, Jul 3 21:41:11 db1 kernel: EDAC k8 MC0: general bus error: participating processor(local node origin), time-out(no timeout) memory transaction type(generic read), mem or i/o(mem

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

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

My three basement machines got upgraded to 2.6.9-34.EL by nightly yum cron job. The two i686 seem to be fine. However, on the old i586 machine I got hole bunch of warnings. Haven't attempted rebooting it with new kernel yet. The warnings are: WARNING: /lib/modules/2.6.9-34.EL/kernel/drivers/edac/amd76x_edac.ko needs unknown symbol edac_mc_del_mc WARNING:

What does the following EDAC problem means? The machine is a AMD 64bit box running Centos 5. It looks like some problems aroung AMD DRAM Memory controller. But what does it really mean b/c most of my AMD boxes has these messages in /var/log/messages. Please help. ... Aug 1 23:29:40 ccn128 kernel: EDAC MC: Ver: 2.0.1 Jun 12 2007 Aug 1 23:29:40 ccn128 kernel: EDAC MC0: Giving out device to

CentOS Errata and Bugfix Advisory 2014:0768 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0768.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: f9238919a8e55753462b1690cc36a16b0a0c29260663dd5fe3e9ee0ae7a187c9 edac-utils-0.9-15.el6.i686.rpm