• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Non-Aliased Uncorrectable Patrol Data ECC?

S

snclawson

Limp Gawd
2FA
Joined
Mar 24, 2010
Messages
407
I recently swapped out the 2GB FB-DIMMs in my SuperMicro X7DWE with 4GB 2-rank modules and now when I start up FAH under linux, I get these messages on the console:

[ 424.980115] EDAC MC0: UE row 0, channel-a= 0 channel-b= 1 labels "-": NON-FATAL recoverable (Branch=0 DRAM-Bank=0 Buffer ID = 0 RDWR=Read RAS=0 CAS=0 NON-FATAL recoverable Err=0x800 (Non-Aliased Uncorrectable Patrol Data ECC))
[ 476.012101] EDAC MC0: UE row 0, channel-a= 0 channel-b= 1 labels "-": NON-FATAL recoverable (Branch=0 DRAM-Bank=0 Buffer ID = 0 RDWR=Read RAS=0 CAS=0 NON-FATAL recoverable Err=0x800 (Non-Aliased Uncorrectable Patrol Data ECC))
[ 514.044086] EDAC MC0: UE row 0, channel-a= 0 channel-b= 1 labels "-": NON-FATAL recoverable (Branch=0 DRAM-Bank=0 Buffer ID = 0 RDWR=Read RAS=0 CAS=0 NON-FATAL recoverable Err=0x800 (Non-Aliased Uncorrectable Patrol Data ECC))

I've swapped around the RAM in just about every combination of individual sticks and it's always the same `error,' so it doesn't seem like it's a particular one that's bad. I've got two other sets of memory and put them back in thinking that maybe I somehow messed up my board when I swapped the DIMMs, but I don't see it with either other set of DIMMs I've got (one set of 4 PC2-6400F 2GB dimms, and a set of 2 PC2-5300F 4GB 4-rank DIMMs).

Anyway, I was just wondering if anyone here has had any experience with this sort of thing? The error is a little confusing...a `NON-FATAL recoverable' error that's also an `Uncorrectable' error?

From my google searches it seems like the Linux EDAC driver is a little buggy/flaky and that most people get around this sort of thing by either unloading the edac module or turning off dynamic scrubbing? but maybe it's just that the FB-DIMMs aren't quite compatible with the board? Any pointers would be appreciated!

Thanks,

Steve
 
Well, it appears that the problem is that the SPD of the new memory is specifying a tRC of 19 and the X7DWE is running them at 18. =( The other 667MHz FB-DIMMs that I've got have a tRC of 20 and if I put in two of those and two of the new DIMMs everything is rock solid. It's times like these that it seems like just a teensy bit of a memory configuration setting in the BIOS would be nice...

So anyone know how to flash an FB-DIMM SPD? I've already tried SPDtool which is ancient enough not to work with the 5400 smbus and tear's linux tool (or the decode-dimms script from i2c-tools for that matter!) doesn't find any DIMMs.

Interestingly, turning off demand scrubbing in the BIOS doesn't seem to turn off patrol scrubbing, in that the `errors' keep coming with it turned off (although I never did check the chipset registers to make sure what the setting really was).
 
Last edited:
I'm fairly sure it's actually a damaged/weak cell in one of the DIMMs.

EDAC's output is unfortunately not very informative.
What distro are you running?

Can you run "dmesg" and see if there are add'l lines beyond the ones you pasted?
 
I'm running Ubuntu 12.04 LTS with kernel 3.2.0-38.

I stuck all the modules back in the system and I'm just seeing a mix of these two (about 1-5 in favor of the `Patrol Data ECC' message):

[ 45.848046] EDAC i5400 MC0: Non-Fatal misc error (Branch=1 Err=0x10000200 ((null)))
[ 53.852036] EDAC MC0: UE row 0, channel-a= 0 channel-b= 1 labels "-": NON-FATAL recoverable (Branch=0 DRAM-Bank=0 Buffer ID = 0 RDWR=Read RAS=0 CAS=0 NON-FATAL recoverable Err=0x10000800 (Non-Aliased Uncorrectable Patrol Data ECC))

Occasionally the high bit isn't set, with the Err code of just 0x800 or 0x200.

According to i5400_edac.c in the kernel, the bits correspond to:

EMASK_M29 = 1<<28, /* DIMM-Isolation Completed */
EMASK_M12 = 1<<11, /* Non-Aliased Uncorrectable Patrol Data ECC */
EMASK_M10 = 1<<9, /* Unsupported on i5400 */

That last one would explain the ((null)) in the error name for that one... The Intel 5400 MCH datasheet claims that M10 is `Non-Aliased Uncorrectable Mirrored Demand Data ECC,' but I certainly don't have Mirroring enabled, so I'm not sure what's going on there in either case.

The messages are the same no matter which DIMM I have installed, or if I've got four, two or just one of them in. As soon as I start hammering the memory bus with FAH or prime (torture test 3) I start seeing the kernel messages.

tRC made sense to me though, since in the past, at least for garden-variety DDR2, tRC was supposed to be (tRAS + tRP) or thereabouts, so with a tRAS of 15 and a tRP of 5, tRC should be 20? Granted, this is an FB-DIMM, so I'm not really sure how the timing values compare.

I'm up to trying something else if it would help!


Thanks!

Steve
 
Ok, but did these two messages come from console or output of "dmesg" ?

Console tends to only print messages that exceeded certain severity level so that's
why I'm inquiring :) -- dmesg often offers more verbose output.

To relay dmesg contents verbatim, I'd propose doing this:
Code: 
sudo apt-get install pastebinit
dmesg | pastebinit
and pasting resulting URL here.
 
The messages came out on the console and there wasn't anything else in dmesg that I could see, but when I go into work tomorrow I'll install pasebinit and post the link.

Thanks!
 
Here's the dmesg output: http://paste.ubuntu.com/5614206

On another note, I did find an older version of Thaiphoon Burner that would actually allow writes and was able to tweak the tRC value in the SPD to 20/240ns and even though Windows now shows the system running with those timings, I'm still seeing the same errors from Linux. So it does appear that was a red herring. I also tweaked the tWR from 3 to 6 with no change. Thaiphoon Burner did seem to think that the SPD checksum was bad, could that be causing problems?
 
Tossing "Non-Aliased Uncorrectable Patrol Data ECC" into Google reveals that this may be an issue with the edac module..

- run 'lsmod | grep -i edac'; should return something like 'i5000_edac' and 'edac_mc';
- run 'modprobe -r <modules>' where <modules> are the listed edac modules from the lsmod command
- once the modules have been removed from the kernel, edac should be disabled (for this boot)

I don't think the edac module really does anything useful anyways

Although I am surprised that this issue still exists in a 3.2 Kernel...
 
snclawson said:
Here's the dmesg output: http://paste.ubuntu.com/5614206

On another note, I did find an older version of Thaiphoon Burner that would actually allow writes and was able to tweak the tRC value in the SPD to 20/240ns and even though Windows now shows the system running with those timings, I'm still seeing the same errors from Linux. So it does appear that was a red herring. I also tweaked the tWR from 3 to 6 with no change. Thaiphoon Burner did seem to think that the SPD checksum was bad, could that be causing problems?
Click to expand...
Thank you, Sir.

Hmm, this output doesn't look too verbose to me. Errors are coming from the chipset
so, I would think, it's gotta have something to do with RAM. But then, there isn't
enough information to identify the DIMM [?]

Next, just like you said, it's recoverable but uncorrectable? WTF.
I suspect this could be either hardware (chipset itself) or software (EDAC) deficiency.

Looks to me like further investigation requires digging into chipset docs and all...
(ofc, you can always squelch EDAC, like extide suggests)

Not sure about TB's complaint about SPD checksum. From my experience, boards
typically skip DIMMs with SPDs with invalid checksums so... it would be weird if all
memory was detected despite bad checksum(s).
 
http://www.intel.com/content/dam/doc/datasheet/5400-chipset-memory-controller-hub-datasheet.pdf

I think it's buggy EDAC.

bit 11 indeed corresponds to "M12Err: Non-Aliased Uncorrectable Patrol Data ECC"
but in the error mask registers (EMASK_FB-DIMM, ERR0_FB-DIMM, ERR1_FB-DIMM,
ERR2_FB-DIMM, MCERR_FB-DIMM) not error status registers (FERR_NF_FB-DIMM,
NERR_NF_FB-DIMM) [sic!]

In error status registers, bit 11 is "M15Err: Memory or FB-DIMM configuration CRC read error"
which is quite interesting (given TB's CRC complaint).

I'd propose turning the EDAC off (unloading EDAC modules) and, if you feel like investigating,
periodically dumping contents of PCI device 16, function 1 registers registers (via /proc/bus/pci/...)
and performing manual analysis...

Oh, and, if you haven't already done so, make sure that Linux can see all the memory... just in case.
 
Linux has never had any problem seeing all of the RAM. The BIOS has always seen all the RAM too, which may be why Linux doesn't have a problem with it.

I did find this bug report from 2012 which had a fix that was not in my kernel:

https://lkml.org/lkml/2012/3/6/27

Applying the diff and compiling didn't change anything however. =(

The driver certainly does look like it's got a bug in the error reporting function in that the status bits are off by 3 from their positions in the mask register. So it does look like what I'm getting is a bunch of `Memory or FB-DIMM configuration CRC read error.'

I dumped the SPD and recalculated the checksum and reprogrammed them with the correct checksum, but I was still seeing M15Err. I just updated tRC and tWR again with a correct checksum and am testing that out now.
 
Hmm...nope. =( After that I started seeing the 0x200 error again (Memory Write error on first attempt?), which would make sense after tweaking tWR. =)

One more try... How about just tweaking tRC and fixing the checksum...

Huh. =( Well, this time I've just seen one ``Memory or FB-DIMM configuration CRC read error'' in the last 10 minutes. Much better. And certainly not anywhere near as scary as Patrol Read error!
 
For posterity, in the end I sent the RAM back and am waiting on a replacement set. While I don't necessarily mind turning off the EDAC module in this case, not knowing how they'll behave in another system (or really, what the problem is in this one!) makes me nervous about selling them to someone else in the future. (Oh, you're not going to run Linux are you? Oh. Well, just don't worry if there are some scary looking messages coming out on the console...)
 
You must log in or register to reply here.
Back
Top