Difference between revisions of "Uninitialized ECC bits"

From EdacWiki
Jump to navigation Jump to search
(Created page with "== uninitialized ECC bits == On the ASUS P5BV motherboard when the bios is set to "quick boot" the ECC bits are left uninitialized. As almost all memory inside Linux should firs…")
 
Line 9: Line 9:
 
! manufacturer !! board !! bios version !! workaround
 
! manufacturer !! board !! bios version !! workaround
 
|-
 
|-
| ASUS || P5BV || 3.04 || disable quick boot
+
| ASUS || P5BV || 3.04 || disable quick boot
  +
|-
 
  +
| ASUS || [http://www.asus.com/Motherboards/AMD_AM3/M4A89TD_PROUSB3/ ASUS M4A89TD Series] || 2001 (2011-04-01) || disable quick boot
 
|}
 
|}

Revision as of 14:18, 10 August 2011

uninitialized ECC bits

On the ASUS P5BV motherboard when the bios is set to "quick boot" the ECC bits are left uninitialized. As almost all memory inside Linux should first be written before being used, simply starting to use the machine results in a few hundred messages and then as more and more memory has become used at least once, the messages drop away.

Is this a serious kernel-problem? Doesn't this say that the kernel uses memory that hasn't been initialized? On the one hand, yes. On the other hand no. Whether it happens in userspace or in kernel-space doesn't matter: It is a problem if memory is used uninitialized. However, when the kernel first writes to location 0x1000, the hardware will fetch 0x1000-0x1040 into the cache, (possibly excluding the just written locations 0x1000-0x1003). This might trigger the EDAC hardware on locations 0x1004 - 0x1040. (but as EDAC works on 8 bytes at a time, to write to 0x1000-0x1003 the hardware will even have to read 0x1000 - 0x1007 and replace 0x1000-0x1003. So unless a 64-bit write is done, the hardware will even have to read the location before the write initializes the ECC bits).

hardware table

manufacturer board bios version workaround
ASUS P5BV 3.04 disable quick boot
ASUS ASUS M4A89TD Series 2001 (2011-04-01) disable quick boot